常驻编程 Agent 如何接单、授权与响应干预

DeepSeek 开源了内部使用的 dsh-superagent。按原文描述，它会持续在线、自行接任务，完成后提交 PR，再向人汇报。它想解决的问题很直接：让人少花时间盯着 Agent，同时拿到更多实际成果。

值得拆解的不是它能自动写多少代码，而是三个协作设计：接任务前分层判断，动代码前公开权限边界，并发再忙也给人的消息留一个位置。对正在把 AI 编程接入团队流程的开发者，这些设计比一句「全自动开发」更有参考价值。

接不接任务，为什么不能全交给模型

dsh-superagent 把接单判断拆成两层。

第一层是用普通代码实现的 gatekeeper，检查发起人是否在允许名单里、是否通过 @ 点名了 Agent。这些条件明确，程序就能判断，不必每次都请模型分析。

第二层是 advisor，由模型阅读周围的上下文，再判断这件事是否应该接。它负责的是需要理解语境的部分。

能用确定规则检查的条件先交给代码，需要理解上下文时再调用模型。

这套分工的理由是成本：简单检查保持低成本，只有需要判断的环节才花一次模型调用。它也让接单流程更容易解释，至少允许名单、点名条件这类规则有明确的执行位置。

不过，原文没有给出调用量、费用或接单准确率的对照数据。能确定的是设计思路，不能据此计算它比纯模型判断省了多少。

自动干活之前，要先交代什么

Agent 接下任务后，会先发布一个工作标识（work badge），再开始改代码。里面说明三件事：依据哪个版本的规则行动、允许修改到什么范围，以及由谁批准。

这里的价值是把授权信息放到执行之前。人看到 Agent 开工时，就能知道它准备按什么规则做、能改到哪里，而不用等 PR 出来后再追问。

原文提到了「规则版本」，但没有提供具体版本号，也没有解释修改范围如何被技术手段强制约束。因此，公开边界和真正守住边界，还需要分别验证。

另一个设计发生在并发控制上：任务有硬性并发上限，同时始终为人的消息保留一个槽位。即使工作队列已经满了，人仍能查询进度，或者调整正在执行的任务。

这个细节关系到 Agent 能否被及时纠偏。自动执行越持久，越不能让状态查询和方向调整也排在大量工作之后。原文作者尤其认可这一点，但没有交代具体并发数，以及保留槽位如何与运行中的任务交互。

我的判断

我认同这三个设计的共同方向：把 Agent 当成需要授权、汇报和接受调整的协作者来设计。

相比把所有接单条件都塞进提示词，代码检查适合承接允许名单这类明确规则；相比把全部并发能力用于执行任务，保留消息处理能力更照顾人的介入需求。代价是需要额外实现调度与状态管理，预留容量也可能减少同时执行的工作数量。

但这篇原文更接近设计摘记，没有展示代码、测试方法或实际运行指标。「尽量少占用人的注意力」是设计目标，尚不能当成已经验证的收益。工作标识是否准确、权限是否真正受限、人的调整能否及时生效，原文都没给足证据。

所以，值得借鉴的是机制，不能直接背书它已经具备同事级别的可靠性。

能拿来做什么

• 如果团队正在做自动接单的编程 Agent，可以先把允许名单、是否被 @ 等条件写成代码检查，再让模型处理上下文判断。
• 在 Agent 修改仓库前，先输出规则版本、允许修改的范围和批准人，让任务执行依据可以被查看和追溯。
• 如果用 Node 实现任务队列，可以单独设计人的消息处理通道或预留槽位，并验证队列满载时仍能查询状态、调整任务。