Agent async chỉ là kéo màn, chưa phải diễn hay

Agent async chỉ là kéo màn, chưa phải diễn hay

Subagent chạy nền giúp agent bớt đứng hình, nhưng production chỉ đáng tin khi bạn thiết kế rõ orchestration, guardrail và dấu vết lỗi.

Bạn đã bao giờ nhắn một agent: “đi kiểm tra giúp mình repo này”, rồi ngồi nhìn chat im lặng như sân khấu tắt đèn chưa?

Không lỗi. Không phản hồi. Không biết nó đang đọc file, gọi tool, kẹt rate limit, hay đã lạc vào một nhánh suy luận nào đó và quên đường về. Với developer thì cảm giác này rất quen: demo nhìn mượt, nhưng khi giao việc dài hơn 30 giây, agent biến thành một cái hộp đen biết tiêu token.

Vì vậy, việc Hermes Agent thêm asynchronous subagents — subagent chạy bất đồng bộ, không chặn parent chat — nghe có vẻ nhỏ, nhưng chạm đúng một điểm đau thật: agent production không chỉ cần “thông minh hơn”, mà cần không làm nghẽn luồng làm việc của con người.

Nhưng đây cũng là chỗ dễ hiểu sai. Async không tự biến hệ thống agent thành đáng tin. Nó chỉ kéo màn cho phép nhiều việc diễn ra song song. Phần khó nằm ở hậu trường: orchestration, guardrail, trace, và cách bạn quyết định thông tin nào được quay lại parent agent.

Sơ đồ minh họa cho bài Agent async chỉ là kéo màn, chưa phải diễn hay

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

Tín hiệu chính: agent đang rời khỏi kiểu chat một luồng

Hermes Agent vốn có cơ chế delegate_task: parent agent giao việc cho subagent, tức một agent con có conversation, terminal session và toolset riêng. Subagent làm xong thì trả lại summary cuối cùng cho parent.

Điểm mới là delegated work không còn bắt parent chat đứng chờ. Với async delegation, parent có thể nhận task_id sớm, còn subagent chạy nền. Người dùng tiếp tục chat, kiểm tra tiến độ, hoặc giao việc khác.

Dịch sang tiếng người: trước đây bạn nhờ một người phụ diễn đi tìm đạo cụ, cả sân khấu phải đứng im chờ. Giờ người đó đi hậu trường làm việc, còn vở diễn chính vẫn tiếp tục.

Đây là một thay đổi kiến trúc đáng chú ý vì nó tách hai thứ thường bị nhập làm một:

Khi hai việc này tách ra, agent bắt đầu giống một hệ thống vận hành hơn là một chatbot dài hơi. Và với builder, đó mới là điểm đáng bàn.

Lớp ẩn bên dưới: async làm lộ bài toán orchestration

Orchestration là cách điều phối nhiều bước, nhiều tool hoặc nhiều agent để hoàn thành một việc. Trong demo, orchestration thường được giấu dưới một câu “agent tự làm”. Trong production, nó là nơi bug sinh sản.

Hermes chọn một thiết kế khá rõ: subagent có context riêng, chỉ nhận những gì parent truyền qua goal và context. Parent không thấy intermediate tool calls hay reasoning của child; nó chỉ nhận summary cuối.

Thiết kế này có một lợi ích lớn: context window — vùng ngữ cảnh model còn giữ được trong một lượt xử lý — của parent không bị nhồi đầy bởi mọi thao tác con. Nếu subagent đọc 20 file, thử 5 lệnh, rồi sửa lỗi 3 lần, parent không phải ôm hết đống đó vào đầu.

Nhưng tradeoff cũng rất thật:

| Quyết định thiết kế | Lợi ích | Rủi ro |
|---|---|---|
| Subagent có conversation riêng | Ít nhiễu context parent | Dễ thiếu thông tin nếu prompt giao việc mơ hồ |
| Chỉ trả summary cuối | Gọn, tiết kiệm context | Khó debug nếu summary che mất lỗi gốc |
| Chạy async | Không khóa chat chính | Cần lifecycle: kiểm tra, hủy, retry, timeout |
| Có thể route model rẻ hơn | Giảm chi phí cho việc phụ | Chất lượng lệch giữa parent và child |

Ví dụ cụ thể: giả sử team bạn dùng agent để review pull request. Parent nhận yêu cầu “review PR thanh toán”, rồi spawn ba subagent: một con đọc logic business, một con kiểm tra test, một con nhìn security. Nếu chạy async, tech lead vẫn có thể hỏi parent: “trong lúc chờ, liệt kê các file có rủi ro cao trước”.

Nghe hợp lý. Nhưng nếu subagent security chỉ trả về “không thấy vấn đề nghiêm trọng” mà không kèm trace tối thiểu, bạn có dám merge không? Đây là ranh giới giữa automation tiện và automation nguy hiểm.

Điều đáng giữ: summary gọn, nhưng trace phải sống ở nơi khác

Một số team nghe “parent không thấy intermediate reasoning” sẽ lo mất khả năng kiểm soát. Lo đúng, nhưng không nhất thiết phải đẩy toàn bộ trace vào parent context.

Cách nghĩ tốt hơn là tách ba lớp:

  1. Parent context: chỉ giữ quyết định, trạng thái task, summary cần hành động.
  2. Execution trace: lưu tool calls, lỗi, retry, output quan trọng ở nơi quan sát được.
  3. Evaluator layer: đọc trace để phát hiện fail pattern và đề xuất sửa.

Nguồn từ AWS Strands Evals nhấn mạnh đúng chuyện này: biết agent fail là chưa đủ, cần biết vì sao fail và sửa ở đâu. Detector có thể phân loại lỗi, nối causal chain — chuỗi nguyên nhân dẫn tới triệu chứng — và gợi ý sửa prompt hay tool definition.

Với async subagents, lớp detector càng quan trọng. Vì khi parent không bị block, nhiều child agent có thể chạy cùng lúc. Nếu không có trace và detector, bạn chỉ có một chùm summary đẹp đẽ nhưng không biết cái nào đáng tin.

Một framework gọn cho builder:

Delegate -> Observe -> Diagnose -> Decide

Sau khi đọc bài này, điều bạn nên nghĩ khác là: async delegation không phải feature UX; nó là lời mời thiết kế lại control plane cho agent. Control plane ở đây là lớp điều khiển task, trạng thái, quyền, log và quyết định.

Điều nên bỏ qua: đừng sùng bái “chạy lâu” hay “chạy nhiều”

Sakana Marlin là một tín hiệu khác cùng hướng: enterprise agent không nhất thiết trả lời trong vài giây. Nó có thể chạy hàng giờ, phát nhiều truy vấn LLM, dựng báo cáo dài và slide cho decision-maker. Backbone AB-MCTS — Adaptive Branching Monte Carlo Tree Search, tức tìm kiếm theo cây với nhánh mở rộng thích nghi — cho thấy inference-time compute đang được dùng như một tài nguyên chiến lược.

Nhưng builder dễ rơi vào bẫy: thấy agent chạy lâu hơn, nhiều subagent hơn, nhiều query hơn thì tưởng chắc chắn tốt hơn.

Không hẳn.

Chạy lâu chỉ đáng tiền nếu hệ thống biết khi nào đi rộng, khi nào đi sâu, khi nào dừng. Chạy song song chỉ đáng tin nếu kết quả có tiêu chuẩn nhận vào. Báo cáo dài chỉ hữu ích nếu có evidence, nguồn, và đường quay lại kiểm chứng.

Với team Việt Nam, nhất là nhóm 3–8 người đang build AI workflow nội bộ, câu hỏi không nên là “có async subagent chưa?”. Câu hỏi nên là:

Nếu chưa trả lời được các câu này, async chỉ làm lỗi xảy ra nhanh hơn và kín hơn.

Một buổi bóc hệ thống: thử với workflow nhỏ

Không cần đập đi xây lại. Bạn có thể kiểm tra readiness của team trong một buổi bằng một workflow hẹp, ví dụ “agent hỗ trợ review PR”.

Bước 1: Chọn một việc có ranh giới rõ

Đừng chọn “tự sửa toàn bộ codebase”. Chọn việc như:

Bước 2: Viết output contract cho subagent

Ví dụ:

{
  "risk_level": "low | medium | high",
  "evidence": ["file:line + lý do"],
  "unknowns": ["điều chưa kiểm chứng"],
  "recommended_action": "merge | ask_human | block"
}

Điểm quan trọng: bắt subagent nói rõ unknowns. Agent không biết thì phải khai báo, không được diễn như đã soi hết hậu trường.

Bước 3: Gắn lifecycle tối thiểu

Mỗi task cần có:

Bước 4: Tạo một detector thô trước khi mơ detector xịn

Chưa cần SDK phức tạp ngay. Bạn có thể bắt đầu bằng rule đơn giản:

Sau đó mới tính chuyện detector dựa trên LLM để đọc execution trace và phân tích root cause.

Nếu là mình, mình sẽ chọn async theo rủi ro, không theo độ hấp dẫn

Mình sẽ không bật async subagent cho mọi thứ. Mình sẽ chia task thành ba nhóm.

Nhóm xanh: chạy nền thoải mái. Tóm tắt tài liệu, gom link, đọc changelog, chuẩn bị nháp. Sai thì phiền, nhưng ít phá production.

Nhóm vàng: chạy nền nhưng cần evidence. Review code, phân tích incident, đề xuất thay đổi config. Parent chỉ được dùng kết quả nếu có trace và output contract đạt chuẩn.

Nhóm đỏ: không cho tự quyết. Deploy, xóa dữ liệu, đổi quyền truy cập, merge code quan trọng. Agent có thể chuẩn bị phương án, nhưng người hoặc policy gate phải bấm nút cuối.

Đây là chỗ guardrail — rào chắn vận hành để giới hạn hành vi nguy hiểm — trở thành phần kiến trúc, không phải dòng nhắc thêm vào prompt.

Hermes async subagents đáng chú ý vì nó làm agent bớt đứng hình. Sakana Marlin đáng chú ý vì nó cho thấy agent dài hơi đang thành sản phẩm enterprise. Strands Evals đáng chú ý vì nó nhắc ta rằng agent fail cần được chẩn đoán như hệ thống phần mềm, không phán bằng cảm giác.

Ba tín hiệu này gặp nhau ở một điểm: agent production không thắng bằng một model hay một tool đơn lẻ, mà bằng khả năng giao việc, quan sát, chẩn đoán và chặn sai đúng lúc.

Kéo màn nhanh hơn là tốt. Nhưng nếu đạo cụ chưa kiểm, ánh đèn chưa khóa, và người nhắc tuồng không biết ai đang đứng đâu, vở diễn vẫn có thể loạn rất chuyên nghiệp.

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

Nguồn tham khảo