Định danh tác nhân, thực thi đáng tin cậy và Ý định chỉ mới được giải quyết một nửa.
Sau vài tháng qua nghiên cứu hàng trăm tài liệu kỹ thuật từ n8n, Google, Gumloop và các nền tảng khác, tôi đã tổng hợp được 75 khả năng mà một công cụ phát triển agent được kỳ vọng sẽ cung cấp.
Nhưng còn rất nhiều thứ khác bạn có thể, cần hoặc nên làm với các agent mà không dễ dàng hoặc công bằng để đưa vào báo cáo, vì vậy tôi chia sẻ một số điều đó ở đây.
Các agent rõ ràng đang rơi vào khoảng trống giữa danh tính con người và phi con người, điều này gây vấn đề vì không có cách nào để theo dõi agent, hành động của chúng và chủ sở hữu. Nếu Agent X quyết định xóa dữ liệu hàng loạt, danh tính sẽ là thứ giúp bạn xác định nó sống ở đâu và ai đã tạo ra con quái vật đó.
Nhưng chưa ai giải quyết được vấn đề danh tính, và nếu họ tuyên bố đã làm được, thì đó là bằng cách áp dụng các kỹ thuật hiện có vào agent, điều này thực sự không hiệu quả (lưu ý rằng Xác thực đang ở vị trí tốt hơn Danh tính, nhưng xác thực chỉ là một phần của danh tính).
Giả sử bạn chạy agent trong n8n. Không có cách nào để định nghĩa chính thức danh tính của một agent sao cho bạn có thể gắn cho nó một thẻ tên, một số chính sách và giám sát hoạt động của nó trong môi trường rộng lớn hơn mà nó hoạt động. Bạn có thể tích hợp nó với các IdP hỗ trợ agent, nhưng vẫn phải tự mày mò kỹ thuật.
Tài liệu này mô tả chi tiết cách nó tích hợp một agent n8n vào Microsoft Entra Agent ID. Mặc dù nó nằm sau tường phí, nhưng nó cho biết bạn cần:
Lựa chọn tốt nhất để chạy native tính đến thời điểm hiện tại là sử dụng Google Gemini Enterprise Agent Platform, đây rõ ràng là lợi thế của danh mục hyperscaler. Agent Identity cung cấp một danh tính mật mã được xác thực mạnh mẽ cho mỗi agent dựa trên tiêu chuẩn SPIFFE. Với Agent Identity, các agent có thể xác thực an toàn với máy chủ MCP, tài nguyên đám mây, điểm cuối và các agent khác, hoạt động thay mặt cho chính nó hoặc thay mặt cho người dùng cuối. Agent Identity sử dụng thông tin xác thực riêng của agent và trình quản lý xác thực Agent Identity. Trình quản lý xác thực có thể tạo và quản lý các nhà cung cấp xác thực, là các cấu hình cụ thể được sử dụng để thu thập, quản lý và bảo mật khóa API, ID client OAuth, bí mật client OAuth và token OAuth ủy quyền của người dùng cuối.
Nhưng ngay cả cách tiếp cận của Google (một trong những cách tiên tiến nhất hiện tại) cũng có thể tìm thấy một số chỉ trích, như việc họ sử dụng SPIFFE. "Mặc dù SPIFFE về mặt kỹ thuật có thể cung cấp danh tính cho agent, nhưng các triển khai Kubernetes hiện tại coi tất cả các bản sao là giống hệt nhau—một sự không tương thích cơ bản với hành vi phi xác định, phụ thuộc vào ngữ cảnh của agent, tạo ra khoảng trống về tuân thủ và quy kết".
LLM tạo ra mã, agent thực thi nó. Và cũng giống như máy chủ bị trục trặc và bạn cần tắt rồi bật lại, agent cũng có thể trục trặc. Tất cả doanh nghiệp đều cảm nhận được nỗi đau này, nhưng tôi thấy rất ít hoặc không có cách tiếp cận có hệ thống (hoặc tôi dám nói là xác định) để đảm bảo agent thực thi đáng tin cậy. Có một số công cụ đang giải quyết vấn đề này, nhưng việc áp dụng còn chậm.
Thứ đơn giản nhất có thể thực thi mã agent là trình thông dịch Python. Bạn nên mong đợi một công cụ phát triển
Dưới đây là bản dịch tiếng Việt cho đoạn văn bạn cung cấp:
...công cụ để làm nhiều hơn Python thuần túy, cụ thể là:
Chúng tôi đã đề cập ngắn gọn về thực thi mã và sandbox trong báo cáo, vậy hãy xem xét hai khía cạnh còn lại:
**Độ bền thực thi Agent** - Agent có thể gặp giới hạn tốc độ từ nhà cung cấp LLM, hết thời gian chờ yêu cầu, hoặc agent tự lưu trữ có thể hết bộ nhớ.
Độ bền thực thi có thể giúp phục hồi sau các sự cố này bằng cách:
**Tính đồng thời** - Agent và môi trường lưu trữ bên dưới cạnh tranh bộ nhớ, CPU và các cuộc gọi mạng. Khi các agent chia sẻ cùng một cơ sở hạ tầng (tức là không có sự cô lập), một phiên tốn nhiều tài nguyên sẽ làm suy giảm mọi phiên khác. Quản lý đồng thời hiệu quả đòi hỏi thực thi hạn ngạch ở cấp kernel, lập lịch thời gian thực trên các khối lượng công việc không đồng nhất, và cơ chế phản áp lực ngăn các đợt gọi agent bùng nổ gây ra lỗi dây chuyền ở hạ nguồn.
Để hỗ trợ tính đồng thời ở lớp cơ sở hạ tầng, bạn có thể thực thi giới hạn tài nguyên mỗi phiên ở cấp kernel qua cgroups, duy trì trạng thái cụm thời gian thực cho các quyết định lập lịch, và cô lập các phiên qua ranh giới microVM hoặc gVisor để ngăn chặn sự can thiệp giữa các agent.
Ở lớp thực thi, bạn có thể thực thi giới hạn đồng thời trên thực thi quy trình làm việc và dung lượng worker, ngăn quá nhiều tác vụ agent chạy đồng thời chống lại một LLM hoặc API bên ngoài bị giới hạn tốc độ. Đây là phản áp lực ở cấp quy trình làm việc, không phải cô lập tài nguyên ở cấp tính toán.
Các kiểm soát đồng thời khác bao gồm hàng đợi công việc, chẳng hạn như giới hạn số lượng phiên bản của một bước hoặc hàm chạy song song. Điều này hữu ích để ngăn cạn kiệt giới hạn tốc độ LLM nhưng không giải quyết được sự tranh chấp tài nguyên cơ bản giữa các phiên.
LLM trôi dạt theo thiết kế, và chỉ nói "làm ơn đừng trôi dạt" hoặc khởi tạo một agent điều phối và yêu cầu nó "làm ơn đừng trôi dạt" sẽ không có tác dụng.
Bạn chắc chắn sẽ kết thúc với các agent không hoàn thành nhiệm vụ được giao, làm việc khác, báo cáo hoàn thành trên một công việc chưa hoàn chỉnh, hoặc chỉ đơn giản là ảo giác kết quả. Bạn cần giám sát sự trôi dạt hành vi để xác định xem logic của agent có còn phù hợp với phạm vi và yêu cầu của nó hay không. Điều này đòi hỏi liên tục quét các cuộc hội thoại và thực thi ở cấp mã để xem nó muốn gọi thư viện nào, các hàm được gọi thực sự sẽ đạt được gì, và LLM đang làm gì với hệ điều hành. Nó theo dõi trường lý luận trong phản hồi và trường gọi công cụ trong phản hồi để hiểu mọi ủy thác logic và lý do tại sao nó làm điều đó.
Và trong khi có rất nhiều công việc ở đây về bảo mật để ngăn chặn các cuộc tấn công tiêm nhiễm prompt và vấn đề deputy bị nhầm lẫn, thì có rất ít công việc để ngăn chặn sự trôi dạt không có chủ đích.
Bạn có thể chọn giữa phân tích ý định dựa trên LLM và không dựa trên LLM.
Phân tích dựa trên LLM dễ triển khai và đa năng. Nhược điểm là các bộ đánh giá LLM kế thừa các vấn đề tương tự mà chúng cố gắng giải quyết. Dù sao, một số trong số này bao gồm:
Phân tích ý định không dựa trên LLM khó triển khai hơn và đòi hỏi tư duy trước, một c...
Thách thức trong một xã hội lập trình theo phong cách "vibe-coding". Bao gồm:
Trong phiên bản thứ hai của báo cáo, chúng tôi đã đánh giá các công cụ dựa trên 75 khả năng, từ thực thi mã và môi trường sandbox đến xác thực và killswitch. Một số tính năng đã trở nên phổ biến rộng rãi, trong khi những tính năng khác là điểm khác biệt rõ rệt.
Người dùng n8n đến từ nhiều nền tảng, trình độ kinh nghiệm và sở thích khác nhau. Chúng tôi đang tìm cách giới thiệu những người dùng khác nhau và các dự án của họ trong các bài đăng trên blog. Nếu bạn đang làm việc với n8n và muốn truyền cảm hứng cho cộng đồng, hãy liên hệ với chúng tôi 💌
