为什么大多数多智能体 Demo 一到生产就崩
我见过很多多智能体 Demo，看起来令人惊叹：一群智能体自主地浏览网页、写代码、跑测试、部署上线。然后你尝试构建真实的东西，整个系统土崩瓦解。
问题不在于底层的大模型，而在于系统设计。
核心问题：智能体需要契约
构建微服务时，你会定义服务间严格的 API 契约。智能体系统同样需要这种约束——但大多数教程完全跳过了这一步。
智能体契约需要规定：
- 智能体接收什么输入（Schema，而非自由文本）
- 智能体负责什么（单一且明确的职责）
- 智能体产出什么输出（结构化的、可解析的 JSON）
- 智能体无法完成任务时做什么
没有契约，智能体就开始做不可预测的事：幻觉中间状态、返回没有任何东西能解析的格式、链路中的错误静默传播，直到你得到一个彻底损坏的最终输出。
真正有效的模式：编排器 + 专家
在三次失败的"自主"智能体循环实验之后，我找到了一个简单且有效的模式：
用户查询
↓
[编排器] ← 规划、协调、决策
↓ ↓ ↓
[智能体 A] [智能体 B] [智能体 C] ← 专家，职责单一
↓ ↓ ↓
[聚合器] ← 合并结果，生成最终输出
编排器的职责仅限于规划和协调——它本身不做实质性工作。专家智能体各司其职。聚合器负责合并与后处理。
让智能体可靠的四个原则
1. 全程使用结构化输出。 不要让智能体返回自由文本再用正则解析。使用 OpenAI Function Calling 或 Claude Tool Use 强制 JSON Schema。这能消除一整类 Bug。
2. 在每个边界处做校验。 每当一个智能体的输出成为下一个智能体的输入时，验证 Schema。大声失败，而非静默传播垃圾数据。
3. 为局部失败设计。 一个智能体失败不应该崩溃整个管道。构建重试逻辑、降级方案和优雅的容错处理。问自己：如果智能体 B 返回 null，智能体 C 和 D 该怎么做？
4. 记录一切，什么都不要信。 在我的系统里，每一次智能体调用都有日志：输入、输出、延迟、Token 用量。这是排查问题的前提，没有商量余地。智能体会做出令人意外的事——你需要完整的审计链路。
Prompt 的设计原则
每个专家智能体应该有：
- 简短的系统提示（< 300 Token），只描述一件事
- 明确的输出格式规范
- "无法完成任务时该怎么做"的指令
编排器的提示词是最重要、也最难写好的。它需要：
- 理解整体目标
- 将其拆解为子任务
- 将子任务分配给合适的专家
- 指定期望接收回的输出格式
实践经验：让编排器在规划前先"逐步思考你有哪些信息、缺哪些信息"，能显著提升拆解质量。
总结与反思
- 严格的契约 > 聪明的智能体。 有明确 Schema 约束的智能体，远胜于提示词模糊的"自主"智能体。
- 并行是双刃剑。 并行运行智能体对延迟很好，对调试很差。并行化之前先加关联 ID 和集中日志。
- 编排器提示词是重中之重。 把 80% 的 Prompt 工程时间花在这里——所有下游都依赖于它能正确规划。
- 先设计失败路径。 智能体超时怎么办？API 挂了怎么办？检索结果为空怎么办？显式处理这些情况，不要让它们级联传播。
构建 Agentic 系统，软件工程的成分远大于 AI 工程。模型已经足够强大，你的工作是给它们正确的结构去发挥。