Agent mới không thiếu, thiếu tháp điều phối

Agent mới không thiếu, thiếu tháp điều phối

Omnigent đáng chú ý không vì thêm một agent nữa, mà vì đặt lại câu hỏi: team nên chuẩn hóa lớp điều phối hay tiếp tục chạy theo từng tool riêng lẻ?

“Anh ơi, task này Claude Code làm nửa chừng, Codex sửa tiếp được không?”

Một bạn dev trong team giả định của mình — gọi là team Vành Khuyên, 6 người, làm SaaS B2B ở Việt Nam — hỏi câu đó lúc gần hết sprint. Cả team đang dùng vài coding agent song song: một người thích terminal agent, một người dùng SDK, một người paste log qua lại giữa Slack, docs và web UI. Mọi thứ vẫn chạy. Chỉ có điều mỗi phiên làm việc giống một chuyến bay tự cất cánh, tự hạ cánh, không ai nhìn được toàn bộ bầu trời.

Rồi Omnigent xuất hiện.

Điểm đáng bàn không phải “lại có thêm tool agent mới à?”. Điểm đáng bàn là: khi agent ngày càng nhiều, lợi thế không nằm ở agent đơn lẻ, mà nằm ở lớp điều phối, chia sẻ và kiểm soát phía trên chúng.

Sơ đồ minh họa cho bài Agent mới không thiếu, thiếu tháp điều phối

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

Chuyện đang xảy ra: agent đã thành đội bay lộn xộn

Databricks mở nguồn Omnigent như một meta-harness cho AI agent. Harness ở đây là lớp bọc biến model thành agent có thể nhận message, đọc file, gọi tool và trả kết quả. Claude Code, Codex, Pi, OpenAI Agents SDK hay Claude Agents SDK đều có thể xem như các harness theo nghĩa vận hành.

Omnigent ngồi cao hơn một tầng. Nó không cố thay model, cũng không ép bạn bỏ tool đang dùng. Nó chuẩn hóa giao diện giữa các harness: message và file đi vào; text stream và tool calls đi ra. Từ đó, các agent khác nhau có thể được bọc trong session thống nhất, chia sẻ qua terminal, web UI, app hoặc API.

Nói thẳng ra thì Omnigent giống một tháp không lưu nhỏ cho team agent: không bay thay máy bay, nhưng biết chuyến nào đang ở đâu, ai được phép làm gì, và dữ liệu nào đang đi qua đường băng.

Với builder, đây là tín hiệu quan trọng hơn một release model mới. Vì nếu bạn đang có 4-5 agent trong workflow, vấn đề thật sự không còn là “agent nào thông minh hơn”, mà là:

Va chạm của team Vành Khuyên: model nhanh không cứu được workflow rối

Ví dụ cụ thể: team Vành Khuyên có một repo backend, một bộ docs nội bộ, một index vector dùng cho RAG, và vài script deploy. Một task phổ biến là sửa bug liên quan billing.

Cách cũ của họ:

  1. Dev A hỏi coding agent trong terminal.
  2. Agent đề xuất sửa code, nhưng thiếu context từ tài liệu pricing.
  3. Dev A copy đoạn docs sang prompt.
  4. Dev B dùng agent khác để viết test.
  5. Một phần log lỗi được paste lên Slack.
  6. Cuối cùng tech lead review lại bằng mắt, vì không biết agent nào đã đọc file nào.

Ở đây, nếu thay model bằng North Mini Code, DiffusionGemma, hay một model chạy nhanh hơn trên GPU, workflow vẫn có nhiễu động. Model nhanh hơn chỉ làm bạn đi qua đoạn rối nhanh hơn.

Các release gần đây đang đẩy mạnh ba hướng:

Những thứ này đáng theo dõi. Nhưng với team đang build hệ thống AI thật, câu hỏi cần đổi là: nâng cấp model có giải quyết đúng nút thắt không, hay bạn đang thiếu lớp vận hành phía trên?

Mổ xẻ Omnigent: thứ hay nằm ở ranh giới, không ở logo

Omnigent có hai mảnh chính: runner và server.

Runner bọc agent trong một sandboxed session — phiên cô lập để giảm rủi ro khi agent đọc file, chạy lệnh, hoặc gọi tool. Với builder, chữ “sandbox” không nên đọc như bảo mật tuyệt đối, mà như một lớp giảm thiệt hại: agent có phạm vi hoạt động rõ hơn thay vì lang thang khắp máy dev.

Server cung cấp policy và sharing. Policy là luật vận hành: ai được chạy gì, session nào được chia sẻ, tool nào được phép gọi. Server cũng expose session qua terminal, app và web API, nghĩa là một phiên agent không còn bị khóa trong cửa sổ terminal của một người.

Điểm mình thích là Omnigent không đặt cược vào một harness duy nhất. Nó nhìn ra một mẫu chung: dù bên trong Claude Code, Codex hay SDK gọi model kiểu gì, bề mặt người dùng vẫn khá giống nhau. Chuẩn hóa bề mặt đó giúp team thay agent mà không viết lại toàn bộ quy trình.

Nhưng đừng đọc nhầm: Omnigent không tự biến agent thành production system. Nó là lớp meta-harness, không phải bộ não toàn năng. Bạn vẫn phải tự lo model credentials, hạ tầng, policy, logging, dữ liệu nhạy cảm, và cách rollback khi agent sửa sai.

Framework cho builder: chọn đường băng trước khi chọn máy bay

Nếu là tech lead, mình sẽ không hỏi “có nên dùng Omnigent không?” ngay. Mình sẽ dùng khung 4 lớp này để quyết định.

| Lớp cần quyết | Câu hỏi kiểm tra | Khi nào Omnigent đáng thử |
|---|---|---|
| Interface | Team có dùng nhiều agent/harness không? | Có từ 2 agent trở lên và đang copy-paste context qua lại |
| Session | Phiên làm việc có cần mở lại, chia sẻ, audit không? | Có review chéo, handoff giữa dev, hoặc cần xem agent đã làm gì |
| Governance | Tool/file/terminal access có cần luật rõ không? | Agent có quyền chạy lệnh, sửa repo, chạm dữ liệu nội bộ |
| Observability | Khi sai, bạn có biết sai từ đâu không? | Câu trả lời hiện tại là “chắc do prompt” hoặc “không rõ” |

Điểm cuối rất quan trọng. Pinecone gần đây nhấn mạnh một bài học đau: vector database có thể không “sập”, nhưng vẫn trả kết quả kém vì index stale, thiếu tài nguyên, hoặc latency lệch dần. Với agent cũng vậy. Hệ thống có thể vẫn trả lời đều đều, nhưng đang âm thầm tạo output xuống cấp.

Observability — khả năng quan sát hệ thống qua metric, log, trace — trong thế giới agent không chỉ là đo latency. Bạn cần biết session nào gọi tool nào, file nào bị sửa, context nào được đưa vào, agent nào sinh quyết định cuối. Không có lớp này, bạn đang điều phối bằng cảm giác.

Điều nên giữ lại: chuẩn hóa trước, tối ưu sau

Từ Omnigent và các release model quanh nó, mình rút ra một thứ nên giữ: đừng để model choice là trung tâm kiến trúc quá sớm.

Với team Vành Khuyên, kế hoạch hợp lý trong một buổi chiều không phải là migrate toàn bộ sang tool mới. Họ có thể làm một spike nhỏ:

  1. Chọn một workflow hay đau: ví dụ “sửa bug + viết test + cập nhật changelog”.
  2. Ghi lại hiện trạng: agent nào dùng, file nào đọc, bước nào phải copy thủ công.
  3. Bọc 1-2 agent vào một lớp session chung bằng Omnigent hoặc một prototype tương tự.
  4. Định nghĩa policy tối thiểu: agent được đọc thư mục nào, được chạy lệnh nào, có được commit không.
  5. So sánh sau spike: số lần handoff, khả năng review session, mức độ dễ thay agent.

Giả sử team bạn 5 người, mỗi người đang dùng một agent khác nhau, mục tiêu của spike không phải “tăng năng suất 30%” — vì con số đó nếu không đo nghiêm túc chỉ là trang trí. Mục tiêu thực tế hơn là: lead có nhìn được đường đi của task không, dev khác có tiếp quản session không, và agent có bị giới hạn trong vùng an toàn không.

Nếu câu trả lời là có, bạn vừa tìm được một tầng kiến trúc đáng đầu tư.

Điều nên bỏ qua: FOMO theo từng release

Có ba thứ mình sẽ không vội nuốt trọn.

Thứ nhất, đừng coi meta-harness là lý do để nhồi thêm agent. Nhiều agent hơn không tự tạo ra workflow tốt hơn. Nếu policy mờ, orchestration — tức điều phối nhiều bước và nhiều tool — sẽ chỉ làm lỗi lan nhanh hơn.

Thứ hai, đừng lấy tốc độ token làm proxy cho hiệu quả team. DiffusionGemma hay MiMo/TileRT cho thấy tốc độ generation có thể tăng rất mạnh trong điều kiện phù hợp. Nhưng nếu task bottleneck ở review, context, quyền truy cập, hoặc test flaky, token nhanh chỉ làm màn hình chạy chữ đẹp hơn.

Thứ ba, đừng xem open-source là miễn phí vận hành. Apache 2.0 rất dễ chịu về license, nhưng chi phí thật nằm ở integration, security review, monitoring, training thói quen team, và người trực khi agent gây rối lúc deploy.

Vậy sau bài này, bạn nên nghĩ khác điều gì? Đừng hỏi “agent nào thắng?” trước. Hãy hỏi “lớp điều phối nào giúp mình thay agent mà hệ thống không vỡ?”

Omnigent đáng chú ý vì nó kéo cuộc nói chuyện từ model/harness đơn lẻ lên tầng hệ thống. Còn bạn có dùng nó hay tự build một lớp tương tự, quyết định nên dựa trên mức độ hỗn loạn hiện tại của workflow, không dựa trên độ ồn của release.

Chọn máy bay hay là việc thú vị. Nhưng nếu sân bay không có tháp điều phối, chuyến bay demo cất cánh đẹp mấy cũng khiến team dưới đất toát mồ hôi.

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

Nguồn tham khảo