上下文边界驱动的多智能体设计
定义
上下文边界驱动的多智能体设计指的是：在设计多智能体系统时，先分析任务之间是否共享同一段上下文、是否需要看到彼此的中间过程、是否存在持续状态依赖与相互影响，再决定是否拆分成多个 Agent，以及应当采用Sub-Agent、Agent Team还是干脆保持单 Agent。
这个概念的核心口号是：Design around context boundaries, not roles.
翻成工程语言，就是：围绕上下文边界设计，而不是围绕角色设计。 任务该怎么拆，不应先从“Planner、Developer、Tester、Reviewer”这类岗位想象出发，而应先看信息流怎么流、哪些上下文必须共存、哪些可以被压缩成结论后再交付。
在本文档中的语境
在本文语境中，这不是一个泛泛的架构建议，而是判断是否需要多 Agent 的第一原则。
原文强调，真正决定架构的，不是“要不要多 Agent”，而是“这个任务到底需要哪种协作”。如果协作方式选错，即使模型很强，系统效果也会被交接损耗、状态不同步和编排复杂度拖垮；如果协作方式选对，即便只用单个模型实例，也可能把任务完成得很干净。
因此，这个概念同时承担三层作用：
- 它是判断该不该拆的前置标准。
- 它是区分Sub-Agent与Agent Team的核心标准。
- 它也是给“team、swarm、crew”这类花哨命名降温的反迷思框架：名字不是重点，任务结构才是重点。
为什么按角色拆分经常失败
原文对“岗位思维”的批评非常明确：大多数多 Agent 系统不是输在模型能力，而是从第一层就按“岗位”拆，而不是按“上下文边界”拆。
典型错误模式是把一个稍复杂的任务直接映射成人类组织分工，例如：
- 一个 Planner 负责定方案；
- 一个 Developer 负责改代码；
- 一个 Tester 负责跑测试；
- 再加一个 Reviewer 做最后把关。
这种结构在叙事上很顺，架构图也好看，但一旦落到 LLM 系统，问题就会暴露：每一次 handoff，信息都会变薄。
原文给出的失败机制很具体：
- 上游 Agent 知道某段代码“之前刚被重构过，所以某个看似奇怪的判断其实有原因”，但这层背景未必能完整传给下游。
- 执行中的 Agent 做过一些临时取舍，例如“这次先不改 token 校验顺序，因为会影响下游 SSO”，但这种过程中的约束、权衡和局部妥协，往往不会自然沉淀到下一次交接里。
- 到测试环节，下游拿到的可能只是一份较干净的结果和一段很薄的说明，于是它只能验证表面行为，却难以判断“这次改动有没有踩到原有约束”。
- 最终审查者看到的是一个似乎都通过了的结果，但由于上下文逐层流失，反而更难建立信心。
这类失败不是一次性发生的，而是在每次 handoff 里逐步漏光。原文的判断是：质量不是被一次性砸坏的，而是在交接中慢慢流失。
根本原因在于：岗位分工是为人类组织设计的，但 LLM 不是有共享记忆、会后补充和非正式交流的人类团队。它只能基于显式给到的上下文工作，拿不到的背景、约束和临时判断，就等于不存在。
判断是否需要多 Agent 的三个关键问题
原文把判断框架压缩成三个非常实用的问题。这三个问题不是锦上添花，而是决定是否拆、如何拆的主判断轴。
1. 子任务是否需要看到彼此的中间过程
如果两个子任务不需要看到彼此的推理过程、探索步骤和中间状态，只需要在最后拿到对方的结论，那么它们更适合被切成相互隔离的子任务。
反过来，如果一个子任务必须观察另一个子任务的中间修改、局部发现或临时判断，说明上下文边界并不干净，强行隔离通常会造成信息损耗。
2. 子任务是否会相互影响
这里的重点不是最终结果会不会汇总，而是执行过程中是否互相影响。
如果 A 做完某一步，会立即改变 B 下一步的判断、优先级或操作路径，那么它们之间存在持续协作关系；这时仅靠“做完再交结果”的模式往往不够。
如果几个子任务互不依赖、互不影响，只是最后需要合并结果，那么拆开并行更合理。
3. 交给同一个 Agent 一次性做是否更省心
这是原文最朴素也最重要的反问：把这两个子任务交给同一个 Agent 一次性干，会不会更省心？
如果答案是“会”，那通常就不该拆。因为拆分带来的不只是性能收益，还会引入编排、路由、契约、监控、调试和治理等一整串额外成本。
这个问题本质上是在阻止“为了多 Agent 而多 Agent”的过度设计。
如何据此区分三类结构
上下文边界驱动的设计，不是预设“多 Agent 一定比单 Agent 高级”，而是先建模任务，再在三种结构里选最合适的一种。
单 Agent：能不拆就不拆
如果单个 Agent 能完成任务，而且体验上“能，且体感不差”，原文建议直接保持单 Agent。
这不是退而求其次，而是更稳的工程选择。尤其当任务高度依赖、协调成本大于收益，或者上下文本来就切不干净时，单 Agent 往往最容易跑通、最容易调试、也最容易持续迭代。
原文特别提醒，多 Agent 的隐藏成本包括：
- 编排逻辑要编写、维护和监控；
- Agent 之间的契约要定义并版本化；
- 调试链路变长，问题定位更难；
- 上下文需要在多个 Agent 之间一致流转，否则会出现由信息差导致的错误；
- 治理成本会扩大，包括审计、回滚和计费。
所以在这个框架里，单 Agent 不是低配方案，而是默认候选方案。
Sub-Agent：上下文能切干净时使用
当子任务边界明确、彼此不需要共享中间过程、也不需要在执行中互相影响时，就适合使用Sub-Agent结构。
原文将Sub-Agent的价值概括为三件事：隔离、压缩、并行。
- 隔离：子任务在自己的独立上下文里执行，不污染父 Agent 的主上下文，避免长任务被大量探索性中间步骤塞满。
- 压缩：子 Agent 回收的是结论，而不是完整过程。也就是说，它把一段混乱探索压缩成可供上层继续工作的干净信号。
- 并行：既然子 Agent 之间不直接通信，它们通常就可以并发执行，例如分别审查安全、性能、测试覆盖率，最后由父 Agent 汇总。
原文还给出了Sub-Agent的几个硬约束，这些约束正是其可控性的来源：
- 子 Agent 之间不能直接通信；
- 子 Agent 不能继续生成新的 Agent；
- 所有流量必须经过父 Agent；
- 跑完只返回最终输出，不带中间思考。