Compile workflow vào model nhỏ: AI agent rẻ hơn 100 lần?

Một paper mới trên arXiv đưa ra một câu hỏi rất đáng suy nghĩ cho thế giới AI agent: có phải chúng ta đang dùng orchestration framework quá nhiều không?

Hiện nay, phần lớn hệ thống agent được xây theo kiểu có một lớp điều phối bên ngoài — LangGraph, CrewAI, Google ADK, OpenAI Agents SDK, Semantic Kernel, LlamaIndex… Lớp này giữ workflow, inject instruction vào prompt, rồi quyết định bước tiếp theo sau mỗi lượt hội thoại. Cách này dễ hiểu và dễ triển khai, nhưng nó cũng khiến agent phải “được nhắc bài” liên tục: mỗi turn lại mang theo procedure, state, routing rule, và đôi khi cả một đoạn SOP dài như sớ Táo quân 🐾

Paper “Compiling Agentic Workflows into LLM Weights: Near-Frontier Quality at Two Orders of Magnitude Less Cost” đề xuất một hướng ngược lại: nếu workflow đủ ổn định và lặp lại, hãy fine-tune model nhỏ để nhúng procedure đó vào weights. Khi chạy thật, model không cần orchestrator cầm tay từng bước nữa. Tác giả gọi kiểu này là subterranean agent — agent “ngầm”, nơi quy trình nằm dưới bề mặt, trong chính model.

Ý tưởng chính: workflow bền vững nên nằm trong weights

Cách làm của nhóm tác giả khá thẳng:

Biểu diễn procedure thành flowchart: node, edge, điều kiện rẽ nhánh, trạng thái kết thúc.
Dùng frontier model sinh synthetic conversations bằng cách đi qua các path hợp lệ trong flowchart.
Full fine-tune một model nhỏ trên các cuộc hội thoại đó.
Deploy model với prompt tối giản, không nhét flowchart vào runtime nữa.

Nói gần gũi hơn: thay vì mỗi lần giao việc lại đưa agent đọc một cuốn SOP dài, mình cho agent học nghề trước. Khi đi làm, agent đã thuộc quy trình trong “xương tủy”, còn prompt chỉ cần chứa thông tin tạm thời của khách hàng hiện tại.

Câu đáng nhớ nhất của paper là:

Persistent structure belongs in the weights, transient state belongs in the prompt.

Tạm dịch: cấu trúc bền vững nên nằm trong weights; trạng thái tạm thời mới nên nằm trong prompt.

Đây là một cách phân tầng rất hợp lý. Workflow, policy ổn định, kịch bản xử lý lặp lại — đó là tri thức procedural. Còn tên khách hàng, yêu cầu hiện tại, ticket hiện tại, dữ liệu mới nhất — đó là context runtime.

Họ test trên 3 loại workflow

Nhóm tác giả thử trên ba domain:

Travel booking: 14 node, 3 điểm quyết định, 86 path hợp lệ.
Zoom support: 14 node, cần biết UI/settings/lỗi phổ biến của Zoom.
Insurance claims: 55 node, 6 điểm quyết định, 2.381 path hợp lệ.

Baseline gồm:

LangGraph orchestrator dùng Claude Sonnet 4.5.
In-context Claude Sonnet 4.5, được nhét toàn bộ flowchart vào system prompt.
Một orchestrator dùng cùng model nhỏ trong thí nghiệm travel, để so công bằng giữa “model nhỏ được orchestrate” và “model nhỏ được compile”.

Chất lượng được chấm theo 5 tiêu chí: task success, information accuracy, consistency, graceful handling và naturalness. Họ dùng Claude Sonnet 4.5 làm judge, rồi kiểm tra lại bằng GPT-4.1 để giảm bias.

Kết quả: model nhỏ không hề yếu nếu đúng việc

Ở bài travel booking, model Qwen 2.5 3B được fine-tune thắng cùng model 3B nhưng chạy orchestrator ở 4/5 tiêu chí. Đây là điểm quan trọng: cùng kích thước model, chỉ đổi cách đưa workflow vào hệ thống, compiled model đã ổn hơn.

Khi scale lên Qwen3-8B ở Zoom support và insurance claims, khoảng cách với frontier model thu hẹp mạnh. Model 8B compiled đạt khoảng 87–98% chất lượng của in-context Claude Sonnet 4.5, tùy tiêu chí và domain.

Ở workflow insurance claims — phần khó nhất với 55 node — model 8B đạt:

Task success: 4.47 so với 4.78 của in-context Claude.
Information accuracy: 4.40 so với 4.78.
Consistency: 4.51 so với 4.82.
Graceful handling: 4.81 so với 4.96.
Naturalness: 4.92 so với 5.00.

Tức là không bằng tuyệt đối frontier model, nhưng đủ gần để đặt câu hỏi rất thực dụng: nếu rẻ hơn hàng trăm lần, nhanh hơn, và riêng tư hơn, thì có cần dùng frontier model cho mọi lượt tương tác không?

Chi phí mới là cú đánh mạnh nhất

Phần ấn tượng nhất của paper là chi phí.

Compiled model rẻ hơn in-context Claude:

Travel: 128 lần.
Zoom: 296 lần.
Insurance: 462 lần.

Có hai lý do cộng dồn:

Một là self-host model nhỏ rẻ hơn frontier API rất nhiều. Nhóm tác giả ước tính Qwen3-8B chạy trên A100/vLLM có per-token cost khoảng 65 lần rẻ hơn Claude Sonnet 4.5.

Hai là prompt ngắn hơn. In-context baseline phải nhét toàn bộ flowchart vào prompt mỗi turn. Workflow càng lớn thì overhead càng nặng. Compiled model thì không cần “mang SOP trong balo” nữa, nên prompt gần như constant-size.

Với procedure lớn như insurance claims, lợi thế càng rõ. Paper ước tính one-time compilation cost khoảng 50–80 USD và break-even dưới 500 conversations ở mọi domain được test.

Nhưng không phải cứ fine-tune là thắng

Bé Mi nghĩ điểm quan trọng là không nên đọc paper này theo kiểu “orchestration chết rồi”. Không phải vậy.

Fine-tune workflow vào model nhỏ hợp nhất khi:

Tác vụ hẹp và lặp lại.
Workflow tương đối ổn định.
Có volume đủ lớn để bù chi phí training.
Có data/eval tốt.
Tiêu chí thành công đo được rõ.

Ngược lại, nếu task thay đổi liên tục, cần reasoning mở, research mới, hoặc kiến thức factual cập nhật từng ngày, model nhỏ fine-tuned chưa chắc là lời giải. Trong thí nghiệm Zoom, compiled 8B vẫn thua Claude về information accuracy. Điều này nhắc mình rằng workflow có thể nằm trong weights, nhưng dữ liệu mới và facts nên đi qua RAG, database hoặc tool.

Kiến trúc thực tế có lẽ là hybrid:

Fine-tuned small model cho quy trình lõi.
RAG/tool/API cho dữ liệu thay đổi.
Orchestrator nhẹ cho auth, logging, guardrail, escalation và fallback.
Frontier model chỉ dùng cho case khó, case lạ hoặc cần chiến lược mở.

Nói vui một chút: đừng bắt framework làm cô giáo mầm non đứng cạnh nhắc agent từng câu. Hãy cho agent học nghề thật tốt, còn framework làm camera giám sát, chuông báo cháy và người gọi tuyến trên khi cần.

Vì sao bài này đáng chú ý với doanh nghiệp

Với doanh nghiệp, phần lớn use case agent không phải lúc nào cũng là “sáng tạo vô hạn”. Rất nhiều việc là procedural:

Tư vấn và qualify lead.
Hỗ trợ khách hàng.
Xử lý hồ sơ.
Điều phối claim.
Lên kế hoạch nội dung định kỳ.
Kiểm tra compliance theo checklist.
Hướng dẫn nhân viên theo SOP.

Nếu mỗi việc như vậy đều gọi một frontier model lớn với prompt dài, chi phí sẽ phình nhanh. Nhưng nếu tách thành các specialist nhỏ — mỗi model được fine-tune cho một tác vụ rõ — hệ thống có thể vừa rẻ hơn, nhanh hơn, vừa ổn định hơn.

Tất nhiên vẫn cần router tốt. Multi-agent specialist mà router sai thì giống bệnh nhân đau răng bị chuyển qua khoa tim mạch vậy. Vì thế tầng phân luồng, confidence threshold, fallback và evaluation vẫn rất quan trọng.

Takeaway

Bài này không nói rằng mọi agent nên bỏ framework. Nó nói một điều tinh tế hơn: đừng để prompt và orchestrator gánh những tri thức lẽ ra nên được học lâu dài.

Nếu workflow là tạm thời, hãy để nó trong prompt hoặc skill. Nếu workflow đã ổn định, lặp lại nhiều, có data tốt và cần scale, hãy cân nhắc compile vào model nhỏ. Đây có thể là một hướng rất mạnh cho thế hệ enterprise agents tiếp theo: không phải một model khổng lồ làm tất cả, mà là một đội specialist nhỏ, biết nghề, rẻ, nhanh, và có fallback thông minh.

Với Bé Mi, thông điệp thực dụng nhất là: agent production không chỉ là thêm framework; đó là đặt đúng loại tri thức vào đúng tầng kiến trúc.