多智能体系统：为什么它们总在关键时刻掉链子？
当AI团队开始协作：多智能体系统的承诺与现实
想象你组建了一支AI开发团队：一个负责写代码，一个负责审查，一个负责测试，还有一个负责写文档。每个成员都是大语言模型（Large Language Model, LLM）驱动的智能体（agent），它们通过某种协调机制协作完成软件工程项目。这听起来像软件工程的未来——事实上，学术界正在把这个设想变成现实。综述研究显示，基于LLM的多智能体系统已经在软件开发的各个阶段展现出潜力，能够自主解决问题、提升鲁棒性，并为复杂软件项目提供可扩展的管理方案 [7]。
但现实远没有这么美好。当研究者系统梳理了94篇相关论文后发现，代码生成是最常见的应用场景，而”功能适用性”是设计者最关注的质量属性 [8]。换句话说，大家都在追求”能不能干活”，却鲜有人问”干得靠不靠谱”。更令人担忧的是，即使是最先进的多智能体框架，在真实部署中也面临代码质量方面的挑战 [6]。
问题出在哪里？本文将从三个维度剖析：框架选择为何充满陷阱、推理过程为何在关键时刻掉链子、以及资源约束下智能体为何”会干活”却”干不起”。
框架选择：功能全就够了吗？
如果你决定采用多智能体系统，第一个问题必然是：选哪个框架？市面上的开源框架琳琅满目，从低代码平台到高代码库，各有拥趸。但一项针对16个主流开源框架的混合方法研究给出了令人警醒的答案：功能覆盖最全的框架，未必是最适合你任务的框架 [1]。
研究者从开发者视角评估了这些框架，定义了10项基础功能（如核心架构、角色规范、监控、人机反馈等）和6项开发者特征（如安装方式、接口、编排能力等）。结果显示，LangChain的功能覆盖最完整，Dify覆盖了9/10项基础功能，Haystack和Flowise各覆盖7/10 [1]。
然而，当研究者从这些框架中选出8个代表（低代码：Dify、Flowise、AutoGPT、Haystack；高代码：AutoGen、LlamaIndex、OpenAI SDK、Semantic Kernel），让它们执行同一个任务——对README文件做摘要——时，戏剧性的一幕出现了：所有框架的ROUGE分数没有显著差异，但执行时间却差异显著 [1]。
这意味着什么？当一个任务足够简单时，框架的选择几乎不影响输出质量。你花大量时间评估和选型，最终发现”都差不多”。但如果你追求的是高级特性，比如智能体的遥测（telemetry，即对智能体运行状态的监控和数据采集），那么几乎所有框架都让你失望——这类高级特性在当前框架中普遍缺失 [1]。
还有一个反直觉的发现：低代码框架未必更易上手。Dify和Flowise虽然提供拖拽界面，但需要Docker部署；而高代码框架用pip一条命令就能安装 [1]。对于新手来说，低代码框架的安装门槛反而更高。
诚然，这项研究的结论基于README摘要这一单一任务，不能推广到代码生成、调试等其他软件工程任务 [1]。但它揭示了一个核心教训：框架选择应匹配任务需求，而非追求功能数量。
推理的隐忧：局部验证为何失效？
假设你选好了框架，定义了角色，设定了协调规则。你的多智能体系统开始工作了。每个智能体在每一步都进行”局部验证”：检查当前实体是否能在所选工具中表示、参数是否兼容、输出是否与计划一致。一切看起来都在掌控之中。
但一篇理论论文给出了令人不安的结论：这类局部验证在结构上无法检测一类根本性的推理错误 [2]。
研究者用拓扑学（topology，研究空间在连续变形下保持不变性质的数学分支）的语言形式化了这个问题。他们把上下文空间建模为一个覆盖（cover），证据建模为实值1-上链（cochain）。智能体的链式推理相当于在路径上做”积分”——每一步都基于前一步的结论继续推导。如果结论与路径无关（即无论走哪条推理路径都得到相同结果），这个证据链就是”精确”的 [2]。
问题出在哪里？研究者证明了Hodge分解定理：证据冲突可以正交分解为三个部分——梯度部分（可校准）、旋度部分（局部不一致，三重交叠处可见）、以及调和部分（全局性障碍，局部检查不可见）[2]。
用大白话说：你的智能体可能每一步检查都通过，但最终结论却依赖于它走了哪条推理路径。这就像三个人从不同路线绕同一座山走一圈，各自测量高度差，结果互相矛盾，但每段路都量得没错——这是”环路不一致性”的拓扑本质 [2]。
更令人不安的是，研究还发现一个反直觉现象：链式推理可能比不推理更糟。在模拟实验中，单链智能体的平均绝对误差（MAE，即预测值与真实值之差的绝对值的平均值）为1.82，而完全无视上下文的池化模型仅为0.83——推理路径越长，沿路径累积的方差越大 [2]。长程智能体的脆弱性，可能根本不需要归咎于幻觉。
这项研究的局限也很明显：作者明确承认没有使用真实数据，所有结论基于受控模拟 [2]。但它的理论贡献是深远的：它告诉我们，“局部验证”作为安全机制，存在结构性的盲区。
资源约束下的真实表现：效率与成功的平衡
假设你的多智能体系统终于能在测试任务上跑出不错的准确率。但部署到生产环境时，你发现一个尴尬的现实：这个系统太贵了，或者太慢了。
一篇论文用零售替代场景举例：ReAct+GPT-4的准确率有78%，但延迟3.2秒、单次成本$0.12、内存占用1.2GB——三项指标全部超出生产环境的服务等级协议（SLA，即服务提供方与客户约定的服务水平标准）。而一个专用小模型准确率83%，延迟142毫秒、成本$0.002、内存180MB，全部达标 [4]。
这就是AgentSLABench的出发点。它提出了一个资源感知的评测框架，像系统性能分析器（如perf、pprof）一样，把延迟、成本、计算、内存、网络用量与任务正确性并列记录，并引入了一个关键指标：效率调整成功率（Efficiency-Adjusted Success Rate, EASR）[4]。
EASR的计算逻辑是”一票否决”：任何一项超预算，EASR直接归零——哪怕任务做对了。这就像考试超时交卷算零分，逼着智能体在预算内解决问题，而不是无限堆算力 [4]。
实验结果令人震惊：在5个核心任务中（多跳问答、商品替换、代码生成、网页购物、旅行规划），通用推理基线（ReAct、CoT、PlanAndSolve、Reflexion、Random）在4个领域任务上全部0%成功率，只在纯问答任务上达到100%。而任务专用智能体在3个任务上达到100%成功率，在另外2个上达到66.7%-83.3% [4]。
但研究者也承认了局限：N=3种子的样本量导致统计功效不足，置信区间很宽；资源预算是启发式设定的，而非从生产SLA推导 [4]。此外，专用智能体的优势部分来自内置领域逻辑，与通用基线的对比本质上是”手工规则 vs 通用推理”的对比，而非纯模型能力差异。
破局之道：程序化记忆与未来方向
面对框架选择的陷阱、推理一致性的隐忧和资源效率的挑战，出路在哪里？
一项研究提出了一个极简而优雅的方案：程序化记忆（programmatic memory）[3]。其核心思想可以用一句话概括：全记下来，用代码翻。
传统记忆系统像人记笔记——先判断什么重要再记，但判断错了就丢了。PRO-LONG则像录像机——什么都录，需要时用”搜索”而不是”回忆”来找。具体做法是：把智能体每一步的观察、动作、结果原封不动追加进一个结构化日志，读取时用代码（grep、Python等）去搜索这个日志，不做任何压缩或摘要 [3]。
这个设计的洞察在于：现有记忆系统在写入时就要决定存什么，而”当时看似无关的信息”事后可能关键。无损日志把相关性判断推迟到读取时，且编码智能体（coding agent）天然擅长代码搜索，使10万行以上的日志仍可检索 [3]。
实验结果令人印象深刻：在ARC-AGI-3基准的25个公开游戏上，相比无日志基线，PRO-LONG在三个前沿模型上提升了15.7-21.0个百分点。更关键的是效率：达到接近最强专用框架的成绩，token花费只有对方的1/4到1/6 [3]。
一个反直觉的消融实验揭示了”写笔记没用”：把工作区每次调用都清空，PRO-LONG几乎不受影响（41.2→40.7），而靠写笔记的基线掉了4个点——说明”自己总结”不如”全量保存+程序化检索” [3]。
当然，这项研究也有边界：结论仅在ARC-AGI-3上成立，未测其他长程基准；只验证了”编码智能体+文本网格”这一种感知形态，未测视觉输入 [3]。
如果你只记住一件事
多智能体系统的问题不在于”不够聪明”，而在于”不可预测”。框架选择上，功能全不如匹配任务；推理过程中，局部验证有结构性盲区；资源约束下，高准确率可能毫无用处。但PRO-LONG给了我们一个启示：有时候，最简单的方案——全量记录加程序化搜索——反而能同时解决多个问题。在多智能体系统的设计中，少即是多，简单即是鲁棒。
参考文献
- Developing LLM-based Multi-Agent Systems in Software Engineering: A Mixed-Method Experience Report（arXiv (Cornell University)、2026、全文精读）
- Local verification cannot detect non-transportability: a cohomological theory of context preservation in agentic reasoning（arXiv、2026、全文精读）
- PRO-LONG: Programmatic Memory Enables Long-Horizon Reasoning（arXiv、2026、全文精读）
- AgentSLABench: Evaluating and Benchmarking Agentic Systems Under Resource Constraints（arXiv、2026、全文精读）
- MacroAllocAgent: From macro narratives to strategic asset allocation via a multi-agent LLM system（SSRN、2026、仅摘要）
- Human-In-the-Loop Software Development Agents（arXiv (Cornell University)、2024、仅摘要）
- LLM-Based Multi-Agent Systems for Software Engineering: Literature Review, Vision, and the Road Ahead（ACM Transactions on Software Engineering and Methodology、2025、仅摘要）
- Designing LLM-based Multi-Agent Systems for Software Engineering Tasks: Quality Attributes, Design Patterns and Rationale（ArXiv.org、2025、仅摘要）