讲讲并评价一下NanmiCoder/dsh-agent-teams的多agent协作机制

回复 群友 1589： 先说定位：NanmiCoder/dsh-agent-teams 是 DeepSeek Harness（DSH）的一个插件，不是独立框架，也不是 Claude Code 那种内置实验功能。它干的事是把你当前这个 DSH 会话原地变成一支队伍的队长，然后由它招人、拆任务、调度、收口，star 数已经上千。 它到底怎么协作的，拆成六层看。 一、队长制，一个队长同时只带一支队 当前会话 create 之后就是 captain，成员是通过 ctx.subagents.startContinuable 拉起来的 durable 子代理——这个词是重点，意思是成员不是一次性的，它有身份、有 persona、有自己的会话记录，任务结束后还能被唤醒接着聊。这跟很多"开三个 agent 各干一段"的写法不一样：那些是一次性调用，这是长期在编的队友。 二、任务是有依赖的有向图，不是流水线 任务状态机是 pending → claimed → in_progress → completed / failed / cancelled。领取任务前会校验依赖，依赖没完成就领不了；同一个成员不允许同时挂两个未完成任务。 比如 requirements → implementation → verification → review → integration，implementation 在 requirements 完成前谁都抢不到。你想扩 DAG 也行，README 的验证用例里跑过 8 成员、31 节点、运行中扩到 38 任务的多层图。 三、调度是事件驱动 + 原子认领，不靠队长逐个派活 这是我觉得最像"工程"而不是"玩具"的一块。成员进入 idle 时会触发共享任务池的自动续领：调度器用真实 running / idle / ready 状态，原子地给每个空闲成员认领一个 ready 任务并唤醒它。空闲成员没有开放任务就自动复用去干下一个 ready 的活，不需要队长手动点名。 四、attempt 级并发控制，专治"迟到写入覆盖新结果" 多 agent 系统最经典的事故就是：A 任务超时被转派给 B，结果 A 过一会儿把自己那份旧结果写回去了，把 B 的成果冲掉。 它的做法是每次执行都带一个单调递增的 attempt 号加唯一 attemptId。转派的时候先撤销旧 attempt、中断旧成员、等它安静下来，新 attempt 才开始，所以迟到的更新在协议层面就写不进去。它的离线测试里专门有 50 次迟到写入、7 路认领竞争、4 个开放任务冷重启这种故障矩阵。另外成员在中断后如果还持有 in_progress 任务，这个 attempt 会"停驻"，只有显式重试/转派/接管才会撤销它，不会被调度器悄悄重铸——这个细节很多实现都做错了。 五、成员之间直连通信，不用队长中转 每个成员一个 JSONL 邮箱（inbox/captain.jsonl、inbox/<member>.jsonl），agent_teams_send_message 可以成员→成员、成员→队长直达并唤醒对方，工具明确拒绝冒名的 from。队长仍然存在，但角色是汇总和收口，不是消息总线。这一点很关键：agent 之间有通信、有工作流，才是真正的多 agent 编排，只是同时把多个 agent 跑起来不算。 六、磁盘是真相源，计划要先审批再启动 团队状态落在 <workspace>/.agent-teams/<teamId>/，team.json 加邮箱文件，Web 面板读的是磁盘而不是内存投影，所以重启、切会话后能冷发现恢复成员树和 DAG。删除团队不是删，是归档保留完整任务和依赖图，方便复盘。 使用协议是两阶段的：先创建 staged 团队，写成员占位、拆任务、声明依赖，等你审查，Approve & Run 之后才真正创建子代理并开始调度。staged 阶段不产生子会话也不领任务。只有你明确说跳过审查才走 approval: automatic。 好话说完，说几个我认为值得质疑的点。 第一，权限没有收窄。成员可以换 persona，但仍然拿着完整工具集（bash/fs/web）。也就是说一个叫 reviewer 的成员理论上能改文件、能跑命令，人格约束是提示词层面的，不是沙箱层面的。对比之下 Claude Code 的 subagent 是可以配工具白名单的。 第二，质量门禁是事后审计，不是事前拦截。它有一套结构化合同：requirements / implementation / verification / review / repair / integration 这几类任务要有 objective、acceptance，实现和修复还要有 inScope 和 verify；review 只有 verdict=pass 才能 completed，needs_revision 必须 failed 并带 finding；review 失败后自动创建 repair 加下一轮 review，且不依赖那条失败的 review。听起来很完整，但范围控制这一版是"完成时对照调用方提交的 changedPaths 做审计"，不是 host 层写入拦截——也就是说越界改了文件，是事后比对发现，防不住，只能追责。文档自己写明了这点，算是诚实。 第三，状态会漂。模型不总是老老实实调 agent_teams_update_task，干完了不汇报，面板就还显示 in_progress。所以队长必须以 agent_teams_status 或磁盘文件为准做对账，不能信成员的口头汇报。这是所有靠模型自觉的系统共同的病。 第四，持久化边界比较窄。文件级状态只保证在单个 DSH 进程内串行化，多进程同时改同一支队不保证一致；调度是事件驱动不是常驻轮询，队长离线时成员没法冷恢复，消息和任务只能躺在磁盘上等队长回来。所以它适合单人、单进程的本地开发流，不适合当团队共享的常驻服务。 第五，和宿主的耦合偏深。它挂的是 DSH 0.1.0-rc.8 的 shell.overlay，注册的是 host 私有能力接缝（tools 注册表、subagents、agents 状态、systemPrompt.section、Web server 路由），连宿主内部服务键从 ctx.httpServer 改名到 ctx.webServer 都得写探测兼容。好处是轻，不用自己搭 workflow 引擎；坏处是宿主一升级就可能崩，而且这套东西搬到别的 harness 上基本要重写。 最后放个参照系。它在解决的问题——用户只跟一个 Agent 说话，由它派活、跟进、验收——和我之前聊过的 Herdr 加 herdr-workflow 是同一类目标。差别在于：Herdr 那一套是跨进程、跨 workspace/worktree 的桌面 kit，能力边界在宿主之外；dsh-agent-teams 是把整套协作协议做进会话内部，亮点是共享任务池加依赖门禁加 attempt 级并发控制这三件套。跟 Claude Code 的 Agent Teams 比，它的持久化和状态机工程化程度更高、更显式，代价是绑死在 DeepSeek Harness 上，生态规模不在一个量级。 一句话总结：这是我目前看到把"多 agent 并发正确性"想得最清楚的一批实现之一——依赖门禁、原子认领、attempt 撤销、quiesce 等待这几件事，很多号称多 agent 的项目根本没考虑；但它的成员权限没收窄、质量门禁是事后审计、状态靠对账兜底，所以适合当个人开发时的自动化班组，不适合当需要强隔离的生产编排层。