AI Agent 开发：多智能体工作流从实验到产线的 5 个工程决策
多智能体系统从实验到产线，5 个核心工程决策：拆分边界、通信协议、HITL 插入点、可观测性、模型路由。每个决策附带真实产线取舍案例。
这是多智能体系统从实验到产线最典型的翻车场景。Runway 在今年 7 月推出自然语言工作流引擎、Android Studio 支持多模块并行处理任务、Claude Code 的 subagent 模式在工程师群体里快速普及——多智能体不再是论文里的概念，但「怎么拆、怎么连、怎么管」这三个问题，大部分团队是在产线上交了学费才搞清楚的。
本文围绕多智能体工作流落地的 5 个核心工程决策展开，每个决策都附带真实取舍逻辑。如果你正在评估相关技术栈或寻找有产线交付经验的团队，这篇应该能帮你少走几个月的弯路。
决策一：单智能体还是多智能体——拆分边界在哪
多模块架构的本质优势是关注点分离：每个执行单元只处理自己擅长的子任务，prompt 更短、上下文更聚焦、输出更可控。但代价也很直接——模块间的协调开销（通信延迟、状态同步、错误传播）会随着拆分数量非线性增长。
一个实用的判断框架：先看任务依赖图，再看上下文隔离需求。如果子任务之间是严格的线性依赖（A 完成 → B 开始），多模块的并行优势为零，反而引入序列化/反序列化开销。如果子任务可以独立执行但需要频繁交换中间结果，通信协议的选择就成了瓶颈（见决策二）。
Anthropic 在 Claude Code 最佳实践中给出了一条经验法则：「先用一个执行单元把整条链路跑通，只有当 context window 频繁溢出或 prompt 指令互相干扰时，再考虑拆分」[1]。这与Claude Code 智能体循环的工程范式一致——在单 Agent 内通过工具链和子任务派发已经能处理大量场景。我们的多个客户项目也验证了这个思路：大部分场景，一个配备完善工具集和清晰 CLAUDE.md 的单元能覆盖 80% 的需求，剩下 20% 才需要 subagent 补位。
| 拆分触发条件 | 建议方案 | 不拆的风险 |
|---|---|---|
| 单模块 context 占用持续超 70% | 拆出专职子单元处理独立子任务 | 上下文溢出导致幻觉和遗漏 |
| 同一 prompt 中不同任务指令互相干扰 | 按职责拆成 2-3 个模块 | 模型在冲突指令间摇摆，输出不稳定 |
| 子任务需要不同的工具权限级别 | 权限隔离，独立模块 | 安全风险：单个模块权限过大 |
| 任务本身是线性依赖，context 够用 | 不拆——用单模块 + 工具链 | 拆分反而增加延迟和故障点 |
决策二：通信协议选型——工具调用 vs 消息传递 vs 共享记忆
一旦决定拆成多个模块，下一个问题就是它们之间怎么对话。三种主流模式各有代价：
工具调用模式：模块 A 把模块 B 当作一个工具来调用。优点是实现简单、与现有 LLM function calling 基础设施兼容。缺点——调用是同步阻塞的，A 必须等 B 完整返回才能继续。Claude Code 的 subagent 采用此方案：主控通过 task 工具派发子任务，子模块独立完成并返回结果[2]。适合「调查-报告」型子任务（如代码库探索、文档检索），不适合需要多轮交互的协作。
消息传递模式：模块间通过消息队列或事件总线异步通信。优点是解耦、可扩展、支持并行。代价是系统复杂度显著上升——需要设计消息格式、处理乱序到达、管理超时重试。适合模块数量 ≥ 4 且子任务可并行的场景。
共享记忆模式：所有模块读写同一个结构化状态存储（如向量数据库 + JSON 状态对象）。优点是不需要显式通信，各自读取最新全局状态即可。代价是状态一致性问题——两个模块同时修改同一字段时谁来仲裁？适合「信息聚合」型场景（如多方并行搜集不同数据源，汇总到共享面板）。
产线实践中，大多数团队最终采用工具调用 + 共享记忆的混合方案：主控通过工具调用派发子任务，子任务结果写入共享状态，其他模块按需读取。关键是要明确每个状态的 owner——任何一个字段只能由一个模块写入，避免写冲突。
决策三：HITL（人在回路）插入点——哪些步骤必须人工确认
完全自主的系统在 2026 年仍然只在少数高信任度场景（如代码补全、文档生成）中可行。涉及资金、合规、客户沟通的生产系统，HITL 不是「要不要」的问题，是「插在哪」的问题。
从工程角度，HITL 的插入点有三种策略：
- 前置审批：执行高风险操作（如发送客户邮件、调用支付接口、修改生产数据库）之前，生成审批摘要等待人工确认。延迟最高，风险最低。
- 后置审计：自动执行所有操作，但生成完整审计日志供人工定期抽查。延迟最低，适合低风险操作。
- 异常升级：自动流转，仅在置信度低于阈值或遇到未预见状态时升级到人工。这是产线中最常见的模式。
我们在一个智能客服项目中采用了分级 HITL：FAQ 类查询（置信度 ≥ 0.95）全自动回复；退换货/投诉类（0.7-0.95）生成建议草稿，人工一键确认；涉及赔偿/法律免责（< 0.7 或关键词触发）直接升级到人工坐席。上线后人工介入率从 100% 降到了 12%，零客诉升级。
决策四：多模块调试与可观测性——5 个单元同时跑，怎么定位故障
单模块出问题，看 prompt + 输出就能定位。5 个单元同时跑，错误可能来自任何一个环节，而且会级联放大——模块 A 给了有偏差的中间结果，B 基于此做进一步推理，偏差被放大，最终 E 输出完全错误的结论。回溯根因极其困难。正如智能体集群树状分解中讨论的，当子任务被层层嵌套后，定位根因需要从结构设计上就埋好观测点。
三个最低成本的观测手段：
- 全链路 Trace ID：每次多模块任务生成一个全局 trace_id，贯穿所有单元的输入/输出/tool call。出问题时按 trace_id 拉完整链路，而不是逐个翻日志。
- 中间结果快照：每个单元的输出在传递前做快照存储（Claude Code 的 checkpoint 机制即为此设计[3]）。出问题时从最后一个正确快照重放，而非从头跑。
- 对抗评审：加一个独立的 review 单元，只做一件事——检查其他单元的输出是否在合理范围内。Anthropic 明确建议「add an adversarial review step」[4]。这增加一次 LLM 调用成本，但在高风险场景下值得。
决策五：成本控制——在「智能度」和「Token 开销」之间做路由
多模块意味着多次 LLM 调用，Token 消耗是单模块的 3-10 倍。如果所有单元都用最强模型（如 Claude Opus 或 GPT-4 级），月度 API 成本可能轻松突破五位数美元。
实际工程做法是模型分层路由：
| 模块角色 | 推荐模型层级 | 理由 |
|---|---|---|
| 主控/编排 | 最强模型（Opus / GPT-4 级） | 需理解全局任务并做路由决策，容错率低 |
| 分类/路由 | 中档模型（Sonnet / GPT-4o-mini 级） | 任务单一、判断标准明确，轻量即可 |
| 信息检索/摘要 | 中档模型 + 长上下文窗口 | 核心需求是吞吐量而非推理深度 |
| 格式校验/语法检查 | 轻量模型或规则引擎 | 不需要 LLM，正则 + AST 更便宜更快 |
| 对抗评审 | 与主控同级或略低一档 | 需要足够判断力才能发现主控的遗漏 |
一个常用优化：缓存共享前缀。当多个模块使用相同的 system prompt 前缀（公司背景、领域知识、输出格式要求）时，利用 prompt caching 机制（Anthropic 和 OpenAI 均支持），可将共享 token 成本降低 90%[5]。
常见问题
问：多模块系统的最小可行架构长什么样？
一个主控单元 + 一个专职 subagent + 共享状态文件。主控负责理解任务、拆分步骤、决策路由；subagent 负责执行具体子任务并回报结果；共享状态文件（JSON 或 Markdown）记录当前进度。这个架构足以覆盖大部分初期需求，复杂度可控。
问：多模块比单模块 + 长 prompt 到底好在哪？
不是「更好」，是「在不同约束下有不同最优解」。单模块 + 长 prompt 的优势是延迟低、调试简单。多模块的优势是每个单元的 context 更干净（无无关指令干扰）、工具权限可隔离、子任务可并行。如果你的单模块方案 context 不溢出、指令不冲突、延迟可接受——就别拆。
问：框架选 LangChain、CrewAI 还是自研？
取决于团队规模和场景复杂度。2-3 人小团队做 PoC，LangChain 或 CrewAI 的抽象层能快速出原型。产线级系统需要精细控制（自定义通信协议、模型路由、HITL 插入点），框架抽象层反而会成为限制——此时基于 LLM SDK 自研更灵活。我们在多个交付项目中采用自研轻量编排层：不做框架级抽象，只做三个基础能力——模块注册、通信总线、观测埋点。
问：多模块的延迟怎么控制？
三个方向：① 并行化——无依赖的子任务同时派发，等待最慢的那个而非串行累加；② 流式输出——不要等完整返回再传递，边生成边流式传递；③ 超时熔断——每次调用设硬超时，超时后走降级路径（缓存结果或升级人工）。
问：你们的交付周期一般多长？
单模块系统（如智能客服、文档问答）通常 4-6 周可上线第一版。多模块协作系统（如工单自动路由 + 处理、多源数据聚合分析）通常 8-14 周，核心时间花在通信协议调试和 HITL 策略调优上。欢迎查看完整案例了解具体项目的时间线和架构选型。如需更具体的交付周期评估，可参考软件定制开发 2026：AI 辅助下交付周期从 12 周压缩到 6 周。
参考
- Claude Code Overview — Anthropic Docs
- Best Practices for Claude Code — Anthropic Engineering
- Claude Code: Use Subagents for Investigation
需要多智能体系统的架构评估或产线交付？
蓝曜炬辉在 2024-2026 年交付了多个多智能体协作系统，涵盖智能客服、工单自动路由、多源数据聚合分析等场景。我们不做框架套壳，只做能跑在产线上的工程方案。
预约架构评估 → | 查看完整案例 →