把团队消息，
变成可追踪的开发任务。
一个面向单个 GitHub 仓库的主动式编码 Agent：先判断工作是否获准，再交给独立会话执行，最后把结果带回原对话。
作为 DeepSeek Harness 的 bundle 运行。
一条消息，如何走到一个 PR？
选一个情境，逐步观察系统把什么交给了谁。
“主动”有多主动，由策略决定。
切换模式，看看同一条消息会不会创建新任务。
理解它，要分清这四组关系。
消息是事件，对话才是上下文。
展开：Source 和 Channel 又是什么？
Source 负责读入事件、保存读取位置和识别机器人自身。Channel 是写回地址：同一段对话可能有多种回复通道。重复 Trigger 在接收时会被去重。
收到上下文，不等于拿到授权。
展开：来自相关 Issue 的消息能授权吗？
执行器可以订阅相关 Thread 作为上下文。这类订阅不带来新的权限，也不会仅凭其中一条真人消息唤醒已结束任务。跨来源的身份也不会自动映射。
任务可以延续，执行分配可以更换。
展开：为什么不直接用 Agent 会话当任务？
任务有自己的订阅、输入和结束原因；会话有工具、目录和运行状态。把两者分开，才能在执行中断后保留工作历史，并在授权仍有效时恢复任务。
报告 ready，可能仍在等人审查。
展开：结束以后还能继续吗？
通常可以。自有 Thread 上的真人消息能在当前策略重新校验 Mandate 后恢复任务。人工 stop 会撤回授权，不能依靠新消息恢复；机器人与 CI 也不会唤醒已结束任务。
带着问题读代码，比从入口读到底更快。
这是 TypeScript 编排应用。DeepSeek Harness 提供 Agent 运行底座，React 提供管理面板。
代码管状态，提示词管工作方式。
这条分界，决定了该改代码、改配置，还是改团队提示词。
由宿主代码执行
接入与任务约束：来源名单、接收规则、Mandate 校验、工具参数和回复用途限制。
可靠性机制：事务保存状态，Effects 在提交后处理外部操作；失败退避重试，Outbox 保存发送回执。
执行调度：每个任务独立会话与目录，限制 worker 并发，并给人的后续消息保留额外槽位。目录本身不保证是 Git worktree。
查看确定性入口由模型按提示词判断
具体做什么：判断语义与范围，阅读代码、实现、验证，决定何时报告结果或提出问题。
怎样与团队协作：Communication、Ticket scope、Delivery requirements 和团队 skills 定义行为。
是否自动合并：由交付提示词约束，宿主没有专门的合并判断逻辑；默认仍需配置另一合并账号的 CLI。
查看交付提示词任务目录隔离，
不等于操作系统沙箱。
worker 以操作者的系统用户运行。命令包装器和 blocked commands 只是默认约束，不能构成安全边界。实际部署建议使用独立 OS 账号、专用 Harness profile 和 Agent 凭据。
运行入口：先阅读 SETUP.md，由编码 Agent 协助配置。开发校验命令为 pnpm check（类型检查、测试、构建）。本页仅分析项目，未部署或运行这个 Agent。
每一个关键结论，都能回到原始资料。
链接固定到本次分析的提交，避免后续代码更新造成口径变化。
基于提交 6337fc823ce20251c8de8085948165c81aaa701e · 2026 年 11 月 2 日分析。仓库声明：这是供研究参考的原型，并非 DeepSeek 官方产品；公开实现与团队内部版本、文章中的设计并不完全一致。本页为独立中文讲解，未执行该项目的测试，流程中的消息、任务和 PR 均为教学示例。