← 返回列表
✓ 可直接安装
DeepSeek Harness 上的多 Agent 编排
自动检查通过:npm 包已发布且 engines 声明满足基线(声明 Node ^22.19.0 || >=24.0.0);该结论来自程序自动检查,未经人工实机验证。 · 最近上游提交 2026/9/4 · 已提供中文文档
DeepSeek Harness 的多智能体编排:将孤立会话转变为可分配工作、审查输出并运行 DAG 工作流的团队——持久任务账本、真实审查者、崩溃安全恢复。
综合分
35.2
GitHub 分
35.2
用户评分
—
★ Stars
6
周下载量
—
安装插件(需先安装 dsh CLI 引擎:npm install -g @deepseek-ai/dsh)
dsh plugin --profile web add dsh-agent-busnpm 包 dsh-agent-bus 已校验归属本仓库,走 npm 安装最省事
数据截至 2026/9/19(元数据每日更新 · 实装验证按队列轮转,单条结论的验证时间见上方)
安装兼容性检查✓ 自动检查通过
以下结论由程序自动检查 npm 包、engines 声明与入口文件得出,未做人工实机验证——能装不等于用着没问题。
✓npm 包dsh-agent-bus @ 0.1.1
✓Node 引擎要求 ^22.19.0 || >=24.0.0 · 基线 Node 22.19 满足
✓dsh CLI 依赖未声明 dsh 版本约束
✓入口文件main/exports/bin 已声明
验证方式:npm registry 存在性 + package.json 静态校验 · 最后验证 2026/9/19 19:16:32
依赖的 DSH / Cordis 模块
@deepseek-ai/cordis@deepseek-ai/dsh-agent@deepseek-ai/dsh-brand@deepseek-ai/dsh-client-runtime@deepseek-ai/dsh-client-ui-primitives@deepseek-ai/dsh-client-ui-slots@deepseek-ai/dsh-client-ui-tool@deepseek-ai/dsh-home-paths@deepseek-ai/dsh-llm@deepseek-ai/dsh-sandbox-policy@deepseek-ai/dsh-session@deepseek-ai/dsh-session-title用户评分
还没有人投票,来当第一个
订阅周报,不错过优质插件更新
每周一封 · 高评分插件 + 新用户活动
README
dsh-agent-bus DeepSeek Harness 上的多 Agent 编排 把一屋子互不相干的 Agent 变成一支真正干活的团队。 在同一条你已经在用的 Inbox 上派活、验收、按 DAG 跑多步骤流程——不用在它们之间复制粘贴,也不用守着循环当保姆。 dsh-agent-bus 是 DeepSeek Harness 插件:给同一工作区的活跃会话配一份持久任务台账、一条验收回路和一台 DAG 调度器——于是协调这件事交给 Agent 自己,而不是你。 任务工作台 任务工作台:每件工作的状态、成员与消耗一目了然。 流程(DAG)看板 流程(DAG)看板:流程的节点,只在全部前置结算后投递。 为什么值得做 Harness 已经能在同一个工作区里开多个 Agent,但它不让它们协作。落到实上:你才是那个粘合剂。 - 规划 Agent 没法把 brief 交给编码 Agent。 你得手动贴过去。 - 编码 Agent 没法等验收 Agent。 你得把 patch 贴过去,再催验收人。 - 第 3 步失败时, 你得从聊天记录里把第 1、2 步重新拼回来,再手动重排后续。 agent-bus 把 你 从这个循环里摘出去:让协调变得可持久、可验收、可自动——这正是它能在生产里用起来、而不是停留在「聊天式演示」的原因。 你能得到什么 | 能力 | 你不用再做的事 | |---|---| | 真正的工作项,不是消息 | create_task 是一件带正文、带验收标准、带验收人的活;send_note 只是没有生命周期的问候。把任务当聊天,活会卡在「进行中」;把聊天当任务,验收就没了。 | | 能自己跑的计划 | create_flow 建一张命名 DAG:每个任务只在全部前置结算后投递。终态失败沿链条传播——不会留下空转的执行者。 | | 一份持久任务日志 | 每件活都是台账里的一行,不是埋在聊天里。get_task 读一件任务的完整一生;长报告落盘,绝不走模型可能泄露的路径。 | | 真正会验收的验收人 | 执行方 report,验收方通过或把同一条任务连同意见打回去。重做全程同一个 id。 | | 自己会走的上下文 | 结算后,执行方附一份交接(数值、决策、注意事项)随下游任务一起投递。下一棒读的是链条,不是考古。 | | 能扛崩溃的记忆 | 台账 + Inbox 检查点在重启后存活;插件自动唤醒滞留执行者并恢复完整工具集。不用任何人把人拉回来。 | | 真·专家而非子代理 | 每个总线成员都是普通 dsh 会话,自带独立的 skills、MCP 服务器、权限预设和模型。create_member 一键入职完整成员,失败自动回滚。 | 生产里能落在哪些地方 agent-bus 是为已超出「一个 Agent + 大量复制粘贴」的团队准备的: - 长期多步骤构建——规划一次发布,拆成 Agent 真去执行的任务,让 DAG 只在依赖被验收后才派下一步。你看面板,不看逐字稿。 - 能力各异专家池——带仓库 MCP 的编码员、带网页 MCP 的研究员、权限更紧的验收人。各自保留配置,总线负责在他们之间路由活。 - 可复现的验收门槛——每件活都有验收标准和验收人。非得一位具名验收人落定,才算「完成」。这是聊天与工作流的分水岭。 - 可查询的审计轨迹——每个决定、结论、交接都是台账行或落盘报告。「昨天验收通过的是哪件?」是一次 get_task,不是翻聊天。 - 能活过重启的团队——会话压缩和进程重启不会丢计划、不会困住执行者。总线会自动把它们拉起来。 怎么工作 投递用的是 harness Inbox:一个 turn 一条 followup(),空闲会话接下一条。本插件不加第二队列。 插件的活是 台账——谁派活、谁执行、什么叫「完成」、谁依赖谁——再加一台读台账的面板。 没有 receive 端工具。执行方看到的是一次普通 turn,干完调 report_task。 note send_note → 对方用 prose 回(或不回) task create_task → queued → submitted → working → completed → settle flow create_flow + tasks → DAG 在前置结算后自动投递下一节点 按轻重选最匹配的通道。 Agent Bus 与子代理 子代理(sub-agent)在今天 Harness 里是默认答案,这不无道理。问题不是「谁更好」,而是 「哪个适配工作的形状」。 子代理擅长什么 spawn_subagent 会启动一个用完即弃的子会话,它继承父会话的权限信封与会话配置,干一件活,还回一条摘要。它在这些情况下正合适: - 你想保护调用方上下文——派一个隔离的探索者去调研,让父窗口保持干净。 - 子会话是一次性的、可丢弃的——它的记忆不需要活过这件活。 - 任务是单个自包含请求,配固定 prompt,而不是一个会接许多活的角色。 agent-bus 擅长什么 总线成员不是子代理。它是一个普通 DeepSeek Harness 会话——你已经会定制的那种——带着自己的 skills、MCP 服务器、插件组、权限预设、模型。这在以下情况很重要: - 执行者是一个你想长期保留的具名专家——带仓库 MCP 的编码员、带网页 MCP 的研究员、权限更紧的验收人。子代理继承给三者同一个信封;按会话配置给各自专属。 - 工作是带依赖的多步骤计划——A 没验收,B 不该开始。那种排序是张 DAG,不是「摘要落地了就 spawn 下一个」。 - 你需要验收回路和审计轨迹,而不是一棵摘要树。任务的正文、验收标准、验收人、结论、交接,都是你能用 get_task 查询的持久台账行。 - 团队得扛得住重启或压缩——台账和 Inbox 检查点比父上下文活得久。 对比 | | 子代理 | Agent Bus | |---|---|---| | 工作单元 | 为一件活而生的子会话,用完即弃 | followup() 进一个已存在的 Peer 会话 | | 执行者是什么 | 一次性孩子:类型 + 能力模式 + 可选 persona | 你在 dsh 里配置的一级会话实例 | | Skills / MCP / 插件 | 继承自父,通常为 spawn 收窄 | 按会话:自己的 skills、MCP 服务器、插件组 | | 权限 | 父会话信封,收窄 | 按会话(多租户 host 下按权限组) | | 拓扑 | 星型:父是中心 | 同一工作区的 Peer + 持久台账 | | 谁验收 | 父读摘要 | 一级验收人验收或重做同一条任务 id | | 排序 | 父必须编排每一次 spawn | DAG:A 没结算,B 不投递 | | 失败 | 父得自己发现 | 终态失败/取消沿链条传播 | | 重启后 | 剧本活在父上下文里 | 台账 + Inbox 检查点存活 | | 并行 | 一个父派多个孩子 | 多个 Peer 并行;每个 Peer 一个 turn 一个 Inbox 项 | | 热上下文 | 每次 spawn 吃一次冷前缀 | 专家长寿;下一条活是暖 turn | 经验法则 用子代理去保护调用方上下文,应对一次性工作——隔离探索、单个请求、用完即弃的孩子。 用 agent-bus 当被调用者是一个具名队友——带着自己的 skills、MCP、插件、权限,还会接下一条活——并且工作值得保留排序、验收和审计轨迹。 它们是互补而非竞争:spawn 一个子代理让调用方保持干净,用总线去跑那个会 spawn、会验收、会把工作往前推的团队。 快速上手 dsh plugin --profile web add dsh-agent-bus dsh web 本地开发: dsh plugin --profile web add . dsh --profile web --dump-config dsh web 需要 Node.js ^22.19.0 或 >=24.0.0(与 harness 一致;CI 跑在 Node 24)。 工具 | 你想… | 用 | |---|---| | 问一句、不是派活 | send_note | | 给一个同伴一件要验收的活 | create_task | | 按顺序跑一个多步骤计划 | create_flow,再带 flow_id / dependencies 的 create_task | | 交差 / 验收 / 重做 / 停掉 / 反问 / 换人 | report_task · settle_task · cancel_task · request_input · reassign_task | | 自己领回被重投的任务 | claim_task | | 回答执行者的结构化提问 | answer_question | | 把上下文交给下一棒 | submit_handoff | | 改还没投递的节点,或查记录 | edit_task · list_flows · list_tasks · get_task | | 给流程改名,让任务组更好管理 | rename_flow | | 看谁在线,声明自己能做什么 | list_peers · update_card | | 把新成员一键入职到工作区 | create_member | 文档 | | | |---|---| | docs/usage.md | 手册(中文):工具、状态机、模板 | | docs/v1.5-resilience-spec.md | 离线消息、改派、离线宽限 | | docs/v1.4-event-driven-scheduling-spec.md | 事件驱动派发、流程、交接 | | docs/a2a-alignment.md | A2A 任务状态对齐 | 许可 MIT
扫码进群