大多数 multi-agent demo，前五分钟看起来都很惊艳。然后同一个问题就会出现：agents 职责重叠、重复劳动、凭空脑补自己该管什么，彼此说了半天，却没产出多少真正有用的结果。
这不是模型问题，而是架构问题。
如果你想让 multi-agent system 经得住真实用户，系统设计就必须围绕“边界”展开，而不是围绕“人格设定”展开。一个 agent 的价值，不在于 prompt 写得多聪明，而在于它只拥有一个狭窄职责，并且能产出让后续链路放心接手的结果。
从专职角色开始，不要一上来就做 swarm
毁掉多智能体系统最简单的办法，就是给每个 agent 都过大的权限。一旦这么做，你就不再是在做 composition，而是在复制一堆职责重叠的通用工。
一条能上线的工作流，需要边界清楚的角色：
- 一个 planner 负责拆任务
- 一个 researcher 负责收集证据
- 一个 writer 负责把证据组织成 draft
- 一个 editor 负责检查结构、一致性和语气
- 一个 formatter 或 renderer 负责把结果打包成目标交付形式
这会带来两件非常实际的好处。第一，prompt 不会无限膨胀。第二，失败可以被诊断。结果弱了，你可以直接去看是哪一层出了问题，而不是一股脑怪整套系统。
Handoff 必须结构化
如果结构化 payload 能解决问题，就不要让 agent-to-agent communication 保持自由发挥。交接里的歧义越多，下游 agent 就越需要重新解释意图。
一个好的 handoff，通常至少会包含：
- 任务目标
- 要求的输出格式
- 约束条件
- 源证据或参考材料
- 尚未解决的问题
这样，接手的 agent 就是在执行一个有边界的 contract。每一层知道自己该吃什么输入、必须吐出什么输出，整条系统就会变得更容易推理。
上下文隔离不是可选项
多智能体系统越跑越差的核心原因之一，就是上下文污染。如果每个 agent 都能看到所有消息，那整套系统最后只会退化成一个更混乱、仪式感更重的超大 prompt。
上下文隔离能把这个问题挡住。每个 agent 只应该看到它真正需要的东西：
- planner 看完整用户目标
- researcher 看研究问题，以及它依赖的前序输出
- editor 看 draft 加 editorial checklist
- renderer 看最终内容和布局约束
这不只是节省 token 的技巧，它本身就是正确性优化。更窄的上下文会减少角色漂移，让输出更稳定。
可以有 Supervisor，但它必须够薄
Supervisor 层当然有用，只要它做的是协调和失败恢复；一旦它开始替所有 specialist 干活，问题就来了。
Supervisor 应该负责的是：
- 拉起正确的 specialist
- 检查必需输出是否存在
- 某一步失败时重试或改路由
- 维护任务状态
它不应该没完没了地重写 specialist 的工作，除非工作流本来就明确要求它这么做。只要 supervisor 变成了第二个 writer、第二个 editor、第二个 researcher，架构清晰度就会立刻崩掉。
可靠性比新奇更重要
最好的 multi-agent architecture，不是 agent 数量最多的那套，而是在正常负载下也能稳定重复交付同等质量结果的那套。
这意味着你必须优先把那些听起来很无聊、但其实最关键的东西做扎实：
- 确定性的 handoff schema
- 有上限的重试
- timeout 处理
- 可观察的执行 trace
- 步骤之间的 artifact persistence
这些细节，决定了一套东西到底是玩具，还是别人真的能运维的系统。
只有当任务真的可分解时，多智能体才值得
如果任务又小又线性，一个强一点的单 agent 通常就够了。Multi-agent 真正值回复杂度的场景，是任务天然能拆成不同类型的工作，而且这些工作需要不同上下文。Research、drafting、review 和 rendering，就很符合这个模式。
最常见的错误，是把多智能体结构硬套到并不值得这么拆的任务上。正确问题不是“我们还能再加多少个 agents”，而是“哪些职责值得拥有自己的边界，因为这个边界会直接提升可靠性”。
只要你老老实实回答这个问题，架构反而会变简单。而能活下来的系统，通常就是简单的系统。
如果你想把这套边界意识落实到内容生成里，可以继续看 面向内容生产的 Multi-Agent AI System；如果你更关心 plan-execute 这类核心运行机制，可以直接跳到 agentic AI workflow 指南。想亲手试一遍真实链路，就去 AtomStorm 开始创建。