Agent đáng tin bắt đầu từ đường ray

Agent đáng tin bắt đầu từ đường ray

Một playbook cho team build agent: thử nhỏ, đặt guardrail, đo failure mode, rồi mới scale. Đừng để demo đẹp kéo cả hệ thống vào rủi ro.

Có một kiểu demo làm mình hơi rén: agent mở file PDF trên S3, đọc điều khoản hợp đồng, gọi tool, nhớ session, rồi trả lời như một trợ lý pháp lý chăm chỉ. Cả phòng gật gù. Tech lead thì bắt đầu nhìn Jira như nhìn đống gỗ mới giao về xưởng: đẹp đấy, nhưng chưa biết đóng thành tủ có đứng vững không.

Vấn đề không nằm ở chuyện agent có làm được hay không. Làm được. Một MCP server đọc PDF từ Amazon S3 theo thời gian thực, một voice agent xử lý đặt lịch, một Nanobot-style agent trong Colab có tool calling và session memory — tất cả đều là vật liệu tốt.

Nhưng với production, câu hỏi đúng không phải là: “Agent này thông minh cỡ nào?”

Câu hỏi đúng là: “Khi nó sai, hệ thống có biết dừng đúng chỗ không?”

Nói thẳng ra thì: agent production không bắt đầu từ model. Nó bắt đầu từ orchestration — lớp điều phối nhiều bước/tool — và guardrail — rào chắn kỹ thuật để giới hạn hành vi.

Sơ đồ minh họa cho bài Agent đáng tin bắt đầu từ đường ray

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

Chốt mục tiêu: agent chỉ được đi trên đường ray đã đóng

Nếu team bạn đang xây agent cho nghiệp vụ thật, đừng bắt đầu bằng “cho nó nhiều tool nhất có thể”. Hãy bắt đầu bằng một workflow hẹp, có thể kiểm soát.

Ví dụ cụ thể: team pháp chế cần hỏi nhanh nội dung trong PDF hợp đồng nằm trên S3. Có hai hướng:

  1. Dùng một MCP server để trích text từ PDF text-based theo yêu cầu.
  2. Dùng Amazon Textract nếu tài liệu có scan, OCR, form, bảng biểu, layout phức tạp.
  3. Dùng batch pipeline nếu câu hỏi không cần trả lời ngay.

Điểm dễ nhầm: thấy “real-time PDF extraction” là muốn thay toàn bộ document processing. Không nên. Với PDF có text sẵn, extraction tương tác rất hợp để làm proof of concept hoặc internal assistant. Với tài liệu scan, bảng lộn xộn, biểu mẫu nhiều ô, Textract vẫn là lựa chọn hợp lý hơn.

Khung nghĩ mình muốn bạn mang về: chọn agent theo failure mode, không chọn theo độ mới của tool.

Trong xưởng mộc, không ai dùng cùng một cái đục cho mọi đường chạm. Agent cũng vậy: tool nào được cầm, cầm trong bối cảnh nào, và cầm đến đâu — đó mới là phần quyết định.

Checklist trước khi cho agent chạm dữ liệu thật

Trước khi viết dòng code orchestration đầu tiên, team nên trả lời được 7 câu này:

Điểm đáng chú ý từ góc MCP không chỉ là “agent gọi tool tiện hơn”. Một giá trị rất thực dụng là đẩy auth flow ra khỏi context của agent. Nếu agent không nhìn thấy token thô, không phải tự xử lý login, và chỉ nhận một tool contract rõ ràng, bạn đã giảm được một mảng rủi ro.

Đây là chỗ nhiều team hiểu sai: MCP không nhất thiết phải là lớp “thần kinh trung ương” của mọi thứ. Đôi khi MCP server chỉ cần là một auth gateway gọn gàng đứng trước API, vậy đã đủ đáng tiền.

Làm một buổi: dựng lát cắt hẹp, không dựng cung điện

Giả sử team bạn có một buổi chiều để thử agent đọc PDF từ S3. Đừng dựng full RAG, dashboard, multi-agent, memory dài hạn. Hãy làm một lát cắt đủ nhỏ để biết có nên đi tiếp không.

Bước 1: chọn một workflow có câu trả lời kiểm chứng được

Chọn task kiểu:

“Tìm điều khoản chấm dứt hợp đồng trong 20 file PDF text-based trên S3 và trả về đoạn trích liên quan.”

Không chọn task kiểu:

“Đánh giá rủi ro pháp lý toàn bộ hợp đồng.”

Task thứ hai có thể là mục tiêu dài hạn, nhưng không phù hợp cho vòng thử đầu. Nó mơ hồ, khó chấm, và dễ khiến agent trả lời trơn tru nhưng sai.

Bước 2: đóng khung tool contract

Tool contract là giao kèo giữa agent và công cụ. Với builder, nó nên cụ thể như bản vẽ trước khi cưa gỗ:

{
  "tool": "extract_pdf_text",
  "allowed_buckets": ["legal-docs-prod"],
  "allowed_prefixes": ["contracts/2026/"],
  "max_pages": 20,
  "returns": ["text", "file_key", "page_hint"],
  "mode": "read_only"
}

Đừng để agent tự quyết bucket, tự quét toàn bộ S3, hoặc tự “thử vài đường dẫn”. Với dữ liệu doanh nghiệp, quyền mơ hồ là lỗi thiết kế chứ không phải lỗi model.

Bước 3: bắt buộc trả lời kèm dấu vết

Với document agent, câu trả lời không có evidence thì chỉ là văn hay. Hãy yêu cầu output có cấu trúc:

{
  "answer": "...",
  "evidence": [
    {
      "file": "contracts/2026/vendor-a.pdf",
      "page_hint": 12,
      "quote": "Either party may terminate..."
    }
  ],
  "confidence_note": "Không thấy phụ lục đi kèm trong phạm vi file được cấp."
}

Confidence note ở đây không phải điểm số màu mè. Nó là chỗ agent nói rõ phần nào chưa chắc, thiếu dữ liệu gì, hoặc vì sao cần người kiểm tra.

Bước 4: log theo bước, không chỉ log câu trả lời cuối

Với agent, log cuối cùng thường quá muộn. Bạn cần log:

Nếu sau này có incident, bạn không muốn ngồi đoán “nó nghĩ gì”. Bạn muốn thấy từng nhát bào: chỗ nào phẳng, chỗ nào lẹm.

Guardrail tối thiểu: đừng đợi đến lúc có sự cố mới gắn

Một agent đọc tài liệu hoặc gọi scheduling API nên có ít nhất 5 guardrail:

| Guardrail | Dùng để chặn gì | Ví dụ áp dụng |
|---|---|---|
| Scope guard | Truy cập ngoài phạm vi | Chỉ đọc contracts/2026/, không đọc toàn bucket |
| Action guard | Hành động nguy hiểm | Tool đọc được tự động, tool hủy lịch cần xác nhận |
| Evidence guard | Trả lời không nguồn | Không có quote thì không được kết luận |
| Escalation guard | Ca cần người xử lý | Khách yêu cầu ngoại lệ chính sách thì chuyển nhân viên |
| Retry guard | Vòng lặp tool call | Quá số lần gọi tool thì dừng và báo lỗi |

Nhìn sang voice agent đặt lịch khám, bài học cũng tương tự: agent có thể xác thực, nhắc lịch, đổi lịch, thu thập thông tin trước buổi hẹn. Nhưng production đáng tin là khi nó biết câu nào không được tự xử lý: danh tính không khớp, yêu cầu y tế nhạy cảm, lịch trùng, hoặc người dùng nổi cáu.

Agent tốt không phải agent nói mãi không vấp. Agent tốt là agent biết lúc nào phải đặt dụng cụ xuống.

Dấu hiệu nên scale, và dấu hiệu nên dừng

Sau một vòng thử nhỏ, đừng hỏi “demo có chạy không?”. Hãy hỏi 4 câu vận hành:

  1. Tỷ lệ câu trả lời có evidence đủ tốt không? Không cần bịa số benchmark; chỉ cần team review thủ công một tập câu hỏi đại diện.
  2. Lỗi nằm ở extraction, retrieval, reasoning, hay tool contract? Nếu PDF extraction sai từ đầu, đổi model không cứu được.
  3. Guardrail có chặn đúng ca nguy hiểm không? Nếu nó chỉ làm đẹp tài liệu thiết kế mà không xuất hiện trong log, coi như chưa có.
  4. Người dùng có sửa câu hỏi để né hệ thống không? Đây là tín hiệu workflow chưa khớp thực tế.

Nên scale khi:

Nên dừng hoặc quay lại thiết kế khi:

Đặc biệt với builder: đừng nhầm session memory — bộ nhớ trong một phiên làm việc — với năng lực hiểu nghiệp vụ. Memory giúp agent nhớ bạn vừa hỏi file nào, không biến nó thành chuyên gia pháp lý hay điều phối viên y tế.

Sau bài này, nên nghĩ khác điều gì?

Nếu trước đây bạn nhìn agent như một lớp thông minh đặt trên hệ thống, hãy đổi sang cách nhìn khác: agent là một workflow có đường ray, có điểm dừng, có người kiểm tra, và có log đủ đọc.

Tool calling, MCP server, PDF extraction, voice interface, session memory — tất cả đều hữu ích. Nhưng chỉ khi bạn đóng khung chúng thành một orchestration rõ ràng. Không phải cứ thêm tool là agent mạnh hơn; đôi khi chỉ là thêm chỗ để nó vấp.

Nếu là mình, mình sẽ bắt đầu bằng một workflow read-only, evidence bắt buộc, auth tách khỏi context, và tiêu chí dừng viết ra trước khi demo. Khi lát cắt đó đứng vững, hãy scale. Còn nếu chưa, cứ bào phẳng lại bản thiết kế — gỗ tốt mà ghép ẩu thì tủ vẫn xiêu.

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

Nguồn tham khảo