别急着上多Agent：5个工作流编排的坑，我替你踩了
第一天就炸了
三周前，我信心满满地部署了一个"全自动内容生产流水线"。
架构很美：13个Agent，分工明确——选题Agent、研究Agent、大纲Agent、写作Agent（拆成三个，分别负责引言/正文/结尾）、事实核查Agent、SEO优化Agent、图片描述Agent、排版Agent、发布Agent，最后还有一个"质检总监Agent"负责兜底。
画在白板上的时候，同事都说：太厉害了。
上线第一天下午两点，我收到一条报警短信。
打开日志一看——研究Agent查到了一篇相关文章，把URL塞进了上下文。写作Agent接到任务时，上下文窗口已经快满了，它悄悄把"背景材料"截断，继续写。事实核查Agent拿到文章，没有原始资料参照，开始自由发挥"核查"。SEO Agent给一篇事实错误的文章打了高分。质检总监Agent在一个400 token的残缺文档上盖了"通过"章。
整条流水线，笑嘻嘻地，发出去了一篇胡说八道的文章。
踩了不少坑之后，我把最核心的5个问题整理出来，帮你避掉。
坑一：Agent交接文档丢失——"我以为你知道"
多Agent系统最大的幻觉，是以为Agent之间的交接像函数调用一样精确。
实际上不是。每个Agent都活在自己的上下文气泡里。当你把"任务"从Agent A传给Agent B时，Agent A做决策时的推理过程、它拒绝的方向、它遇到的歧义……全消失了。这叫隐式上下文丢失。
解法方向： 显式交接文档（Handoff Document）。不要只传"结果"，要传：当前任务完成了什么、遇到了什么不确定性、下游需要注意的约束、被跳过的选项及原因。LangGraph的State概念可以在图的边上附带结构化状态。
坑二：状态管理混乱——"它改了什么我不知道"
举个具体场景：你有一个"用户需求"对象。Agent A在处理过程中，觉得"这个限制条件太死板了"，悄悄调整了描述。Agent B读到修改后的版本，以为这是用户原始意图，又做了进一步推断。到了Agent C，原始需求已经面目全非。
更危险的是"写-写冲突"：两个并行Agent同时修改同一份文档，后写的覆盖前写的。
解法方向： 用户的原始输入、约束条件、最终目标应该是只读的基准（Ground Truth）。Agent的中间产出放在可追溯的工作区，每次修改打时间戳和来源标注。并行场景下，用消息队列模式比共享可变状态安全。
坑三：错误级联——"一个Agent挂了，整条链路废了"
Agent不像服务那样会返回HTTP 500。它通常会返回一个"还能用"的输出，只是质量很差。然后下游Agent把这个低质量输出当成正常输入，继续处理，错误一层层放大。
我遇到过一个案例：数据分析Agent遇到格式异常的CSV，跳过了异常行继续分析。被跳过的那些行恰好是最关键的异常数据。下游决策Agent拿到报告，做出了完全错误的推荐。从日志上看，整个流程"成功"了。
解法方向： 每个Agent的输出需要一个质量信号（confidence字段）。在关键位置插入校验Agent判断"上游输出是否满足继续的最低标准"。错误要显式传播，不要被吞掉。
坑四：成本失控——"跑一晚上，账单让我窒息"
多Agent成本坑在三个地方：
token复用成本：10个Agent组成的链路，最后一个Agent的输入可能包含前9个Agent的所有输出——成本是累积的。
重试成本：错误发生在链路中段，重试整条链路，前置Agent的成本又来一遍。
并行膨胀：同一时刻token消耗叠加。
解法方向： 设置硬性token预算，超额强制停止。用缓存避免重复调用。LangGraph内置的持久化检查点支持从失败点重启，而不是从头来。先在小样本上跑完整流程，算出日成本上限再决定架构。
坑五：评估困难——"我不知道它变好了还是变坏了"
13个Agent产出一个结果，这个结果不够好——是哪个Agent的问题？是交接哪里断了？你改了写作Agent的prompt，整体指标变好了——是写作Agent变好了，还是输出格式变化让下游更好解析？
解法方向： 分层评估。每个Agent单独有评估集，隔离环境打分。设计接口契约测试（Agent A的输出格式是否满足Agent B的输入要求）。把关键路径上的中间产物也纳入评估——不只看最终输出。
最后说一句
多Agent架构不是银弹，但也不是骗局。CrewAI、AutoGen、LangGraph这些框架已经相当成熟，底层能力不是瓶颈。卡住大多数团队的，是这5个工程问题。
建议把这5个问题当成设计清单过一遍，先回答"我准备怎么处理它"，再动手搭架构。不然，你也会在第一天下午两点收到那条报警短信。
