不妨设想一次常见协作：你在 GitHub 上让 Agent 修分页 Bug。它开始改代码，同事补充了一个边界条件；PR 提交后还要等评审，服务中途又重启了一次。

dsh-superagent 要接住的，就是这段持续变化的工作。 它把新请求变成有授权的任务，让后续讨论找到负责人，再把可审查的结果或需要人决定的问题送回原会话。

先看它怎样分工，再沿着这次分页修复，逐步打开里面的机制。

先认清分工：谁接消息，谁决定，谁执行

dsh-superagent 面向一个 GitHub 仓库，也可以接入飞书。它作为 DeepSeek Harness（简称 DSH）的插件包运行：DSH 提供会话、模型、工具等基础能力，Superagent 负责围绕团队任务安排工作。

图 1：先看职责，不展开内部类。接入与回传连接团队，编排与执行处理工作，持久状态和 DSH 托住运行。

图里的三块业务能力可以顺着读：接入层把平台事件整理成统一消息；编排层判断该新建任务还是交给已有任务；执行层读取代码、修改和验证。结果沿回传渠道返回 GitHub 或飞书。管理面板让人查看进度、回答问题、审核结果。

编排层里面，有两位不同的“负责人”。主会话运行模型，负责理解请求；Engine 是普通 TypeScript 代码，负责检查并修改任务状态。 模型可以建议接单，但状态变化仍要经过 Engine 的规则和事务。

src/index.ts 创建的 Runtime 把这些组件连接起来，也管启动、恢复和关闭。先记住这个分工就够了：它既需要模型理解讨论，也需要代码保存和约束工作。下面再看，一项工作究竟保存成什么。

第一步：把“讨论什么”和“正在做什么”分开

你在 Issue 中留言：“请修复分页漏数据，并补回归测试。”GitHub 的接入代码把这条事件转换成 Trigger。同一事件重复送达时，系统先按 ID 查重，避免再走一遍接收流程。

Trigger 还保存来源给出的发送者信息。评论正文、引用和文档内容可以帮助理解任务，但不能凭一句“我是管理员”改写来源身份。谁有权提出工作，由接入代码提取的发送者身份和准入规则判断。

这条消息所在的持续讨论叫 Thread。后面同事补充条件、评审提出意见，还会出现更多消息。它们增加了上下文，却不一定增加一项工作。

获准处理的工作，才会形成 Ticket。这里的 Ticket 可以是“修复分页漏数据”。它持有授权范围、输入、回传位置和执行记录。

图 2：讨论可以承载多项工作，一项工作也可能经历多次派工。图中是局部示例，不限定为一对一关系。

任务交给执行器时，还会产生一次 Assignment，也就是派工。第一次执行失败后，可以保留原 Ticket，再创建新的 Assignment。这样既知道“还是同一个分页修复”，又能区分“这是第二次尝试”。

一个 Thread 可能讨论多个独立任务；同一个 Ticket 也可能同时跟进原 Issue 和新开的 PR。因此，讨论、任务和执行会话都不能直接画等号。

这些对象的状态，由 src/core/engine.ts 统一修改。接收事件的入口只有一行主要逻辑：

receive(trigger: Trigger): ReceiveResult {  return this.repo.atomic(() => this.intake.receive(trigger))}

这里摘自源码，仅调整换行。atomic 把一次接收涉及的状态变化放进同一事务。它先保证任务记录自洽，外部执行怎样接上去，后面再讲。

我会先借用这种对象分离，而不是急着增加 Agent 数量。否则服务一重试，就容易把“继续原工作”变成“再开一份新工作”。

第二步：能接什么，由规则和模型各管一部分

消息到了，不代表 Agent 就应该动手。比如“这里看起来不太对”，究竟是在请求修复，还是同事之间的讨论？

接单判断先经过代码中的 Gate。它检查消息来源、发送者、是否点名 Agent，以及这个接入范围的规则，给出拒绝、explicit 或 inferred 的准入结果。

explicit 可以理解为具备明确请求的准入强度，但不代表代码已经理解正文。允许名单中的人点名请求可以进入这条路径；特定接入范围也可以配置为允许名单外的人点名请求。

图 3：明确请求由主会话理解并路由；推断候选要接单，需要完整研判，还要检查主动接单模式。

接着，主会话阅读消息。对于明确请求，它可以接单、关联已有任务、停止或忽略。对于从事件中推断出的工作机会，想接单就要经过完整的 Assessment：逐条判断启用的规则，给出请求实施的证据，确认目标明确或有既定标准可恢复，而且没有尚待人决定的设计问题。

比如，“页面不好看”不能直接让 Agent 自选风格重做；“把这个间距恢复到既有规范”才可能符合局部视觉修复规则。仓库的默认主动工作规则也只覆盖较窄的文案修正和局部视觉修复。

默认 observe 只记录“本来会接单”，不创建推断任务。auto 才允许符合条件的推断任务进入执行；off 关闭推断候选的准入。这三个模式不等于整个 Agent 的开关，符合条件的明确请求仍可处理。

决定接单时，系统会保存 Mandate，记录这项工作的范围、准入依据和策略版本。分页修复由此有了一份可追溯的授权记录。决定记录、Ticket、订阅关系和派工意图在同一事务里建立，避免留下“已经确认接单，却没有可执行任务”的半套状态。

这份记录能让程序检查授权依据是否仍然成立，但其中的范围仍是文本，具体语义还需要执行器遵守。策略变化会通知在途任务，并使旧评估重新处理；它不会立刻终止所有工作。已结束任务要恢复时，才会重新验证原 Mandate。

这里的策略版本只覆盖接单规则、模式和来源侧策略。更换模型或调整并发数，不会仅因为运行参数改变，就让之前的授权决策失效。源码把“允许做什么”和“怎样调度执行”分开保存。

第三步：同事补了一句话，交给正在做事的人

Agent 开始修分页后，同事在原 Issue 下补充：“空结果集也有同样的问题。”如果系统再创建一个任务，就可能出现两位执行器同时改同一处代码。

dsh-superagent 用 Subscription 记录任务订阅了哪些讨论。新消息到来后，先送给相关 Ticket。人类消息已经交给已有任务负责时，不再重复走新任务评估。

图 4：追问增加上下文，但不会自动扩大原来的授权。

原执行器知道修复进度，也更容易判断“空结果集”属于当前缺陷。主会话会收到通知，但不能趁这条消息仍由执行器负责，再拿它接一份新单；停止工作是特殊允许的动作。

如果新要求变成“顺便把支付服务重构一下”，执行器应当把它交回。源码提供了 orchestrator_trigger_handback；一条消息有多个负责的任务时，要等这些任务都交回或不再负责，才会重新进入评估。

任务也可以仅为了解情况而订阅其他讨论。这种 context-only 订阅提供上下文，不赋予新的工作权限，也不会唤醒已结束的任务。

普通任务结束后，人的新消息可能在原授权下恢复工作，恢复前仍要复验 Mandate。机器人和 CI 消息不会这样恢复已结束任务；人明确停止过的任务也不会被自动唤醒。

这使系统能够持续听见讨论，同时保留一个判断：值得读的新消息，是否真的授权了一项新工作。

第四步：代码写好了，任务未必结束

分页修复交给 DshExecutor 后，会使用该 Ticket 对应的 DSH 会话和工作目录。执行器负责读源码、改代码、运行验证；主会话负责路由与协调。

目录通过配置中的 prepare 命令准备。文档给了 Git worktree 的做法，但源码没有强制固定为 worktree 或 clone；没配置准备命令时，执行器会从空目录开始。

图 5：执行器报告 ready，通常意味着有结果可审查；跟进 PR 的任务，还需要结合 PR 状态及剩余工作判断结束。

假设分页修复已经通过本地测试，执行器可以报告 ready。如果它仍跟进一个待审核 PR，Ticket 不必随之结束；还要看绑定的 PR 是否合并或关闭，以及是否有尚未处理完的后续工作。

报告采用结构化状态，面板据此区分等待回答、等待审核、受阻、失败或继续工作。需要人作决定时，执行器通过 human_action 上报具体问题，系统记入任务，再通知主会话回到对应渠道提问；无歧义、已获授权的部分可以继续推进。

这也解释了面板为什么优先显示待回答、待审核和异常任务。正常进展主要留在 Ticket 中；必须让人采取动作时，问题才需要出现在原来的讨论里。面板读数据生成视图，停止、重试等操作则调用领域接口，不直接修改工单记录。

并发控制也照顾到了“人回来回答问题”的情况。普通执行有数量上限，但人的后续消息唤醒已有任务时，可以使用一个额外槽位。WorkerSlots.reserve 的检查是：

if (  this.used() >=  this.max() + (by === 'person' ? 1 : 0)) throw new Later('No worker slot is free')

这段同样只调整了源码换行。额外容量只有一个，机器人和 CI 输入不能借用；后台任务或子代理还在运行时，也不能只因模型结束一轮输出，就认定 worker 已空闲。

执行边界还要单独看：当前会话使用 danger-full-access，独立目录不构成硬沙箱。主会话“不做技术决策”和自动合并要求中有些约定由提示词管理；需要强制评审时，仍应配置 GitHub 分支保护。

团队可以编辑沟通、任务范围和交付要求。Prompt 有版本记录，上游默认内容变化也能比较差异。执行器还会读取 DSH 的编码指令和仓库 AGENTS.md，这些协作约定与代码里的准入检查分别起作用。

第五步：服务重启后，沿着已保存的事实恢复

最后看开头那次重启。假设数据库已经记录“接受分页修复”，worker 还没启动，进程就退出了。如果派工只在内存里，这项工作可能再也接不上。

dsh-superagent 把两件事放进同一个事务：保存任务状态，同时登记接下来要做的动作。Store 用 SQLite 保存记录，Effects 保存待执行动作。事务提交后，适配器才启动会话、投递输入或发送消息。

图 6：状态和待办一起提交；执行、重试和恢复发生在提交之后。外部操作仍有各自的失败与幂等边界。

这样，重启后可以查到“接了什么、还准备做什么”。启动逻辑检查中断的派工：需要恢复执行的重新排队，已有明确等待或失败报告、且之后没有新输入的，保留其原状态。

给人的回复由 Outbox 专门管理。它先保存待发消息和发送记录，再排入 Effects，实际发送时找到 GitHub 或飞书渠道。Source 暂停时可以等待，目标会话消失时记录丢弃原因。

为减少重复回信，GitHub 发送前会检查稳定标记，飞书使用幂等键。会话内消息还会检查持久历史和待处理 inbox 中的 ID。它们分别处理不同位置的重复，不能合并成“所有外部操作恰好执行一次”的保证；Git push、自定义脚本仍需看各自的失败窗口。

调度器 Passes 每两秒或按请求推进工作，每轮唤起队列并检查到期评估，不等某个修复任务全部跑完。同一讨论的评估串行，评估期间的新消息留给下一批。队列失败后退避重试；暂时没有 worker 槽位的 Later 则表示稍后再试，不计为执行失败。

队列还防一种容易漏掉的竞争：同一个动作正在执行时，又收到更新的内容。它用代次区分新旧版本，旧执行结束时不会把新版待办一并删掉。会话投递也区分“送到 inbox”和“已进入历史”，避免把取消的处理步骤误算成已经读过消息。

SQLite 保存的是任务事实和待办，DSH 另外提供会话历史。恢复要结合这两类记录，不能仅把聊天记录再读一遍，也不能承诺从任意 shell 命令的中间指令无缝继续。

读到这里，才适合回头看装配代码。Runtime 将存储、来源、策略、研判、执行和回传接口接到 Engine 上；Engine 内部再分管接入、评估、任务、派工与回复。配置与提示词则各自保存版本。源码里的分层，正好对应前面逐步遇到的问题。

如果要继续读实现，可以沿这条短路线：

• • 接入与接单：sources/ → core/intake.ts → policy.ts、core/evals.ts。
• • 任务继续与执行：core/tickets.ts → executor/dsh.ts、core/assignments.ts。
• • 恢复与回传：app/store.ts → app/effects.ts、app/outbox.ts，最后回到 app/runtime.ts 看装配。

这份原型值得借鉴的是一条清楚的工作线：新请求有接单依据，追问有负责人，执行有独立记录，重启有可恢复的状态。搭建自己的团队 Agent 时，可以先沿这条线检查，再决定怎样扩展模型、工具和主动工作规则。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】