Agent phải có bếp trưởng đứng canh

Agent phải có bếp trưởng đứng canh

Tiền đang đổ vào observability cho agent không phải vì agent đã hoàn hảo, mà vì production bắt đầu đau thật.

Có một tín hiệu thị trường khá lạ: một công ty làm monitoring gọi vốn 200 triệu USD vì họ đặt cược rằng sẽ có người cần “nhìn chừng” AI agent.

Lạ ở chỗ, nếu nghe pitch agent ngoài kia, bạn sẽ tưởng tương lai là phần mềm tự chạy, tự sửa lỗi, tự quyết định, tự làm hết. Nhưng tiền lớn lại đang chạy về lớp quan sát, chặn lỗi, audit, policy, interceptor. Tức là thị trường đang nói nhỏ vào tai builder một câu hơi mất hứng: agent càng tự động, hệ thống càng cần dây cương rõ hơn.

Mình thích tín hiệu kiểu này hơn demo hào nhoáng. Demo cho bạn thấy agent biết làm gì. Funding cho observability cho bạn thấy doanh nghiệp sợ điều gì khi agent bước vào production.

Sơ đồ minh họa cho bài Agent phải có bếp trưởng đứng canh

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

Tín hiệu thật không nằm ở con agent

Coralogix gọi vốn thêm 200 triệu USD, được định giá 1,6 tỷ USD sau vòng gọi vốn, trong bối cảnh họ đặt cược vào nhu cầu monitoring cho AI agents. Điểm đáng chú ý không phải là “một startup nữa ăn theo AI”. Điểm đáng chú ý là observability đang được kéo lên thành lớp hạ tầng bắt buộc của agentic systems.

Observability — khả năng quan sát hệ thống qua logs, metrics, traces — trước đây chủ yếu trả lời câu hỏi: server có chết không, latency có tăng không, service nào đang nghẽn?

Với agent, câu hỏi đổi vị:

Nói thẳng ra thì, monitoring kiểu cũ nhìn nồi nước có sôi hay không. Monitoring cho agent phải biết ai đã bỏ muối, bỏ lúc nào, và có lỡ tay đổ cả hũ vào nồi không.

Đây là chỗ nhiều team đang hiểu sai: họ nghĩ chọn model tốt hơn sẽ làm hệ agent đáng tin hơn. Không hẳn. Model tốt giúp giảm lỗi ở một số bước, nhưng production reliability đến từ orchestration và guardrail.

Orchestration — cách điều phối nhiều bước, nhiều tool hoặc nhiều agent — là nơi bạn quyết định luồng nào được phép xảy ra. Guardrail — hàng rào kiểm soát hành vi — là nơi bạn quyết định luồng nào phải bị chặn, sửa, hoặc escalate.

Mổ lớp đầu: agent không chạy code, agent tạo quyết định

Ứng dụng truyền thống chạy logic đã viết sẵn. Agent thì khác: LLM quyết định runtime sẽ gọi tool nào, với tham số gì, theo thứ tự nào. Chính điểm này làm audit khó hơn.

Một API backend bình thường giống công thức đã ghi trên giấy: bước 1, bước 2, bước 3. Agent giống người đứng bếp được quyền nêm nếm theo tình huống. Vấn đề là khi món hỏng, bạn không thể chỉ hỏi “bếp có bật không?”. Bạn phải biết người đó đã nêm gì.

Nguồn từ AWS về Bedrock AgentCore gateway chạm đúng vết đau này: khi một nền tảng có hàng trăm agent và hàng nghìn MCP tools, bài toán không còn là “agent có gọi tool được không”, mà là agent nào được gọi tool nào, trong điều kiện nào, với payload nào.

MCP tools — các công cụ được expose qua Model Context Protocol — giúp agent thao tác với hệ thống ngoài như CRM, database, ticketing, data warehouse. Càng nhiều tool, mặt phẳng rủi ro càng rộng.

AWS đưa ra hai lớp đáng để builder để ý:

Điểm hay nằm ở cặp đôi này: policy xử lý cái biết trước, interceptor xử lý cái chỉ biết khi request thật xuất hiện.

Nếu bạn đang build agent nội bộ, đừng bắt đầu bằng câu “dùng framework nào?”. Hãy bắt đầu bằng câu: call graph nào được phép tồn tại? Call graph là sơ đồ các lệnh gọi giữa agent và tool. Với agent, sơ đồ này không cố định tuyệt đối, nhưng bạn vẫn phải giới hạn biên của nó.

Lớp thứ hai: open-source multi-agent cũng cần đồng hồ đo

BigSet của TinyFish là một ví dụ đáng nhìn theo hướng khác. Nó không chỉ là “nhập tiếng Anh, ra bảng dữ liệu”. Kiến trúc multi-agent của nó phải làm nhiều việc: suy luận schema, tìm nguồn, thu thập, deduplicate, export CSV/XLSX, rồi còn có scheduled refresh.

Multi-agent system — hệ nhiều agent chia việc — nghe có vẻ như tăng năng suất. Nhưng trong production, nó cũng tăng số điểm có thể sai.

Ví dụ cụ thể: bạn yêu cầu tạo dataset “các công ty YC đang tuyển kỹ sư, kèm funding stage, location, số vị trí mở”. Một agent suy schema, agent khác đi tìm dữ liệu, agent khác lọc trùng. Nếu bảng cuối cùng sai, bạn cần biết sai từ đâu:

Nếu không có trace — dấu vết từng bước chạy — bạn chỉ có một file CSV đẹp và một cục nghi ngờ trong bụng.

Đây là lý do mình xem BigSet như tín hiệu cho builder: open-source agent sẽ làm workflow dữ liệu rẻ hơn và dễ thử hơn, nhưng nếu đem vào vận hành mà thiếu quan sát từng bước, bạn đang outsource sự mù mờ cho một pipeline mới.

Lớp thứ ba: biết không trả lời cũng là năng lực production

Một bài về support agent nhấn mạnh “escalation-first design”: agent phải quyết định route trước khi sinh câu trả lời, và mặc định fail về hướng chuyển người thay vì trả lời sai.

Escalation — chuyển ca cho người hoặc luồng an toàn hơn — thường bị xem là thất bại. Với agent production, nó là tính năng sống còn.

Trong support fintech, câu “thẻ của tôi bị mất” không giống “làm sao đổi avatar?”. Nếu agent tự tin trả lời bằng số hotline cũ, thiệt hại không nằm ở prompt xấu. Thiệt hại nằm ở thiết kế cho phép agent trả lời khi đáng ra nó phải im.

Ở đây có một nguyên tắc builder nên bê thẳng vào backlog: agent không chỉ cần policy để được làm gì, mà cần policy để biết khi nào không được làm.

Một hệ agent trưởng thành nên có ít nhất ba terminal paths — ba kết cục rõ ràng:

  1. reply: đủ căn cứ để trả lời.
  2. ask_clarification: thiếu dữ kiện, hỏi lại.
  3. escalate: rủi ro cao, chuyển người hoặc quy trình cứng.

Nếu mọi đường đều dẫn tới “generate answer”, bạn không có agent. Bạn có một cái máy pha câu trả lời đang chạy lửa quá lớn.

Framework: bốn lớp canh agent trước khi deploy

Nếu là mình, mình sẽ không đánh giá agent bằng câu “nó trả lời đúng mấy lần trong demo?”. Mình sẽ dùng khung bốn lớp này trước khi cho đụng hệ thống thật.

| Lớp | Câu hỏi cần trả lời | Dấu hiệu đã ổn |
|---|---|---|
| Intent routing | User đang yêu cầu loại việc gì? | Có route rõ: trả lời, hỏi lại, escalate, hoặc từ chối |
| Tool permission | Agent được gọi tool nào? | Policy theo vai trò, tài nguyên, điều kiện |
| Runtime validation | Payload và response có an toàn không? | Interceptor kiểm tra trước/sau tool call |
| Trace & replay | Khi lỗi, có dựng lại được chuyện gì xảy ra không? | Log đầy đủ input, tool call, output, quyết định route |

Framework này không phụ thuộc bạn dùng Bedrock, OpenAI, Anthropic, LangChain, hay tự ráp. Tool thay đổi, nhưng bốn câu hỏi này vẫn bám production.

Hình dung thế này: bạn có agent tạo báo cáo doanh thu từ data warehouse. Nếu agent chỉ đọc dữ liệu, rủi ro thấp hơn. Nếu agent được quyền chạy query nặng, gửi email cho khách, hoặc cập nhật CRM, rủi ro nhảy tầng. Khi đó, guardrail không còn là “nice to have”. Nó là phần thiết kế chính.

Một buổi chiều để tự bóc hệ agent của bạn

Không cần dựng platform hoành tráng ngay. Trong một buổi chiều, team có thể làm bản kiểm tra tối thiểu như sau.

Bước 1: Liệt kê tool theo mức nguy hiểm

Chia tool thành ba nhóm:

Agent chỉ được tự động dùng nhóm write-heavy nếu có policy và trace rõ.

Bước 2: Viết ma trận quyền đơn giản

Ví dụ minh họa:

Agent: support_triage
Allowed:
- search_docs: all tickets
- create_draft_reply: low_risk tickets
- escalate_ticket: all tickets
Denied:
- refund_payment
- update_user_identity
- send_final_reply for high_risk tickets

Bước 3: Thêm pre-tool check

Trước mỗi tool call, ghi lại:

{
  "agent": "support_triage",
  "route": "reply",
  "tool": "search_docs",
  "risk_level": "low",
  "reason": "user asks password reset steps"
}

Không cần hoàn hảo. Nhưng nếu không log được reason, bạn cũng khó debug được hành vi.

Bước 4: Thiết kế đường thoát

Với mỗi domain rủi ro cao, thêm luật:

If ticket mentions stolen card, account takeover, legal request, payment dispute:
- do not generate final answer
- escalate to human queue
- attach retrieved context only

Đây là chỗ agent bắt đầu đáng tin hơn: không phải vì nó nói hay hơn, mà vì nó biết né việc không nên làm.

Điều nên giữ, điều nên bỏ qua

Giữ lại tín hiệu này: AI agent đang kéo observability, policy, interceptor, audit log thành thị trường hạ tầng riêng. Khi nhà đầu tư đổ tiền vào lớp “ai canh agent”, đó là vì doanh nghiệp chuẩn bị gặp lỗi ở quy mô mà dashboard cũ không giải thích nổi.

Bỏ qua FOMO rằng bạn phải mua ngay một nền tảng mới hoặc chuyển hết sang framework mới. Với nhiều team Việt Nam, việc thực dụng hơn là bắt đầu ghi trace đúng, giới hạn tool call, và ép agent có đường escalate.

Sau bài này, thứ mình muốn bạn nghĩ khác là: agent production không phải cuộc thi xem model nào thông minh nhất; nó là bài toán xem hệ thống có kiểm soát được quyết định của model hay không.

Nồi agent có thể sôi rất nhanh. Nhưng nếu không có người canh lửa, món cháy thì dashboard cũng chỉ báo “khói đang tăng”.

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

Nguồn tham khảo