Để xây dựng một super-agent tương tự như mô hình được DeepSeek Harness mô tả, hãy chia agent của bạn thành hai tầng: một phiên Router tồn tại lâu dài để tương tác với con người và điều phối công việc, cùng nhiều phiên Worker cô lập, mỗi phiên thực thi một tác vụ với đầy đủ bộ công cụ. Cung cấp dữ liệu đầu vào cho cả hai từ các Trigger sự kiện (chat, GitHub, CI), định tuyến các tương tác tiếp theo theo Thread, đồng thời bổ sung một Watchdog độc lập để giám sát mọi thứ.
Hướng dẫn này sẽ chuyển hóa bài viết thiết kế của DeepSeek Harness, “Exploring Super-agent Design”, thành một quy trình xây dựng cụ thể. Một điểm cần lưu ý: bài viết mô tả về mặt kiến trúc chứ không phải một tính năng đã phát hành chính thức. Một số phần của nó hiện diện trong plugin nguyên mẫu có tên là dsh-superagent-prototype, được các tác giả nhấn mạnh là “không phải sản phẩm chính thức của DeepSeek”. Mọi đoạn mã minh họa bên dưới đều chỉ nhằm mục đích giải thích, không phải mã nguồn của DeepSeek.
Super-agent là gì?
Super-agent là một đồng đội AI duy nhất, luôn trực tuyến, tiếp nhận sự kiện từ nhiều kênh (chat, pull request, CI), chạy song song nhiều tác vụ trong các phiên độc lập và phản hồi con người dưới một danh tính nhất quán duy nhất.
Vấn đề hiện nay: các phiên agent thường hoạt động tách biệt, và “một người thông thường chỉ có thể theo dõi cùng lúc từ 3 đến 5 phiên đang chạy”. Hiệ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.
Nó sở hữu bốn đặc điểm cốt lõi:
- Tính liền mạch (Continuous): một agent duy nhất hoạt động xuyên suốt từ ứng dụng chat (IM) đến GitHub. Bạn thảo luận Kế hoạch A trong tin nhắn, chuyển sang Kế hoạch B trong bình luận PR, và nó vẫn bắt kịp ngữ cảnh.
- Năng suất cao (Productive): chạy song song nhiều tác vụ và sẵn sàng nhận chỉ dẫn tiếp theo ngay cả khi chỉ dẫn trước đó chưa hoàn thành.
- Chủ động (Proactive): liên tục theo dõi các sự kiện và giữ im lặng trừ khi có việc thực sự cần đến nó.
- Bền bỉ (Persistent): luôn trực tuyến và có khả năng tự phục hồi khi gặp sự cố.
Nếu bạn mới tìm hiểu về chính harness này, hãy bắt đầu với bài viết DeepSeek Harness là gì và so sánh DeepSeek Harness với Claude Code.
Kiến trúc super-agent: năm module cốt lõi
Bài viết nêu ra năm module chính. Dưới đây là danh sách cùng bước xây dựng tương ứng cho từng module:
| Module | Vai trò | Bước xây dựng |
|---|---|---|
| Kiến trúc hai tầng (Two-level architecture) | Router điều phối, Worker thực thi | 1 |
| Trigger hướng sự kiện (Event-driven Triggers) | Chuyển đổi sự kiện từ chat, GitHub và CI thành đầu vào cho agent | 2 |
| Song công toàn phần, đa kênh (Full-duplex, multi-channel) | Công cụ bất đồng bộ, phản hồi thích ứng theo từng kênh | 4 |
| Tách biệt tính toán, trạng thái và môi trường (Compute, state, environment split) | Vòng lặp không trạng thái, lưu trạng thái trong DB, giữ nguyên môi trường máy | 5 |
| Watchdog | Phiên riêng biệt để kiểm tra tiến độ và lỗi | 6 |
Bước 1: Tách biệt Router khỏi các Worker
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 dài, đầu ra ngắn, được gộp chung trong giai đoạn prefill.
Mỗi Worker là một phiên cô lập riêng cho từng tác vụ. Nó được trang bị đầy đủ công cụ và sử dụng mô hình mạnh nhất mà bạn có thể đáp ứng. Worker không bao giờ giao tiếp trực tiếp với con người mà chỉ báo cáo lại cho Router. Bản thân một Worker cũng có thể sử dụng các subagent 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ô hình này.
# Illustrative sketch, not DeepSeek's code
class Router:
def on_events(self, batch): # triggers arriving mid-turn are batched
plan = self.llm_light.decide(batch) # dispatch, reply, or ignore
for task in plan.new_tasks:
Worker.spawn(task, model="strongest", tools="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, một payload từ Slack 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.
- 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”.
- 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 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 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ỏng đoán (speculative execution): trong nhóm người dùng thử nghiệm của họ, chính sách “âm thầm tái hiện và sửa lỗi” chỉ gửi đi bản sửa lỗi đơn giản đã được kiểm chứng, còn lại sẽ hoàn toàn giữ im lặng.
Bước 5: Tách biệt tính toán, trạng thái và môi trường
Hãy chạy vòng lặp của agent trong các container đám mây không trạng thái (stateless) và lưu trữ trạng thái phiên làm việc trong cơ sở dữ liệu. Môi trường sẽ được giữ nguyên tại chỗ: mỗi máy chạy một tiến trình ngầm (daemon) gọn nhẹ, mà bài viết gọi là BYOM (Bring Your Own Machine - Mang máy của riêng bạn). Nếu một vòng lặp gặp sự cố và dừng đột ngột, nó có thể khởi động lại ở bất cứ đâu và tải lại trạng thái của mình, trong khi các kho mã nguồn (repo) vẫn nằm nguyên vẹn trên máy cục bộ.
Bài viết dẫn chứng bài viết “Scaling Managed Agents: Decoupling the brain from the hands” 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ỳ, nằm ngoài hệ thống chính. Nó xử lý các lỗi API và truy vấn mô hình xem từng Worker có đang tiến triển hay đang đi chệch hướng. Đội ngũ bảo trì cũng có thể trực tiếp hỏi Watchdog lý do vì sao một tác vụ nào đó thất bại. Hãy đặt Watchdog bên ngoài tiến trình của Router để khi Router bị treo thì hệ thống giám sát này cũng không bị sập theo.
Kết quả từ các thử nghiệm
Các tác giả đã thử nghiệm với khoảng 300 tin nhắn chat và thông báo CI chứa khoảng 20 yêu cầu công việc, mô phỏng quá trình lập trình bằng bộ đếm thời gian và chạy mỗi cấu hình 5 lần. Họ lưu ý rằng kết quả này “chỉ mang tính chất tham khảo”.
| Cấu hình | p50 (phút) | p95 (phút) | Token đọc từ cache mỗi lượt chạy |
|---|---|---|---|
| Super-agent | 12.4 | 15.7 | 23.2M |
| Không có Thread pass-through | 12.6 | 15.5 | 31.8M |
| Phiên đơn lẻ + công cụ subagent, prompt trung tính | 20.4 | 29.5 | 6.1M |
| Phiên đơn lẻ, prompt ưu tiên ủy quyền | 13.8 | 29.0 | 10.8M |
Có hai phát hiện nổi bật. Với prompt trung tính, phiên đơn lẻ không hề ủy quyền tác vụ trong cả 5 lần chạy, khiến p95 của nó cao gần gấp đôi so với super-agent. Prompt ưu tiên ủy quyền đã cải thiện được giá trị trung vị (median) nhưng không giải quyết được phần đuôi phân phối (tail). Super-agent tiêu tốn nhiều token hơn so với một phiên đơn lẻ, đồng nghĩa với việc bạn đang đánh đổi token để lấy độ trễ thấp hơn và tiết kiệm sự chú ý của con người.
Một thử nghiệm thứ hai đã kiểm tra tải riêng trên Router. Khi số lượng Trigger tăng từ 1 lên 40 mỗi 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 (batching) chính là yếu tố giúp một Router đơn lẻ không sớm trở thành điểm nghẽn cổ chai của hệ thống.
Kiểm thử điểm tiếp nhận Trigger với Apidog CLI
Mỗi Trigger ban đầu đều là một HTTP request gửi tới endpoint tiếp nhận của bạn, vì vậy endpoint này là hạng mục đầu tiên rất đáng để kiểm thử. Nếu nó bỏ sót một bình luận PR hoặc cấp một thread_id mới cho mỗi sự kiện, việc định tuyến theo Thread sẽ bị hỏng và mọi tương tác tiếp theo sẽ lại phải đi vòng qua Router. Hãy để agent lập trình của bạn viết và thực thi bài kiểm thử đó với Apidog CLI.
npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com # pick your agent when prompted
Sau đó, hãy đưa cho agent của bạn prompt sau:
In Apidog project <id>, create POST /triggers/github for a GitHub
pull_request_review_comment webhook. Add a test case that sends two
comments on the same PR and asserts: status 202, a trigger_id in the
body, and the same thread_id both times. Run it against staging and
summarize any failures.
Agent sẽ đọc schema của từng payload, xác thực JSON, tạo endpoint cùng trường hợp kiểm thử (test case) và tiến hành chạy:
apidog cli-schema get endpoint-create
apidog cli-schema validate endpoint-create --file endpoint.json
apidog endpoint create --project <id> --file endpoint.json
apidog cli-schema get test-case-create
apidog cli-schema validate test-case-create --file case.json
apidog test-case create --project <id> --file case.json
apidog run --test-case <caseId> --project <id> -e <stagingEnvId> -r cli,json
Lệnh gọi apidog run tương tự với tham số -r junit có thể tích hợp trực tiếp vào pipeline của bạn; xem thêm bài viết Apidog CLI trong CI/CD. Nếu agent của bạn chính là DeepSeek Harness, hãy làm theo hướng dẫn thiết lập này; đối với Claude Code, hãy tham khảo hướng dẫn tại đây. Gói Free của Apidog hỗ trợ tối đa tới 4 người dùng.
Những thách thức còn bỏ ngỏ
Bài viết cũng liệt kê những vấn đề hiện vẫn chưa có lời giải đáp hoàn chỉnh:
- Mở rộng quy mô Router và lựa chọn mô hình kiến trúc Worker phù hợp khi tải hệ thống tăng cao.
- Bộ nhớ dài hạn (Long-term memory) vượt ra ngoài phạm vi của Chuỗi truy hồi (Chain of Recall).
- Trải nghiệm người dùng (UX) không phụ thuộc phiên: cách điều hướng một agent khi không còn một cửa sổ chat tập trung duy nhất.
- Ranh giới ngữ cảnh và giao thức giao tiếp giữa các agent (agent-to-agent), trong đó A2A là một ứng viên tiềm năng.
- Bảo mật. Một cuộc tấn công prompt injection lọt vào vòng lặp đám mây có thể lan sang mọi cỗ máy kết nối, đồng thời thông tin xác thực trong ngữ cảnh có nguy cơ bị rò rỉ. Các tác giả mong muốn agent có thể sử dụng thông tin xác thực mà không bao giờ trực tiếp nhìn thấy chúng.
Câu hỏi thường gặp (FAQ)
Super-agent có phải là một tính năng có sẵn trong DeepSeek Harness mà tôi có thể bật lên dùng ngay không? Không. Bài viết chỉ mô tả về mặt kiến trúc. Một số phần hiện có trong plugin dsh-superagent-prototype, được các tác giả nêu rõ là không phải sản phẩm chính thức của DeepSeek. Các công cụ song công toàn phần (full-duplex) đã được hiện thực hóa nhưng mặc định đang tắt.
Tại sao Router lại sử dụng mô hình nhẹ hơn? Nó chỉ đảm nhận việc điều phối và giao tiếp với con người; nó không bao giờ thực thi tác vụ hay cần đến Bash. Các Worker mới là nơi thực hiện các tác vụ suy luận phức tạp bằng mô hình mạnh nhất.
Super-agent khác gì so với một nhóm agent (agent team)? Trưởng nhóm (team lead) phân chia một tác vụ có tính liên kết cao thành nhiều phần nhỏ. Còn Router chỉ điều phối các tác vụ hoàn toàn độc lập. Một Worker có thể tự vận hành một nhóm agent riêng bên trong super-agent.
Thread pass-through là gì? Các sự kiện tiếp nối trên một PR, chủ đề IM hoặc chuỗi trao đổi email sẽ được chuyển thẳng đến Worker nắm giữ Thread đó, bỏ qua... [truncated 795 chars]