一句话：多智能体系统不是「想得不够聪明」，而是「跑起来之后到处脱节」
多智能体系统这几年从 demo 走到了不少公司的核心链路，但它的坑到底长在哪儿，过去多是开发者凭手感吐槽。9 月 30 日前后预印本的一篇实证研究（arXiv 2610.00905）换了个更扎实的办法：不去问「哪个模型更强」，而是去翻开源项目里真实工程师踩过的坑。研究者从 21 个开源 LLM 多智能体项目里拉出 22,848 条已关闭的 issue，再用自动加人工的混合方式筛出 944 条确实和智能体相关的，逐条归类它们遇到的问题、成因与解法。结论对做工程的人很有用：头号故障不在模型推理，而在编排与执行——也就是「谁在什么时候该干什么、工具怎么接、记忆怎么管」这一层。
他们怎么做的：从 2.2 万条 issue 里淘出 944 条真问题
方法本身值得记一笔。直接拿全部 issue 训练分类器会引入大量噪声——很多 issue 其实是「文档写错了」「编译不过」「求功能」这类和智能体机制无关的内容。于是研究者先用自动化规则粗筛，再人工复核，把范围收敛到 944 条真正刻画了多智能体开发或使用中困难的 issue。接下来他们对每条做开放式编码，归纳出反复出现的问题类型、背后的成因，以及社区实际采用的解法。这种「从生产现场反推痛点」的路子，比实验室 benchmark 更贴近从业者每天面对的麻烦。
排在最前的故障：编排与执行
结果里最醒目的一点是，被提及次数最多的问题类型是「编排与执行」——也就是多个智能体之间怎么分工、怎么把任务切给对的角色、怎么在步骤之间传递状态、怎么在出问题时收尾。它压过了单智能体的提示词调优、压过了模型选型。换句话说，当一个系统从「一个模型答一句话」变成「好几个角色接力完成一件事」，真正的脆性往往出现在接力棒交接的地方，而不是任何一个角色自身的脑子够不够用。
根子在哪儿：工作流、工具、记忆
再往成因挖，排在最前的三项是工作流问题、工具集成问题和记忆问题。工作流指的是任务流转本身设计得不合理或缺乏兜底；工具集成指的是智能体调外部 API、数据库、文件系统时的契约不一致、报错处理缺失；记忆指的是跨轮次该记住什么、忘掉什么、怎么在多个角色间共享又不串味。有意思的是，这三项恰好对应开发者平时最头疼的三件事：流程怎么定、外部能力怎么接、上下文怎么留。论文没有把锅甩给模型不行，而是把矛头指向了「把多个能力拼起来」这件工程活。
增量认知：优化工作流是当下最划算的修法，但别止步于此
这篇最有价值的地方，不是又给了模型一个分数，而是把多智能体的「工程负债」摆上了台面：当你把问题归因为编排与执行，解法自然也该落在架构层，而不是换更大的模型。论文里最常被社区采用的解法是「优化工作流」，这很合理——它成本最低、见效最快，往往不需要动模型。但对工具集成和记忆这两类成因，光理顺流程不够，还得回到接口契约与记忆边界上去补。对正在上智能体的团队，一个可落地的动作是：先建一套能复现「编排与执行」故障的最小场景，再决定是改流程、封接口还是重做记忆，而不是凭感觉逐个调提示词。
边界：这是「痛点地图」，不是「性能排行榜」
也要说清它能和不能证明什么。这篇研究刻画的是开源社区报告的问题分布，反映的是维护者认为值得提 issue 的困难，不等于每个生产系统的故障占比；它也没有给出「用了某框架就能少踩坑」的因果结论。样本偏向活跃开源项目，企业内部闭源实践未必完全一致。把它当成一张「别人已经替你踩过的坑位图」来用，比当成选型依据更稳妥。至于不同框架之间到底谁更抗造，仍要靠各自的线上数据与对照实验，本批另一篇关于评测的稿件会更直接地碰这个问题。
结语
多智能体的瓶颈，正从「单个角色够不够聪明」转向「一整套角色怎么不散架」。这篇覆盖 944 条真实 issue 的研究没有神话任何模型，而是把矛头指向编排、工具与记忆这三道工程接缝。对从业者来说，它的实用价值就在于：下次系统出问题，先别急着换模型，先问一句——是接力棒交接的地方断了吗。