Agent bị ốm ở phần điều phối

eve của Vercel đáng chú ý không vì thêm một framework agent, mà vì ép team hỏi đúng câu: production contract của agent nằm ở đâu?

Nếu chiều nay tech lead hỏi: team mình có nên thử một framework agent mới không, bạn sẽ trả lời bằng gì?

Mình đoán nhiều người sẽ mở GitHub, nhìn star, xem demo, rồi hỏi model nào hỗ trợ. Cũng hợp lý. Nhưng với agent chạy thật, câu hỏi đó hơi giống đi khám mà chỉ hỏi thuốc nào đang hot, chưa đo huyết áp, chưa hỏi bệnh nền.

Vercel vừa giới thiệu eve, một open-source agent framework để build, run và scale agent. Điểm họ nhấn mạnh không phải là agent thông minh hơn, mà là bớt cảnh mỗi team tự ráp lại cùng một đống plumbing: config model, instruction, tools, skills, nơi agent sống, lúc nào agent tự chạy, cách fallback provider, cách nén context.

Luận điểm của mình: framework agent chỉ đáng tiền thời gian khi nó biến phần production thành hợp đồng rõ ràng, không phải khi nó làm demo trông mượt hơn.

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

Cơn sốt framework không phải vấn đề chính

Agent đang ở giai đoạn hơi kỳ: ai cũng build được một con bot biết gọi tool, nhưng để nó chạy ổn trong sản phẩm thì lại đụng cả mớ việc không vui.

Bạn cần orchestration — cách điều phối nhiều bước, nhiều tool hoặc nhiều agent. Bạn cần guardrail — rào chắn để agent không làm sai việc nguy hiểm. Bạn cần runtime — môi trường thực thi nơi agent chạy, log, retry, fail, và hồi phục. Bạn cần cách quản lý prompt, tool, tài liệu nghiệp vụ, quyền truy cập, và fallback khi provider model chập chờn.

Điểm thú vị ở eve là nó không bán câu chuyện “agent tự làm mọi thứ”. Nó đi theo hướng: agent nên được mô tả bằng file và cấu trúc rõ ràng. Ví dụ agent.ts để cấu hình agent và model; instructions.md làm system prompt — phần chỉ dẫn nền được gắn vào mỗi lần gọi model; các file kiểu tool hoặc skill mô tả việc agent có thể làm.

Đây không phải chuyện cú pháp đẹp. Đây là chuyện vận hành: khi agent hỏng, bạn biết phải mở hồ sơ bệnh án ở đâu.

Mổ xẻ eve: phần đáng nhìn không nằm ở chữ open-source

Nhiều team nghe open-source là tự động cộng điểm. Mình cũng thích open-source, nhưng trong production, mã nguồn mở chỉ là điều kiện tốt, chưa phải quyết định đủ.

Với eve, thứ đáng mổ xẻ là mô hình tổ chức agent thành các thành phần có địa chỉ rõ:

• Agent config: model nào, option nào, fallback ra sao.
• Instructions: agent là ai, luật đứng là gì, trả lời theo nguyên tắc nào.
• Tools: hàm hoặc API agent được phép gọi để làm việc cụ thể.
• Skills: kiến thức hoặc năng lực đóng gói, ví dụ định nghĩa revenue, cách tạo chart, quy trình phân tích.
• Autonomy trigger: điều kiện để agent tự hành động, thay vì chỉ phản hồi khi người dùng hỏi.

Nếu bạn từng maintain một agent nội bộ sau 3 tháng, bạn sẽ thấy giá trị của cấu trúc này. Không phải vì nó thần kỳ, mà vì nó giảm kiểu “prompt nằm đâu đó trong code”, “tool này ai thêm không biết”, “fallback model đổi hồi nào”, “vì sao tuần trước còn chạy mà tuần này trả lời sai”.

Hình dung thế này: team bạn có một agent phân tích doanh thu. Nó đọc định nghĩa chỉ số, gọi query, tạo chart, rồi viết nhận xét. Nếu định nghĩa revenue nằm lẫn trong prompt dài, chart tool nằm trong một file tiện tay đặt tên, còn model fallback cấu hình bằng env rải rác, mỗi lần sai số là một buổi hội chẩn mệt nghỉ. Còn nếu mỗi phần có file riêng, review pull request sẽ giống kiểm tra triệu chứng theo từng mục: luật có đổi không, tool có đổi không, model có đổi không, dữ liệu có đổi không.

Quyết định thật: chọn framework hay tự ráp?

Đừng hỏi “eve có tốt không?” trước. Hỏi: team mình đang đau ở lớp nào?

| Tình huống của team | Nên nghiêng về | Lý do |
|---|---|---|
| Mới có prototype, một agent, một người maintain | Tự ráp nhẹ trước | Framework có thể làm bạn học abstraction trước khi hiểu failure mode |
| Có nhiều agent nội bộ, nhiều người chỉnh prompt/tool | Thử framework như eve | Cần chuẩn hóa cấu trúc, review, và tái sử dụng plumbing |
| Agent đụng dữ liệu nhạy cảm hoặc hành động có rủi ro | Chỉ dùng nếu guardrail và permission rõ | Cấu trúc file chưa thay thế được kiểm soát quyền và audit |
| Đang phụ thuộc nhiều provider model | Xem kỹ provider fallback | Fallback tốt giúp giảm kẹt vận hành, nhưng cũng cần test sai khác output |
| Team đã có platform agent riêng | So sánh migration cost | Đổi framework chỉ đáng nếu giảm nợ vận hành rõ rệt |

Điểm mình muốn bạn đổi cách nghĩ: framework agent không phải thứ để làm agent đầu tiên nhanh hơn, mà là thứ để agent thứ năm không trở thành ca cấp cứu.

Với team Việt Nam cỡ nhỏ, đây là khác biệt lớn. Một nhóm 4-6 dev thường không có người riêng chỉ ngồi làm agent platform. Nếu mỗi agent sinh ra một kiểu folder, một kiểu prompt, một kiểu log, một kiểu gọi tool, chi phí không nổ ngay tuần đầu. Nó âm thầm tăng ở tháng thứ hai, khi PM hỏi vì sao cùng câu hỏi mà agent A trả lời khác agent B.

Điều đáng giữ lại: production contract

Mình thích nhất ở hướng của eve là nó ép builder biến những thứ mơ hồ thành artifact có thể review.

Production contract ở đây hiểu nôm na là cam kết vận hành được viết ra bằng cấu trúc: agent dùng model nào, được làm gì, đọc luật nào, gọi tool nào, và tự chạy khi nào. Không phải cam kết pháp lý, mà là hợp đồng kỹ thuật giữa người build, người review và hệ thống chạy thật.

Một contract tốt nên trả lời được 5 câu:

1. Agent này có nhiệm vụ gì, và không làm gì?
2. Quy tắc nào luôn được gắn vào mỗi model call?
3. Tool nào được gọi, input/output kỳ vọng ra sao?
4. Khi model/provider lỗi, fallback thế nào?
5. Log nào giúp truy ra vì sao agent quyết định như vậy?

Trong preview của eve, có vài mảnh ghép liên quan trực tiếp: instructions.md cho luật đứng, file tool/skill cho năng lực, config model một chỗ, hỗ trợ provider fallback qua AI Gateway, và compaction — cơ chế nén hoặc rút gọn ngữ cảnh để agent không mang quá nhiều thông tin thừa qua các lượt xử lý.

Compaction đáng chú ý vì agent dài hơi rất dễ bị “phình hồ sơ”: càng làm nhiều bước, context càng đầy, model càng dễ lẫn. Nhưng compaction cũng là dao hai lưỡi. Nén sai có thể bỏ mất chi tiết quan trọng. Vì vậy nếu dùng, bạn nên test bằng các case có thông tin dễ bị bỏ sót: điều kiện ngoại lệ, định nghĩa nghiệp vụ, hoặc ràng buộc compliance.

Điều nên bỏ qua: ảo giác Next.js cho agent

Vercel có quyền kể câu chuyện của họ: web từng hỗn loạn trước framework, Next.js chuẩn hóa nhiều thứ, giờ eve muốn làm tương tự cho agent. Nghe hợp lý, nhưng bạn không nên bê nguyên phép so sánh đó vào roadmap.

Web app có request/response tương đối rõ. Agent thì lắt léo hơn: model có thể trả lời khác nhau, tool có thể lỗi, dữ liệu có thể thiếu, user có thể đưa yêu cầu mơ hồ, và hành động tự động có thể tạo hậu quả ngoài màn hình chat.

Vậy nên, nếu bạn kỳ vọng cài framework xong là agent production-ready, bạn sẽ thất vọng. Framework có thể cho bạn phòng khám sạch hơn, hồ sơ rõ hơn, quy trình khám bớt loạn hơn. Nhưng chẩn đoán sai vẫn là chẩn đoán sai nếu guardrail, eval và monitoring không có.

Các thứ không nên outsource hoàn toàn cho framework:

• Permission model: ai được cho agent làm gì, trên dữ liệu nào.
• Evaluation set: bộ ca kiểm thử phản ánh lỗi thật của sản phẩm.
• Observability: log, trace, và alert để biết agent hỏng ở bước nào.
• Human override: khi nào cần người duyệt trước khi agent hành động.
• Data boundary: dữ liệu nào không được đưa vào model hoặc tool bên ngoài.

Nếu framework không làm rõ các điểm này, bạn vẫn phải tự thiết kế. Nếu framework có hỗ trợ, bạn vẫn phải cấu hình theo rủi ro của sản phẩm mình.

Một buổi chiều để ra quyết định, không cần cưới vội

Nếu team bạn tò mò về eve, mình sẽ không bắt đầu bằng việc migrate agent đang chạy. Hãy làm một spike nhỏ trong một buổi chiều:

1. Chọn một agent nội bộ ít rủi ro, ví dụ agent tạo báo cáo tuần hoặc phân tích ticket.
2. Tách 3 phần hiện tại thành file riêng: instruction, tool, skill/tài liệu nghiệp vụ.
3. Viết lại bằng cấu trúc tương tự eve, giữ logic càng gần bản cũ càng tốt.
4. Chạy 10-20 case cũ mà team từng dùng để bắt lỗi, không cần bịa benchmark.
5. Ghi lại 3 thứ: dễ review hơn không, dễ debug hơn không, và có giảm code plumbing không.

Nếu sau spike, bạn chỉ thấy “folder đẹp hơn” nhưng debug không dễ hơn, chưa cần đổi. Nếu review prompt/tool rõ hơn, onboarding dev mới nhanh hơn, và lỗi được khoanh vùng tốt hơn, lúc đó mới bàn tiếp về adoption.

Khuyến nghị của mình:

• Nên thử eve nếu bạn đang có nhiều agent, nhiều team cùng chỉnh, hoặc plumbing lặp lại đến mức ai cũng ngán.
• Khoan dùng nếu bạn mới đang tìm product-market fit cho một agent đơn giản.
• Chỉ đưa vào production khi bạn đã có eval, monitoring, permission, và rollback tương ứng.

Rủi ro còn lại là lock-in ở cấp kiến trúc, dù mã nguồn mở. Khi bạn viết agent theo convention của một framework, migration sau này vẫn có giá. Vì vậy quyết định đúng không phải “dùng hay không dùng eve”, mà là “mình có đang cần chuẩn hóa production contract cho agent không?”.

Agent không chết vì thiếu framework. Agent thường nhập viện vì không ai biết nó đã làm gì, dựa vào luật nào, và gọi nhầm tool từ lúc nào. Chữa đúng bệnh thì framework là đơn thuốc tốt; kê theo trend thì chỉ thêm thuốc bổ vào tủ.

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