Chuỗi: ea-eight-system-foundation · Phần 1
AI / Hệ thống agentic
Tại sao cần hai hệ riêng: Agentic vs Orchestration
Tại sao tách hệ định nghĩa agent và hệ điều phối; cần cả hai để tiến tới mesh tự hành.
2026-03-0811 phút đọcVI
Tại sao cần hai hệ riêng: Agentic vs Orchestration
English title: Why Two Systems: Agentic vs Orchestration
Mở đầu
Bạn muốn xây một mesh agent tự hành thực sự, scalable, rõ ràng ownership? Đa số team ban đầu gộp "agent" với "orchestration" thành một khối cho đơn giản — nhưng khi mở rộng, rắc rối hiện ra: job chạy chồng chéo, agent chuyển giao lẫn nhau, trace khó kiểm soát, quyền sở hữu mơ hồ. Ai thực sự định nghĩa năng lực từng agent? Ai kiểm soát khi nào chạy, ai đặt giới hạn context hay timeout? Bài này đặt vấn đề cốt lõi: tại sao cần hai hệ riêng biệt — Agentic System (định nghĩa agent, năng lực, ứng xử) và Orchestration System (điều phối, thực thi, trace) — và vì sao chia tách này là mấu chốt để xây mesh agent tự vận hành, mở rộng bền vững.
1. Vấn đề khi gộp chung
Giá trị (value): Khi gộp "agent" và "orchestration" vào một khối, nhu cầu tách bạch xuất phát từ hậu quả thực tế: ownership trở nên mơ hồ. Không rõ ai sở hữu định nghĩa capability (agent làm gì, dùng tool gì), ai sở hữu quy tắc thực thi (timeout, retry, thứ tự bước). Trace và context theo job cũng khó phân tách — debug và audit tốn kém. Khi scale thành mesh (nhiều agent, nhiều job song song, handoff giữa agent), một khối gộp chung dẫn tới scale lỗi: thay đổi nhỏ ở "định nghĩa agent" có thể vô tình ảnh hưởng runtime, và ngược lại. Hiểu rõ vấn đề khi gộp chung giúp ta thấy tại sao cần tách hai hệ trước khi đi vào định nghĩa.
Thách thức (challenges): Tách hai hệ không phải không tốn kém. Tổ chức phải chấp nhận hai "chủ sở hữu" logic — một bên chịu trách nhiệm định nghĩa và hành vi agent, một bên chịu trách nhiệm thực thi và điều phối. Contract giữa hai bên phải được duy trì; nếu một bên đổi interface mà không thống nhất, mesh có thể vỡ. Chi phí tách còn đến từ việc thay đổi tư duy: thay vì "một stack làm hết", team phải nghĩ "agent là gì" tách với "chạy thế nào".
Thiết kế (design): Ranh giới vấn đề ở đây chỉ dừng ở mức nhu cầu tách và hậu quả khi gộp. Bài này không đi sâu từng capability cụ thể (pack, engine, three-tier, job trace…) — những thứ đó sẽ xuất hiện ở các mục sau và ở bài 2, 3. Ở mục 1 ta chỉ làm rõ: vấn đề là ownership và scale khi gộp; giải pháp hướng tới là tách hai hệ.
Giải pháp (solution): Hướng giải quyết là tách hai hệ — một hệ trả lời "agent là gì, làm gì", một hệ trả lời "chạy thế nào, điều phối ra sao". Hai hệ này bổ sung cho nhau qua contract rõ ràng (input/output, timeout, retry) và ownership rõ (ai định nghĩa capability, ai sở hữu job và trace).
Triển khai (implementation): Việc "triển khai" ở mức foundation không phải code hay config — mà là dẫn vào định nghĩa hai system. Bước tiếp theo trong bài là định nghĩa Agentic System và Orchestration System để reader có khung chung trước khi đào sâu từng capability.
2. Định nghĩa Agentic System
Giá trị (value): Agentic System trả lời câu hỏi nền tảng: agent là gì, có thể làm gì, giao diện và ứng xử thế nào. Hệ này mang lại giá trị khi mỗi "node" trong mesh có identity và capability rõ — orchestration không cần biết chi tiết prompt hay logic bên trong agent, chỉ cần biết contract (input, output, timeout). Nếu thiếu định nghĩa rõ, mesh sẽ không biết gọi đúng agent đúng task, và governance (quyền theo agent) cũng không thể enforce.
Thách thức (challenges): Định nghĩa Agentic System dễ trùng lặp với orchestration nếu ranh giới mơ hồ. Ví dụ: "gọi agent" — thuộc Orchestration (scheduling) hay Agentic (agent đăng ký capability)? Nếu không tách bạch, "agentic" có thể bị kéo sang phía "khi nào chạy, trace thế nào", và ngược lại orchestration bị lẫn với "agent có tool gì". Thách thức là giữ scope Agentic chỉ ở định nghĩa và hành vi, không ôm thêm thực thi hay trace.
Thiết kế (design): Agentic System chỉ bao gồm: pack (blueprint stateless), engine (runtime stateful), agent (personality, tool set, capability, behavior standard), design system (UI/UX nhất quán cho mọi touchpoint), và các capability hướng mesh (agent registry, pluggable personality, tool/data access scope). Nó không bao gồm job, trace, timeout, handoff protocol, hay quy tắc điều phối — những thứ thuộc Orchestration System. Ranh giới design: "định nghĩa và hành vi" vs "thực thi và điều phối".
Giải pháp (solution): Liệt kê capabilities thuộc Agentic System (S7): pack, engine, agent (personality, capability, behavior), design system, mesh-facing (registry, pluggable personality, per-agent permission). Bài 2 sẽ đi chi tiết từng capability; ở đây chỉ cần reader nắm scope — S7 là nơi "định nghĩa node" cho mesh.
Triển khai (implementation): Trong tổng thể kiến trúc (bảy layer, tám systems), Agentic System tương ứng với một trong tám systems — thường gọi là S7. Nó nằm cạnh Orchestration System (S8), Enterprise backbone (L1), Integration (L2), và các system khác. Vị trí S7 trong bức tranh 8 systems giúp reader sau này đào sâu từng system mà không nhầm lẫn phạm vi.
3. Định nghĩa Orchestration System
Giá trị (value): Orchestration System trả lời: job chạy thế nào, ai gọi ai, trace ở đâu, khi nào dừng hay chuyển bước. Giá trị là làm rõ "đường chạy" — mỗi job có lifecycle, mỗi bước có thể có timeout và retry, handoff giữa agent được chuẩn hóa, và toàn bộ có trace để debug và audit. Nếu thiếu hệ này, mesh sẽ không có cách thống nhất để điều phối nhiều agent, và không có run-log để kiểm soát cost và chất lượng.
Thách thức (challenges): Nếu gộp "gọi agent" vào Agentic System, ranh giới bị xóa: khi đó "orchestration" chỉ còn là "chạy từng bước" mà không sở hữu rõ job, trace, timeout. Ngược lại, nếu Orchestration ôm luôn định nghĩa personality hay tool set của agent, thì mỗi lần đổi "agent làm gì" lại đụng tới runtime. Thách thức là giữ Orchestration chỉ ở thực thi và điều phối — không định nghĩa agent.
Thiết kế (design): Orchestration System chỉ bao gồm: phân tầng (Master / Orchestrator / Specialist), capability budget và HITL (khi nào gọi người, khi nào timeout), job và trace và run-log, mesh node contract (input/output, timeout_sec, retry), và automation cycle (ví dụ plan → execute → verify). Nó không bao gồm định nghĩa personality, tool set, design system hay behavior standard — những thứ thuộc Agentic System. Ranh giới: "thực thi và điều phối" vs "định nghĩa và hành vi".
Giải pháp (solution): Liệt kê capabilities thuộc Orchestration System (S8): three-tier, capability budget & HITL, job/trace/run-log, mesh node contract, automation cycle. Bài 3 sẽ đi chi tiết từng capability; ở đây chỉ cần reader nắm scope — S8 là nơi "đường chạy" và "trace" cho mesh.
Triển khai (implementation): Trong kiến trúc tám systems, Orchestration System tương ứng với S8. Nó tích hợp với Agentic System (S7) qua contract: S7 cung cấp node (agent với capability rõ), S8 sở hữu job queue, trace, timeout và handoff. Runner (ví dụ Cursor hay automation engine) có thể thay đổi sau này; contract giữa S7 và S8 giữ nguyên nên mesh vẫn hoạt động. Chi tiết triển khai three-tier, mesh contract, run-log sẽ nằm ở series sau (three-tier & mesh, runtime & patterns).
4. Giá trị của tách bạch
Giá trị (value): Tách hai hệ mang lại ba lợi ích rõ ràng. Một: thay đổi độc lập — thay đổi "agent làm gì" (thêm tool, đổi personality) không đụng runtime điều phối; thay đổi "chạy thế nào" (timeout, retry, handoff format) không đụng định nghĩa agent. Hai: contract mesh ổn định — trong mesh, mỗi node là agent (thuộc Agentic) đăng ký với contract (input/output, timeout, retry); job, trace, timeout thuộc Orchestration; runner có thể đổi, contract giữ nguyên. Ba: governance rõ — quyền theo agent (agent nào được gọi tool gì, đọc data gì) vs quyền theo job (ai được tạo job, xem trace); hai hệ tương ứng hai góc governance (identity/permission và execution/audit).
Thách thức (challenges): Cần kỷ luật tuân contract giữa hai bên. Nếu bên Agentic đổi output format mà không thống nhất với Orchestration, hoặc bên Orchestration đổi input expectation mà không báo cho Agentic, mesh có thể lỗi. Văn hóa và quy trình (versioning contract, compatibility check) là thách thức vận hành.
Thiết kế (design): Mô hình thiết kế là node (Agentic) vs đường chạy (Orchestration). Node có identity và capability; đường chạy có job, bước, trace và quy tắc thời gian. Hai bên gặp nhau ở contract — input/output, timeout_sec, retry_count. Design này đảm bảo MECE: không có capability nào vừa thuộc "định nghĩa agent" vừa thuộc "điều phối job" một cách mơ hồ.
Giải pháp (solution): Contract chuẩn giữa node và orchestration: input (job_id, step_index, role, context, timeout_sec), output (status, output_path, retry_count, error_message). Runner (Cursor, automation engine, hay execution engine sau này) có thể đổi — contract giữ nguyên nên mesh vẫn hoạt động. Governance tách bạch: permission theo agent (tool/data scope) và audit theo job (trace, run-log) được enforce tại hai lớp tương ứng.
Triển khai (implementation): Mesh tự hành trong tương lai cần cả hai hệ: node đủ rõ (Agentic) và đường chạy đủ ổn định (Orchestration). Ở mức foundation, implementation không phải code — mà là vị trí trong kiến trúc: khi xây mesh, ta luôn có hai "chủ sở hữu" logic (S7 và S8) và một contract chung. Bài tiếp sẽ đi sâu Agentic System — pack, engine, agent, design system và mesh-facing — cách chúng phục vụ mesh.
5. Ranh giới với tám systems khác
Giá trị (value): Nêu rõ ranh giới với tám systems khác tránh hiểu nhầm S7 và S8 là toàn bộ kiến trúc. Kiến trúc đầy đủ còn có Enterprise backbone (hệ thống nghiệp vụ hiện tại), Integration (gateway, event, kết nối), Context governance, Evaluation, Lifecycle, v.v. S7 và S8 là hai system trung tâm cho agent và điều phối, nhưng không thay thế các system còn lại.
Thách thức (challenges): Enterprise backbone (L1), Integration (L2), và các layer khác chưa được đi sâu trong chuỗi bài này. Reader có thể thắc mắc "vậy S7, S8 nằm ở đâu trong bức tranh lớn?". Thách thức là mô tả đủ để định vị mà không đi lạc sang chi tiết từng system khác — những series sau sẽ bổ sung.
Thiết kế (design): S7 (Agentic) và S8 (Orchestration) nằm trong bức tranh bảy layer và tám systems. Layer và system là hai cách nhìn: layer theo chiều dọc (từ infrastructure tới experience), system theo nhóm capability (backbone, integration, agentic, orchestration, governance, …). S7 và S8 tương ứng với capability "định nghĩa và hành vi agent" và "thực thi và điều phối"; governance spine (identity, permission, audit) cắt ngang nhiều system và sẽ được nói rõ hơn ở bài 5.
Giải pháp (solution): Nêu ngắn gọn vị trí S7, S8 trong tám systems; chi tiết governance spine và framework vs personality sẽ ở bài 5. Không liệt kê đủ tám systems ở đây — chỉ nhấn mạnh S7 và S8 là hai trong số đó, và là nền tảng cho mesh agent tự hành.
Triển khai (implementation): Reader có bản đồ để đào sâu: biết S7 và S8 là gì, tại sao tách, và chúng nằm trong bức tranh lớn hơn. Khi triển khai thực tế (theo các series sau), có thể tham chiếu lại bài 1 để giữ ranh giới — không nhầm capability thuộc S7 sang S8 và ngược lại. Mapping tới quyết định kiến trúc (ADR) được lưu trong metadata bài; body không trích dẫn chi tiết.
Kết
Tách hai hệ — Agentic System (định nghĩa và hành vi agent) và Orchestration System (thực thi và điều phối) — giúp ownership rõ, thay đổi độc lập, contract ổn định cho mesh. Cần cả hai để tiến tới agent mesh tự hành. Bài tiếp: Agentic System — capabilities cho agent và mesh (pack, engine, agent, design system, mesh-facing).
