多Agent协作没那么美：串联执行的实际坑与优化思路

这个确实说到点子上了，JSON Schema强制统一格式我试过之后效率提升很明显，不然光是debug agent之间传递的Markdown列表缩进问题就能耗掉半天。不过动态路由这个坑更深，我最近尝试用LLM自己判断下一步路由，结果经常跑偏，你们有没有试过在预定义工作流里加个“异常处理Agent”来兜底？

刚看完你这段分享，确实说到我心坎上了。我最近也在折腾多Agent协作，第一个坑跟你一模一样——上下文格式一致性简直要命。我这边更离谱，A Agent输出里带了个代码块，B Agent死活识别不了，后来才发现是缩进用了tab和空格混在一起。后面我也被迫上了JSON Schema，但有个问题想请教：你们是怎么处理Schema变更的？有时候业务逻辑一调整，中间数据结构就得改，但多个Agent的prompt里都嵌着Schema描述，改起来跟牵一发动全身似的，有没有什么优雅的版本管理方式？

另外你提到动态路由那部分，我特别有同感。预定义工作流在demo里跑得飞起，一上真实数据就抓瞎。我遇到过一种情况：研究Agent查到的资料质量太低，按理说应该直接跳过代码审查这个环节，但工作流硬是往下传，最后审查Agent对着垃圾输入输出了一堆无意义评论。你们后来有没有尝试过让某个Agent自己决策“是否继续”或者“切换模式”？我试过给Agent加一个“判断点”，让它在输出里带一个路由字段，但准确率不太稳定，有时候该跳的不跳，不该跳的瞎跳。

JSON Schema这点太真实了，之前我们团队搞多Agent的时候，也是被上下文格式坑得最惨。A Agent输出个带表格的markdown，B Agent解析到一半直接崩了，查了半天才发现是某个竖线对齐的问题。后来我们干脆强制所有Agent用统一的JSON结构通信，字段名、层级、类型都锁死，甚至写了个校验中间件，不符合schema的直接拒绝，虽然粗暴但真的省心。

动态路由这块我也有同感，预定义工作流在简单场景下还行，一旦任务复杂起来，比如研究Agent发现某个方向需要先做数据清洗，但工作流里没这个节点，就得硬塞或者手动干预。我们现在的做法是引入一个“调度Agent”，它本身不干活，但负责根据当前上下文和任务状态，动态决定下一步派哪个Agent、传什么参数。代价是调度逻辑本身要写得很健壮，不然容易死循环。

另外想补充一点，Agent之间的“记忆”也是个隐藏坑。比如研究Agent查了3轮资料，中间结果如果只传最终摘要，后面的代码审查Agent可能丢失关键细节；但如果全传，上下文窗口又扛不住。你们是怎么平衡信息压缩和完整性的？我们试过让每个Agent维护一个结构化记忆池，按重要性排序，但实现起来挺复杂。

中间数据结构这个坑我太有同感了。之前搞过一个文档生成+代码审查的串联流程，A Agent输出的是带表格的markdown，B Agent那边用正则解析，结果表格里有个换行符没处理，直接卡了三天。后来被迫统一成JSON Schema，每个字段还得规定是否允许null，不然C Agent拿到空值就崩。说实话，光定义这个Schema就花了小一周，而且一旦某个Agent改了输出字段名，所有下游都得跟着改，维护成本比预想的高不少。

动态路由这个点你提得很准。我试过在预定义工作流里加个“判断节点”，让LLM根据初步结果决定走哪条分支，结果LLM自己经常选错路径。比如研究阶段说“需要更多数据”，结果它反复循环同一个子任务，最后超时。后来干脆写了个简单的规则引擎，把判断逻辑硬编码成if-else，虽然土但至少稳定。

另外想补充一个坑：上下文窗口的隐性消耗。串联执行时，每个Agent都带着前面所有Agent的输出历史，token量像滚雪球一样涨。有一次任务链跑了6个Agent，最后光上下文就撑爆了上下文窗口，不得不加个“摘要节点”把前面的历史压缩成关键信息。但摘要本身又可能遗漏细节，导致后续Agent理解偏差。

你们现在是怎么处理Agent之间状态不一致的？比如A认为任务完成了，B却因为解析失败卡住，这种异步错误目前除了重试机制，有没有更好的解法？