When Coding Agents Watch GitHub: A Practical Safety Checklist Before They Open PRs
A coding agent that waits for a prompt is easy to understand. You give it a task, watch the run, and review the result. An agent that watches issues and comments changes the arrangement. It may notice a request, decide whether it is allowed to act, create a separate work session, and return a pull request later.
The deepseek-ai GitHub organization hosts a public dsh-superagent research prototype, but its README explicitly says it is not an official DeepSeek product. The README describes it as reference research code, not production-ready software. Its value here is as a design case: the project makes permission and review questions visible.
This is not a setup guide for that prototype. I have not installed or tested it. The checklist below is a safer way to evaluate any system that turns GitHub activity into coding work.
A new input is also a new trust boundary
The prototype's flow is more than "issue in, code out." Its documentation describes sources that receive events, policies that decide who may request work, tickets that hold tasks, and executors that do the coding. Work can return to the conversation where it started. Its setup guide recommends a dedicated agent account and an initial observe mode for work inferred from activity, rather than immediately executing it.
That separation matters. A public issue is not automatically an authorized instruction. A comment can include misleading requests, hostile text, or copied instructions from an untrusted source. If that text reaches a model connected to a shell and a write-capable account, it is part of the system's input whether or not the author intended it as a command.
GitHub's own Actions security guidance makes a related point: workflow credentials should have the least privilege needed, and default token permissions should be read-only where possible. The same principle applies to an agent. Its model may be capable, but its permissions should assume that some inputs will be wrong or malicious.
What the prototype gets right, and what it does not prove
The project draws a useful line between a direct request from an allowed person and work inferred from ambient activity. In its documented setup, inferred work begins in observe mode. The operator can see what the system would have done before enabling that behavior. The guide also advises using a dedicated GitHub identity, keeping it separate from the operator's personal account, and requiring human review rather than enabling automatic merging as the default.
Those are good starting choices, not a security certification. The same deployment documentation warns that its worker sessions run with broad operating-system access under the operator's user. The account wrappers select GitHub credentials, but they do not isolate the process. A worker may still run programs by path and read files in that user's home directory. The docs recommend a dedicated OS account for isolation.
This is the important distinction: separate GitHub identity is not the same as a sandbox. A bot account limits how the agent appears and what it can do in the repository. It does not, by itself, limit what code running on the host can read or execute.
The checklist: start with observation, not autonomy
Before connecting any always-on coding agent to a real repository, answer these questions in order.
1. Which events can create work?
Start with explicit mentions from a small set of trusted accounts. Avoid treating every new issue, every comment, or every conversation as permission to run code. If the tool supports inferred work, keep it in a mode that records candidate tasks without executing them until you have inspected its decisions.
Write the rule down in plain language. For example: "Only a new comment that mentions the agent, from an approved account, can start a task." That is easier to test than a vague instruction such as "help with relevant issues."
2. Who is allowed to ask?
Use an explicit allowlist. Do not assume that repository visibility, team membership, or an issue label is enough to establish intent. Review who can add accounts to the list and how quickly removals take effect.
Try negative tests before real work: an unapproved account mentions the agent; a bot posts a comment; a user edits an old issue to add a mention. The expected result should be no execution and a clear record of why the request was rejected.
3. What can the agent's GitHub identity change?
Create a separate account for the agent, then grant only the repository access required for its task. Keep merge rights with people. Make the agent's branches easy to identify, and ensure its comments and commits are visibly attributed to the agent rather than to a human maintainer.
Review token scopes and repository permissions directly. If the agent only needs to read issues and create branches or pull requests, do not give it organization-wide administration or access to unrelated repositories. Recheck permissions when the tool or workflow changes.
4. What can the process read on the host?
This is easy to miss when setup instructions focus on GitHub accounts. Find out which operating-system user runs the agent, which directories it can read, whether its shell can access environment variables, and where credentials are stored. Check whether its tools can reach internal network services.
Use a dedicated OS account or a properly isolated execution environment when the agent handles untrusted issue text. Keep secrets out of the agent's checkout and home directory where possible. A wrapper that changes which GitHub account a command uses is helpful, but it is not a process sandbox.
5. Can text in the task change what the agent is allowed to do?
Prompt instructions are not a permission boundary. Define limits outside the model too: allowed repositories, allowed commands, network access, branch rules, and whether secrets are available. Treat instructions quoted inside issues, pull requests, logs, and linked pages as untrusted data unless a trusted person explicitly confirms the task.
6. What has to pass before a pull request is ready?
Require the same checks you expect from a human contribution: tests, formatting, dependency review, and a human reading the diff. The agent should explain what it changed, which tests it ran, and what it could not verify. A green check means the configured checks passed; it does not mean the request was safe or correct.
Keep automatic merge disabled while you learn how the agent behaves. A pull request is a review boundary, not a guarantee. If the agent can merge its own changes, review whether that permission is genuinely necessary and what happens when tests are incomplete or the change touches sensitive code.
7. How will you stop and investigate it?
Know how to pause event intake, stop active workers, revoke credentials, and inspect logs before enabling the service. Decide who receives alerts for stuck tasks, repeated retries, or unexpected repository writes. Test the stop path before the agent has access to valuable credentials.
A low-risk rollout in three stages
A small rollout makes failures easier to understand.
- Stage one: observe. Connect a test repository or a narrow set of events. Let the system record what it would do. Compare its decisions with what maintainers actually want.
- Stage two: prepare changes. Permit a dedicated account to create branches and draft pull requests in a low-risk repository. Keep a person responsible for every review and merge.
- Stage three: expand one permission at a time. Add more requesters or repositories only after you have checked false triggers, quality, noisy behavior, and recovery. Do not change event access, host access, and merge rights together. If something goes wrong, you need to know which new permission caused it.
Keep a short record of expected behavior for test cases: who requested work, what event started it, what the agent was allowed to do, which checks ran, and who approved the result. This creates evidence for a decision to widen access, rather than relying on a few impressive demonstrations.
The useful idea is the workflow, not the word "autonomous"
DeepSeek's prototype points to a real design problem: a team may want one agent to carry work across messages, code changes, and review comments without making people restate the task in every session. That can save coordination effort. It also means the agent becomes a long-running participant with access to event streams and execution tools.
The project itself is careful to label its public implementation as a research reference, not production-ready software. Its documentation also exposes tradeoffs that a launch headline can hide, including broad host access and the need for a separate operating-system boundary. Those caveats are reasons to test it as an operations system, evaluating both its code and the safeguards around it.
A useful rule is simple: automate the preparation of a change before automating permission to apply it. Start with narrow inputs, limited credentials, isolated execution, visible drafts, and human approval. Expand only when the logs show that the system follows those limits consistently.
Before enabling an issue-to-PR agent, check:
- Only approved people can create an executable request.
- Inferred work is observed before it is allowed to run.
- The agent uses a dedicated, narrowly scoped GitHub identity.
- Its operating-system access is isolated from personal files and secrets.
- Pull requests require human review and do not merge themselves.
- You can pause the service, revoke access, and inspect its actions.
I write about software engineering and AI systems. Subscribe if you want practical, source-based guides like this one.
Have you let an agent act on GitHub issues or pull requests? What permission limit would you set first?
Sources: DeepSeek dsh-superagent prototype, DeepSeek setup guide, DeepSeek deployment and permissions guide, DeepSeek project philosophy, GitHub Actions secure use reference.
DeepSeek’s Super-agent Wants Less of Your Attention. Test That Claim.
A bot can finish useful work and still make a team slower by asking everyone to watch it happen. DeepSeek’s October 31 code drop makes that problem unusually explicit: its Super-agent prototype is designed around conserving human attention. The practical test is whether people can find the result and act at the right moment with fewer unnecessary interruptions.
Disclosure: This article was generated and fact-checked with AI using the public sources linked here. It was published through an automated workflow and has not been reviewed by Keith.
The repository describes a coding agent scoped to one GitHub repository, with optional Feishu input, separate work sessions, and replies in the originating conversation. It also labels the code a research prototype, not an official DeepSeek product or production-ready software. The public implementation differs from its internal version. This is an inspectable design to learn from, not evidence that every team can deploy an autonomous colleague and immediately save time.
Its philosophy document treats messages and notifications as costs. Its communication policy distinguishes internal work from a result someone can use or a decision someone must make. That is a useful design constraint for operational software as well as coding agents.
A status change does not always deserve an interruption
The Garden case study documents connected staff work, follow-up owners, due dates, and workflow states. Garden Work extends a self-hosted Plane Community foundation, with access projected from the wider platform. The replacement of Planning Center remains staged, with migration and staff acceptance still requiring contextual completion. Nothing in that case study claims a deployed DeepSeek integration.
Consider a proposed assistant for an isolated staff-work demonstration. It prepares a summary for a task owner. While working, it loads the task, revises the draft, retries a temporary lookup, and produces a reviewable summary. Each event is worth retaining in the execution record. Sending four chat updates would ask the owner to inspect activity that may not change what they can do.
Define the notification around the recipient’s next action. “The summary is ready to review” can point to a stable draft. A question can identify the missing decision. A failure can explain what remains unavailable. “Still processing” needs a reason tied to the task’s expectations, rather than being emitted whenever the agent changes state.
That distinction belongs in application logic. Keep an internal event history and a separate notification decision. A worker retry should not automatically become a staff message just because both pass through the same event system. The system can remain observable without making a person its live log viewer.
Before dispatching a delayed notification, check the task’s current owner and state. A summary prepared for an earlier owner may no longer require their attention. If the task was canceled, a queued “ready for review” message could create unnecessary work. Use an explicit delivery record so replaying the same ready event does not produce another interruption. These are proposed implementation choices, not reported Garden features or DeepSeek guarantees.
Measure what the quiet version makes people miss
A useful pilot compares notification behavior on the same fictional task history. Run one version that announces routine transitions and another that reserves interruptions for agreed outcomes and exceptions. Keep the underlying task results identical. Otherwise, fewer messages might simply mean the quieter version did less work.
Ask participants to identify what needs their attention, open the relevant result, and choose the next step. Record unnecessary messages alongside missed decisions and the time required to locate the deliverable. If the quiet version hides a blocked task until its deadline passes, the smaller message count is not an improvement.
Include a change of owner and a canceled task in the replay. Deliver a repeated event, too. Those cases reveal whether the system notifies the person responsible now, suppresses obsolete work, and avoids turning one result into several alerts. Use synthetic records so the exercise does not expose real member notes or contact details.
Agree on silence expectations before the pilot. A background task expected to finish later can expose status in a work view. A time-sensitive task may need an exception notification when its expected completion window is no longer credible. A direct request for status also deserves an answer. Suppression should remove interruptions that offer no useful action; it should not conceal a broken promise.
DeepSeek’s communication instructions keep detailed engineering evidence in the work record while making the outbound message brief and useful. Apply the same separation to the proposed staff assistant: keep the summary, relevant evidence, and unresolved limitations available at the linked destination. A short notification should not require the recipient to reconstruct the task from scattered messages.
There is a cost to maintaining that separation. Delivery records, cancellation checks, and recipient selection need ownership and testing. For a small, infrequent workflow, a simple manual update may be easier to operate. For a busier system, a notification policy becomes part of the product’s usefulness.
DeepSeek has published a goal about attention, not a measured result for another organization. The worthwhile experiment is to see whether quieter delivery preserves timely decisions. Count the interruptions, then check whether the right person still knows what to do.
Mentions
When Coding Agents Watch GitHub: A Practical Safety Checklist Before They Open PRs A coding agent that waits for a prompt is easy to understand. You give it a task, watch the run, and review the result. An agent that watches issues and comments changes the arrangement. It may notice a request, decide whether it is allowed to act, create a separate work session, and return a pull request later. The deepseek-ai GitHub organization hosts a public dsh-superagent research prototype, but its README explicitly says it is not an official DeepSeek product. The README describes it as reference research code, not production-ready software. Its value here is as a design case: the project makes permission and review questions visible. This is not a setup guide for that prototype. I have not installed or tested it. The checklist below is a safer way to evaluate any system that turns GitHub activity into coding work. A new input is also a new trust boundary The prototype's flow is more than "issue in, code out." Its documentation describes sources that receive events, policies that decide who may request work, tickets that hold tasks, and executors that do the coding. Work can return to the conversation where it started. Its setup guide recommends a dedicated agent account and an initial observe mode for work inferred from activity, rather than immediately executing it. That separation matters. A public issue is not automatically an authorized instruction. A comment can include misleading requests, hostile text, or copied instructions from an untrusted source. If that text reaches a model connected to a shell and a write-capable account, it is part of the system's input whether or not the author intended it as a command. GitHub's own Actions security guidance makes a related point: workflow credentials should have the least privilege needed, and default token permissions should be read-only where possible. The same principle applies to an agent. Its model may be capable, but its permissions should assume that some inputs will be wrong or malicious. What the prototype gets right, and what it does not prove The project draws a useful line between a direct request from an allowed person and work inferred from ambient activity. In its documented setup, inferred work begins in observe mode. The operator can see what the system would have done before enabling that behavior. The guide also advises using a dedicated GitHub identity, keeping it separate from the operator's personal account, and requiring human review rather than enabling automatic merging as the default. Those are good starting choices, not a security certification. The same deployment documentation warns that its worker sessions run with broad operating-system access under the operator's user. The account wrappers select GitHub credentials, but they do not isolate the process. A worker may still run programs by path and read files in that user's home directory. The docs recommend a dedicated OS account for isolation. This is the important distinction: separate GitHub identity is not the same as a sandbox. A bot account limits how the agent appears and what it can do in the repository. It does not, by itself, limit what code running on the host can read or execute. The checklist: start with observation, not autonomy Before connecting any always-on coding agent to a real repository, answer these questions in order. 1. Which events can create work? Start with explicit mentions from a small set of trusted accounts. Avoid treating every new issue, every comment, or every conversation as permission to run code. If the tool supports inferred work, keep it in a mode that records candidate tasks without executing them until you have inspected its decisions. Write the rule down in plain language. For example: "Only a new comment that mentions the agent, from an approved account, can start a task." That is easier to test than a vague instruction such as "help with relevant issues." 2. Who is allowed to ask? Use an explicit allowlist. Do not assume that repository visibility, team membership, or an issue label is enough to establish intent. Review who can add accounts to the list and how quickly removals take effect. Try negative tests before real work: an unapproved account mentions the agent; a bot posts a comment; a user edits an old issue to add a mention. The expected result should be no execution and a clear record of why the request was rejected. 3. What can the agent's GitHub identity change? Create a separate account for the agent, then grant only the repository access required for its task. Keep merge rights with people. Make the agent's branches easy to identify, and ensure its comments and commits are visibly attributed to the agent rather than to a human maintainer. Review token scopes and repository permissions directly. If the agent only needs to read issues and create branches or pull requests, do not give it organization-wide administration or access to unrelated repositories. Recheck permissions when the tool or workflow changes. 4. What can the process read on the host? This is easy to miss when setup instructions focus on GitHub accounts. Find out which operating-system user runs the agent, which directories it can read, whether its shell can access environment variables, and where credentials are stored. Check whether its tools can reach internal network services. Use a dedicated OS account or a properly isolated execution environment when the agent handles untrusted issue text. Keep secrets out of the agent's checkout and home directory where possible. A wrapper that changes which GitHub account a command uses is helpful, but it is not a process sandbox. 5. Can text in the task change what the agent is allowed to do? Prompt instructions are not a permission boundary. Define limits outside the model too: allowed repositories, allowed commands, network access, branch rules, and whether secrets are available. Treat instructions quoted inside issues, pull requests, logs, and linked pages as untrusted data unless a trusted person explicitly confirms the task. 6. What has to pass before a pull request is ready? Require the same checks you expect from a human contribution: tests, formatting, dependency review, and a human reading the diff. The agent should explain what it changed, which tests it ran, and what it could not verify. A green check means the configured checks passed; it does not mean the request was safe or correct. Keep automatic merge disabled while you learn how the agent behaves. A pull request is a review boundary, not a guarantee. If the agent can merge its own changes, review whether that permission is genuinely necessary and what happens when tests are incomplete or the change touches sensitive code. 7. How will you stop and investigate it? Know how to pause event intake, stop active workers, revoke credentials, and inspect logs before enabling the service. Decide who receives alerts for stuck tasks, repeated retries, or unexpected repository writes. Test the stop path before the agent has access to valuable credentials. A low-risk rollout in three stages A small rollout makes failures easier to understand. - Stage one: observe. Connect a test repository or a narrow set of events. Let the system record what it would do. Compare its decisions with what maintainers actually want. - Stage two: prepare changes. Permit a dedicated account to create branches and draft pull requests in a low-risk repository. Keep a person responsible for every review and merge. - Stage three: expand one permission at a time. Add more requesters or repositories only after you have checked false triggers, quality, noisy behavior, and recovery. Do not change event access, host access, and merge rights together. If something goes wrong, you need to know which new permission caused it. Keep a short record of expected behavior for test cases: who requested work, what event started it, what the agent was allowed to do, which checks ran, and who approved the result. This creates evidence for a decision to widen access, rather than relying on a few impressive demonstrations. The useful idea is the workflow, not the word "autonomous" DeepSeek's prototype points to a real design problem: a team may want one agent to carry work across messages, code changes, and review comments without making people restate the task in every session. That can save coordination effort. It also means the agent becomes a long-running participant with access to event streams and execution tools. The project itself is careful to label its public implementation as a research reference, not production-ready software. Its documentation also exposes tradeoffs that a launch headline can hide, including broad host access and the need for a separate operating-system boundary. Those caveats are reasons to test it as an operations system, evaluating both its code and the safeguards around it. A useful rule is simple: automate the preparation of a change before automating permission to apply it. Start with narrow inputs, limited credentials, isolated execution, visible drafts, and human approval. Expand only when the logs show that the system follows those limits consistently. Before enabling an issue-to-PR agent, check: - Only approved people can create an executable request. - Inferred work is observed before it is allowed to run. - The agent uses a dedicated, narrowly scoped GitHub identity. - Its operating-system access is isolated from personal files and secrets. - Pull requests require human review and do not merge themselves. - You can pause the service, revoke access, and inspect its actions. I write about software engineering and AI systems. Subscribe if you want practical, source-based guides like this one. Have you let an agent act on GitHub issues or pull requests? What permission limit would you set first? Sources: DeepSeek dsh-superagent prototype, DeepSeek setup guide, DeepSeek deployment and permissions guide, DeepSeek project philosophy, GitHub Actions secure use reference.
DeepSeek Super-Agent คืออะไร? แผนที่เปิดให้อ่าน กับโค้ดที่ตามแผนยังไม่ครบ โดย Nokka (นก-กา) | 2 พ.ย. 2026 !ภาพประกอบ: โต๊ะทำงานมืดที่มีกล่องไม้หกกล่องวางเรียงเป็นวง ตรงกลางมีลูกแก้วเรืองแสงหนึ่งลูก และมีเส้นบาง ๆ เชื่อมกล่องเข้าหากัน ปลายเดือนตุลาคมที่ผ่านมา DeepSeek ปล่อยรีโปใหม่ชื่อ dsh-superagent-prototype ขึ้น GitHub [1] ตอนที่ผมเปิดดูเมื่อ 2 พ.ย. 2026 มีคนกดดาวราว 10,500 คน และมีฟอร์กกว่า 1,000 ครั้ง [1] ทวีตภาษาฝรั่งเศสบทหนึ่งที่ผมเจอเขียนว่า DeepSeek เปิด "แผนที่สมบูรณ์" ของ agent แบบใหม่ พร้อมโค้ด MIT ให้ดูกันเต็ม ๆ และบอกว่าทั้ง Grok Bot, Muse, Claude Duet และ ChatGPT Dot กำลังสร้างของแบบเดียวกันอยู่ [2] ผมอ่านแล้วเห็นด้วยว่าแผนถูกเปิดให้อ่านจริง แต่สิ่งที่คนอ่านมักเติมเองในหัวคือคิดว่าโค้ดทำได้ครบตามแผนแล้ว ตรงนั้นไม่จริง และทีม DeepSeek เขียนยอมรับไว้เองใน README รีโปนี้คืออะไรกันแน่ deepseek-ai/dsh-superagent-prototype เป็นโปรเจกต์ภาษา TypeScript สัญญาอนุญาต MIT สร้างเมื่อ 31 ต.ค. 2026 [1] แต่บรรทัดแรกของ README เขียนไว้ชัดว่า > Research prototype for reference only, not an official DeepSeek product. แปลว่าโค้ดชุดนี้เป็นงานวิจัยให้ดูเป็นตัวอย่าง ไม่ใช่ผลิตภัณฑ์ทางการของ DeepSeek [3] และมีอีกประโยคที่สำคัญกว่าประโยคแรก รีโปนี้ถูกปรับเพื่อการเผยแพร่ จึงไม่เหมือนกับเวอร์ชันที่ใช้ภายในบริษัท และไม่เหมือนกับสิ่งที่บทความออกแบบอธิบายไว้ทุกจุด บางแนวคิดในบทความเป็นทิศทางสำหรับอนาคต และยังไม่ได้ถูกใส่ลงในโค้ดชุดนี้ [3] ประโยคนี้คือกุญแจของทั้งเรื่อง อีกบริบทที่ควรรู้คือ The Next Web สรุปว่าดีไซน์ชุดนี้ถูกเปิดเผยผ่านโพสต์ WeChat ของทีมเมื่อวันเสาร์ และอ้างรายงานของ Bloomberg ว่า DeepSeek ตั้งเป้าแข่งกับ Claude Code [8] แผนมาจากไหน และมีกี่ชิ้น ตัวแผนคือบทความชื่อ Exploring Super-agent Design เผยแพร่บน X เมื่อ 1 พ.ย. 2026 โดยบัญชี DeepSeek Harness [9] บทความนั้นยาวราว 33 นาทีอ่าน และวางโครงเป็นสองชั้น คือชั้น Router ที่คุยกับคน กับชั้น Worker ที่ลงมือทำงาน ในฉบับแปลอังกฤษของสำเนาเขียนว่า "five modules form the basic framework" แปลว่าโครงหลักมีห้าโมดูล [9] ส่วนภาพที่แนบมากับทวีตต้นทางวาดเป็นหกกล่อง [2] ผมจะไล่ทีละข้อตามภาพหกกล่องนั้น แล้วเทียบกับโค้ดจริง เพราะนั่นคือจุดที่คนอ่านจะได้ประโยชน์มากที่สุด มันทำงานอย่างไรในเวอร์ชันที่โค้ดมีจริง ตัวโปรแกรมเป็นส่วนขยาย (extension) สำหรับ DeepSeek Harness ซึ่งเป็น harness โอเพนซอร์สของ DeepSeek ที่เปิดให้ใช้แบบ public preview [4] หน้าที่ของมันคือดูแล หนึ่งรีโป GitHub ฟังข้อความที่เข้ามา แล้วเมื่อมีคนที่ได้รับอนุญาตขอให้ทำงาน มันจะเปิดงานหนึ่งชิ้น ทำงานในเซสชันและโฟลเดอร์ของตัวเอง แล้วกลับไปตอบในบทสนทนาเดิม เช่นส่ง pull request [3] เส้นทางการไหลของงานในเอกสารเขียนไว้แบบนี้ [5] Source -> Trigger -> Thread -> Eval -> Ticket + Mandate -> Assignment -> Executor -> Channel ถ้าใครเคยออกแบบระบบ agent มาบ้าง โครงนี้จะดูคุ้นทันที เพราะมันคือการแยก "การตัดสินใจว่าจะทำงานไหม" ออกจาก "การลงมือทำงาน" จุดที่ผมคิดว่าฉลาดคือ Mandate เมื่อ Eval รับงาน มันไม่ได้ส่งงานเปล่า ๆ ไปให้ worker แต่แนบ mandate ไปด้วยว่าทำอะไรได้แค่ไหน [5] ตัว worker จึงไม่มีอำนาจเกินกว่าที่กำหนดไว้ตั้งแต่ต้น หกชิ้นในแผนภาพ กับสถานะของหกชิ้นในโค้ด หนึ่ง การคัดกรองด้วยกฎในโค้ดก่อนถึงโมเดล - เต็ม เอกสารออกแบบเรียกว่านโยบายสองชั้น ที่ให้โค้ดกรองก่อนแล้วค่อยให้โมเดลช่วยตัดสิน [9] และเอกสารกำกับอำนาจระบุว่า host เป็นผู้บังคับใช้รายชื่อที่อนุญาต กฎ และ mandate ข้อความจากคนแปลกหน้าจึงไม่มีสิทธิ์เริ่มงาน [6] สอง Router ที่เป็นตัวเดียวคุยกับคน และไม่ลงมือทำงานเอง - บางส่วน แผนระบุชัดว่า Router ไม่ทำงานเอง แต่ออกแบบมาให้คุยกับคนและจ่ายงานเท่านั้น [9] โค้ดมี preset ชื่อ dsh-superagent-router แยกจาก WORKER_PRESET ของ worker [3] แต่เอกสารในรีโปไม่ได้ระบุว่า router ต้องเป็นโมเดลขนาดเล็ก ที่สำคัญกว่านั้น ตัว main session ยังถือเครื่องมือ bash กับ read อยู่ เอกสารจึงเขียนตรง ๆ ว่าการไม่ไปอ่านโค้ดเป็นกฎของ prompt ไม่ใช่การตัดเครื่องมือทิ้ง [3] สาม Worker แยกเซสชันและโฟลเดอร์ต่อหนึ่งงาน - เต็ม README เขียนตรง ๆ ว่าแต่ละงานได้เซสชันและไดเรกทอรีของตัวเอง [3] สี่ คำตอบสั้นไม่เกิน 100 คำ - เต็ม และกว้างกว่าที่ผมคิดตอนแรก เอกสาร prompt เขียนว่าข้อความแชตมีเพดานแข็ง 100 คำ ไม่ใช่แค่ข้อความตอบรับ [3] ไฟล์ prompts/replies.md ยังย้ำว่า 100 คำเป็นเพดาน ไม่ใช่เป้าที่ต้องเขียนให้ได้ขนาดนั้น ห้า Watchdog ที่เฝ้าว่า worker เดินหน้าหรือวนอยู่กับที่ แล้วซ่อมให้ - บางส่วน ในแผนคือ Control Loop แยกที่รันนอกระบบหลัก เป็นเซสชันของตัวเอง รับข้อความตามตารางเวลา ทำสองหน้าที่ คือจัดการเหตุขัดข้องระดับโครงสร้าง และใช้โมเดลตัดสินว่า worker กำลังคืบหน้าหรือออกนอกเป้า [9] ในโค้ด ผมสแกนโฟลเดอร์ src และเอกสารสถาปัตยกรรมแล้วไม่พบส่วนที่ตัดสินความคืบหน้าของ worker เลย ของที่ใกล้ที่สุดคือ hourly check ในไฟล์ SETUP ที่คอยซ่อม service เมื่อมันไม่รัน [7] กับการดึงงานที่ถูกขัดจังหวะกลับมาทำใหม่ตอนสตาร์ท [3] สองอย่างนั้นเป็นครึ่งโครงสร้างของ watchdog แต่ยังขาดครึ่งที่ต้องใช้โมเดลตัดสิน หก Memory ที่อยู่นอกโมเดล เปลี่ยนโมเดลได้โดยไม่เสียความจำ - บางส่วน เอกสารโดเมนไม่มีคำว่า memory เลย [5] แต่มีสิ่งที่ทำหน้าที่ใกล้เคียงอยู่ Store เป็นฐานข้อมูล SQLite หนึ่งไฟล์ เก็บ Ticket, Thread และสถานะงานไว้ด้วย id [3] ส่วน Session เองก็อยู่รอดข้ามการรีสตาร์ทเช่นกัน [3] มี storeReads เป็นชุดคำสั่งอ่านสำหรับหน้าเว็บ เครื่องมือ และการดึงข่าวของ Source [3] ชั้นที่แผนเรียกกว่าการแยก compute ออกจาก state เต็มรูปแบบยังไม่มีอยู่ในรีโป คือให้ตัวลูป agent เป็นของชั่วคราวทั้งหมด แล้วเหลือแค่ state ในฐานข้อมูล พร้อมกลไกดึงบริบทเก่ากลับมาเมื่อต้องใช้ [9] สรุปสั้น ๆ คือ จากหกข้อ มีของจริงเต็มสามข้อ คือข้อหนึ่ง สาม และสี่ มีแบบบางส่วนอีกสามข้อ คือข้อสอง ห้า และหก ไม่มีข้อใดขาดหายไปทั้งหมด แต่ก็ยังเหลืออีกสามข้อที่ยังไม่เต็มตามแผน ถ้าผมเขียนแค่ว่า "DeepSeek แจก agent ครบชุด" คุณจะเสียเวลาไปกับการหาของที่ยังไม่มี ส่วนที่ผมคิดว่ามีค่าที่สุด และไม่ใช่สถาปัตยกรรม หลักการเดียวที่แปลงเป็นกฎวัดผลได้ เอกสารปรัชญาของโปรเจกต์เขียนหลักการเดียวว่า > Take as little human attention as possible, and give as much value as possible. เอาใจคนให้น้อยที่สุด ให้คุณค่ามากที่สุด [10] แล้วมันแปลงเป็นกฎห้าข้อที่วัดได้ทันที - agent ลงมือเมื่อถูกขอ หรือเมื่อมีกฎที่ทีมเขียนไว้เท่านั้น งานที่ไม่มีใครขอต้องเริ่มในโหมดที่แค่บันทึกว่าจะทำอะไร - agent พูดเมื่อมีคนต้องลงมือ หรือมีผลลัพธ์ให้ใช้ พอยืนยันคำขอครั้งเดียวแล้วเงียบระหว่างทำงาน - ถามทีละคำถาม และถามเป็นแบบฟอร์ม ไม่ใช่ฝังไว้ในรายงานยาว - หยุดตามระดับผลกระทบ ไม่ใช่ตามระดับความพยายาม - รายงานตามจริง งานที่ยังไม่เสร็จต้องบอกว่ายังไม่เสร็จ และห้ามข้ามข้อจำกัดเพียงเพื่อเลี่ยงการถาม ข้อสุดท้ายผมชอบเป็นพิเศษ เพราะมันคือจุดที่ agent ส่วนใหญ่พลาด บ่อยครั้งไม่ใช่เพราะโมเดลไม่เก่ง แต่เพราะมันไม่กล้าบอกว่า "ผมทำไม่เสร็จ" เรื่องสิทธิ์ที่ทีมอื่นมักมองข้าม เอกสารกำกับอำนาจเขียนไว้คมมากว่า ข้อความ คอมเมนต์ และเอกสารที่ถูกอ้างถึง เป็นได้แค่ข้อมูลเข้าไปสู่การตัดสินใจ แต่เปลี่ยนสิทธิ์ไม่ได้ [6] และ bot ตัวหนึ่งสามารถสร้าง "ผู้สมัครงานที่อนุมานได้" แต่ไม่มีทางสร้างคำขอที่ชัดเจนได้เลย [6] นี่คือรายละเอียดที่คนสร้างระบบ multi-agent มักลืม เพราะถ้า agent ตัวหนึ่งสั่ง agent อีกตัวได้ ระบบจะขยายวงได้ไม่จำกัด ตัวอย่างที่ผมคิดว่าควรลองถ้าจะเอาไปใช้ สมมติทีมคุณมีรีโปเดียว และมีคนร้องเรื่องบั๊กในแชตทีมทุกวัน ลำดับที่ตรงกับดีไซน์ของโปรเจกต์คือ 1. เริ่มจากโหมดที่ agent แค่บันทึกว่ามันจะทำอะไร โดยไม่ลงมือ 2. ใส่รายชื่อคนที่อนุญาตให้สั่งงาน 3. กำหนดขอบเขตว่า agent แตะ branch ไหนได้ 4. ให้มันทำงานในเซสชันแยก และตอบกลับในเธรดเดิม 5. ตั้งคนหนึ่งดูพาเนลทุกเช้า ว่ามีงานไหนรอการตัดสินใจ ขั้นที่ 5 จำเป็นเพราะรีโปนี้ยังไม่มี watchdog ที่คอยตัดสินความคืบหน้าให้เอง คุณไม่ต้องรอระบบมาบอก แต่ควรเปิดพาเนลดูเองทุกวันในช่วงแรก สิ่งที่ผมยังไม่ได้ทำ ผมยังไม่ได้ติดตั้ง DeepSeek Harness และไม่ได้รัน agent ตัวนี้กับรีโปจริง ผมโคลนรีโปมาอ่านเอกสารในโฟลเดอร์ docs หกไฟล์ คือ philosophy, domain, authorization, execution, prompts และ architecture รวมถึง README กับ SETUP แล้วค้นด้วยคำสั่ง grep เพื่อยืนยันว่าคำบางคำไม่มีอยู่ในเอกสาร ผมอ่านบทความออกแบบฉบับเต็มผ่านสำเนาที่เก็บข้อความไว้ครบ เพราะหน้าต้นทางบน X เปิดได้แต่เนื้อหาโหลดไม่ขึ้นจากเครื่องนี้ ผมอ่านทวีตต้นทางผ่าน API ของ fxtwitter และตรวจตัวเลขดาว สิทธิ์อนุญาต (license) และวันที่สร้างผ่าน GitHub API แหล่งอ้างอิง [1] GitHub · deepseek-ai/dsh-superagent-prototype (MIT · สร้าง 31 ต.ค. 2026 · ตรวจ 2 พ.ย. 2026) · deepseek-ai/dsh-superagent-prototype [2] X · @iamsupersocks (1 พ.ย. 2026) · x.com [3] dsh-superagent · README, docs/003 execution, docs/004 prompts, docs/007 architecture (เข้าถึง 2 พ.ย. 2026) · github.com/deepseek-ai/dsh-superagent-prototype/b… [4] DeepSeek · Harness (public preview) (เข้าถึง 2 พ.ย. 2026) · deepseek.com [5] dsh-superagent · docs/001 Domain model (เข้าถึง 2 พ.ย. 2026) · github.com/deepseek-ai/dsh-superagent-prototype/b… [6] dsh-superagent · docs/002 Authorization (เข้าถึง 2 พ.ย. 2026) · github.com/deepseek-ai/dsh-superagent-prototype/b… [7] dsh-superagent · SETUP.md (เข้าถึง 2 พ.ย. 2026) · github.com/deepseek-ai/dsh-superagent-prototype/b… [8] The Next Web · DeepSeek open-sources Super-Agent (1 พ.ย. 2026) · thenextweb.com [9] DeepSeek Harness · Exploring Super-agent Design (1 พ.ย. 2026) · ต้นทาง x.com · สำเนาที่อ่าน haowenji.com [10] dsh-superagent · docs/000 Philosophy (เข้าถึง 2 พ.ย. 2026) · github.com/deepseek-ai/dsh-superagent-prototype/b… บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)
DeepSeek’s Super-agent Wants Less of Your Attention. Test That Claim. A bot can finish useful work and still make a team slower by asking everyone to watch it happen. DeepSeek’s October 31 code drop makes that problem unusually explicit: its Super-agent prototype is designed around conserving human attention. The practical test is whether people can find the result and act at the right moment with fewer unnecessary interruptions. Disclosure: This article was generated and fact-checked with AI using the public sources linked here. It was published through an automated workflow and has not been reviewed by Keith. The repository describes a coding agent scoped to one GitHub repository, with optional Feishu input, separate work sessions, and replies in the originating conversation. It also labels the code a research prototype, not an official DeepSeek product or production-ready software. The public implementation differs from its internal version. This is an inspectable design to learn from, not evidence that every team can deploy an autonomous colleague and immediately save time. Its philosophy document treats messages and notifications as costs. Its communication policy distinguishes internal work from a result someone can use or a decision someone must make. That is a useful design constraint for operational software as well as coding agents. A status change does not always deserve an interruption The Garden case study documents connected staff work, follow-up owners, due dates, and workflow states. Garden Work extends a self-hosted Plane Community foundation, with access projected from the wider platform. The replacement of Planning Center remains staged, with migration and staff acceptance still requiring contextual completion. Nothing in that case study claims a deployed DeepSeek integration. Consider a proposed assistant for an isolated staff-work demonstration. It prepares a summary for a task owner. While working, it loads the task, revises the draft, retries a temporary lookup, and produces a reviewable summary. Each event is worth retaining in the execution record. Sending four chat updates would ask the owner to inspect activity that may not change what they can do. Define the notification around the recipient’s next action. “The summary is ready to review” can point to a stable draft. A question can identify the missing decision. A failure can explain what remains unavailable. “Still processing” needs a reason tied to the task’s expectations, rather than being emitted whenever the agent changes state. That distinction belongs in application logic. Keep an internal event history and a separate notification decision. A worker retry should not automatically become a staff message just because both pass through the same event system. The system can remain observable without making a person its live log viewer. Before dispatching a delayed notification, check the task’s current owner and state. A summary prepared for an earlier owner may no longer require their attention. If the task was canceled, a queued “ready for review” message could create unnecessary work. Use an explicit delivery record so replaying the same ready event does not produce another interruption. These are proposed implementation choices, not reported Garden features or DeepSeek guarantees. Measure what the quiet version makes people miss A useful pilot compares notification behavior on the same fictional task history. Run one version that announces routine transitions and another that reserves interruptions for agreed outcomes and exceptions. Keep the underlying task results identical. Otherwise, fewer messages might simply mean the quieter version did less work. Ask participants to identify what needs their attention, open the relevant result, and choose the next step. Record unnecessary messages alongside missed decisions and the time required to locate the deliverable. If the quiet version hides a blocked task until its deadline passes, the smaller message count is not an improvement. Include a change of owner and a canceled task in the replay. Deliver a repeated event, too. Those cases reveal whether the system notifies the person responsible now, suppresses obsolete work, and avoids turning one result into several alerts. Use synthetic records so the exercise does not expose real member notes or contact details. Agree on silence expectations before the pilot. A background task expected to finish later can expose status in a work view. A time-sensitive task may need an exception notification when its expected completion window is no longer credible. A direct request for status also deserves an answer. Suppression should remove interruptions that offer no useful action; it should not conceal a broken promise. DeepSeek’s communication instructions keep detailed engineering evidence in the work record while making the outbound message brief and useful. Apply the same separation to the proposed staff assistant: keep the summary, relevant evidence, and unresolved limitations available at the linked destination. A short notification should not require the recipient to reconstruct the task from scattered messages. There is a cost to maintaining that separation. Delivery records, cancellation checks, and recipient selection need ownership and testing. For a small, infrequent workflow, a simple manual update may be easier to operate. For a busier system, a notification policy becomes part of the product’s usefulness. DeepSeek has published a goal about attention, not a measured result for another organization. The worthwhile experiment is to see whether quieter delivery preserves timely decisions. Count the interruptions, then check whether the right person still knows what to do.
¡Muy interesante esto de DeepSeek! Ha lanzado de código abierto DSH SuperAgent Un agente de código que escucha eventos de un repo de GitHub y crea Pull Request de forma autónoma Lo mejor es que explica paso a paso cómo está montado: deepseek-ai/dsh-superagent-prototype t.co
刚仔细看了 DeepSeek 发布的 Super-agent deepseek-ai/dsh-superagent-prototype 看完第一反应： 这不就是分布式里最经典的 Master-Worker 吗？ Router 做 Master，负责接消息、派任务 Worker 各自一个会话，独立干活 状态外置，执行和状态分离 一下子想起 2014 年在百度实习的时候 我们组就做过一个分布式任务调度系统 当时参考的就是 Hadoop 那一套： 一个 Master，几个 Worker 靠心跳维持联系，任务顺着心跳下发 十多年过去了，后端的技术架构其实没太变化 DeepSeek 自己也说没有提出新理论 这篇东西本质上就是把成熟的后台工程模式搬到 Agent上 所以Agent 再怎么变，包括现在火的 Harness 最后还是绕不开分布式和后端那一套
DeepSeek が描く AI エージェントの未来像 DeepSeek が Super-agent という AI エージェントの構想を公開しました。利用者と会話を続けながら複数の仕事を進め、GitHub やチャットの変化にも対応します。人が作業やセッションを管理する負担をどう減らすのか、既存のエージェントとの違いも含めてまとめました。 TL;DR Super-agent は仕事の進行やセッションの管理をシステムへ任せ、人が細かく指示・確認する負担を減らす構想です。 利用者との会話と仕事の振り分けは Router、個々の作業は Worker が担当します。GitHub やチャットの通知も受け取り、対応が必要なものを担当へ届けます。 Router と Worker をクラウドで動かし、自宅PCのコードや開発ツールを使って作業する構成も想定しています。 利用者が複数サービスで組んでいる仕組みを、AI ベンダーが体系化して提供してくれることに期待しています。 Worker もクラウド側にあるため、自宅PCとの接続や GUI・ブラウザ操作が安定して動くかは気になるところです。 はじめに DeepSeek Harness のチームが、Exploring Super-agent Design: Towards a More Autonomous Agent System という設計記事を公開しました。 元記事では、仕事の振り分けやセッション間の情報の引き継ぎをシステムへ任せ、人が細かく指示・確認する負担を減らす設計を提案しています。その分、人が仕事の目的や優先順位を決めたり、成果を確認して承認したりすることに集中できるようにする狙いです。 以前、Work や dot から自宅PCの Codex へ仕事を依頼する構成を記事にしました。今回の構想では、利用者との対話と実作業を分担する仕組みを、エージェントの実行基盤として扱っています。 自分でも仕組みを理解しておきたかったので、元記事の設計を既存のエージェントと比べながらまとめてみました。 DeepSeek の Super-agent 構想 Super-agent が目指すのは、人が個々のセッションを操作して仕事を進める負担を減らし、複数の仕事を継続して任せられるエージェントです。人は目的や優先順位を伝え、必要な場面で判断や承認を行います。その間の仕事の振り分けや情報の引き継ぎを、システム側が受け持つ設計です。 元記事では、モデルの能力が上がるにつれて個々の仕事への監視や細かな指示が減ってきたと説明しています。複数のエージェントを連携させる能力も上がり、別々のセッションへ仕事を分担する使い方も可能になってきました。 Claude Code や Codex で複数の仕事を進めるときは、実装用や調査用のセッションを分けて使うことがあります。文脈が混ざらない一方で、進捗の確認や対応するセッションへの追加指示は利用者が行う必要があります。 個々の仕事を任せられるようになっても、どのセッションが何を知っているかを人が覚えておく必要があれば、同時に任せられる仕事の数は人間の注意力に制限されます。元記事では、モデルの能力向上に伴って、この人間側の負担が生産性を制限するようになると説明しています。 そこで、担当を決めて必要な情報を届けるところまでエージェントの仕組みに含めます。人からの指示に加えて GitHub やチャットの変化も受け取り、対応が必要な仕事を進めます。途中で判断が必要になったときや成果の確認を求めるときには、人へ戻ってきます。 利用者が話す相手や場所を変えても、それまでの依頼を踏まえて対応する。作業中にも別の仕事を引き受け、異常があれば復旧する。こうした動作を継続して行えるように、エージェントの実行基盤を設計し直すのが Super-agent の構想です。 比較の出発点として、ローカルのエージェントを仕事ごとに起動する構成を描くと次のようになります。 利用者が仕事ごとのセッションを管理する構成 Super-agent では利用者とのやり取りを受け持つ Router と、仕事を実行する Worker を分けます。会話や作業の記録は実行プロセスの外へ保存し、コードや開発ツールがある環境にも接続します。 DeepSeek の Super-agent 構想 利用者は実装を頼んだ後に別の調査を依頼しても、同じ Router と話を続けられます。担当は裏でそれぞれの仕事を進め、結果や相談が必要な点を Router へ返します。チャットから始めた仕事について、後から GitHub の PR に書いた追加指示を受けて進めることも想定しています。 元記事が挙げる性質は次のとおりです。 性質 目指す動作 Continuous チャットや GitHub などやり取りする場所が変わっても、同じエージェントとして文脈を保つ Productive 複数の仕事を並行して進め、作業中にも次の依頼を受ける Proactive 外部の出来事を確認し、対応する価値があるものに自ら取りかかる Persistent 継続して稼働し、必要な作業環境へ接続しながら異常から復旧する これを Router と Worker の分担やイベントの処理、非同期のやり取りによって実現します。実行処理と状態・環境を分けることや、外側から監視する仕組みも含まれます。ハーネスを含む実行基盤全体の設計が話の中心になります。 仕事ごとのセッションは内部に残ります。その管理をシステムへ任せ、利用者が毎回どのセッションを開くか考えなくても済むようにする構想だと理解しました。 利用者との対話と作業担当の分担 Router は利用者との会話を続けながら、新しい仕事を Worker へ振り分けます。進行中の仕事との関係や、複数の仕事にまたがる判断も扱います。 たとえば、ある不具合の修正を頼んだ後に別のライブラリの調査を依頼したとします。修正は Worker A、調査は Worker B が担当し、Router は両方の状況を把握して利用者と話を続けます。 Router 自身は実作業を行いません。元記事では Bash ツールを持たなくてもよく、軽いモデルで速度と品質を両立できる場合が多いとしています。会話を担当するモデルが実装や長い調査に取りかかると、その間の会話や別の依頼への応答も遅くなるためです。 Worker は仕事ごとに分かれた文脈と、実作業に必要なツールを持ちます。不具合の原因を調べてコードを直す担当と、ライブラリの仕様を調べる担当では、途中のログや推論を共有し続ける必要はありません。各 Worker が作業を進め、重要な結果を Router へ報告します。利用者への返答は Router がまとめて行います。 別の担当へ仕事を任せる点は、一般的な orchestrator / worker 構成やサブエージェントと共通しています。ただ、複雑な仕事を細かい作業へ分ける orchestrator と、ここでいう Router では担当範囲が違います。Router は独立した仕事の振り分けと全体の調整を行い、一件の仕事の詳細な計画や分割は Worker 側が受け持ちます。 Worker はその仕事に必要ならさらにサブエージェントを使えます。たとえば機能追加を担当する Worker の中で、設計・実装・テストを分担する Agent Team を動かす形です。Router と Worker は役割の区分なので、必ずそれぞれが一つのセッションになるという意味でもありません。 外部イベントと作業中の追加指示 継続して仕事を進めるには、最初の依頼に加えて、その後に起きたことも受け取る必要があります。 修正した PR にレビューが付く。CI が失敗する。チャットで変更の相談が出る。元記事ではこうした外部の出来事を Trigger として扱います。 すべてをモデルに判断させると、関係のないメッセージにも推論が必要になります。そこで、送信元や対象のグループなど、決まった条件で判定できるものはプログラムで先に絞ります。そのうえで、内容を読まないと対応の要否が分からないものをモデルに判断させます。元記事の Fast Path / Slow Path はこの分担です。 担当が決まった後の続報にも、毎回 Router の判断は必要ありません。 たとえば Worker A が PR の修正を担当するなら、その PR に関する通知の届け先として Worker A のセッションを登録します。コメントや CI 結果の通知が届くと、プログラムがこの登録に従って Worker A へ直接送ります。通知のたびに Router のモデルが担当を選び直す必要はありません。 元記事の subscription (購読) は、この通知先の登録を指しています。PR やチャットのスレッドごとに届け先を登録し、後続の通知をプログラムで振り分ける仕組みです。届いた内容を読んで対応を考えるのは Worker です。 まだ担当のいない新しい仕事や、担当をまたぐ調整は Router が扱います。Worker も重要な結果を Router へ報告するので、Router は全体の状況を追いながら利用者とやり取りできます。 作業中の追加指示を受け取るため、ツールの実行も非同期にします。長いビルドを開始したら、完了までその呼び出しの中で待ち続けず、結果が後からイベントとして届くようにします。その間に届いた追加指示も、現在のモデルの推論ステップが終わった時点で扱えます。 これならビルド中に方針が変わっても、ビルドの終了まで会話を止めずに済みます。単に裏でコマンドを実行するだけでなく、作業の途中にも入力を受け取れるようにする設計です。 長く動かすほど増える履歴にも工夫があります。直近で必要な情報はコンテキストへ入れ、長い内容や古い記録は外へ置いて参照を残します。過去の仕事が再び話題になったら、その参照をたどって必要な記録を読み直します。元記事では Inline & Spill、Chain of Recall と呼んでいる仕組みです。 実行処理・履歴・作業環境の分離 この構想ではエージェントの実行処理と履歴をクラウドへ置き、実際に作業する環境を必要に応じて接続します。 Agent Loop はモデルに問い合わせ、返ってきたツール呼び出しを実行へつなぎ、その結果をモデルへ返す処理です。これを実行するプログラムと、残しておきたい会話や作業の記録を分けます。 分ける対象 置き場所と役割 Agent Loop クラウドでモデルへの問い合わせとツール呼び出しを取りまとめる 会話履歴・作業状態 外部のデータベースなどへ保存し、実行処理を起動し直しても読み出せるようにする 作業環境 コードや SDK、ファイル、アプリがあるPCなど。必要な処理を実際に行う Agent Loop のプロセスが落ちても、記録は外へ残ります。別のプロセスがその記録を読み直せれば、同じ仕事の続きを扱えます。実行中の一つのプロセスを生かし続けることと、仕事の継続を分けて考えるわけです。 元記事でも、Anthropic の Managed Agents の設計記事を参照しています。こちらもハーネスとセッションの記録、作業環境を分け、それぞれを交換できるようにする設計です。 DeepSeek が特に接続先として挙げているのは、利用者が普段使っているPCです。自宅PCには未コミットの変更や、そのPCで使っている開発ツールがあります。すべてをクラウドへ複製する代わりに、作業環境をそのまま使います。 PC側にはコマンドを実行して結果を返す軽量な daemon を置きます。会話や仕事の状態はクラウド側で管理し、Agent Loop が必要な処理をPC側へ依頼する形です。元記事では BYOM (Bring Your Own Machine) と呼んでいます。クラウドの環境や、必要なときに作る環境も接続先に含まれます。 この構成なら、自宅PCを閉じてもクラウド側での対話や記録は維持できます。そのPCが必要な作業は接続を待ち、再びオンラインになったときに進める想定です。 継続運用には外側から状態を見る Watchdog も置きます。プロセスの停止や API エラーだけでなく、同じ作業を繰り返して進んでいない状態や、目的からのずれも確認します。Watchdog 自身もツールを持つエージェントのセッションで、主な実行処理とは別に監視や復旧を行います。 以前の自分の構成では、クラウド側の dot からローカルで動く Codex などの作業担当へ依頼していました。Super-agent の構想では Worker の Agent Loop もクラウド側に置き、ローカルPCにはコマンドを実行して結果を返す daemon を置きます。 以前は作業担当がPC上で動いていたので、そのPCの GUI やブラウザを操作するツールを直接使えました。Worker がクラウド側にあると、手元の画面を確認したり操作したりするためにも、クラウドとPCの間でやり取りする仕組みが必要になります。クラウドに用意したブラウザで調べる仕事と、自宅PCのアプリや既存のブラウザを使う仕事では、接続先も変わります。 クラウド側で操作を判断し、PC側のプログラムに画面取得やクリックを実行してもらう形が考えられます。会話や仕事の記録が残っていても、通信が切れる前と同じ画面が開いているとは限りません。接続が戻ったら操作対象の状態を確認し、その状態に合わせて続きを進める必要があります。 操作の指示や結果がクラウドとPCを行き来するため、途中で止まったり、結果がうまく戻らなかったりしないかは気になります。画面の取得から操作結果の確認、通信断後の再開まで、基盤側で安定して扱えるようになることを期待しています。 構想の一部を実装した dsh-superagent-prototype も公開されています。README には内部版や設計記事と同一ではなく、記事中の将来構想には未実装のものもあると明記されています。ここで説明した全体像がそのまま完成した製品として使える段階ではないようです。 既存のエージェントとの比較 Claude Code や Codex でもサブエージェントへの分担やクラウドでの作業、離れた端末からの追加指示ができます。Cowork にも複数段階の仕事を任せ、クラウドで並行して進めたり定期実行したりする機能があります。 Super-agent の構想で整理されているのは、そうした機能を継続的な仕事の流れとしてどう組み合わせるかです。利用者と話す担当や続報の届け先に加え、記録の保存と作業環境への接続まで設計しています。 利用体験としては Grok Bot や ChatGPT dots、Claude Duet にも近い部分があります。 製品 公式に説明されている仕組み Super-agent と重なる部分 Grok Bot 専用のクラウドPCで常駐する Bot。まとめ役と専門の Bot が連携し、スマホやデスクトップから仕事を頼める 会話を続ける担当と、複数の担当による仕事の分担 ChatGPT dots 継続的な仕事を引き受け、会話の合間も作業を進める。Work や Codex へ仕事を依頼して進捗を扱う 会話を続けながら別の担当へ作業を任せる構成 Claude Duet 継続する会話と専用のクラウドPC・ブラウザを持ち、接続したアプリを確認して必要な結果や判断依頼を知らせる 常時動く作業環境と、必要なときに人へ戻るやり取り Claude Duet は現時点では research preview で、接続したアプリを一定間隔で確認します。 Grok Bot や dots、Duet を見ると、普段の会話を保ったまま裏で仕事が進む使い方は想像しやすくなります。DeepSeek の記事は、その使い方を実現するための実行基盤を具体的に説明しているところが面白いと感じました。 おわりに 仕組みを追っていくと、最近見かける Grok Bot からほかのエージェントへ仕事を任せる構成に近いと感じました。以前自分が組んだ dots 基盤も、会話を担当するエージェントと実作業を進めるエージェントをつなぐ点では同じ発想です。 利用者が複数のサービスを組み合わせて作っているこうした仕組みを、AI ベンダーが体系化して提供してくれると面白そうです。サービス同士のつなぎ方や仕事の引き継ぎを自分で組まなくても済むなら、より多くの人がエージェントに仕事を任せやすくなると思います。 自分は以前、dot との接続がうまくいかず、結局使わなくなりました。その経験もあるので、Worker までクラウド側へ移る構成で自宅PCとのやり取りがどう扱われるかは気になります。普段の開発環境や GUI・ブラウザの操作まで含めて安定して使えるなら、かなり自分の使いたい形に近づきそうです。
クラウド型コーディングエージェントとは何か：DeepSeek Super-agent はどこに置けるか :::note info この記事は AIHubMix が作成しました。DeepSeek の Super-agent は研究用プロトタイプで、DeepSeek 社内版とは同一ではなく、設計エッセイのすべてのアイデアを実装したものでもありません。内容はリポジトリの README、設計エッセイ、各社の公式ドキュメントに基づいています。チケットをトリガーから PR まで通しで実行する検証はしていません。 ::: TL;DR - クラウド型コーディングエージェントは、エディタを開かずに依頼し、自分のマシンの外で実行し、レビューできる成果物を受け取る製品です - GitHub、Cursor、OpenAI、Anthropic、Cognition、xAI の6製品を同じ軸で並べると、トリガー、実行環境、返り値の違いが見えます - Grok Bot はリポジトリ作業用ではなく、Cursor がホストするアカウント単位のクラウドマシンで動く常駐型の AI チームメイトです - 自前で動かす例が DeepSeek の Super-agent で、DSH 向けの MIT ライセンスの TypeScript プラグインとして公開されています - ただし danger-full-access で動き、既定のサンドボックスはなく、対象は github.com の1リポジトリです - レビュー工程はどの製品でも残ります。エージェントが減らすのはタイピングです クラウド型コーディングエージェントとは何か クラウド型コーディングエージェントは、エディタの外から依頼を受け取り、自分のマシンの外にある環境で作業し、レビューできる成果物を返す製品です。GitHub、Cursor、OpenAI、Anthropic、Cognition、xAI が、クラウドエージェント、バックグラウンドエージェント、クラウドセッション、自律型ソフトウェアエンジニアといった名前で、それぞれの形を提供しています。 エンジニアリングの課題は、モデル呼び出しではありません。そこは Base URL とキーとモデル ID で済みます。難しいのは周辺です。ノート PC を閉じても動くトリガー、リポジトリを clone してビルドできる環境、認証情報の境界、そして人間がレビューできる出力です。 このカテゴリの製品には、共通する3つの部品があります。 - エディタを開かずに済むトリガー。 Issue のアサイン、Slack や Feishu での @メンション、Web アプリのプロンプト、API 呼び出し、CLI からの引き渡しです - 自分のマシンの外にある環境。 エージェントはリポジトリを clone し、必要なものをインストールし、ベンダーまたは組織が管理するサンドボックスやワークスペースで作業します - レビューできる成果物。 ブランチ、差分、下書きの PR、コメントなど、人間が確認して次の行動に移せるものです これは、近い2つのものと区別されます。ローカル IDE エージェントは、見ている間だけノート PC 上で動きます。チャットアシスタントは、リポジトリに触れずに質問へ答えます。クラウド型はその中間で、実際のツールと実際のチェックアウトを持ちながら、人間がその場を離れることを前提にしています。 ボット という言葉は、同じアイデアのチャットネイティブな形を指します。Issue をアサインする代わりに、Slack、Teams、Feishu でエージェントにメンションします。トリガーは変わりますが、遠隔の環境は変わりません。出力は PR や差分のこともあれば、完成したファイル群のこともあります。 製品マップ 6製品を、各社の説明に沿って並べます。 | 製品 | 開始点 | 実行環境 | 返り値 | |---|---|---|---| | GitHub Copilot cloud agent | Issue、@、Agents パネル | クラウドサンドボックスまたは Actions | ブランチまたは PR | | Cursor Cloud Agents | デスクトップ、Web、Slack、Linear | 隔離されたクラウド VM | PR | | OpenAI Codex Cloud | ChatGPT の Web、デスクトップ、モバイル | クラウドワークスペース | 変更または PR | | Claude Code cloud sessions | ブラウザ、モバイル、デスクトップ、ターミナル | Anthropic 管理の VM またはセルフホスト環境 | ブランチまたは PR | | Devin | Slack、Teams、Web、CLI、API | ターミナル、エディタ、ブラウザを備えたワークスペース | 下書き PR | | Grok Bot | デスクトップ / モバイルのチャット、X の @bot | クラウドマシン（Cursor がホスト） | ファイルまたは下書き | 「実行環境」列は各社の表現に従っています。隔離の詳細は製品ごとに異なり、Devin のドキュメントは VM 構成や隔離の保証を説明していません。 Grok Bot はもっとも広い位置づけです。xAI のドキュメント は、デスクトップまたはモバイルのチャットから、あるいはアカウントを連携していれば X で @bot にメンションすることで開始できる、常駐型の AI チームメイトだと説明しています。Cursor がホストするアカウント単位のクラウドマシン上で動き、ブラウザ、ストレージ、コマンドラインにアクセスできます。ドキュメントが説明しているのは完成したファイルと下書きで、リポジトリのワークフローではありません。ブランチや PR の作成は記載されていません。つまり、ボット寄りの端に位置します。 表より重要な違いは4つあります。 トリガーがどこにあるか。 GitHub Copilot cloud agent と OpenAI Codex Cloud は、GitHub または ChatGPT アプリにすでにある作業を中心に設計されています。Cursor Cloud Agents と Devin はチャットネイティブで、Slack や Teams のスレッドが入口です。Claude Code cloud sessions は、ブラウザ、スマートフォン、デスクトップアプリ、ターミナルの claude --cloud から開始でき、スケジュール実行もできます。 ベンダーがどこまで見せるか。 Claude Code は隔離の説明が詳しいです。Anthropic がホストする環境では、各セッションが隔離された VM で動き、ネットワークアクセスは既定で制限され、git の認証情報はサンドボックスの外に置かれ、プロキシがセッションの代わりに認証します。組織はセッションをセルフホスト環境に振り向けることもでき、その場合の隔離は組織の責任です。クラウドセッションはプランのレート制限を共有し、VM の追加課金はありません。一方で claude.ai のサインインが必要で、Claude Code が Amazon Bedrock、Google Cloud の Agent Platform、その他のサードパーティプロバイダ向けに設定されている場合は使えません。他のベンダーは内部構成の公開が少なく、「サンドボックス」や「VM」という言葉で説明が終わることがよくあります。 エージェントが何に触れられるか。 1リポジトリに限定する製品もあれば、組織全体や複数リポジトリの作業をうたう製品もあります。自分の環境に照らして最初に確認すべき点です。能力の高いエージェントでも、リポジトリの範囲が誤っていれば、役に立たないか危険かのどちらかになります。 どんな作業に向くか。 このリストの大半はリポジトリ単位のコーディングです。Grok Bot は汎用のクラウドチームメイトで、ドキュメントが説明するのはファイルと下書きであり、リポジトリのワークフローではありません。「クラウドエージェント」は単一の製品形ではなく、スペクトラムとして読む必要があります。 ループはどう回るか ブランドを剥がすと、ループはどこでも似ています。 1. 受け付け。 トリガーが届きます。製品はそれが実際のタスクかを判断し、ときには確認の質問を1つ返し、セッションをキューに入れます 2. 環境。 エージェントは正しいブランチでリポジトリを clone し、セットアップスクリプトまたはイメージを実行し、ツールチェーンをインストールします。ネットワークアクセスとシークレットはここで設定され、後回しにはなりません 3. 作業。 エージェントはコードを読み、ファイルを編集し、テストやコマンドを実行し、ときにはブラウザを開きます。長いタスクはノート PC がスリープした後も続きます 4. 出力。 ブランチを push して PR を開くか、差分と文章の要約を残します。マージ前に止まることが前提の製品は、下書き PR を返します 5. レビュー。 人間が差分を読み、コメントし、マージするか、変更を依頼するか、作業をローカルセッションに戻します。PR を監視して、CI が失敗したときに修正を push できる製品もあります 差が出るのは、2と5です。セットアップスクリプトが長すぎる、リポジトリを clone できない、ネットワークポリシーがパッケージレジストリを塞ぐ、サンドボックスから認証情報が見えない、といったことが、単純に見えたタスクを止めます。そして「レビューできる出力」は、人間がレビューするという意味です。どの製品もレビュー工程をなくすのではなく、タイピングの位置を移しています。 いまこの波が起きている理由 3つの条件がそろいました。モデルが、常時の監督なしで長いツールループを回せるほど信頼できるようになりました。サンドボックスとセットアップスクリプトが、タスクごとに環境を用意できるほど安くなりました。そして PR が、エージェントとレビュアーの間の既定のインターフェースになり、チームは新しいレビュー工程を発明せずに済みました。 注意に関する議論もあります。DeepSeek の設計エッセイは、1つのタスクはモデルで制約されるが、多数のタスクをまたぐ人間のスループットは注意で制約される、と明示しています。クラウドエージェントは、セッション管理、コンテキストスイッチ、待ち時間を人間から移します。この主張は DeepSeek のエッセイによるもので、独立した研究によるものではありませんが、カテゴリが有用に感じられる理由を説明しています。 何を手放すことになるか ホスト型の製品は、どれも利便性と引き換えに制御を手放します。 - 信頼境界。 コードと、場合によっては認証情報が、自分のマシンの外に出ます。隔離、保持、ネットワークアクセスについての公開情報の量はベンダーごとに違うため、カテゴリ全体を一律とみなさず、製品ごとに確認してください - 隔離。 管理された VM はエージェントを閉じ込めるように設計されていますが、それはベンダーの環境です。「サンドボックス」は、強化された VM から、広いネットワークアクセスを持つコンテナまでを指し得ます - カスタマイズ。 ホスト型エージェントが公開するのは設定で、ソースコードではありません。トリガー、レビュールール、モデルを変えたい場合、製品が用意した範囲に限られます - コストモデル。 多くはサブスクリプションまたは利用上限付きのプランで課金され、エージェントの時間は直接管理できる明細ではありません。トークンではなくプランで予算を組みます - 範囲とロックイン。 複数リポジトリの対応、チャット連携、エンタープライズ向けの制御はベンダーごとに違い、ワークフローの移行も無料ではありません 自前で動かす例：DeepSeek の Super-agent DeepSeek のリリースが興味深いのは、管理プレーンを自分の側に残したとき、同じループがどうなるかを問うているからです。リポジトリは deepseek-ai/dsh-superagent-prototype で、DeepSeek Harness（DSH）向けの MIT ライセンスの TypeScript プラグイン、バージョン 0.1.0 として、研究用プロトタイプの形で公開されています。README は、公開用に調整されたもので、DeepSeek 社内版とは同一ではなく、設計エッセイのすべてのアイデアを実装したものでもない、と明示しています。 形は、長命の Router セッションと、Ticket ごとの Worker セッションです。イベントは Source → Trigger → Thread → Eval → Mandate → Ticket → Assignment → Executor の順に流れます。チームはポリシーで作業を許可し、許可された人からの明示的な @メンションは受け付けます。先回りの作業は observe モードで始まり、チケットを開かずに、エージェントが何をしたはずかを記録します。Ticket ごとにセッションとディレクトリが割り当てられ、prepare コマンドで Ticket ごとの git ワークツリーを作れます。 運用モデルは、ベンダーのサンドボックスの反対側にあります。監視するのは github.com の1リポジトリ（GitHub Enterprise Server は非対応）と、任意の Feishu です。Router と Worker のプリセットは、どちらもオペレーターの OS ユーザーとして danger-full-access で動きます。アカウントラッパーが選ぶのはエージェントの認証情報で、プロセスを隔離するわけではありません。デプロイガイドの指針は、エージェントの認証情報だけを持つ専用 OS アカウントです。状態は、設定した stateDir の下の SQLite に置かれます。哲学は予算として書かれています。人間の注意をできるだけ取らず、価値をできるだけ返す、というものです。 プロトタイプはモデルをハードコードしません。Eval または Execution で上書きしない限り Harness プロファイルの既定値を使うため、Router に軽いモデル、Worker に強いモデルを置くこともできます。 設計エッセイは、合成ワークロードのスケジューリング数値を報告しています。約300メッセージと20件の作業リクエスト、シミュレーションしたツール、5回の実行で、p50/p95 は約12.4 / 15.7分でした。サブエージェント呼び出しのなかった単一セッションのベースラインは、p95 が約29.5分です。これはエッセイ自身による自己申告の測定で、シミュレーションしたツール下の数値であり、独立したコーディング品質のベンチマークではありません。 ハマりどころ danger-full-access のまま使い始めると権限が広すぎる Router と Worker は、オペレーターの OS ユーザーとして danger-full-access で動きます。アカウントラッパーは認証情報を切り替えるだけで、プロセスをサンドボックス化しません。使い始める前に、エージェントの認証情報だけを持つ専用 OS アカウントを用意してください。 github.com の1リポジトリが前提で、GitHub Enterprise Server は非対応 監視できるのは github.com 上の1つの owner/name リポジトリで、GitHub Enterprise Server は非対応です。 「サンドボックス」と書いてあっても、中身の説明はベンダーごとに違う Claude Code は、隔離された VM、既定で制限されたネットワーク、サンドボックス外に置かれる git 認証情報まで説明しています。一方で、他のベンダーの公開情報は「サンドボックス」や「VM」で終わることが多く、Devin のドキュメントは VM 構成や隔離の保証を説明していません。同じ言葉から同じ保証を仮定しないでください。 Claude Code のクラウドセッションは claude.ai のサインインが必要で、Amazon Bedrock や Google Cloud の Agent Platform では使えない Claude Code のクラウドセッションは、プランのレート制限を共有し、VM の追加課金はありませんが、claude.ai のサインインが必要です。Claude Code が Amazon Bedrock、Google Cloud の Agent Platform、その他のサードパーティプロバイダ向けに設定されている場合は利用できません。 セットアップスクリプトが長い、パッケージレジストリに届かない、認証情報が見えない ループの2番目で止まる典型です。セットアップスクリプトが長すぎる、リポジトリを clone できない、ネットワークポリシーがパッケージレジストリを塞ぐ、サンドボックスから認証情報が見えない、のいずれかがあると、単純に見えたタスクが進みません。 レビューを省こうとすると、どの製品でも止まる どの製品も、最後は差分や PR を人間がレビューする形で終わります。エージェントが移すのはタイピングで、承認ではありません。レビュー工程を前提に、トリガーと権限を設計してください。 この記事で検証していないこと - Super-agent のチケットをトリガーから PR まで通しで実行する検証はしていません。接続経路はドキュメントに基づく説明です - 設計エッセイのスケジューリング数値は自己申告で、シミュレーションしたツール下の測定です。独立したコーディング品質の結果ではありません - ホスト型各社の機能は公式ドキュメントに基づく要約で、再現テストは行っていません - Super-agent は研究用プロトタイプで、DeepSeek 社内版とは同一ではなく、既定のサンドボックスもありません まとめ - クラウド型コーディングエージェントは、エディタを開かずに済むトリガー、自分のマシンの外の環境、レビューできる成果物の3つで整理できます - GitHub、Cursor、OpenAI、Anthropic、Cognition、xAI の6製品は同じループを共有し、違いはトリガー、隔離の公開度、対象範囲に現れます - Grok Bot はリポジトリ作業用ではなく、Cursor がホストするアカウント単位のクラウドマシンで動く常駐型の AI チームメイトです - DeepSeek の Super-agent は、管理プレーンを自分の側に残す実装例ですが、danger-full-access で動き、既定のサンドボックスはなく、対象は github.com の1リポジトリです - 性能数値は設計エッセイの自己申告であり、独立した品質評価ではありません - どの製品でも、最後のレビューは人間に残ります AIHubMix は OpenAI 互換エンドポイント（https://aihubmix.com/v1）を提供しており、DSH の基本接続は DeepSeek Harness ガイド で確認できます。ガイドが扱うのは基本接続までで、Super-agent プラグインは対象外です。Super-agent のプロセス自体は AIHubMix ではホストされず、DSH を導入したマシン上で動きます。 参考 1. deepseek-ai/dsh-superagent-prototype（GitHub）— README、設計エッセイ、docs/000–008 2. Connect DeepSeek Harness to AIHubMix（AIHubMix） 3. GitHub Copilot cloud agent（GitHub Docs） 4. Claude Code in the cloud（Anthropic） 5. Grok Bot documentation（xAI）
My take on DeepSeek’s new multi-agent prototype So DeepSeek is researching a new kind of AI system: one that works more like a team of specialized agents than a single chatbot. The interesting part is not simply that it uses multiple AI agents. It is the structure around them. The prototype separates responsibilities into: - Routers that decide which worker should handle a task - Workers that perform focused tasks - Triggers that start actions - A Watchdog that monitors progress and handles failures This feels closer to an AI team than a single chatbot. My main takeaway is that the future of useful AI agents may depend less on making one model answer everything and more on building reliable systems around several specialized agents. The important caveat is that this is a research prototype, not a finished product. You can explore the implementation here: DeepSeek-ai/dsh-superagent-prototype What do you think is the hardest part of making multi-agent systems reliable?
クジラちゃんニュースですっ♪ DeepSeekが、いつもオンで動くコーディングエージェント「dsh-superagent」の試作版をGitHubでオープンソース公開したんですよ〜！MIT ライセンスで、GitHubのリポジトリを見張って、頼まれたら自分で作業を進めるそうです。研究用の試作品とのことですっ✨ #AI #DeepSeek deepseek-ai/dsh-superagent-prototype
把 DeepSeek 的 Super-agent 思路做成一个人的桌面助手： AnyModelBot，首个开箱即用的 DeepSeek Super Agent DeepSeek 前阵子开源了 [dsh-superagent 原型]( deepseek-ai/dsh-superagent-prototype)，核心原则就一句：占用尽量少的注意力，带来尽量多的价值。 不过它是面向团队、盯着 GitHub 仓库的研究原型，个人没法直接用。 我们把这套思路做进了开源桌面助手 AnyModelBot，装好就是开箱即用的 DeepSeek Super Agent ，这是它的首个实现，不需要任何配置。  Super Agent 三件套 - 后台任务：调研、做报告这类要跑一阵子的事，交代一句就在后台做，聊天照常，不用排队等。 - 定时规则：一句话写下长期吩咐，比如「每天早上 8 点看看 X 的价格，低于 200 告诉我」，按时自动执行。新规则可以先用「观察」模式试跑，只读、不打扰你。 - 「需要你」：所有等你回答、批准的事集中在一处，没事时不占地方。 不打扰是硬规矩：只推结果、决定和失败三种消息，默认 22:00–08:00 免打扰，每个任务和规则都有预算上限。  它本来就是一个完整的 AI 机器人 - 一个账号 70+ 模型：GPT 、Claude 、Gemini 、Grok 、DeepSeek 、Kimi 、GLM……每个对话用 /model 随时切换。  - 在微信和飞书里也能用：微信扫码连接，支持图片和文件；飞书是流式回复卡片。  - 能操作你的电脑：读写文件、沙箱执行命令、电脑操作（ macOS 为 Beta ），三档权限加审批卡片，你说了算。  - 本地优先、开源免费：对话、记忆、文件和 Key 都留在你的电脑上； MIT 开源，Windows / macOS / Linux / Docker 都能跑，模型按量付费、没有订阅。 想深入看 设计细节（和原型的差别、DeepSeek Harness 怎么跑、权限和预算怎么设计）都写在 GitHub 的设计文档里，功能介绍和下载在官网： - GitHub： modelflare-ai/AnyModelBot （欢迎 Star ⭐） - Super Agent 设计文档： github.com/modelflare-ai/AnyModelBot/blob/master/… - 官网： anymodel.bot 项目还很新（ v0.1.x ），是独立开源项目，与 DeepSeek 官方无关。欢迎试用、提 issue 、拍砖 🙏