Trợ lý AI chạy cục bộ có thể chẩn đoán sự cố mà không cần quyền trên cả mạng không?
Bản mã nguồn mở của Transit cho phép chọn mô hình cục bộ hoặc dịch vụ lưu trữ. Lệnh, thông tin xác thực và dữ liệu đi qua ranh giới vẫn quyết định phạm vi có thể điều tra an toàn.
Một chi nhánh báo điện thoại gọi đi được nhưng nhận cuộc gọi chập chờn. Nhóm mạng thấy thay đổi ở một giao diện, một sự kiện định tuyến và hàng loạt lần hết thời gian chờ. Trợ lý hữu ích có thể sắp xếp các quan sát và đề xuất lệnh chỉ đọc tiếp theo. Chọn mô hình chỉ là một phần. Người vận hành còn cần biết công cụ dùng thông tin xác thực nào, văn bản nào rời khỏi máy và mô hình có thể dẫn đến thay đổi hay không.
Transit là công cụ điều tra mạng đã đưa ứng dụng khách vào dự án mã nguồn mở Apache 2.0 ngày 21 tháng 10 năm 2026. Trang chuyển đổi đặt ngày 5 tháng 11 làm mốc kết thúc quyền truy cập theo năm và ngày 17 tháng 11 là thời điểm dự kiến thay đổi dịch vụ AI lưu trữ. Những ngày đó nói về chuyển đổi mô hình kinh doanh. Phần mềm có thể dùng và trạng thái một tài khoản lưu trữ cụ thể là hai việc riêng. Hãy xem bản phát hành, README và tài liệu tính năng để biết chính xác phiên bản nhóm định thử.
Cục bộ có nghĩa gì trong một cuộc điều tra?
Chọn điểm cuối mô hình. Minh họa do Telli.sh thực hiện.
Ứng dụng khách có thể dùng Ollama hoặc một điểm cuối tương thích OpenAI. Tài liệu cũng mô tả dùng khóa OpenAI hoặc Anthropic của mình và đăng nhập thử nghiệm với tài khoản ChatGPT Plus hoặc Pro đủ điều kiện. Trỏ Transit đến máy chủ Ollama trên cùng máy có thể giữ phần suy luận tại máy đó. Trỏ đến điểm cuối công ty sẽ gửi dữ liệu đến địa chỉ đó. Chọn nhà cung cấp đám mây sẽ gửi yêu cầu tới nhà cung cấp, sau khi áp dụng cách che dữ liệu dự án mô tả.
Ứng dụng khách vẫn cần đến được thiết bị mạng để thu bằng chứng. Cuộc điều tra có thể đi qua máy trung chuyển, tài khoản người vận hành chỉ đọc và nhiều thiết bị. Điểm cuối mô hình cục bộ không giới hạn những thiết bị ứng dụng khách có thể liên hệ. Giới hạn nằm ở khả năng kết nối mạng và phạm vi quyền của thông tin xác thực.
Kho mã mô tả bộ công cụ giới hạn và danh sách lệnh được phép cho hãng được hỗ trợ. Tài liệu nêu chính sách duyệt lệnh, trong đó có thể tự động duyệt lệnh khớp quy tắc do người vận hành đặt trên hệ thống được hỗ trợ. Che dữ liệu và lọc lệnh là hai lớp có thể kiểm thử. Hãy coi thông báo đầu phiên và nhật ký thiết bị là văn bản chưa đáng tin, nhất là khi có câu mệnh lệnh. Trợ lý có thể tóm tắt chúng mà không xem nội dung đó là quyền hạn.
| Ranh giới | Câu hỏi cho người vận hành | Bài kiểm tra hữu ích |
|---|---|---|
| Điểm cuối mô hình | Lời nhắc tổng hợp được gửi đi đâu? | Kiểm tra địa chỉ đích với một ca giả |
| Quyền đến thiết bị | Công cụ có thể đến thiết bị và tài khoản nào? | Thử máy nằm ngoài phạm vi trong phòng lab |
| Duyệt lệnh | Ai được duyệt hành động đề xuất? | Từ chối một lệnh và xác nhận thiết bị không chạy |
| Bằng chứng và nhật ký | Dữ liệu nào được giữ hoặc rời khỏi máy? | Dùng dấu mốc vô hại và kiểm tra phần xuất |

Bộ chuyển mạch và bảng đấu nối thuộc loại người vận hành điều tra. Ảnh bối cảnh của Dsimic, đã cắt và đổi kích thước, CC BY-SA 4.0. Nguồn ảnh · Giấy phép.
Hãy thử với sự cố đã biết
Điều tra mạng. Minh họa do Telli.sh thực hiện.
Dựng phòng lab nhỏ có lỗi định tuyến hoặc giao diện đã biết. Cấp cho công cụ tài khoản tối thiểu trên thiết bị đích và đặt thêm một máy không liên quan phải nằm ngoài tầm truy cập. Yêu cầu nêu giả thuyết và danh sách ngắn các quan sát có thể bác bỏ nó. Chạy một lệnh hiển thị được đề xuất sau khi xem lại. So đầu ra với cùng quan sát thu bằng tay.
Ở lượt hai, đưa triệu chứng mơ hồ. Dịch vụ chậm có thể phù hợp với nhiều đường mạng, còn lệnh thiết bị có thể lộ mã khách hàng ở môi trường thật. Chuỗi đánh dấu giả cho phép kiểm tra đầu ra được truyền, ghi hay giữ ở đâu. Tách kết nối lab khỏi máy trung chuyển sản xuất đến khi người vận hành hiểu mỗi chế độ để lộ gì.
Khi xuất kết quả, gắn lệnh, thời gian, danh tính thiết bị và đầu ra liên quan với giả thuyết mà chúng hỗ trợ. Người vận hành có thể đọc chuỗi bằng chứng thay vì nhớ câu nào đến từ bộ định tuyến và câu nào do mô hình viết.
Kiểm tra tính toàn vẹn của bản phát hành và giới hạn mô hình cục bộ
Transit nói các bản dựng phát hành chưa ký. Tệp SHA256SUMS của từng bản có thể giúp kiểm tra tệp tải về có khớp giá trị băm công bố không. Chỉ so khớp không xác thực được nhà phát hành. Nhóm cần tệp ký có thể cân nhắc dựng từ thẻ đã rà soát qua quy trình phân phối phần mềm của mình. Tài liệu cài đặt Windows cũng yêu cầu PowerShell 7.
Suy luận cục bộ có thể bớt phụ thuộc dịch vụ đám mây và hợp môi trường hạn chế chia sẻ dữ liệu. Mô hình nhỏ hơn có thể bỏ ngữ cảnh, hiểu sai đầu ra từ nhiều hãng hoặc chạy lâu hơn trên phần cứng sẵn có. Thử cùng ca đã biết với cấu hình cục bộ và dịch vụ lưu trữ đã duyệt nếu cả hai được phép. Đếm số giả thuyết đúng, lệnh thừa, nhầm thiết bị và tổng thời gian của người vận hành.
Lần đầu nên xem đây là công cụ thu bằng chứng có giới hạn, với tự động duyệt tắt và người vận hành xem từng lệnh. Nếu lab cho bằng chứng nhất quán và báo cáo giải trình được, câu hỏi tiếp theo là loại điều tra chỉ đọc nào có thể dùng quy trình đó trên hệ thống thật. Đó là quyết định cụ thể hơn cấp quyền mạng chung cho mô hình.
Cài một bản đã biết và ghi rõ giới hạn
Bản v6.5.11 sửa tên không khớp trong danh sách mã kiểm tra để mục nhập phù hợp tên tệp được GitHub chuẩn hóa. Chọn bản và nền tảng có chủ đích, kiểm tra mã công bố trước khi chạy trình cài. Đọc ghi chú phát hành và lấy tệp qua kho chính thức. Nếu tổ chức cài phần mềm đã duyệt từ danh mục quản lý, hãy theo quy trình đó. Giá trị băm khớp chưa phải quyền cài đặt.
README mô tả sáu công cụ điều tra. Số ít chỉ hữu ích khi người vận hành biết từng công cụ có thể đến đâu. Liệt kê điểm cuối mô hình, máy trung chuyển và một bộ chuyển mạch thử trước khi cấp thông tin xác thực. Ghi tài khoản nào mở mỗi kết nối. Nếu lập trình viên cấu hình máy chủ Ollama riêng, hãy kiểm tra địa chỉ ứng dụng thật sự dùng. Dịch vụ trên mạng văn phòng vẫn là địa chỉ bên ngoài nếu nhìn từ máy tính xách tay.
- Tạo ca lab có triệu chứng đã biết và tài khoản giới hạn trong thiết bị đích.
- Xác minh bản đã chọn và xem cấu hình điểm cuối, thông tin xác thực và lưu giữ.
- Hỏi trợ lý cần quan sát gì tiếp theo và quan sát đó có thể bác bỏ giả thuyết nào.
- Tắt tự động duyệt, từ chối một đề xuất và kiểm tra nhật ký thiết bị trước khi cho phép một lệnh an toàn khác.
- Đưa dấu mốc vô hại vào nhật ký mẫu. Kiểm tra ứng dụng có che chúng và chúng xuất hiện ở đâu trong hồ sơ cục bộ hoặc điểm cuối đã cấu hình.
- Xuất kết quả và để một người vận hành khác tái hiện chẩn đoán bằng hồ sơ.
Người dùng đổi nhà cung cấp nên chạy lại bài thử sau khi đổi cấu hình. Cùng một nút có thể tạo đường dữ liệu khác khi điểm cuối thay đổi. Người quan sát mạng trong lab được phép có thể xác minh các địa chỉ đích. Ảnh màn hình cài đặt chưa chứng minh địa chỉ nào nhận yêu cầu.
Phân biệt bộ chuyển mạch được hỗ trợ với shell thông thường
Mô hình mối đe dọa ở thẻ Transit mô tả chính sách lệnh cho hãng được hỗ trợ, có tùy chọn tự duyệt theo quy tắc phù hợp đã bật từ trước. Đợt thử có thể tắt tùy chọn đó và yêu cầu người vận hành xem mỗi đề xuất. Công cụ vẫn cần tài khoản thiết bị có quyền hẹp. Hộp thoại duyệt không thể biến tài khoản dịch vụ thành tài khoản đặc quyền tối thiểu.
Cùng tài liệu mô tả chính sách khác cho Linux và Unix nói chung. Đường này cảnh báo người vận hành, yêu cầu duyệt từng lệnh và không có quy tắc luôn cho phép. Chính sách lệnh bên dưới không giới hạn lệnh trên hệ thống loại này. Giữ nó ngoài lần thử chỉ đọc đầu tiên nếu tổ chức không thể tự thực thi phạm vi. Loại thiết bị và tài khoản đều là thành phần của thiết kế an toàn.
Ca lab thứ hai có thể kiểm tra lúc công cụ gặp đầu ra lạ. Lệnh có thể trả bộ đếm mô hình không nhận ra hoặc giao diện dự kiến có tên khác trên hai hãng. Phản hồi hữu ích trích quan sát gốc và xin một phép kiểm tra giúp phân biệt. Phản hồi yếu coi cách hiểu hợp lý như sự thật đã xác lập. Người vận hành có thể chấm cả hai mà không đưa thiết bị sản xuất vào.
Làm bản xuất đủ hữu ích để bàn giao ca
Chẩn đoán một dòng tiện cho người vừa điều tra. Bàn giao ca cần quan sát cuối đã xác nhận, điều đã loại, điều còn chưa rõ và phép kiểm tra tiếp theo không cần mở lại mọi phiên. Gắn tham chiếu bằng chứng cạnh mỗi khẳng định quan trọng. Nếu mô hình đổi chẩn đoán khi thấy dòng nhật ký mới, ghi lý do.
Phép so sánh tốt nhất bao gồm quy trình thủ công nhóm đang dùng. Ghi thời gian tìm quan sát hữu ích đầu, số đề xuất lệnh không liên quan và thời gian viết bàn giao. Mô hình cục bộ có thể mang lại lợi ích riêng tư rõ nếu làm được việc ở tốc độ chấp nhận được. Mô hình lưu trữ đã duyệt có thể thực tế hơn cho ca khó nếu chính sách dữ liệu cho phép. Giữ rõ đường kết nối và bằng chứng kết quả ở cả hai chế độ.
Theo dõi riêng từng đích dữ liệu
Hồ sơ cấu hình hữu ích liệt kê phần giao diện gửi, phần chuyển tới suy luận và phần lấy từ thiết bị. Nó giúp dễ rà soát khi đổi nhà cung cấp. Xem lưu giữ ở mỗi đích là thiết lập riêng. Xóa lịch sử phiên cục bộ không chứng minh điểm cuối đã xóa yêu cầu trước.
| Chế độ | Đích suy luận | Bước kiểm tra hữu ích |
|---|---|---|
| Ollama trên cùng máy trạm | Điểm cuối loopback | Xác nhận tiến trình kết nối đúng dịch vụ lắng nghe cục bộ |
| Máy chủ suy luận công ty | Địa chỉ nội bộ | Xác minh xác thực dịch vụ và lưu giữ lời nhắc |
| Nhà cung cấp lưu trữ | Điểm cuối nhà cung cấp được duyệt | Kiểm tra che dữ liệu và chính sách với bằng chứng giả |
| Đăng nhập thử nghiệm | Tài khoản đủ điều kiện | Xác minh đúng tài khoản và quyền quản trị có sẵn |
Bảng mô tả cấu hình thường gặp. Nhóm nên quan sát điểm cuối thật và cấu hình dịch vụ đã chọn. Quản trị viên có thể thấy cùng thương hiệu trong phần cài đặt dịch vụ lưu trữ và cổng riêng. Xác định đúng tên máy và đơn vị vận hành giúp kiểm toán luồng dữ liệu.
Dùng bằng chứng tổng hợp để thử che dữ liệu
Tạo nhật ký lab với địa chỉ IP giả, nhãn thiết bị tưởng tượng và dấu mốc trông giống mã khách hàng. Đánh dấu mục chính sách cần giữ, che hay bỏ. Thử cùng mẫu trong hai thao tác riêng, như tóm tắt hội thoại và xuất hồ sơ. Hệ thống có thể tạo hai đầu ra theo cách khác nhau. Kiểm tra từng kênh trước khi cho phép dữ liệu thật.
Phép thử thứ hai đặt dấu mốc trong mô tả dài hoặc đầu ra có định dạng. Quy tắc có thể che trường đã nhận ra mà bỏ sót cùng giá trị trong văn xuôi. Nếu kết quả vẫn lộ dấu mốc đến đích không được phép, đóng đường đó trước khi nối thiết bị sản xuất. Có thể thu nhỏ tập nguồn rồi thử lại để biết lớp bảo vệ nào thực sự có tác dụng.
Đánh giá lại sau nâng cấp
Sau khi cập nhật ứng dụng, ghi nhà cung cấp đã chọn và chạy lại cùng các ca lab. Thay đổi danh sách lệnh cho phép hay cách khớp tự động duyệt có thể đổi điều công cụ đề xuất. Đổi mặc định điểm cuối có thể đổi đích đến của bằng chứng. Xác minh cùng lúc một lệnh bị từ chối, một ca che dữ liệu và một chẩn đoán đúng đã biết. Bộ hồi quy nhỏ giúp vận hành công cụ mã nguồn mở khi môi trường của nhóm thay đổi.
Kiểm tra độc lập công cụ và tài khoản thiết bị
Công cụ đọc có thể trả siêu dữ liệu thiết bị hoặc bằng chứng đã có. Công cụ chạy lệnh có thể yêu cầu thiết bị cung cấp bằng chứng mới qua tài khoản đã kết nối. Vẫn nên tóm tắt được khi không thể thực thi. Thử rõ ranh giới bằng cách ngắt thiết bị nhưng giữ điểm cuối mô hình. Phản hồi cần phân biệt thông tin từ lần quan sát trước với quan sát mới không thể thu thập.
Sau đó kết nối bằng tài khoản xem được một bộ chuyển mạch nhưng không được vào chế độ cấu hình hoặc sang phân đoạn khác. Nhóm có thể thử đường từ chối trong lab của mình mà không yêu cầu trợ lý thay đổi thật. So hồ sơ hành động đề xuất trong ứng dụng với nhật ký đăng nhập và lệnh của chính thiết bị. Phép thử tách quyết định chính sách công cụ khỏi quyền tài khoản thực tế.
Nguồn
Để lưu các cuộc trao đổi và quyết định trong công việc theo cách có thể tìm lại, hãy tạo tài khoản Telli.sh.