企业级 AI 架构 · 07 多 Agent 与组织协作｜从一个人，到一支队伍

企业级 AI 架构 · 07 多 Agent 与组织协作｜从一个人，到一支队伍

系列第 07 篇。前面六篇都在讲"单个 Agent 怎么干对"，这一篇升一层：当组织里冒出成百上千个 Agent，怎么让它们像一支队伍，而不是一盘散沙。照旧三方对照。

呼应 00 总览的中央论点：多 Agent 编排，是把控制平面从"单 Agent"升维到"一支队伍"——让确定性的协调（而非模型的临场发挥）覆盖整支队伍，而非仅单次调用。

---

一、WorkBuddy 的权威主张：组织竞争力，是一个公式

WorkBuddy 的汪晟杰（WAIC 2026）给"多 Agent / 组织协作"定了个调，一句话说透：

组织竞争力 = 人才密度 × AI 杠杆 ÷ 组织摩擦。

AI 的价值不是"让人快 20%"，而是能力量级跃迁（10 倍甚至数十倍）。但光有超级个体不够——企业真正的痛点在于：超级员工一旦离职，他练出来的那套 AI 能力就跟着走了。所以方向是三步走：

超级个体 → 超级团队 → 超级组织。

图：单 Agent → 企业治理四级，L3–L4 不在单 Harness 内，需上层平台补。

"超级个体"有四个特征：AI First（先让 AI 跑，再判断修正）、能力量级跃迁、主动性极强、影响力溢出。而"超级团队 / 超级组织"要解决的，是多 Agent 协作的三个硬问题：

• 目标：谁去哪个方向；
• 边界：谁管什么、不碰什么；
• 交接：谁把结果交给谁、怎么验收。

一票否决式的信息增量判据：是否上多 Agent，书给出的唯一判据是——协作是否引入了单个 Agent 在生成时无法获得的新信息（如代码执行反馈、视觉渲染反馈、工具验证反馈）。若无新信息增量，多 Agent 往往只是徒增数倍 token 开销；同等思考预算下，单 Agent 可能持平甚至更好。这与本系列 00 中央论点「信息如何在控制平面流动」一脉相承：多 Agent 不是「更聪明」的代名词，而是「引入新信息」的手段。

落点是 Agent OS：一个统一底座 + 成果级共识锚点 + 统一管理。企鹅智库《2026 Q2 AI 趋势报告》把这个转变讲得很直白：企业衡量 AI，正从"消耗多少 Token"转向"沉淀多少可复用的 Skill / 工作流 / 工具 / 组织知识"。

再往产品层，是 2026 年 8 月 WorkBuddy 的一系列动作：项目空间（团队共享知识库 + Agent 运行上下文）、人机双写（人和 Agent 同屏协作）、以及 OPC（一人公司）社区，把"组织协作"一路下沉到"一个人也能跑起一家公司"。

（WorkBuddy 闭源，以上是公开方法论，只当"标准答案"。）

---

二、Pi 怎么做：刻意不做子 Agent

Pi 在这篇的答案是反直觉的，而且它说得明明白白：

Pi 的哲学是 "keep core small"，所以它刻意不含内置的子 Agent 编排。

别的框架把多 Agent 当标配，Pi 偏偏不内置。为什么？还是那句 "Primitives, not features"，它给你底层 SDK，不给你现成的多 Agent 协作层。

这意味着什么？如果你用 Pi 做多 Agent，得自己搭：用多个进程 / 多个容器各自跑一个 Pi 实例，再用你自己的编排（比如一个 shell 脚本、一个队列、或者干脆上 Octo / Avernet 这类上层平台）把它们串起来。Pi 不会替你决定"这个任务该拆给几个子 Agent、谁负责什么"。

这不是缺陷，而是立场：多 Agent 的"目标 / 边界 / 交接"是业务强相关的，框架硬塞一套通用编排，往往套不进去。所以 Pi 选择把这一层完全交给用户，你要的协作结构，你自己定义。

（顺带一句：这正好和 WorkBuddy 的 Agent OS 形成对照——WorkBuddy 把组织协作做进了平台，Pi 把组织协作留给平台外。）

---

三、DeepSeek Harness 怎么做：subagent 是内置能力

DSH 站另一边，它的多 Agent 能力是内置的。

在 DSH 里，subagent（子 Agent）是一等公民：主 Agent 可以把子任务委派给 subagent，各自在独立上下文里执行，再把结果带回主线。配合 workflow（工作流）和 Ralph loop（一种循环编排），DSH 提供了一套内置的"多 Agent 编排"能力。但要补一条时效：v0.1.6-alpha.1 起 Ralph 默认不再启用，需要用时得手动打开——"内置"和"默认开着"是两件事，这次它把开关关上了。

这背后的支撑还是它"一切皆插件"的架构——subagent 本身是插件，编排逻辑可配置、可替换。等于说，DSH 把"目标 / 边界 / 交接"这三件事，做成了运行时里可配置的能力，而不是留给用户自己造。（subagent 在新版里已是正式子系统；另有实验性的 Agent Teams——持久花名册 / 任务板 / 邮箱，属于 opt-in 的可选能力，标注 experimental，是否纳入生产以官方进度为准。到 v0.1.5-alpha.2，Agent Teams 包已可从 npm 直接安装，但必须显式添加 profile 才启用、默认不开——这条默认关的设定很关键：多 Agent 编排是能力，也是风险面，官方选择把开关交到用户手上而不是替用户打开。）而且 subagent 可独立指定 provider / model / reasoning effort / max tokens——等于把"每个子任务用哪个脑子、花多少预算"也做成了配置，主 Agent 派活时就能按任务轻重挑模型。

这里还有一次接口收口：v0.1.6-alpha.1 起实验性 Team 模式统一使用 spawn_teammate，关闭了 subagent 与 subagent_fork 两个入口，默认队友创建上限从 8 增至 16；alpha.2 又给"可继续对话的 subagent 链"设了默认值——最多同时保留 8 个子代理、委派深度为 1（可在设置中调）。也就是说，多 Agent 的"能开多少个、能往下派几层"第一次有了明确上限。对企业来说这反而是好消息：并发数与委派深度正是成本与失控风险的两个闸门，现在它们有默认值了，你就知道该去哪儿改、该改多少。

到 v0.1.7-alpha.1，Team 这条线又收了两处口子。 一是任务看板改为只读——任务的创建和更新只能由 Agent 通过工具完成，人不再直接从看板改；二是Team 工具统一以成员名称作为操作目标，子代理与 Team 的空闲/就绪状态显示也一并统一（alpha.2 又给 Team 成员的初始任务补上"查找队友、联系 Lead"的指引，并明确按成员名发消息）。第一处尤其值得注意：它把"谁有权改任务状态"从人的界面收回到 Agent 的工具调用上——看板变成观察面，不再是操作面。多 Agent 协作里"谁能改什么"这类边界的划法，和前面 spawn_teammate 统一入口是同一个方向。

v0.1.2-rc.1 又把"交接"和"选模"各推进了一步。交接这块，父子 Agent 之间的后续消息改用 send_message 双向传递，取代了原先单向的 report 工具——子 Agent 不再是"派出去、回来交一份报告"的一次性通道，而成了可持续对话的对象。选模这块则从"调用方指定"扩成了三档：Agent 在授权范围内自主挑、调用方指定（provider / model / reasoning effort / max tokens）、以及为 Claude Code、Codex 这类外部编码器单独配置模型。

同一批变更里还有条语义层的：send_message 在 Agent Team 里统一采用 steer 语义，跨 Agent 投递与冷恢复时保留发送者归属与顺序。这条看着细，却是"交接"能不能真跑起来的关键——消息不只是送到，还得说清是谁说的、按什么顺序说的；冷恢复（进程重启后接着跑）尤其依赖这一点，否则恢复出来的多 Agent 会话会串线。

后面两版把"可持续对话的子代理"这条线又补了两截，方向完全一致——让它越来越像一个能正经打交道的对象，而不是一次性通道：v0.1.3-alpha.2 给可继续对话的子代理加上了消息排队、编辑、删除、单条或全部 Steer，以及停止操作——注意这几个动作，和人跟人协作时"撤回一句、插一句、叫停"是同一套语义，也和主线会话的能力对齐了。v0.1.5-alpha.1 又修正了可继续子代理的归属，避免它们被当作根会话参与定时调度——这条看着是 bug 修复，实质是在厘清一条边界：子代理不是独立主体，它归属于发起它的那次会话。多 Agent 编排里"谁对谁负责"这件事，正是靠这类边界一条条划出来的。

标注：DSH 目前是 developer preview（写作时 v0.1.7-alpha.2，非 GA），subagent / workflow 的接口仍在快速迭代、会有破坏性变更，本系列只做架构对照，不承诺逐行跟跑。

---

四、三方对照：多 Agent，三种"组织方式"

协作维度	WorkBuddy（方法论之尺）	Pi（极简派，可跟跑）	DeepSeek Harness（极繁派，dev preview）
组织公式	人才密度 × AI 杠杆 ÷ 组织摩擦	（无内置组织层）	（无内置组织层）
子 Agent 编排	Agent OS 统一底座	刻意不含，用户自建	subagent 内置
目标/边界/交接	多 Agent 协议 + 成果级共识锚点	交给上层平台（如 Octo/Avernet）	workflow / Ralph loop 配置（Ralph 自 v0.1.6-alpha.1 起默认关闭）
组织资产化	Skill 市场 + 企业 AI 资产	文件化 Skill 可团队共享	插件可分发

速记一句话：多 Agent 的难点不在"让一个 Agent 变聪明"，而在"让一群 Agent 目标对齐、边界清楚、交接顺畅"，WorkBuddy 把它做进 Agent OS，DSH 把它做成内置的 subagent/workflow，而 Pi 反其道：不内置，把组织层留给上层平台。三种选择，对应三种对"组织该怎么长出来"的判断。

---

五、从协议到选型：组织协作的评估清单

三方对照讲了"三种做法"，但读者更关心的其实是"我该怎么选"。这一节把"组织协作"拆成五维评估清单——任何上层平台（无论闭源 WorkBuddy Enterprise，还是开源的 Octo / Avernet，详见 09 篇 §四）都可以按这五维自查。

第一维：身份（Identity）。一个 Agent 在组织里是谁？代表谁、归属谁、谁为它担责？这条看似常识，在多 Agent 编排里却极易丢——子 Agent 跑完一圈回来，没人知道它派生于哪个会话、归属哪个业务、谁是它的"问责人"。WorkBuddy 的做法是 OneID 统一登录 + Agent 实名；DSH 在 v0.1.5-alpha.1 修了一项子代理归属的 bug（避免被当作根会话参与定时调度），本身就是这条边界的工程化；开源侧 Octo / Avernet 把身份认证作为一等公民。这条不到位，其他四维都建在沙地上。

第二维：边界（Boundary）。Agent 能调什么、不能调什么？权限在哪儿执行？本系列 04 篇反复强调"权限在模型外执行、计算型控制优先"——这条在多 Agent 场景下的延伸是：每个子 Agent 都要有自己的"作用域 + 凭据范围"，主 Agent 不能把自己的权限一股脑塞给子 Agent。Octo 的"Channel / Thread 作用域"、Avernet 的"访问授权"，都是把这条落成工程，而非依赖 Agent 自觉。

第三维：交接（Handoff）。任务从一个 Agent 流转到下一个 Agent，结果怎么交付、消息怎么投递、归属怎么保留？本篇 §三讲 DSH 用 send_message 双向传递、steer 语义保留发送者归属，正是把"交接"从一次性报告变成可持续对话；开源侧 Octo 的多 Bot 编排、Avernet 的生命周期管理，也都把交接做成配置而非代码。

第四维：复用（Reuse）。协作产出的资产（流程、模板、决策）能否沉淀下来，让下一个团队不重来？WorkBuddy 的 Skill 市场与企业 AI 资产、Pi 的文件化 Skill 可团队共享、DSH 的插件可分发，都是基础设施层的复用——L3–L4 的关键，是让"组织知识"沉淀在平台里，而不是停在某个员工的本地。

第五维：审计（Audit）。谁在什么时间、因为什么、做了什么决定？这条决定了多 Agent 系统能不能进企业内网、合规场景。WorkBuddy 的全链路审计、Octo 的私有化部署、Avernet 路线图里的"后续开放审计"，都把审计当作可信的前提而非附加品。

评估维度	缺失的典型症状	落点参照
身份	子 Agent 派出去回来不知归谁	OneID / Agent 实名
边界	主 Agent 权限被一股脑继承	作用域 + 凭据范围
交接	派活后只回一份报告，丢失上下文	双向消息 + steer 归属
复用	协作产出只在本地，下一次重做	Skill 市场 / 插件分发
审计	决策过程不可追溯，禁入合规	全链路审计 / 私有化

一句话收口：L3–L4 不在单 Harness 里，所以 Pi / DSH 都自觉不做；上层平台无论选 WorkBuddy Enterprise 还是 Octo / Avernet，都可以用"身份 / 边界 / 交接 / 复用 / 审计"五维自查。组织协作的真正难点，不是"让一群 Agent 变聪明"，而是"让一群 Agent 在组织里有身份、有边界、能交接、能沉淀、可审计"——这张清单，正是把这五个判断点摆到桌面上。

---

相关阅读（系列互链）

本篇是【企业级 AI 架构】技术深轨，与公众号《AI思想的东方注脚》哲学引子、本体智能 / FDE 系列同源联动——同一观点不重复讲，按兴趣深潜：

• 《奇正相生：多智能体双擎》（AI思想的东方注脚·B6）——多智能体的排兵布阵，孙子叫奇正相生
• 《庖丁解牛：人机权责》（AI思想的东方注脚·D12）——协作之后最难的，是划清人与 Agent 的权责
• 《中国式 FDE：企业内部 + 外部行业，你的组织怎么搭》（FDE·篇7）——组织侧的另一半答案

下一篇：08 · 性能与 Token 效率——队伍会带了，该算账了：上下文是钱、Token 是钱，三方怎么省。

---

多智能体 #智能体协同 #组织架构 #企业级AI

关注公众号「农夫三拳有点癫」，第一时间读到本系列更新。