Agent không cần thêm não trước

Muốn agent chạy production, đừng vội nâng model. Hãy kiểm tra lớp orchestration, quyền truy cập dữ liệu và guardrail trước đã.

“Agent của mình fail, chắc phải đổi sang model mới hơn.”

Câu này mình nghe nhiều đến mức muốn in ra dán cạnh màn hình. Không phải vì nó sai hoàn toàn. Model mạnh hơn đúng là giúp được vài ca. Nhưng trong hệ thống production, nhiều agent không hỏng vì thiếu IQ. Chúng hỏng vì không biết đi đâu, được phép đụng vào gì, khi nào phải dừng, và ai kiểm tra phần việc vừa làm.

Nói thẳng ra thì: nếu agent là một căn nhà, nhiều team đang mua nội thất xịn trong khi móng, khung kèo và giàn giáo vẫn dựng tạm.

LlamaIndex vừa đưa ra một tín hiệu khá đáng chú ý với Retrieval Harness: thay vì xem retrieval như bước tiền xử lý tĩnh kiểu “chunk → embed → index → retrieve”, họ đẩy nó gần hơn về dạng filesystem primitives — những thao tác truy cập dữ liệu giống cách một agent làm việc với file, thư mục, chỉ mục và trạng thái trong quá trình chạy. Đây không chỉ là chuyện RAG thêm một feature. Nó chạm vào câu hỏi lớn hơn: agent production cần data access động, có kiểm soát, chứ không chỉ cần context dài hơn.

Sơ đồ tóm tắt ý chính của bài viết.

Điều đang bị hiểu sai: agent fail vì model chưa đủ mạnh

Niềm tin phổ biến nghe rất hợp lý: agent càng thông minh thì càng tự xử lý được nhiều bước. Nếu nó code sai, chọn model coding tốt hơn. Nếu nó đọc tài liệu sai, chọn model context dài hơn. Nếu nó lập kế hoạch kém, chọn model reasoning mới hơn.

Vấn đề là production không vận hành bằng niềm tin “nó sẽ tự hiểu”. Production vận hành bằng quyền hạn, trạng thái, log, kiểm chứng và rollback.

Trong RAG truyền thống, dữ liệu thường được chuẩn bị trước: chia nhỏ tài liệu, tạo embedding, đưa vào index, rồi lúc hỏi thì retrieve vài đoạn liên quan. Cách này ổn cho hỏi-đáp cơ bản. Nhưng agent doanh nghiệp lại khác: nó không chỉ hỏi “điều khoản này nằm ở đâu?”, mà có thể cần đọc nhiều file, so sánh phiên bản, mở rộng truy vấn, kiểm tra kết quả trung gian, rồi quyết định bước tiếp theo.

Ở đây, Retrieval Harness đáng chú ý vì nó thừa nhận một sự thật hơi khó chịu: data access của agent là một workflow đang sống, không phải một khối bê tông đổ xong từ đầu dự án.

Mổ lớp thứ nhất: retrieval không còn là cái hộp đen

Với builder, điểm cần nhìn không phải là tên sản phẩm, mà là sự dịch chuyển kiến trúc.

Trước đây, nhiều hệ thống làm như sau:

User question
  -> retrieve top-k chunks
  -> stuff vào prompt
  -> model trả lời

Luồng này có một ưu điểm lớn: đơn giản. Nhưng khi agent làm việc dài hơi, nó bắt đầu lộ nứt:

• top-k quá ít thì thiếu ngữ cảnh.
• top-k quá nhiều thì context window — vùng ngữ cảnh model còn giữ được — bị nhồi căng.
• tài liệu có bảng, sơ đồ, phụ lục, bản scan thì chunk đẹp trên giấy nhưng sai khi dùng thật.
• agent không có cách “đi lại” trong kho dữ liệu ngoài việc hỏi retrieval thêm lần nữa.

Retrieval Harness gợi ý một hướng khác: cho agent các primitive gần với filesystem hơn. Hiểu nôm na: thay vì đưa cho agent một xấp giấy đã cắt sẵn, bạn cho nó một căn phòng hồ sơ có kệ, nhãn, đường đi và quy định mở tủ.

Ví dụ cụ thể: team bạn xây agent đọc hợp đồng. Nếu chỉ retrieve vài đoạn theo câu hỏi “điều khoản chấm dứt hợp đồng là gì?”, agent có thể bỏ qua phụ lục sửa đổi. Nhưng nếu agent có primitive để liệt kê tài liệu liên quan, mở file, tìm phần phụ lục, kiểm tra phiên bản và ghi lại path đã đọc, bạn có cơ hội audit đường đi của nó. Khi sai, bạn biết nó sai vì không thấy file, đọc nhầm section, hay suy luận quá tay.

Đó là khác biệt giữa “model trả lời hay” và “hệ thống có thể điều tra được”.

Mổ lớp thứ hai: orchestration là bản vẽ thi công

Orchestration — lớp điều phối nhiều bước, tool và agent — thường bị xem như phần plumbing nhàm chán. Nhưng với agent, nó là bản vẽ thi công. Không có bản vẽ, thợ giỏi cũng có thể xây lệch tầng.

Mình thích tách hệ thống agent production thành 3 mặt phẳng:

1. Access plane: agent được chạm vào dữ liệu nào?

Đây là nơi bạn định nghĩa primitive truy cập: list, read, search, diff, inspect metadata, query index. Với tài liệu doanh nghiệp, phần này phải trả lời được:

• agent có được đọc toàn bộ kho không?
• có phân quyền theo user/session không?
• dữ liệu nào chỉ được đọc, dữ liệu nào được ghi?
• mỗi lần truy cập có log đủ để truy vết không?

Nếu không có access plane rõ, bạn sẽ gặp kiểu lỗi rất đau: agent trả lời đúng về mặt ngôn ngữ nhưng dùng nhầm tài liệu, nhầm version, hoặc lộ phần không nên lộ.

2. Decision plane: ai quyết định bước tiếp theo?

Đây là nơi bạn xác định agent tự quyết bao nhiêu. Nó có được gọi tool tùy ý không? Có cần planner riêng không? Có giới hạn số bước không? Có trạng thái trung gian không?

Nguồn từ Fireworks đưa ra một pattern đáng để soi: open-source worker + closed-source advisor. Worker mã nguồn mở chạy task end-to-end, còn advisor model mạnh hơn chỉ review một lần ở bước kiểm tra, ở chế độ read-only. Advisor không sửa file, chỉ đọc trajectory và diff rồi đưa nhận xét.

Điểm hay không nằm ở câu “rẻ hơn”. Điểm hay là quyền lực được tách vai: người làm có tay, người duyệt có mắt, nhưng không ai vừa làm vừa tự đóng dấu cuối cùng mà không để lại dấu vết.

3. Verification plane: hệ thống biết mình sai bằng cách nào?

Verification plane là lớp kiểm chứng: test, evaluator, policy check, human review, sandbox, replay. Với agent, kiểm chứng không nên chỉ là “model tự đánh giá câu trả lời”. Bạn cần kiểm tra hành động.

TechCrunch nhắc đến xu hướng dùng digital environments để stress-test agent trong các bản sao website hoặc hệ thống nội bộ. Không cần chạy theo mọi thuật ngữ mới, nhưng tín hiệu này đáng giữ: agent cần bị thử trong môi trường có tình huống, trạng thái và hậu quả, không chỉ trên benchmark một lượt.

Nếu agent của bạn sẽ thao tác CRM, hãy test nó trong CRM giả lập. Nếu nó sẽ đọc hợp đồng nhiều phiên bản, hãy tạo bộ case có phụ lục, scan lỗi, điều khoản mâu thuẫn. Nếu nó sẽ chạy command, hãy sandbox và log mọi lệnh.

Điều đáng giữ: filesystem mindset cho dữ liệu agent

Điểm mình muốn bạn mang về không phải “hãy dùng đúng tool X”. Tool sẽ đổi. API sẽ đổi. Release notes thì mình vẫn đọc, nhưng không bắt bạn thức cùng.

Điều đáng giữ là filesystem mindset: xem kho dữ liệu của agent như một không gian có cấu trúc, quyền truy cập, đường đi, trạng thái và lịch sử thao tác.

Khi áp dụng mindset này, thiết kế của bạn sẽ đổi:

• thay vì chỉ tối ưu top-k, bạn thiết kế hành trình đọc dữ liệu;
• thay vì chỉ log prompt/response, bạn log tool call và file path;
• thay vì chỉ hỏi “model có trả lời đúng không?”, bạn hỏi “nó đã dựa vào những vật chứng nào?”;
• thay vì nhồi context, bạn cho agent cách mở đúng ngăn hồ sơ khi cần.

Hình dung thế này: một agent pháp lý trả lời “có thể chấm dứt hợp đồng trong 30 ngày”. Câu trả lời nghe ổn. Nhưng production sẽ hỏi tiếp: nó lấy điều đó từ hợp đồng chính, phụ lục, email sửa đổi, hay template cũ? Nếu không trả lời được, bạn chưa có hệ thống đáng tin; bạn mới có một demo biết nói trôi chảy.

Điều nên bỏ qua: cuộc đua “agent tự trị hoàn toàn”

Có một kiểu demo rất dễ làm người ta phấn khích: agent tự đọc yêu cầu, tự mở tool, tự sửa, tự test, tự kết luận. Nhìn mượt. Nhưng trong team thật, tự trị không phải mục tiêu đầu tiên. Tự trị có kiểm soát mới là mục tiêu.

Với team Việt Nam đang build nội bộ, mình sẽ không bắt đầu bằng multi-agent phức tạp. Mình sẽ bắt đầu bằng một quyết định kiến trúc nhỏ hơn:

Task quan trọng
  -> worker agent làm trong sandbox
  -> retrieval primitives có log
  -> advisor/reviewer chỉ đọc và chấm
  -> policy gate quyết định có cho ghi ra hệ thống thật không

Trong một buổi chiều, bạn có thể thử bản mini như sau:

1. Chọn một workflow hẹp: ví dụ “đọc 5 file policy và trả lời câu hỏi compliance”.
2. Bắt mọi retrieval/tool call ghi log gồm: tool name, input, output summary, file/path, timestamp.
3. Thêm một bước reviewer read-only: model khác hoặc rule-based script kiểm tra câu trả lời có citation đúng không.
4. Tạo 10 case xấu: file trùng tên, version cũ, phụ lục mâu thuẫn, câu hỏi mơ hồ, tài liệu thiếu trang.
5. Chỉ cho phép output “final” nếu reviewer không phát hiện lỗi nghiêm trọng.

Đây không phải kiến trúc cuối cùng. Nhưng nó buộc team nhìn vào phần hay bị bỏ qua: agent đã đi đường nào để tới câu trả lời.

Cách nghĩ mới: đừng hỏi agent thông minh cỡ nào trước

Sau bài này, nếu có một câu hỏi mình muốn bạn đổi, thì là đổi từ:

“Model nào làm agent tốt nhất?”

sang:

“Hệ thống của mình có đủ primitive, guardrail và kiểm chứng để model làm việc an toàn chưa?”

Guardrail — lớp rào chắn hành vi — không phải vài dòng system prompt kiểu “hãy cẩn thận”. Nó là quyền đọc/ghi, sandbox, giới hạn bước, reviewer độc lập, log có thể replay, và test case đủ khó để làm agent vấp trước khi khách hàng làm nó vấp.

Model mới có thể nâng trần nhà. Nhưng nếu móng truy cập dữ liệu và khung điều phối còn yếu, nâng trần chỉ làm bạn thấy vết nứt rõ hơn.

Chốt gọn: agent production không cần thêm não trước; nó cần biết cửa nào được mở, sàn nào được bước, và ai kiểm tra bản vẽ trước khi đổ bê tông.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng