笔者本人的工作中，会经常遇到一些agent部署类的咨询。

最近一个月，遇到最多的一个问题就是，我们花了几个月时间搭出来了一个 Multi-Agent 系统，结果上线就被一个提示词吊打了，问题到底出在哪里？

其实这里面很多问题，不出在你的架构、也不出在模型，而是在一开始的选型上，就把问题复杂化了。

有时候，在考虑 Multi-Agent 之前，不妨先问问自己，单agent能满足需求吗？如果不能，那构建 Multi-Agent 时，数据检索能力，又是否合格了？

01单智能体真的走到头了吗？

很多团队在架构讨论时，会把 Multi-Agent 当成提升能力的默认选项。但 Anthropic 的工程师们见过太多相反的案例：花数月构建的复杂架构，最终被一个改进过的提示词击败。

首先，Multi-Agent 的真实代价比大多数人想象的要高。token 消耗通常是单智能体的 3 到 10 倍，而且每个智能体都是潜在的故障点，智能体间传递上下文的过程中信息会持续损耗，协调开销有时甚至比实际工作还多。很多团队按问题类型来分解工作，规划、执行、测试各司其职，看起来分工明确，实际上每次交接都在丢失上下文，最终效率反而下降。

因此，在投入 Multi-Agent 之前，有三个问题，需要先重点跟踪。

第一个是上下文极限。上下文压缩技术在快速发展，单智能体保持长期有效记忆的能力在持续提升，今天需要 Multi-Agent 解决的上下文问题，明天可能单智能体就能处理。

第二个是工具如何选。当智能体拥有 15 到 20 个以上的工具时，模型确实容易出错。但在拆分智能体之前，先试试工具搜索工具，它让 Claude 按需动态发现工具，而不是一开始就加载所有定义，可以将 token 使用率降低多达 85%。

第三个是真正独立的并行子任务到底有多少。当任务自然分解为相互独立的部分时，并行子智能体才能带来真正价值。如果子任务之间需要频繁交互、共享状态，拆分只会制造麻烦。

随着模型能力持续提升，这些阈值也会不断变化，有时候，今天需要 Multi-Agent 解决的问题，明天可能单智能体就能搞定。

02 这些场景更需要 Multi-Agent

场景 1：上下文污染

客服系统是一个典型案例。用户咨询订单问题时，智能体需要查询完整的订单历史，可能有 2000 个 token 以上。把这些信息全部塞进主智能体的上下文，当用户随后咨询技术问题时，这些无关的订单数据会严重干扰推理质量。

合理的做法是让一个专门的子智能体处理完整订单历史，只向主智能体返回 50 到 100 个 token 的结构化摘要。主智能体的上下文始终保持干净，推理质量不受无关信息影响。

判断这个场景的依据相对清晰：子任务会产生大量上下文，其中大部分与主任务无关，而且可以明确提炼出关键摘要。三个条件同时成立，才值得拆分。

场景 2：并行化搜索

Claude 的研究功能采用了这个模式。主智能体将一个复杂问题分解为多个独立的研究方向，同时派出多个子智能体并行调查，最后综合所有发现。

这种方式的价值在于彻底性，总耗时通常更长，但能覆盖比单个智能体更大的信息空间，适合那些宁可慢一点也要找全的场景。前提条件是各研究方向相互独立，中间不需要频繁沟通。

这种模式对底层数据检索提出了明确的高并发要求：多个子智能体同时发起搜索，需要数据层稳定承载并发检索，而不是随着并发量上升就显著退化。这个工程问题在第五节展开讨论。

场景 3：专业化分工

考虑一个需要对接 CRM、营销自动化和消息平台的集成系统，每个平台有 10 到 15 个 API 端点。如果让单个智能体管理 40 个以上的工具，工具选错的概率会显著上升。

合理的做法是分别创建 CRM 智能体、营销智能体和消息智能体，每个配备 8 到 10 个专属工具和定制化的系统提示词，再加一个协调智能体负责把请求路由到合适的专业智能体。

这个场景的触发条件是工具总数超过 20 个且频繁选错，工具跨越多个无关领域，以及不同任务需要截然不同的行为模式，比如客服场景需要同理心，代码审查场景需要严谨性。

专业化分工意味着每个智能体需要快速检索自己领域的信息，同时避免被其他领域数据干扰召回精度。这对数据层的隔离能力提出了具体要求，同样在第五节讨论。

03 分工的原则：以上下文为中心

把代码写作、测试编写和代码审查分配给三个不同的智能体，这种看起来分工很清晰。问题在于，测试智能体不了解某些实现决策的背景，审查智能体缺乏探索和迭代的完整历史，每次交接都在丢失上下文。表面上的分工明确，实质上是在制造信息损耗。

更合理的做法是让处理某个功能的智能体同时负责该功能的测试，因为它已经有完整的上下文。拆分工作的前提是上下文能够真正隔离，而不是工作的类型可以被划分。

那么，什么样的边界可以拆得了？独立的研究路径，比如亚洲市场调研和欧洲市场调研；分离的组件且有清晰接口，比如前端和后端；黑盒验证，也就是只需运行测试并报告结果，不需要理解实现细节。

反过来，同一作品的连续阶段（规划、实施、测试）、紧耦合的组件，以及需要共享状态的工作，都不适合用拆分智能体来解决。

04 最通用的 Multi-Agent 模式：验证子智能体

主智能体完成一项工作后，我们往往需要额外生成一个专门的验证子智能体，配备清晰的成功标准和验证工具。验证者不需要理解工作是如何完成的，只需要判断结果是否符合标准。

这个模式有效的原因很简单：验证天然只需要最少的上下文传递。验证智能体可以像黑盒一样工作，无需完整的构建历史，完全符合上下文可以真正隔离的拆分原则。质量保证、合规检查、输出验证、事实核查，都是它能发挥作用的地方。

但这里也有个坑，验证智能体有时候会运行一两个测试就宣布全盘通过。解决方法是把全盘验证直接写进提示词就好，明确要求运行完整的测试套件，只有所有测试通过才能标记为成功。

05 向量数据库：Multi-Agent 系统的数据层

前几节讨论的三个场景，最终都指向同一个工程问题：智能体从哪里检索信息，以及检索得有多快、多准、多稳定。

单智能体场景下这个问题通常不显眼。但当多个子智能体并行运行、每个专业智能体需要访问自己的数据域、验证智能体需要实时核查事实时，数据检索层的性能和架构直接决定了整个系统能否跑通。

Milvus 是目前生产环境中应用最广的开源向量数据库，针对 Multi-Agent 系统的几个典型需求，有一些具体能力值得关注。

并发承载

多个子智能体同时发起检索请求时，系统需要稳定支撑高并发读负载。Milvus 的存算分离架构允许独立扩展查询节点，专门应对读密集型流量，不需要同步扩展存储层。在生产环境的基准测试中，十亿级向量规模下的查询延迟可以维持在 50ms 以内，为并行智能体系统提供了可预期的性能下限。

数据隔离

专业化分工场景下，各智能体需要访问独立的数据域，同时避免被其他领域数据干扰召回精度。Milvus 支持从数据库、集合到分区键的多级隔离策略，单集群可以处理数十万个逻辑租户单元，每个专业智能体可以拥有独立的数据分区。

混合检索

验证智能体需要同时具备语义层面的相关性判断和精确的关键词匹配。Milvus 2.5 起原生支持在同一集合中存储密集向量和稀疏向量，可以在单次查询中同时执行语义搜索和全文检索，通过重排序合并结果，不需要维护两套独立的检索系统。其 BM25 引擎的基准测试性能比 Elasticsearch 快约 4 倍，对于需要高频核查的验证智能体，这个差距在整体延迟上会有明显体感。

存储成本

Multi-Agent 系统的 token 成本已经显著高于单智能体，向量存储的成本结构同样需要弹性。Multi-Agent 系统的一个典型特征是数据访问频率差异极大，并行搜索任务产生的向量是热数据，历史记录归档后几乎不再访问。Milvus 的分层存储机制根据访问频率自动将数据分配到内存、SSD 或对象存储，根据 2.6 版本的测试数据，相比全量 SSD 存储，整体存储成本可以降低 40 到 50%，同时不影响热数据的检索性能。

06 小结

采用 Multi-Agent 架构之前，需要确认几件事。

单智能体已经遇到了具体的上下文污染，或者有真正独立的并行任务，或者工具管理已经混乱到影响准确率。在这之前，先把提示词优化到极限，先测试上下文压缩技术，先试试工具搜索工具。

当确实需要 Multi-Agent 时，各种子agent，我们需要按上下文需求来分解，而不是按问题的阶段或类型。此外，子智能体需要能够在不依赖完整上下文的情况下独立验证自己的输出。

在数据层，同样的原则适用。不要在没有真实并发压力之前搭建过度设计的检索架构，Milvus 支持从单机部署到分布式集群的平滑扩展，可以先从轻量级方案开始，等系统真正遇到瓶颈再做横向扩展。

总而言之，从最简单的方法开始，只有证据支持时再增加复杂性。架构是这样，工具选型也是这样。

作者介绍

Zilliz黄金写手：尹珉

阅读推荐
实测｜春节我用三种姿势在手机上用Claude Code，上班路上也能当牛马了
教程：Nano Banana2+ Milvus+ qwen3.5，打造电商生图爆款流水线
一个春节烧掉3个$200 Claude Max plan，我终于明白了怎么用AI写infra代码
AI互撕后code review表现会更好？Claude、Gemini、Codex、Qwen、MiniMax 最新模型测评
开源：我们复刻了OpenClaw的mem系统，为所有Agent打造透明、可控的记忆
拆解：OpenClaw就是agent记忆的最佳范式！其逻辑与RAG有何区别？