The full article body is currently published in Chinese. English titles, summaries, and site navigation are available first; full translations can be added article by article.
多 Agent 协作没有被放弃。
但“默认多 Agent 并行”的产品叙事，确实正在退潮。
早期的多 Agent 想象很有吸引力：
- 一个 Agent 负责规划；
- 一个 Agent 负责执行；
- 一个 Agent 负责审查；
- 一个 Agent 负责反思；
- 多个 Agent 互相讨论，最后自动得到更好的结果。
这个叙事适合 demo。
它让系统看起来更智能，也更像一个“AI 团队”。
但真实产品环境会很快暴露另一个问题：
多 Agent 的难点不在于能不能启动多个 Agent，而在于系统能不能治理它们的行为和产出。
当多个 Agent 同时工作，产品要面对的不只是并行吞吐量，还包括任务拆分、上下文边界、权限控制、结果合并、冲突处理、成本管理、审计链路和失败恢复。
所以更准确的判断是：
多 Agent 没有消失，它只是从产品叙事回到了系统治理。
主流方向不再是“让多个 Agent 自动开会”，而是：
默认串行
必要并行
默认单主线
必要委派
默认人类可审查
必要后台执行
默认上下文受控
必要时扩大上下文
默认结果可验证
再谈自动化规模这篇文章讨论的不是“多 Agent 有没有用”，而是更产品化的问题：
在什么边界内，多 Agent 并行才值得启用？
多 Agent 叙事为什么降温
多 Agent 早期叙事的核心假设是：
更多 Agent = 更强能力这个假设并不总是成立。
多个 Agent 可以提高产出速度，但不会自动提高结果质量。
多个 Agent 可以覆盖更多路径，但也会引入更多冲突。
多个 Agent 可以降低单个上下文窗口压力，但会制造多个局部世界观。
在软件工程任务里，这些问题尤其明显。
一个单 Agent 系统已经需要处理：
- 上下文管理；
- 工具调用；
- 权限审批；
- 状态恢复；
- 审计日志；
- 错误处理；
- 用户接管；
- 结果验证。
多个 Agent 并行后，还会增加：
- 任务拆分；
- 子任务生命周期；
- Agent 间依赖；
- 结果合并；
- 变更冲突；
- 并发成本；
- 权限隔离；
- 多份执行记录的审计。
所以多 Agent 不是一个简单的能力增强。
它是一种复杂度投资。
复杂度投资必须回答一个问题：
它消耗了更多治理成本，换来了什么确定的产品价值？
如果答案只是“看起来更自动化”，那通常不够。
真正的瓶颈不是 Agent 数量
Agent 产品的瓶颈正在发生变化。
当 Agent 能力较弱时，问题是：
Agent 能不能做事？当单 Agent 能力越来越强时，问题会变成：
Agent 做出来的东西，人类能不能理解、审查、验证、接管和回滚？这也是多 Agent 并行最容易被误判的地方。
如果单 Agent 串行输出的计划、diff、日志和测试结果已经让用户审不过来，那么多个 Agent 同时输出只会把问题放大。
并行提高的是产出速度。
但产品真正需要提高的是可验证速度。
二者不是一回事。
一个 Agent 产品最终要解决的不是“如何让更多 Agent 同时工作”，而是：
- 如何让任务边界清晰；
- 如何让上下文可治理；
- 如何让变更可解释；
- 如何让执行可观察；
- 如何让结果可验证；
- 如何让用户保留最终决策权；
- 如何让失败后可以恢复。
所以 Agent 应用的上限，不取决于能启动多少 Agent。
它取决于系统能否治理 Agent 的行为和产出。
Codex 的启示：并行发生在 worktree 和任务边界上
Codex 的并行更接近任务级并行，而不是传统意义上的多个 Agent 自发协作。
从 Codex Worktrees 的官方文档看，worktree 的价值不是让多个 Agent 在同一个上下文里互相讨论，而是让用户可以：
- 在不干扰本地工作的情况下让 Codex 并行处理任务；
- 把后台任务排队运行；
- 在准备好时再切回本地检查、测试或继续协作；
- 通过独立 checkout 隔离代码变更；
- 在需要时创建分支、提交、推送和打开 PR。
这个设计很关键。
它把并行放在 Git worktree、thread 和任务边界上，而不是放在一个共享上下文里。
换句话说，Codex 的并行不是：
多个 Agent 在同一个任务里自由协作而更像：
多个任务在隔离环境中并行推进这是一种更稳的产品策略。
因为每个任务都有自己的工作区、变更记录和审查入口。用户可以选择继续、暂停、废弃、切回本地或创建分支。
并行被约束在可审查的边界内。
这比“让多个 Agent 自动分工并合并结果”更接近真实交付。
Claude Code 的启示：subagent 是按需委派
Claude Code 的 subagent 机制也不是简单地把所有任务多 Agent 化。
它更像一种按需委派机制。
当某个任务会污染主上下文，或者需要专门 prompt、专门工具、专门权限时，主 Agent 可以把任务交给 subagent。
Claude Code 官方文档里，subagent 可以配置：
- system prompt；
- 工具权限；
- disallowed tools；
- 模型；
- permission mode；
- skills；
- MCP servers；
- hooks；
- memory；
- background；
- worktree isolation。
这说明 subagent 的重点不是“多一个 Agent”，而是“给一个子任务配置独立上下文和能力边界”。
更重要的是，官方文档对使用边界也很明确。
主会话适合需要频繁来回、共享大量上下文、快速定向修改和低延迟的任务。
subagent 更适合：
- 输出量很大、会污染主上下文的任务；
- 需要特定工具限制或权限策略的任务；
- 自包含、可以返回摘要的任务；
- 多条互相独立的 research path。
这其实是一个非常产品化的判断：
subagent 的价值不是替代主会话，而是保护主会话。
它帮助主 Agent 保持主线判断，把高噪声、低耦合、可摘要的任务隔离出去。
这和“多 Agent 自动协作”的早期想象不同。
它更接近一种上下文治理工具。
什么时候适合并行
多 Agent 并行应该是 opt-in，而不是 default。
我会用五个条件判断一个任务是否适合并行。
1. 子任务低耦合
如果子任务之间存在大量隐性依赖，就不适合并行。
例如全局架构调整、跨模块状态重构、复杂 UX 设计、数据模型变更、共享依赖改造，这些任务表面上可以拆分，实际会彼此影响。
拆得不好，多个 Agent 会在不同方向上制造冲突。
低耦合任务更适合并行：
- 多模块独立调研；
- 多方案探索；
- 日志分析；
- 代码库搜索；
- 文档整理；
- 测试失败分类；
- 竞品资料汇总。
2. 上下文依赖低
每个 Agent 到底应该看到什么，是多 Agent 场景里的核心问题。
看到太少，无法正确完成任务。
看到太多，会增加成本、噪声和误判概率。
如果一个子任务需要持续依赖主会话里的细节、用户偏好、最新决策和未稳定计划，那么它不适合交给独立 Agent。
适合并行的任务，应该能用一个清晰 delegation prompt 描述清楚。
3. 执行环境可隔离
代码 Agent 的并行必须考虑工作区隔离。
如果多个 Agent 可能修改同一个文件、同一组依赖、同一个 schema 或同一个运行环境，就必须有隔离策略。
这也是 worktree 有价值的原因。
并行不应该建立在“大家都在同一个目录里改文件”的基础上。
那不是协作，是冲突制造。
4. 结果可验证
没有验证器，多 Agent 容易变成“更多不确定性的生产机器”。
结果可验证，至少包括：
- lint；
- type check；
- unit test；
- integration test；
- benchmark；
- schema 校验；
- 可复现运行环境；
- diff review；
- 人类验收标准。
如果一个任务无法被验证，就不应该因为“可以并行”而让多个 Agent 同时产出。
并行之前，先要有验证。
5. 用户愿意承担额外 review 成本
并行会增加 review 成本。
这是很多产品叙事里被隐藏的问题。
多个 Agent 同时产出多个方案、多个 diff、多个日志和多个结论，用户需要决定哪些可信、哪些冲突、哪些可以合并、哪些应该丢弃。
如果用户没有足够动机承担这些成本，并行就会变成负担。
所以并行不应该只问系统能不能做。
还要问用户是否愿意审。
多 Agent 的产品边界
我更倾向于把 Agent 产品里的并行分成三层。
第一层：多会话并行
这是最现实、也最容易治理的一层。
每个会话对应一个任务，每个任务有独立上下文、独立执行记录、独立变更结果。
用户可以决定哪些任务继续，哪些任务暂停，哪些任务废弃。
这适合 Codex worktree、cloud task、后台任务队列这类设计。
第二层：主 Agent 按需委派
主 Agent 保持主线判断，在局部任务上调用 subagent。
subagent 的目标不是全面接管，而是处理一段相对独立的工作：
- 跑测试并总结失败；
- 搜索代码库并返回相关文件；
- 调研一个模块；
- 检查一类风险；
- 生成候选方案；
- 阅读长日志并压缩结论。
这适合 Claude Code subagent 这类设计。
第三层：多 Agent 协作式执行
这是最复杂的一层。
多个 Agent 共同参与同一个任务，彼此通信、交接、审查、修改、合并。
这一层不是不能做，但它必须建立在更强的治理能力之上：
- 明确角色边界；
- 明确任务所有权；
- 明确上下文来源；
- 明确事件记录；
- 明确冲突解决；
- 明确权限模型；
- 明确验证流程；
- 明确最终责任人。
如果这些能力没有准备好，就不应该直接把多 Agent 协作做成默认能力。
对 Plato 的启发
对 Plato 来说，最有价值的方向不是追逐“多 Agent 并行”概念。
更好的表达应该是：
Plato 支持受控的任务级并行，并确保任务隔离、上下文可治理、变更可审计、结果可验证。
这意味着 Plato 的重点不是 Agent 数量，而是治理平面。
Task Context
Task Context 要解决的是每个任务在执行时应该携带什么上下文。
在多 Agent 场景里，它还要解决：
- 哪些上下文可以共享；
- 哪些上下文必须隔离；
- 哪些上下文是稳定事实；
- 哪些上下文只是临时观察；
- 哪些上下文可以进入 delegation prompt；
- 哪些上下文必须留在主任务中。
Audit Page
并行之后，用户更需要审计。
Audit Page 不只是展示日志。
它应该回答：
- Agent 做了什么；
- 为什么这么做；
- 改了哪些文件；
- 哪些结果已经验证；
- 哪些结果还需要人工判断；
- 哪些任务之间存在冲突；
- 哪些任务可以安全合并。
Confirmation Flow
并行执行不能绕过关键决策。
当 Agent 要执行高风险操作、合并结果、覆盖文件、部署、删除数据或改变权限时，系统必须把决策权交还给用户。
这不是降低自动化能力。
这是让用户敢用 Agent 的前提。
Review Surface
真正限制 Agent 产品规模的，往往不是执行，而是审查。
Review Surface 要帮助用户快速判断：
- 哪些结果可信；
- 哪些变更重要；
- 哪些风险需要先看；
- 哪些 diff 可以忽略；
- 哪些失败需要重新执行；
- 哪些任务应该终止。
多 Agent 并行如果没有 Review Surface，就很容易把用户淹没在输出里。
结论
多 Agent 协作没有消失。
但它不应该被理解成 Agent 应用的默认架构，也不应该被当成产品价值的核心来源。
它更适合作为一种受控优化手段，在低耦合、可隔离、可验证的任务中提高吞吐量。
未来更稳的 Agent 产品形态应该是：
默认串行，必要并行
默认单主线，必要委派
默认人类可审查，必要后台执行
默认上下文受控，必要时扩大上下文
默认结果可验证，再谈自动化规模对 Plato 来说，真正的壁垒不是 Agent 数量。
而是任务、上下文、执行、审计、验证和用户控制权能否被系统化治理。
换句话说：
多 Agent 的产品价值，不在于“并行”本身，而在于并行之后仍然可控。