Agent phá sản vì thiếu sổ điều phối

Agent phá sản vì thiếu sổ điều phối

Agent làm task ngắn có thể rất giỏi, nhưng chạy một hệ thống dài ngày là chuyện khác. Muốn production đáng tin, hãy mổ orchestration trước model.

Bạn có dám giao cho agent quyền điều hành một startup giả lập trong 500 ngày không?

Không phải kiểu trả lời email, sửa bug nhỏ, hay bấm vài bước trên web. Mình đang nói tới chuyện: chọn ưu tiên sản phẩm, phân bổ tiền, đọc tín hiệu nhiễu, quyết định thuê hay không thuê, rồi sống sót qua hàng trăm ngày mô phỏng. Một bài test tên CEO-Bench của nhóm Princeton làm đúng việc đó: cho agent chạy một công ty phần mềm thuê bao giả định, bắt đầu với 1 triệu USD, zero customer, dùng Python API gồm 34 tools và database 19 bảng.

Kết quả đáng gờn không nằm ở chỗ model nào thắng. Điểm làm mình khựng lại là: đa số model hiện tại phá sản, và một heuristic rule-based đơn giản không dùng AI lại vượt gần hết.

Nếu bạn đang build agent cho production, đây không phải drama benchmark. Đây là tờ phiếu nhắc trả sách quá hạn: mình tưởng đã mượn được trí thông minh chiến lược, hóa ra mới mượn được kỹ năng làm bài tập ngắn.

Sơ đồ minh họa cho bài Agent phá sản vì thiếu sổ điều phối

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

Tín hiệu chính: task ngắn đang đánh lừa chúng ta

Agent ngày nay khá lên rất nhanh ở các việc có cấu trúc gọn:

Ví dụ: fix một bug nhỏ, tuân thủ policy trong cuộc hội thoại support, hoặc hoàn thành workflow trên website. Những việc này giống như tra một cuốn sách trong phòng đọc: bạn biết tên sách, biết kệ nào, lấy ra, ghi chú, xong.

Nhưng nhiều hệ thống production không vận hành như vậy. Một agent xử lý procurement, phân tích tài chính, điều phối ticket support cấp cao, hay quản lý campaign marketing phải ra quyết định dưới nhiễu. Feedback có thể đến muộn. Lựa chọn hôm nay làm hỏng ngân sách tuần sau. Một action đúng trong local context có thể sai khi nhìn toàn hệ thống.

Đó là lý do CEO-Bench đáng để builder chú ý. Không phải vì nó mô phỏng đúng mọi startup ngoài đời, mà vì nó kéo agent ra khỏi sân chơi task ngắn và đặt vào long-horizon decision-making — ra quyết định qua chuỗi dài, nơi chi phí của sai lầm tích lũy.

Dịch sang tiếng người: agent không chỉ cần biết làm việc tiếp theo; nó cần biết việc tiếp theo có đang làm hỏng mục tiêu dài hạn không.

Lớp ẩn: model không phải người giữ ngân quỹ

Sai lầm phổ biến của nhiều team là nhìn agent như một model có thêm tool. Model mạnh hơn, context window dài hơn, tool calling mượt hơn, vậy chắc agent sẽ đáng tin hơn.

Có, nhưng chưa đủ.

Tool calling là khả năng để model gọi API hoặc công cụ thay vì chỉ trả lời bằng chữ. Nó giúp agent hành động. Nhưng khi agent có thể hành động, câu hỏi production chuyển từ ‘nó biết làm gì không?’ sang ‘ai kiểm soát chuỗi hành động đó?’

Ở lớp hệ thống, mình sẽ tách agent production thành 5 lớp:

| Lớp | Câu hỏi cần trả lời | Nếu thiếu sẽ ra sao |
|---|---|---|
| Goal contract | Mục tiêu và giới hạn có được viết rõ không? | Agent tối ưu nhầm thứ |
| State ledger | Trạng thái nào được ghi lại sau mỗi bước? | Agent quên nợ kỹ thuật, quên chi phí |
| Orchestration | Ai quyết định bước tiếp theo và thứ tự tool? | Chuỗi hành động lan man |
| Guardrail | Điều gì bị chặn trước khi gây thiệt hại? | Sai nhỏ thành lỗi vận hành |
| Evaluation world | Agent được stress-test trong môi trường nào? | Demo đẹp, production vỡ |

Orchestration nghĩa là lớp điều phối nhiều bước, nhiều tool, nhiều trạng thái để hoàn thành việc. Đây là phần nhiều demo agent cố giấu dưới tấm thảm. Nhưng trong production, orchestration mới là thủ thư quyết định cuốn nào được lấy ra, cuốn nào phải đối chiếu, và cuốn nào không được mang khỏi kho lưu trữ.

Một heuristic đơn giản thắng nhiều model trong bài test kiểu CEO-Bench không có nghĩa là rule-based luôn tốt hơn AI. Nó nói một điều khác: quy tắc ổn định đôi khi đáng giá hơn suy luận linh hoạt nhưng không có khung kiểm soát.

Mổ xẻ hệ thống: vì sao agent giỏi vẫn phá sản

Hình dung thế này: team bạn build một agent quản lý ngân sách quảng cáo cho SaaS B2B. Agent có quyền đọc dashboard, tăng giảm budget, tạo campaign, tạm dừng keyword, gửi báo cáo.

Ở sprint đầu, demo rất ổn. Agent thấy campaign A CPA cao thì giảm ngân sách. Campaign B conversion tốt thì tăng. Báo cáo viết mạch lạc. PM vui, sales gật gù.

Nhưng sau một tháng, bạn phát hiện agent đã bóp nghẹt campaign top-of-funnel vì nó chỉ nhìn conversion ngắn hạn. Pipeline quý sau mỏng đi. Budget thì còn, nhưng cơ hội đã cháy.

Lỗi này không nằm ở việc model không hiểu marketing. Lỗi nằm ở hệ thống không ép agent ghi và cân đối các mục tiêu theo thời gian:

Đây là loại lỗi CEO-Bench muốn soi: agent có thể đưa ra từng quyết định nghe hợp lý, nhưng tổng các quyết định lại làm công ty hết tiền.

Với builder, câu hỏi quan trọng không phải ‘model nào làm CEO tốt nhất?’. Câu hỏi nên là: hệ thống của mình có bắt agent giữ sổ cái quyết định không?

Sổ cái ở đây không phải database log cho có. Nó cần ghi được:

Decision: tăng budget campaign B 20%
Reason: CAC 7 ngày thấp hơn ngưỡng nội bộ
Assumption: dữ liệu đủ ổn định sau 14 ngày chạy
Risk: làm giảm ngân sách thử nghiệm ở campaign C
Review at: sau 3 ngày hoặc khi spend vượt ngưỡng
Rollback rule: nếu qualified lead giảm rõ rệt thì hoàn tác

Khi thiếu lớp này, bạn chỉ có transcript dài. Transcript giống đống giấy để lung tung trong kho; tìm lại được, nhưng không biết tờ nào là quyết định, tờ nào là suy đoán, tờ nào là cảnh báo.

Điều đáng giữ: digital world, nhưng phải dùng đúng vai

Nguồn liên quan về Patronus AI cho thấy một hướng đang nóng: tạo các môi trường mô phỏng, hay digital world models — bản sao có kiểm soát của website, workflow, hoặc hệ thống nội bộ để stress-test agent. Các môi trường này cho phép agent va vào tình huống phức tạp hơn trước khi chạm production thật.

Mình thích hướng này, với một điều kiện: đừng biến nó thành bảng điểm khoe model.

Một môi trường test tốt cho agent nên trả lời 4 câu:

  1. Agent có giữ được mục tiêu dài hạn khi feedback ngắn hạn hấp dẫn không?
  2. Agent có biết dừng lại khi dữ liệu thiếu không?
  3. Agent có phân biệt action đảo ngược được và action khó đảo ngược không?
  4. Agent có để lại dấu vết đủ cho con người audit không?

Nếu test chỉ đo ‘hoàn thành task chưa’, bạn vẫn đang kiểm tra kỹ năng phòng đọc. Production cần thêm kiểm tra khả năng quản lý kho lưu trữ: biết tài liệu nào quan trọng, thay đổi nào cần ghi biên bản, và quyết định nào phải được duyệt trước khi đưa ra ngoài.

Với team Việt Nam quy mô 5-15 người, bạn không cần dựng một vũ trụ mô phỏng hoành tráng ngay. Có thể bắt đầu nhỏ hơn:

Đây là bài tập một buổi chiều cho tech lead: chọn một agent workflow đang được demo nhiều nhất trong team, rồi thêm 3 ràng buộc dài hạn vào test. Bạn sẽ thấy ngay agent nào chỉ giỏi chạy nước rút, agent nào có khả năng giữ nhịp đường dài.

Điều nên bỏ qua: FOMO model mới nhất

Có một phản xạ mình thấy khá nhiều: agent fail thì đổi model. Model mới hơn, context dài hơn, reasoning tốt hơn, hy vọng mọi thứ tự ổn.

Đổi model có thể giúp. Nhưng nếu hệ thống không có goal contract, state ledger, guardrail và evaluation world, model mạnh hơn đôi khi chỉ giúp bạn phá nhanh hơn.

Đây là mini-framework mình sẽ dùng khi review một agent trước production:

1. Nếu sai, thiệt hại có đảo ngược được không?
Nếu không, cần approval gate hoặc dry-run.

2. Agent đang tối ưu metric nào, và metric đó có phản tác dụng không?
Ví dụ tối ưu tốc độ xử lý ticket có thể làm giảm chất lượng support.

3. Feedback đến sau bao lâu?
Feedback càng muộn, càng cần checkpoint và decision record.

4. Có rule-based baseline chưa?
Nếu một bộ luật đơn giản đã đủ tốt, đừng vội cho agent quyền tự trị rộng.

5. Có môi trường stress-test mô phỏng nhiễu chưa?
Không cần hoàn hảo, nhưng phải có tình huống thiếu dữ liệu, dữ liệu mâu thuẫn, và mục tiêu xung đột.

Sau khi đọc CEO-Bench, điều mình muốn bạn nghĩ khác là: agent production không nên được đánh giá như một nhân viên thông minh, mà như một hệ thống ra quyết định có ngân sách, ký ức, giới hạn và trách nhiệm giải trình.

Model là một phần của câu chuyện. Nhưng cái làm agent sống sót qua 500 ngày không phải chỉ là IQ. Nó là khả năng không tự đốt sổ sách trong lúc đang rất tự tin ký quyết định.

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

Nguồn tham khảo