DeepSeek开源以减少人工打扰为目标的代理原型

DeepSeek 这次发布的重点，不是一个写代码更强的新模型，而是一套让编程 Agent 在后台持续干活、尽量少打扰人的运行机制。它把开发者的注意力当成有限资源：任务怎么分派、什么时候提问、权限能否扩大，都要围绕这笔预算设计。

这套机制值得看，但不能直接当成成熟产品。原文介绍的是研究原型，没有公开的可复现基准，执行权限也相当宽。对前端和全栈团队来说，最值得带走的是任务边界与人工介入的设计。

后台 Agent 要解决的，是谁来管理这些任务

据原文，DeepSeek Harness 团队于 2026 年 10 月 31 日，以 MIT 许可证开源了 dsh-superagent-prototype。它是面向 DeepSeek Harness 插件框架的组件，一次围绕一个 GitHub 仓库工作。

入口包括 issue、PR 评论、webhook，也可以接入 Feishu。获得授权的人提出请求后，系统创建工作项，分配独立会话和工作目录，执行任务，再回到原来的讨论中交付结果，例如创建 PR。

这里真正挪动的是管理责任。传统的多个 Agent 会话，往往还需要人来回切换、补充上下文、盯住进展。后台会话越多，这部分工作越容易变成负担。

任务并行只有在协调成本可控时，才可能节省人的时间。

DeepSeek 称，其内部实例已经持续用于复现和修复 bug、响应代码审查，以及迭代 DeepSeek Harness。但这是公司的使用描述。开源版本与内部系统并不相同，README 也明确把它定位为可能存在 bug 的研究原型。

新消息可以补上下文，但不能顺手扩大权限

架构分成两层：主会话负责路由，使用较少的工具；worker 会话负责具体编码。领域模型包含五个概念：

• Sources 提供事件来源，例如 GitHub 通知。
• Triggers 是来源产生的不可变事件。
• Threads 按顺序组织相关事件。
• Tickets 表示被接受的工作项。
• Mandates 固定工作项的范围与允许的操作强度。

无状态的 Eval 组件读取一批 Triggers，依据仓库策略判断是否创建 Ticket。它不在规划 Agent 里维护待办队列、重试计时器和轮询循环。等待 CI 或代码审查，也交给外部事件来源处理；结果出现后，再生成新的 Trigger。

「无状态」指的是 Eval 不在两次运行之间保留调度状态，并非整个系统没有状态。按原文设计，Source 会利用 git 历史和 webhook 偏移恢复读取位置，帮助系统在重启后继续处理事件。

更关键的是订阅机制。Ticket 可以订阅相关 Threads，让 PR 评论、CI 结果直接进入 worker 上下文。这个分发过程绕过 Eval，却不能修改既有 Mandate。

例如，原任务只是修复一个页面 bug，后续评论又要求重构整套组件。worker 应当把新增请求交回路由层，而不是把评论自动视为扩权许可。

收到的信息可以增加，获准执行的范围必须单独确认。

每个 Ticket 还会获得独立的 git worktree。Shell 命令运行超过 5 秒，会自动转入后台；后台任务达到 30 分钟硬上限后被终止，输出进入审计记录。前者让安装、测试不阻塞消息接收，后者限制失控任务持续运行。

少打扰人的关键，是明确什么时候必须找人

原文用一个场景解释注意力成本：Agent 发出 20 条通知、开出 4 个草稿 PR，再问 5 个含糊问题，可能比人工完成任务还费时间。这是说明问题的例子，并非实验统计。

原型采用显式人工交接。Agent 需要帮助时，写入结构化的 attention 字段；Ticket 随后等待，释放 worker 槽位，并向原始渠道发送一个结构化问题。Web 面板只展示需要人工操作的事项。

运行时不从自由文本记录里猜测 Agent 是否需要帮助。任务是否卡住、需要谁决定、下一步等待什么，都应成为系统能识别的状态。

策略更新也有收尾过程：系统通知正在执行的任务，让 worker 保存检查点或回滚后结束，避免直接中断留下未处理的工作目录。

原文还给出一个号称约 40 行的 Python 3 示例，将提问限制设为 max_questions_per_hour = 2。下面这段方法展示了预算控制：

def can_ask(self, limit: int) -> bool:
    now = time.time()
    self.asked = [t for t in self.asked if now - t < 3600]
    return len(self.asked) < limit

def ask(self, mandate: Mandate, question: str) -> str | None:
    # Returns ONE structured question, or None if the budget is spent.
    if not self.can_ask(mandate.max_questions_per_hour):
        return None  # budget exhausted: checkpoint instead of asking
    self.asked.append(time.time())
    return f"[{mandate.ticket_id}] {question}"

要看的是 return None：额度耗尽后，调用方应保存进度并等待，不能继续追问，也不能擅自猜答案。代码只返回信号，并没有实现检查点。

示例使用 T-42 标识任务，将范围设为 src/payments/，检查 src/payments/refund.py 后，询问部分 SEPA 付款应采用 v1 还是 v2 退款策略。路径检查通过 path.startswith(p) 完成，只能说明范围约束的思路，不能充当完整的文件访问安全机制。

原文代码存在排版损坏和重复定义，上面的片段也依赖类定义及导入，不能单独运行。这里应借鉴机制，不宜照抄成生产组件。

我的判断

我认可它把路由、权限和人工交接分开。相比让一个长会话同时负责规划、等待、编码和求助，这样更容易回答三个实际问题：任务为何启动、允许做什么、为何停下来。

但「注意力预算」目前更像设计原则。原文没有提供完整的预算计量方式，也没有数据证明通知减少后，漏报和返工是否增加。它展示了结构化交接，不能据此认定已经找到最佳打扰频率。

性能数字同样需要保留边界。媒体转述的一次内部测试称，p95 完成时间从单会话方案的 29.5 分钟降到 15.7 分钟；原文没有给出任务分布、样本量和可复现方法，DeepSeek 也未公布正式基准。这个数字只能视为公司主张。

执行边界更需要认真区分：worker 会以操作者的 OS 用户身份运行 Shell 命令，没有审批提示。git worktree 隔离工作目录，不隔离系统权限；Mandate 描述任务授权，也不能替代操作系统限制。

此外，单仓库设计无法直接覆盖跨服务协调。MIT 和可自行部署有利于控制部署位置，但原文没有交代模型调用与数据流，不能直接推导出数据始终留在本地。媒体所称代码按字节约 97.5% 为 TypeScript，以及首 12 小时约 2,000 stars、170 forks，也分别只能说明实现构成和关注度。

能拿来做什么

• 给现有 AI 编程任务增加明确的范围、完成条件和人工决策点。例如修复前端组件时，先约定允许修改的目录，收到额外重构要求后重新评估授权。
• 在 Node 编写的 Agent 工具里，把求助做成结构化返回值，记录任务编号、具体问题和等待原因，再按任务或团队设置通知额度。
• 为并行任务分配独立 git worktree，把安装、测试等长任务转入后台并设置超时，同时单独限制执行环境的系统权限。
• 评估后台 Agent 时，同时记录完成时间、人工提问次数、审查耗时与返工情况。没有这些记录，就很难判断它究竟节省了多少人的时间。