dsh-agent-teams

Name: NanmiCoder/dsh-agent-teams
Author: NanmiCoder

NanmiCoder/dsh-agent-teams

AgentTeams 多智能体团队。

40836TypeScriptMIT源码

安装

把 dsh-agent-teams 装进 DeepSeek Harness

npm 方式

直接拉已发布的 tarball，不用克隆整个仓库，也不需要额外配置。如果你用的是别的 profile，把 `web` 换成对应的名字。

GitHub 方式 · npm 包

从 GitHub 装会执行项目自己的构建脚本，而 pnpm 默认拦着不让跑——先跑一次这条命令，pnpm 会打印出要加到 ~/.dsh/profiles/web/pnpm-workspace.yaml 里 `allowBuilds` 下面的那个 key。

安装前须知

装 dsh-agent-teams 之前，先看这几条

源码在这里： NanmiCoder/dsh-agent-teams——已进入社区精选库，DSH 自带的插件市场就是从这儿装的。
开源协议：MIT。
自动识别到：终端执行。授权之前请先读一遍源码。
被收录在这里不代表通过了安全审计。插件是带着你 agent 的权限在跑。

dsh-agent-teams 是做什么的

dsh-agent-teams 是一个 DeepSeek Harness 插件，把当前会话变成负责统筹的 captain，并创建可继续唤醒的 DSH sub-agent 团队。它可以按角色拆分目标，建立带依赖关系的任务，让成员并行处理，再由 captain 汇总结果；成员之间也能直接发送持久消息，不需要经过中继。

插件使用共享调度器管理 running、idle 和 ready 状态：空闲成员会原子领取可执行任务，异常中断或进程重启后，仍未完成的尝试会获得新的 attempt_id。团队状态写入 <workspace>/.agent-teams/，Web UI 同时读取这些文件和实时 sub-agent 活动。默认情况下，成员沿用 captain 当前步骤实际使用的 provider、model 与 reasoning effort；只有明确提出异构团队时，才通过 provider 和 model 指定成员配置。

它适合代码审查、调查和需要多个专业视角的工作。如果任务本身不需要并行协作，或者必须由多个 DSH 进程同时修改同一团队状态，就不适合使用；文件状态只在一个 DSH 进程内串行化。该插件还涉及 terminal surface，因为成员会在当前 harness 环境及 agent 可用权限内执行分配的工作，并非运行在隔离的工作流服务中。

dsh-agent-teams 的文档

配置

插件可直接使用默认值，也可在 trusted profile 中覆盖成员行为。

Key	Value	作用
`stateDir`	`.agent-teams`	团队状态目录
`memberProvider`	`spawn` / `fork`	sub-agent 运行后端
`memberModel`	`deepseek-v4`	所有成员的默认 model
`memberMaxDepth`	`1`	成员深度设置
`maxMembers`	`8`	成员数量上限

memberProvider 不是 LLM provider。跨 provider 路由使用 agent_teams_add_member 的可选 provider 与 model 字段；memberModel 只是统一默认值。

命令

配置组合后可用 dsh --profile web --dump-config 验证，使用 dsh web 启动 Web UI。源码开发使用 pnpm build 和 pnpm verify；修改源码后需要再次运行 pnpm build。

行为说明

当前会话是 captain，一次只能领导一个 active team。idle 成员自动领取 ready 任务。重新分配或 captain 接管时，旧的 attempt_id 会被撤销，并等待旧 worker 停止。无法实时投递的消息会持久保存，并在之后的状态边界重试。成员创建默认记录 captain 当前步骤的 provider、model 和 reasoning effort。

环境要求与已知限制

需要已有的 DeepSeek Harness 安装。状态保存在 <workspace>/.agent-teams/，多个进程同时编辑同一团队不会被协调。面板按持久化状态显示；model 可能完成工作却未更新预期的任务状态。除显式提供 provider 和 model 外，插件不提供每个成员独立的 model 或 reasoning prompt。

根据项目自己的文档整理，会跟着上游更新。两边对不上时以源码仓库为准—— 去 GitHub 看原始 README

同一分类