5 thành phần để xây “company harness” cho AI agent

Từ các agent nội bộ cho marketing, sales và kỹ thuật, LangChain nêu 5 thành phần của một “company harness”: nơi làm việc, danh tính, bộ nhớ có phạm vi, sandbox chạy code và các lượt chạy theo lịch hoặc sự kiện.

Một AI agent chỉ trả lời trong khung chat chưa đủ để trở thành công cụ làm việc xuyên phòng ban. Khi agent bắt đầu theo dõi lead, soạn nội dung, mở pull request hoặc tự chạy tác vụ định kỳ, doanh nghiệp cần một khung vận hành bao quanh nó.

LangChain gọi khung này là “company harness”. Từ các agent nội bộ phục vụ marketing, sales và kỹ thuật, công ty nêu ra năm thành phần lặp lại: agent phải ở đúng nơi nhân viên làm việc, có danh tính rõ ràng, bộ nhớ theo phạm vi, môi trường chạy code cô lập và khả năng chạy theo lịch hoặc sự kiện.

1. Agent cần sống ở nơi đội ngũ đang làm việc

Các agent nội bộ của LangChain chủ yếu hoạt động trong Slack. Mỗi agent có ứng dụng Slack riêng; người dùng có thể nhắn riêng hoặc gắn thẻ agent trong một kênh.

Theo LangChain, lợi ích của việc đặt agent trong kênh là mọi người có thể quan sát cách người khác sử dụng nó. Công ty cũng thêm cơ chế để agent tách sang một luồng riêng khi cần, tránh làm gián đoạn cuộc trò chuyện giữa người với người.

Tuy vậy, chat không phải giao diện phù hợp cho mọi tác vụ. LangChain lấy ví dụ về việc duyệt email: xử lý một email đơn lẻ qua Slack có thể ổn, nhưng theo dõi một danh sách email tồn đọng lớn lại cần giao diện chuyên biệt.

Điểm đáng chú ý: agent không nhất thiết phải thay thế toàn bộ phần mềm hiện có. Nó có thể bắt đầu từ nơi công việc vốn diễn ra, nhưng những tác vụ cần theo dõi hàng loạt có thể cần một UI riêng.

2. Danh tính quyết định agent hành động thay mặt ai

LangChain xem danh tính là một trong những vấn đề khó nhất khi xây agent đa người dùng. Khi agent thực hiện hành động, cần xác định rõ nó đang làm việc thay mặt người gọi hay dùng danh tính riêng của hệ thống.

Bài viết nêu hai cách phổ biến:

On-behalf-of: agent hành động thay mặt người dùng đã gọi nó. Fixed credentials: agent dùng một bộ thông tin xác thực cố định, chẳng hạn tài khoản dịch vụ.

Cách LangChain áp dụng khác nhau tùy agent và tác vụ:

OpenSWE mở pull request bằng tài khoản GitHub của người nhắn agent. Nhưng khi chạy nền để review code, nó dùng danh tính GitHub App riêng. GTM Agent dùng danh tính cố định cho một số công cụ như Salesforce. Với email, agent hành động thay mặt người dùng và công cụ này chỉ có trong tin nhắn riêng, không xuất hiện ở kênh chung. Content Studio có thể dùng danh tính người gọi với một số công cụ như Notion. Với tài khoản Twitter của công ty, agent dùng thông tin xác thực cố định; chỉ người dùng trong danh sách cho phép mới có thể gọi một số thao tác nhất định.

Đây là khác biệt quan trọng giữa việc “kết nối một API key vào AI” và vận hành agent trong doanh nghiệp: quyền truy cập không chỉ phụ thuộc vào công cụ, mà còn phụ thuộc vào người gọi và ngữ cảnh gọi.

3. Bộ nhớ phải được chia theo phạm vi

LangChain cho biết các agent của họ có hai tầng bộ nhớ:

Global memory: áp dụng cho mọi người dùng. User memory: chỉ áp dụng cho từng người dùng cụ thể.

Agent tự quyết định thông tin nào nên được ghi nhớ ở tầng nào. LangChain cũng mô tả đây là mảng vẫn còn nhiều việc cần khám phá.

Cách phân tách này đặc biệt đáng lưu ý với các đội đang xây agent nội bộ. Không phải mọi thông tin agent học được trong một cuộc trao đổi đều nên trở thành kiến thức chung cho toàn công ty. Một số dữ kiện chỉ phù hợp với ngữ cảnh của một người dùng, trong khi một số khác có thể áp dụng rộng hơn.

4. Code cần chạy trong sandbox

Cả ba agent chính của LangChain đều có thể viết và thực thi code để hoàn thành công việc. Kiến trúc được mô tả là agent chạy bên ngoài sandbox, sau đó kết nối vào sandbox để thực thi code bên trong.

Mỗi agent có base image và dependency riêng. Với OpenSWE, LangChain cho biết agent có thể chọn base image khác nhau tùy theo kênh hoặc người dùng.

LangChain sử dụng secret proxy trong LangSmith Sandboxes để agent kết nối tới các dịch vụ cần xác thực từ bên trong sandbox. Mục tiêu là cho phép agent thực hiện công việc với dịch vụ có quyền truy cập, trong khi phần chạy code vẫn nằm trong môi trường cô lập.

Với người xây AI agent, đây là một ranh giới kiến trúc đáng quan tâm: năng lực viết code và năng lực chạy code là hai việc khác nhau. Khi agent cần thực thi, môi trường chạy và cách kết nối tới dịch vụ xác thực trở thành phần cốt lõi của hệ thống.

5. Nhiều lượt chạy diễn ra ở nền, không phải từ câu lệnh trực tiếp

Theo LangChain, một tỷ lệ lớn lượt chạy của các agent diễn ra theo lịch hoặc được kích hoạt bởi sự kiện, thay vì do người dùng trực tiếp yêu cầu.

Có hai nguồn thiết lập các lượt chạy này:

Nhà phát triển agent cấu hình sẵn. Ví dụ, OpenSWE lắng nghe pull request mới và review khi có PR được tạo. Người dùng yêu cầu agent thiết lập. Ví dụ, GTM Agent có thể tạo cron để gửi daily brief sau khi được người dùng đề nghị.

Đây là điểm khiến agent trở thành một thành phần hoạt động liên tục trong quy trình, thay vì chỉ phản hồi từng câu hỏi đơn lẻ. Agent có thể theo dõi sự kiện, chạy đúng thời điểm và đưa kết quả trở lại môi trường làm việc chung.

Ba agent LangChain dùng để minh họa

LangChain mô tả ba agent nội bộ chính:

GTM Agent: agent chủ động hỗ trợ các hoạt động go-to-market; theo dõi và phản hồi email, xử lý lead đủ điều kiện, gửi brief hằng ngày, trả lời câu hỏi về account và hỗ trợ outbound. OpenSWE: agent kỹ thuật có thể làm việc và soạn pull request, đồng thời review code trên các pull request. Content Studio: agent marketing có thể tạo tài sản nội dung như blog, hình ảnh, PowerPoint và video theo phong cách cùng định vị của công ty.

Theo LangChain, cả ba đều được xây theo cùng một cách tiếp cận. Chúng chạy trên Managed Deep Agents, nền tảng nằm trên harness mã nguồn mở Deep Agents. Nền tảng này cung cấp hạ tầng cho các vấn đề như channels, crons, sandboxes, memory và identity, đồng thời vẫn cho phép tùy biến hành vi agent.

Một khung để nhìn lại agent trong doanh nghiệp

Năm thành phần LangChain nêu ra cho thấy trọng tâm khi đưa agent vào vận hành không chỉ nằm ở model hay prompt.

Câu hỏi quan trọng hơn là:

Agent xuất hiện ở đâu trong quy trình làm việc? Nó đang dùng danh tính nào khi hành động? Thông tin nào được nhớ cho tất cả mọi người, thông tin nào chỉ dành cho một người? Code được thực thi trong môi trường nào? Agent chỉ phản hồi khi được gọi, hay còn làm việc theo lịch và sự kiện?

Đó là khoảng cách giữa một chatbot hữu ích và một agent có thể tham gia vào công việc thường nhật của nhiều đội ngũ.