Cách Xây Dựng Super-Agent Như DeepSeek: Giải Mã Router, Worker và Trigger

Posted on Nov 4 • Originally published at apidog.com

ệu quả của một tác vụ đơn lẻ bị giới hạn bởi năng lực mô hình, trong khi khả năng đa nhiệm lại bị giới hạn bởi sự chú ý của con người. Super-agent được tạo ra nhằm giải quyết giới hạn thứ hai này.

Router là một phiên làm việc tồn tại lâu dài. Nó xử lý toàn bộ hoạt động tương tác với con người cùng việc điều phối, và không bao giờ tự mình thực thi tác vụ. Router có thể vận hành mà không cần đến công cụ Bash, đồng thời chỉ cần một mô hình nhẹ hơn, tiết kiệm chi phí hơn là đủ. Khi có nhiều Trigger cùng gửi đến trong một lượt xử lý của Router, chúng sẽ được gom thành một đợt (batch) cho lần gọi tiếp theo: đầu vào hoặc hoạt động như một nhóm agent hoàn chỉnh.

Đừng nhầm lẫn mô hình này với một nhóm agent (agent team). Trưởng nhóm (team lead) sẽ phân rã một tác vụ có tính liên kết chặt chẽ; trong khi Router chỉ điều phối các tác vụ độc lập với nhau. Bạn hoàn toàn có thể kết hợp cả hai môall", report_to=self) for msg in plan.replies: self.channels.send(msg) # only the Router speaks to humans

## Bước 2: Chuyển đổi sự kiện thành các Trigger Mọi đầu vào gửi tới super-agent đều là một Trigger: từ một tin nhắn chat, một [ sự kiện webhook của GitHub ]( https://docs.github.com/en/webhooks/webhook-events-and-payloads ), một payload từ [ Slack Events API ]( https://docs.slack.dev/apis/events-api/ ) cho đến một CI callback. Phần lớn trong số chúng hoàn toàn không cần chuyển tới mô hình ngôn ngữ, vì vậy bài viết đề xuất lọc qua hai lượt. 1. **Lượt nhanh, bằng mã nguồn (Fast path).** Lọc theo nguồn, nhóm, cùng danh sách cho phép (allowlist) của người dùng hoặc bot.

Mỗi nguồn sẽ được gán một chế độ: "chỉ phản hồi khi có yêu cầu rõ ràng", "ứng viên tiềm năng" hoặc "bỏ qua". 2. **Lượt chậm, bằng LLM (Slow path).** Các ứng viên tiềm năng được chuyển đến mô hình để áp dụng những chính sách viết dưới dạng prompt, chẳng hạn như "phản hồi khi có ai đó báo cáo lỗi trong kênh này". Endpoint tiếp nhận dữ liệu của bạn nên xác nhận phản hồi thật nhanh và xử lý tác vụ sau. [ Quy chuẩn webhook tốt nhất ]( https://docs.github.com/en/webhooks/using-webhooks/best-practices-for-using-webhooks ) của GitHub yêu cầu bạn phải phản hồi mã 2XX trong vòng 10 giây—điều mà một lượt gọi mô hình không thể đảm bảo.

Hãy trả về `202 Accepted`, đưa Trigger vào hàng đợi (queue) và để Router xử lý sau. Hướng dẫn của chúng tôi về [ thiết kế webhook đáng tin cậy ]( https://apidog.com/vi/blog/how-to-design-reliable-webhooks?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation ) sẽ trình bày chi tiết về cơ chế thử lại (retry) và tính lũy đẳng (idempotency) cho tầng này. ## Bước 3: Định tuyến các tương tác tiếp theo theo Thread Một **Thread** là một chuỗi các sự kiện liên tiếp diễn ra trên cùng một PR, một chủ đề chat (IM topic) hoặc một chuỗi email trao đổi. Worker được khởi tạo từ sự kiện đầu tiên của Thread sẽ đăng ký theo dõi Thread đó.

Các sự kiện tiếp theo sau đó sẽ được chuyển thẳng tới Worker này mà không cần thông qua lệnh gọi đến Router. Cơ chế ánh xạ ở đây là quan hệ nhiều - nhiều. Nếu hai Worker cùng tác động lên một PR, cả hai đều sẽ nhận được các sự kiện của PR đó, và chúng có thể giải quyết xung đột trực tiếp thông qua PR mà không cần nhắn tin qua lại với nhau.

Bỏ qua bước này, bạn sẽ phải trả giá đắt: trong thử nghiệm của bài viết, việc loại bỏ cơ chế chuyển tiếp trực tiếp (pass-through) khiến Router phải đưa ra quyết định nhiều hơn khoảng 30% và làm tăng lượng token tiêu thụ thêm khoảng 37%. ## Bước 4: Xem ngữ cảnh như bộ nhớ đệm và chuyển đổi công cụ sang bất đồng bộ Router không thể lưu trữ toàn bộ dữ liệu, do đó bài viết coi ngữ cảnh như một bộ nhớ đệm (cache): - **Lưu trực tiếp (Inline)** những thông tin có khả năng cần đến: ID, bản tóm tắt ngắn, các tin nhắn lân cận. - **Đẩy ra ngoài (Spill)** phần còn lại: cắt ngắn dữ liệu và để lại một con trỏ (pointer) để agent có thể truy xuất khi cần. Các định danh (ID) ổn định của Trigger, Thread và Worker tạo nên một đồ thị tham chiếu mà các tác giả gọi là "Chuỗi truy hồi" (Chain of Recall). Agent có thể chuyển tiếp từ một Trigger đến Thread tương ứng, rồi đến Worker đã xử lý nó, mang lại khả năng truy hồi qua nhiều bước (multi-hop recall) mà không cần nhồi nhét một prompt khổng lồ.

Tiếp theo, hãy chuyển sang cơ chế **song công toàn phần (full-duplex)**. Thay thế công cụ `run()` mang tính đồng bộ/chặn (blocking) bằng các lệnh bất đồng bộ `start()` và `stop()`. Lệnh `start()` sẽ trả về trạng thái "Started" ngay lập tức, và kết quả sẽ được gửi đến sau dưới dạng một sự kiện mới. Điều này cho phép agent tiếp nhận chỉ dẫn tiếp theo của bạn ngay cả khi tác vụ trước đó vẫn đang chạy.

Bài viết cho biết DeepSeek Harness đã hiện thực hóa cơ chế này nhưng chưa kích hoạt mặc định. Cuối cùng, hãy thiết kế các câu trả lời **thích ứng theo kênh (channel-aware)**. Quy tắc được thử nghiệm giới hạn phản hồi trên các ứng dụng chat (IM) ở mức dưới 100 từ, trong khi các nội dung trên GitHub, email và tài liệu sẽ được trình bày chi tiết, có cấu trúc chặt chẽ.

Cơ chế này cũng mở đường cho ** thực thi ph brain from the hands"](https://www.anthropic.com/engineering/managed-agents) của Anthropic như một ý tưởng tương đồng, nhưng nhắm đến các sandbox được quản lý thay vì máy của chính bạn. ## Bước 6: Bổ sung thêm Watchdog Watchdog là một phiên độc lập chạy theo lịch trình định kỳ phút, kích thước batch tăng từ 1.0 lên 2.8 và thời gian xử lý mỗi yêu cầu tăng từ 2.5 giây lên 3.9 giây, trong khi thời gian cho mỗi quyết định lại giảm từ 6.4 giây xuống 1.6 giây. Xử lý theo đợt (batch://apidog.com/apidog-cli/?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation). Enter fullscreen mode Exit fullscreen mode bash npm install -g apidog-cli@latest apidog auth login --with-token npx -y skills add https://apidog.com # pick your agent when prompted