1. 从单轮到多 Agent：为什么这个话题值得认真聊

Agent 这个词在过去一年多里被反复提及，但真正落到工程实现层面，很多人的认知还停留在“调一次大模型 API，返回一段文本”的阶段。如果你也是这么理解的，那说明你看到的还只是最表层的单轮调用。单轮调用确实是最简单的 Agent 雏形——用户输入一句话，模型返回一段结果，流程结束。但真正的 Agent 系统，尤其是多 Agent 协作系统，复杂度比这高出好几个数量级。

我接触 Agent 开发这段时间，踩过的坑基本都集中在“以为它很简单”这件事上。单轮调用看起来够用，一旦业务稍微复杂一点，比如需要多步骤推理、需要调用外部工具、需要在多个角色之间传递上下文，单轮调用的天花板就立刻暴露出来了。这时候你不得不面对一个核心问题：怎么从单轮调用演进到多 Agent 协作？中间的架构决策点在哪里？每一步的取舍逻辑是什么？

这篇内容就是围绕这条演进路线展开的。我会从最基础的单轮调用讲起，逐步拆解到多 Agent 协作的完整架构，把每个阶段的核心原理、实现方式、适用场景和踩坑经验都摊开来讲。不管你是刚接触 Agent 开发的新手，还是已经在做 Agent 项目但卡在协作环节的开发者，都能从中找到可以直接参考的东西。

需要提前说明的是，这篇偏理论架构层面，但不会只讲空泛的概念。每个架构决策我都会解释“为什么这么选”，每个关键环节都会给出可落地的实现思路。理论篇的价值不在于给你一段能跑的代码，而在于让你在做技术选型的时候，脑子里有一张清晰的地图。

2. 单轮调用：Agent 的最小可用单元

2.1 单轮调用的本质与边界

单轮调用说白了就是一次请求-响应循环。用户给一个输入，模型基于这个输入生成一个输出，整个交互到此结束。从工程角度看，它的结构极其简单：一个 prompt 模板，一次 API 调用，一个结果解析。没有状态管理，没有循环控制，没有工具调用，也没有记忆机制。

这种模式能解决什么问题？最典型的就是分类、摘要、翻译、简单问答这类“输入到输出”的映射任务。比如你做一个情感分析工具，用户输入一段评论，模型输出正面或负面，这就是单轮调用的典型场景。它的优势非常明显：实现成本极低，延迟可控，调试简单，不需要考虑上下文窗口管理。

但边界也很清晰。一旦任务需要多步推理，单轮调用就力不从心了。举个例子，用户问“帮我查一下明天北京的天气，然后根据天气推荐穿什么衣服”。这个问题需要两步：先查天气，再根据天气结果做推荐。单轮调用没法在中间插入工具调用，也没法把第一步的结果作为第二步的输入。你可能会想，那我让模型一次性把两步都做了不就行了？理论上可以，但实际效果很差，因为模型没有真实的天气数据，只能靠编。

注意：单轮调用最大的陷阱是“看起来什么都能做”。很多新手会把复杂任务硬塞进一个 prompt 里，结果就是模型输出不稳定、幻觉严重、无法调试。判断标准很简单：如果任务需要外部信息或者多步决策，就不该用单轮调用。

2.2 单轮调用的工程实现要点

虽然单轮调用结构简单，但工程上仍有几个关键点需要处理好。首先是 prompt 模板的设计。很多人觉得 prompt 就是随便写几句话，实际上模板的结构直接影响输出质量。我习惯把 prompt 分成四个部分：角色定义、任务描述、输入占位符、输出格式约束。角色定义让模型知道自己是干什么的，任务描述说清楚要做什么，输入占位符负责动态替换，输出格式约束保证结果可解析。

其次是输出解析。单轮调用的输出通常是自然语言，但下游系统往往需要结构化数据。这时候有两种做法：一种是在 prompt 里要求模型输出 JSON，然后直接解析；另一种是让模型自由输出，再用规则或另一个模型做后处理。前者效率高但容易因为模型不听话而解析失败，后者更稳定但多了一次调用成本。我的经验是，如果对延迟敏感就用 JSON 模式，如果对稳定性要求极高就用后处理。

还有一个容易被忽略的点是错误处理。单轮调用看起来简单，但 API 超时、返回格式异常、内容被截断这些问题都会出现。基本的重试机制、超时控制、降级策略都得有。我见过太多项目因为没做这些基础防护，上线后一遇到网络波动就全线崩溃。

2.3 从单轮走向多轮的触发条件

什么时候该从单轮调用升级到多轮？我的判断标准有三个。第一，任务需要外部信息。只要模型需要查数据库、调 API、读文件，单轮就不够了。第二，任务需要多步决策。比如先分析问题、再制定计划、最后执行，这种流程必须拆成多轮。第三，任务需要状态保持。如果后续交互依赖前面的结果，单轮调用没法传递上下文。

这三个条件满足任意一个，就该考虑多轮架构了。多轮调用的核心变化是引入了循环和状态。每一轮的输出会作为下一轮的输入，模型可以在中间调用工具、更新状态、决定下一步做什么。这就从“一次映射”变成了“一个流程”。

3. 多轮调用与工具使用：Agent 的能力扩展

3.1 多轮调用的循环控制逻辑

多轮调用的核心是一个循环：模型生成输出，系统判断是否需要继续，如果需要就把输出和新的观察结果一起送回模型，直到满足终止条件。这个循环的控制逻辑是整个 Agent 系统的心脏。

终止条件的设计很关键。常见的有几种：模型主动输出结束标记、达到最大轮数、满足某个业务条件。我一般会同时设置多个终止条件，比如最大轮数设为 10，同时检测模型是否输出了“任务完成”之类的标记。这样既能防止无限循环，又能在任务完成时及时退出。

循环中的状态管理是另一个难点。每一轮产生的中间结果都需要保存下来，因为后续轮次可能需要引用。最简单的做法是用一个列表按顺序存储所有轮次的输入输出，每次调用时把整个历史都塞进 prompt。但这样会导致 token 消耗快速增长，几轮之后就可能超出上下文窗口。更优雅的做法是做状态压缩，只保留关键信息，或者用外部存储保存历史，prompt 里只放摘要。

3.2 工具调用的实现机制

工具调用是多轮 Agent 能力扩展的核心。没有工具，Agent 只能靠模型内部知识回答问题；有了工具，Agent 就能查实时数据、操作外部系统、执行具体动作。

工具调用的实现通常分三步。第一步是工具注册，把每个工具的名称、描述、参数格式告诉模型。第二步是模型决策，模型根据当前任务判断是否需要调用工具，如果需要就输出工具名称和参数。第三步是执行与回传，系统执行工具调用，把结果返回给模型，模型基于结果继续推理。

这里有个关键细节：工具描述的质量直接决定调用准确率。我见过很多项目工具功能没问题，但模型总是调错或者不调，原因就是描述写得太模糊。好的工具描述应该包含三要素：这个工具做什么、什么时候该用、参数怎么填。比如“查询天气”这个工具，描述应该写成“根据城市名称查询指定日期的天气情况，当用户询问天气相关问题时使用，参数为城市名和日期”。

提示：工具数量不要一次性给太多。我实测下来，单次给模型超过 10 个工具，调用准确率会明显下降。如果工具很多，可以分组或者做一层路由，先让模型选工具类别，再在类别内选具体工具。

3.3 工具调用的常见故障与排查

工具调用最容易出的问题是参数错误。模型可能把日期格式写错、把城市名拼错、把数值类型搞混。排查这类问题的第一步是看模型输出的原始参数，确认是模型理解错了还是工具定义有歧义。如果是模型理解问题，可以在 prompt 里加几个示例；如果是工具定义问题，就改描述。

第二个常见问题是工具调用死循环。模型反复调用同一个工具，每次都得到相似结果，但就是不结束。这种情况通常是终止条件没设计好，或者工具返回的结果让模型误以为任务没完成。解决办法是在循环控制里加检测，如果连续两轮调用同一个工具且参数相同，就强制终止或者换一种策略。

第三个问题是工具执行超时。外部 API 响应慢或者挂了，整个 Agent 流程就卡住了。这时候需要给每个工具调用设置超时时间，超时后返回一个错误信息给模型，让模型决定是重试还是换方案。千万别让工具调用无限等待，否则整个系统都会被拖垮。

4. 多 Agent 协作：从单体到团队的架构演进

4.1 为什么需要多 Agent 协作

单 Agent 加工具调用已经能解决很多问题了，但遇到复杂任务还是会吃力。原因在于单个 Agent 的上下文窗口有限，能承载的角色和知识也有限。当一个任务需要同时具备多种专业能力、需要并行处理多个子任务、或者需要不同视角的交叉验证时，单 Agent 就撑不住了。

多 Agent 协作的核心思路是分工。把一个大任务拆成若干子任务，每个子任务交给一个专门的 Agent 处理，最后把结果汇总。这就像一个小团队，有人负责调研、有人负责分析、有人负责写作、有人负责审核。每个 Agent 有自己的角色定义、工具集和知识范围，通过消息传递来协同工作。

这种架构的优势很明显。首先是能力扩展，每个 Agent 可以专注于自己擅长的领域，整体能力上限远高于单 Agent。其次是并行效率，多个子任务可以同时执行，总耗时取决于最慢的那个而不是所有任务之和。最后是可靠性，一个 Agent 出错不会导致整个系统崩溃，其他 Agent 可以继续工作或者接管。

4.2 多 Agent 协作的典型拓扑结构

多 Agent 系统的拓扑结构决定了 Agent 之间怎么通信、怎么协调。常见的结构有几种，每种适合不同场景。

第一种是中心化结构，也叫 Orchestrator 模式。一个主 Agent 负责接收任务、拆解任务、分配给子 Agent、收集结果、汇总输出。子 Agent 之间不直接通信，所有协调都通过主 Agent 完成。这种结构的好处是控制逻辑清晰，容易调试，适合任务拆解逻辑明确的场景。缺点是主 Agent 容易成为瓶颈，而且主 Agent 的决策质量直接决定整个系统的表现。

第二种是去中心化结构，Agent 之间可以直接通信，没有统一的管理者。每个 Agent 根据自己的状态和收到的消息决定下一步行动。这种结构更灵活，适合动态性强的场景，但调试难度大，容易出现消息风暴或者死锁。

第三种是层级结构，介于前两者之间。顶层 Agent 负责战略决策，中层 Agent 负责战术拆解，底层 Agent 负责具体执行。这种结构适合任务复杂度高、需要多层决策的场景，但实现成本也最高。

我个人的经验是，大部分项目从中心化结构起步就够了。等业务复杂到中心化结构扛不住的时候，再考虑往层级化演进。去中心化结构除非有明确的动态性需求，否则不建议一上来就用。

4.3 Agent 之间的通信与状态同步

多 Agent 协作的另一个核心问题是通信。Agent 之间怎么传递消息、消息格式怎么定义、状态怎么同步，这些细节直接决定系统能不能跑通。

消息格式我一般用结构化的 JSON，包含发送者、接收者、消息类型、内容、时间戳这几个字段。消息类型区分任务分配、结果返回、状态更新、错误报告等。内容部分根据消息类型不同而不同，任务分配时放任务描述和参数，结果返回时放执行结果。

状态同步是个更棘手的问题。多个 Agent 可能同时读写共享状态，如果不做同步就会出现数据不一致。最简单的做法是让所有状态变更都经过一个中心化的状态管理器，Agent 只能通过它来读写状态。这样虽然牺牲了一点性能，但保证了数据一致性。如果对性能要求高，可以用乐观锁或者版本号机制，但实现复杂度会上升不少。

注意：多 Agent 系统里最容易出问题的地方就是状态同步。我踩过的坑包括 Agent A 改了状态但 Agent B 不知道、两个 Agent 同时写同一个字段导致覆盖、状态更新顺序错乱导致逻辑错误。建议在开发阶段就把状态变更日志打全，出问题的时候能快速定位。

5. 多 Agent 协作的进阶话题与实战经验

5.1 Agent 记忆机制的设计取舍

Agent 记忆是让多 Agent 系统真正“聪明”起来的关键。没有记忆，每个 Agent 都是无状态的，每次交互都从零开始；有了记忆，Agent 能记住之前的交互、积累经验、避免重复犯错。

记忆通常分三层。第一层是短期记忆，就是当前任务的上下文，存在内存里，任务结束就清掉。第二层是长期记忆，跨任务保存的信息，比如用户偏好、历史决策、常见问题，一般存在数据库或向量库里。第三层是共享记忆，多个 Agent 都能访问的公共信息，比如任务全局状态、其他 Agent 的输出摘要。

设计记忆机制时最大的取舍是“记多少”和“记多久”。记太多会导致检索效率下降、token 消耗增加；记太少又会让 Agent 显得“健忘”。我的做法是分层设置过期策略：短期记忆任务结束即清，长期记忆按重要性设置不同的保留时长，共享记忆只保留当前任务相关的部分。

向量数据库是长期记忆的常用存储方案。把历史信息转成向量存进去，需要的时候用相似度检索。这里有个细节：检索回来的记忆不要全部塞进 prompt，要先做相关性排序，只取 top-k 条。我一般取 3 到 5 条，太多会稀释关键信息。

5.2 并发场景下的 Agent 稳定性保障

多 Agent 系统天然涉及并发，多个 Agent 同时执行、同时读写状态、同时调用工具。并发带来的问题包括资源竞争、死锁、消息乱序、状态不一致。这些问题在单 Agent 场景下不存在，但在多 Agent 场景下必须认真对待。

资源竞争最常见的表现是多个 Agent 同时调用同一个外部 API，触发限流。解决办法是做一层请求队列，所有工具调用都经过队列排队，控制并发数。队列的实现可以用简单的信号量，也可以用成熟的消息队列中间件。

死锁通常发生在 Agent 之间互相等待对方的消息。比如 Agent A 等 Agent B 的结果，Agent B 等 Agent A 的结果，两边都不动。预防死锁的办法是设置超时，等待超过一定时间就放弃并走降级逻辑。另外，尽量避免设计循环依赖的 Agent 关系。

消息乱序是另一个坑。Agent A 发了消息 1 和消息 2，Agent B 先收到消息 2 再收到消息 1，处理顺序就错了。解决办法是给消息加序号，接收方按序号排序后再处理。如果对顺序要求极高，可以用同步调用代替异步消息。

5.3 多 Agent 系统的评测与调优

多 Agent 系统上线前必须做评测，否则你根本不知道它到底能不能用。评测的核心是构建一套覆盖典型场景的测试集，每个测试用例包含输入、期望输出、评分标准。

评分标准的设计是个技术活。简单的任务可以用精确匹配，复杂任务就得用模型评分或者人工评分。我一般会结合多种方式：先用规则做初筛，再用模型做细评，最后人工抽检。这样既保证了效率，又保证了准确性。

调优的方向主要有几个。一是 prompt 优化，调整角色定义、任务描述、输出格式约束，提升单个 Agent 的表现。二是拓扑优化，调整 Agent 之间的协作结构，减少不必要的通信。三是参数优化，调整最大轮数、超时时间、并发数这些运行时参数。四是记忆优化，调整记忆的存储和检索策略。

提示：评测集要持续更新。我见过很多项目评测集建好之后就不动了，结果上线后遇到新场景就翻车。建议每次发现 bad case 就把它加进评测集，这样评测集越来越贴近真实场景，调优也更有针对性。

5.4 从理论到落地：我的实操建议

理论讲完了，最后分享几条实操建议。第一条，不要一上来就搞多 Agent。先用单 Agent 加工具调用把业务跑通，确认单 Agent 确实扛不住了再考虑多 Agent。很多项目其实单 Agent 就够了，硬上多 Agent 反而增加了复杂度和维护成本。

第二条，Agent 的数量不是越多越好。我见过一个项目拆了十几个 Agent，结果协调成本比任务本身还高。一般来说，3 到 5 个 Agent 能覆盖大部分场景。如果超过这个数量，先想想是不是可以合并。

第三条，日志和监控必须做全。多 Agent 系统的调试难度远高于单 Agent，没有详细的日志根本没法定位问题。每个 Agent 的输入输出、每次工具调用、每次状态变更都要记下来。监控要覆盖响应时间、成功率、token 消耗这些关键指标。

第四条，做好降级方案。多 Agent 系统出问题的概率比单 Agent 高，必须有降级路径。比如某个 Agent 挂了，能不能用备用 Agent 顶上；工具调用失败了，能不能用缓存结果或者默认值。降级方案要在设计阶段就考虑，不要等上线了再补。

第五条，控制 token 成本。多 Agent 系统的 token 消耗是单 Agent 的好几倍，如果不加控制，成本会失控。控制手段包括压缩 prompt、限制历史长度、缓存重复调用、选择更便宜的模型处理简单任务。我一般会设置一个 token 预算，超过预算就触发告警或者降级。

这套架构我从单轮调用一路踩坑踩到多 Agent 协作，中间经历过的失败案例比成功案例多得多。每次出问题回头看，基本都是某个环节的理论没想清楚就急着写代码。所以这篇理论篇的价值不在于给你现成的方案，而在于让你在动手之前把每个决策点的逻辑都想明白。想明白了再动手，能省下大量返工的时间。