从单轮到多Agent协作：大模型Agent架构演进与工程实践指南

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

Agent这个词在过去一年里被反复咀嚼，从最初的新鲜概念到如今几乎每个技术团队都在尝试落地。但真正动手做过Agent项目的人都有一个共同感受：单轮调用的Agent做Demo很容易，做到生产可用很难；多Agent协作听起来很美，真正跑起来到处都是坑。我自己从最早写一个简单的工具调用循环，到后来搭建包含规划、执行、反思多个角色的协作系统，中间踩过的坑足够写一本小册子。

这篇文章想做的事情很纯粹：把Agent从最简单的单轮调用到复杂的多Agent协作这条演进路径讲清楚。不是泛泛而谈概念，而是把每一种实现方式背后的设计动机、适用边界、核心机制和实操要点都拆开来看。如果你正在做Agent相关的项目，或者正在纠结要不要上多Agent架构，这篇文章应该能帮你少走一些弯路。

先明确一下讨论范围。这里说的Agent，指的是能够自主感知环境、做出决策并调用工具执行动作的大模型驱动系统。它和普通的ChatBot最大的区别在于：ChatBot是问答式的，你问它答；Agent是目标驱动的，你给它一个目标，它自己决定怎么一步步完成。这个区别听起来简单，但实现复杂度差了好几个量级。

从单轮调用到多Agent协作，本质上是在解决三个递进的问题：单次能不能做对、多次能不能做稳、多个协作能不能做大。下面我按这个脉络，把每种实现方式的理论基础和工程实践都过一遍。

2. 单轮调用：Agent的最小可行形态

2.1 单轮调用的本质是什么

单轮调用是所有Agent系统的起点，也是最容易被低估的形态。很多人觉得单轮调用太简单了，不就是让模型输出一个工具调用请求然后执行吗？但如果你仔细想，单轮调用其实已经包含了Agent的核心要素：感知（读取输入）、决策（选择工具和参数）、执行（调用工具）、反馈（返回结果）。只是这个循环只跑了一次就结束了。

单轮调用的典型结构是这样的：用户输入一个问题，模型判断是否需要调用工具，如果需要就输出工具名称和参数，系统执行工具后把结果返回给模型，模型基于结果生成最终回答。整个过程只有一次工具调用，没有循环，没有反思，没有规划。

这种形态适合什么场景？信息查询类任务是最典型的。比如用户问“今天北京的天气怎么样”，Agent调用天气API拿到数据，然后组织语言回答。再比如“帮我查一下这个订单的物流状态”，Agent调用订单查询接口，返回结果。这类任务的特点是：目标明确、路径唯一、不需要多步推理。

2.2 单轮调用的技术实现要点

从工程角度看，单轮调用的实现涉及几个关键决策点。第一个是工具描述的设计。模型怎么知道有哪些工具可用、每个工具干什么、参数怎么填？全靠你给的tool description。我见过太多项目在这里翻车：工具描述写得含糊不清，模型要么选错工具，要么参数填得乱七八糟。

一个好的工具描述应该包含：工具的功能说明（一句话说清楚干什么）、参数说明（每个参数的类型、含义、是否必填）、使用示例（什么情况下用这个工具）。举个例子，同样是查询天气的工具，差的描述是“查询天气”，好的描述是“根据城市名称查询指定城市的实时天气信息，参数city为城市中文名称，如‘北京’、‘上海’”。

第二个是输出格式的约束。单轮调用要求模型输出结构化的工具调用请求，通常是JSON格式。这里有个实操经验：不要指望模型每次都能输出完美的JSON，一定要做格式校验和容错处理。我一般会在prompt里明确给出JSON schema，同时在代码层面做解析失败的重试机制。

第三个是错误处理。工具调用可能失败——网络超时、参数错误、权限不足。单轮调用因为没有循环，错误处理相对简单：要么直接返回错误信息给用户，要么让模型基于错误信息生成一个解释。但这里有个细节：错误信息不要直接抛给用户，而是要让模型理解错误后生成友好的回复。

2.3 单轮调用的边界在哪里

单轮调用能解决的问题有限，一旦任务需要多步操作，它就力不从心了。比如“帮我订一张明天从北京到上海的机票，要下午出发的，靠窗座位”，这个任务需要：查询航班、筛选时间、选择座位、确认订单，每一步都依赖上一步的结果。单轮调用做不到这种链式操作。

这时候就需要引入循环，让Agent能够多次调用工具，根据每次的结果决定下一步做什么。这就是下一节要讲的ReAct模式。

3. 循环调用：ReAct模式与它的变体

3.1 ReAct的核心思想

ReAct（Reasoning + Acting）是Agent发展史上一个里程碑式的模式。它的核心思想很朴素：让模型在每一步都先推理再行动，行动的结果作为下一步推理的输入，循环往复直到任务完成。

具体来说，ReAct的每一轮包含三个阶段：Thought（思考当前应该做什么）、Action（选择并调用工具）、Observation（观察工具返回的结果）。这三个阶段循环执行，直到模型认为任务完成，输出Final Answer。

为什么ReAct有效？因为它把复杂的多步任务拆解成了多个简单的单步决策。每一步模型只需要关注当前状态和下一步动作，不需要一次性规划出完整路径。这大大降低了单次推理的难度，也让Agent能够根据中间结果动态调整策略。

3.2 ReAct的工程实现细节

实现ReAct循环，有几个关键点需要处理好。首先是循环终止条件。不能让它无限循环下去，必须设置最大迭代次数。我一般会设10到15轮，超过就强制终止并返回当前结果。同时要检测模型是否输出了Final Answer，如果输出了就正常结束。

其次是上下文管理。ReAct的每一轮都会往上下文里追加Thought、Action、Observation，轮数多了上下文会爆炸。这里需要做上下文压缩：可以只保留最近N轮的完整记录，更早的轮次只保留摘要；也可以把中间步骤存到外部存储，需要时再检索。

第三是工具调用的幂等性。ReAct循环中，同一个工具可能被调用多次。如果工具是有副作用的（比如发邮件、下单），必须保证幂等，否则会出大问题。我的做法是给每个工具调用生成一个唯一ID，在工具层面做去重。

3.3 ReAct的常见变体

ReAct之后出现了很多变体，核心都是在“推理”和“行动”这两个环节上做文章。Plan-and-Execute是先让模型制定完整计划，然后按计划逐步执行。这种方式适合步骤明确、依赖关系清晰的任务，但缺点是计划一旦制定就不好调整，遇到意外情况容易卡住。

Reflexion是在ReAct基础上增加了反思环节：任务完成后，让模型回顾整个过程，总结经验教训，存入记忆。下次遇到类似任务时可以参考之前的经验。这种方式适合需要持续优化的场景，但实现复杂度较高。

Tree of Thoughts是把推理过程组织成树结构，每个节点是一个思考步骤，可以回溯和分支。这种方式适合需要探索多种可能性的任务，但计算成本很高，一般只用在关键决策点上。

从实操角度看，ReAct仍然是大多数场景下的默认选择。它的实现简单、调试方便、适用面广。其他变体可以在特定场景下作为补充，但不建议一上来就用复杂模式。

4. 多Agent协作：从单兵作战到团队配合

4.1 为什么需要多Agent

单Agent再强，也有能力边界。当任务复杂到需要多种专业知识、多个视角、或者需要并行处理时，单Agent就显得力不从心了。这时候就需要多Agent协作。

多Agent协作的核心价值在于分工与专业化。就像一个公司，不可能一个人干所有事，需要产品、开发、测试、运营各司其职。多Agent系统里，每个Agent可以专注于自己擅长的领域，通过协作完成复杂任务。

但多Agent不是银弹。引入多Agent会带来新的问题：通信成本、协调复杂度、一致性保证。我见过不少项目，本来单Agent跑得好好的，非要拆成多Agent，结果性能下降、bug增多、维护困难。所以我的建议是：能用单Agent解决的，不要上多Agent。只有当单Agent确实遇到瓶颈时，才考虑拆分。

4.2 多Agent的典型架构模式

多Agent协作有几种常见的架构模式，每种适合不同的场景。

第一种是主从模式（Orchestrator-Worker）。一个主Agent负责理解任务、拆解子任务、分配给工作Agent，工作Agent执行完把结果返回给主Agent，主Agent汇总后输出。这种模式结构清晰，适合任务可以明确拆解的场景。比如一个报告生成系统，主Agent负责规划报告结构，工作Agent分别负责数据收集、分析、撰写。

第二种是对等模式（Peer-to-Peer）。多个Agent地位平等，通过消息传递协作。每个Agent可以主动发起对话、请求帮助、提供信息。这种模式灵活度高，但协调复杂度也高，容易出现死锁或无限对话。一般需要引入一个协调机制，比如轮次控制或话题聚焦。

第三种是层级模式（Hierarchical）。多层Agent组成树状结构，上层Agent负责规划和监督，下层Agent负责执行。这种模式适合超复杂任务，但实现和维护成本都很高。

从实操角度，主从模式是最容易落地的一种。它的边界清晰、调试方便、性能可控。对等模式和层级模式更适合研究探索，生产环境慎用。

4.3 多Agent通信的关键设计

多Agent协作的核心是通信。Agent之间怎么传递信息、传递什么信息、什么时候传递，这些设计直接决定了系统的效果。

通信内容方面，我一般会定义一套标准的消息格式，包含：发送者、接收者、消息类型（请求/响应/通知）、消息内容、上下文引用。消息内容要结构化，避免自然语言的歧义。

通信方式方面，有同步和异步两种。同步通信简单直接，但容易阻塞；异步通信灵活，但需要处理消息队列和状态管理。我的经验是：关键路径用同步，非关键路径用异步。

通信协议方面，建议定义清楚每种消息类型的语义和预期响应。比如“请求”消息必须收到“响应”消息，“通知”消息不需要响应。这样可以避免Agent之间互相等待导致的死锁。

4.4 多Agent协作的典型应用场景

多Agent协作在几个场景下特别有价值。第一个是复杂决策场景，比如投资分析，需要从多个角度评估，每个Agent负责一个维度，最后综合判断。第二个是创意生成场景，比如广告文案创作，可以让多个Agent分别生成不同风格的方案，然后评选最优。第三个是长流程任务，比如软件开发，需求分析、设计、编码、测试各由不同Agent负责。

但要注意，这些场景的前提是任务确实可以拆解且拆解后收益大于成本。如果任务本身是原子性的，拆解反而会增加开销。

5. Agent记忆机制：从短期上下文到长期知识

5.1 记忆为什么重要

Agent的记忆机制是决定其能力上限的关键因素之一。没有记忆的Agent，每次对话都是全新的开始，无法积累经验、无法保持一致性、无法处理需要历史信息的任务。

记忆分为短期记忆和长期记忆。短期记忆就是当前对话的上下文，通常直接放在prompt里。长期记忆是跨对话、跨任务的知识积累，需要外部存储和检索机制。

5.2 短期记忆的管理策略

短期记忆的管理核心是上下文窗口的合理利用。模型的上下文窗口有限，不可能把所有历史都塞进去。常见的策略有几种。

滑动窗口是最简单的：只保留最近N轮对话。优点是实现简单，缺点是可能丢失重要信息。摘要压缩是让模型定期对历史对话做摘要，保留摘要而非原文。优点是信息密度高，缺点是摘要可能丢失细节。重要性筛选是根据信息的重要性决定保留哪些，比如用户明确说“记住这个”的信息优先保留。

我的实操经验是：滑动窗口+关键信息提取的组合最实用。保留最近几轮完整对话，同时把更早对话中的关键信息（用户偏好、任务状态、重要结论）提取出来单独存储。

5.3 长期记忆的实现方式

长期记忆通常用向量数据库实现。把历史信息向量化存储，需要时通过相似度检索召回。这种方式适合知识问答、个性化推荐等场景。

但向量检索有个问题：它只能找到相似的内容，找不到相关但表述不同的内容。比如用户之前说“我不喜欢辣的食物”，后来问“推荐几个菜”，向量检索可能找不到之前的偏好记录。解决方案是引入结构化记忆：把用户偏好、任务状态等结构化信息单独存储，检索时结合向量检索和结构化查询。

5.4 记忆机制的实操建议

关于记忆机制，我有几个实操建议。第一，不要什么都记。记忆是有成本的，存储成本、检索成本、维护成本。只记真正有价值的信息。第二，记忆要有过期机制。有些信息有时效性，过期了就应该清理。第三，记忆要可解释。当Agent基于记忆做出决策时，要能说清楚是哪些记忆影响了决策，方便调试和优化。

6. Agent安全与并发：生产环境的必修课

6.1 Agent安全的核心问题

Agent安全是一个容易被忽视但极其重要的话题。Agent有了工具调用能力，就意味着它有了实际操作能力，可以发邮件、下单、修改数据。一旦被恶意利用或出现意外，后果可能很严重。

Agent安全的核心问题包括：权限控制（Agent能调用哪些工具、能访问哪些数据）、输入验证（用户输入是否包含恶意指令）、输出过滤（Agent的输出是否包含敏感信息）、行为审计（Agent的每一步操作是否可追溯）。

6.2 权限控制的设计原则

权限控制要遵循最小权限原则：Agent只拥有完成任务所需的最小权限。比如一个查询天气的Agent，就不应该拥有发送邮件的权限。

实现上，可以用工具白名单：明确列出Agent可以调用的工具，不在白名单里的一律拒绝。同时要做参数校验：即使工具在白名单里，参数也要校验，防止Agent被诱导传入恶意参数。

6.3 并发场景下的Agent设计

当Agent服务需要支撑高并发时，会面临新的挑战。首先是状态管理：每个用户的对话状态需要隔离，不能互相干扰。其次是资源竞争：多个Agent同时调用同一个工具时，需要做限流和排队。第三是一致性：并发操作可能导致数据不一致，需要事务或补偿机制。

我的经验是：无状态设计+外部状态存储是最可靠的方案。Agent本身不保存状态，所有状态存在外部存储（如Redis），每次请求从存储加载状态，处理完再写回。这样可以方便地水平扩展。

6.4 Agent评测集的构建

Agent评测是另一个容易被忽视的环节。怎么判断一个Agent好不好？不能只看几个case，需要系统化的评测集。

评测集应该包含：正常场景（任务能正常完成）、边界场景（输入为空、超长、特殊字符）、异常场景（工具调用失败、超时、返回异常数据）、对抗场景（恶意输入、诱导性指令）。

评测指标方面，除了任务完成率，还要关注步骤效率（完成任务的步数）、工具调用准确率（选对工具的比例）、响应时间、成本（token消耗）。

7. 框架选型与学习路线

7.1 主流Agent框架对比

现在Agent框架很多，选型时容易眼花缭乱。我把几个主流框架的特点整理了一下。

选型的核心原则是：匹配你的技术栈和场景需求。不要为了用框架而用框架，简单的场景直接手写循环可能更可控。

7.2 Agent开发学习路线

如果你刚开始学Agent开发，我建议按这个路线走。

第一阶段：理解基础概念。搞清楚什么是Agent、和ChatBot的区别、核心组件有哪些。这个阶段不需要写代码，多看几篇高质量的文章和论文就够了。

第二阶段：手写单轮调用。不要用框架，直接用API手写一个单轮调用的Agent。理解工具描述、输出解析、错误处理的细节。

第三阶段：实现ReAct循环。在单轮基础上加上循环，实现Thought-Action-Observation的完整流程。这个阶段会接触到上下文管理、循环控制等核心问题。

第四阶段：引入记忆和工具。给Agent加上记忆机制，接入更多工具。理解记忆管理和工具编排。

第五阶段：尝试多Agent。在单Agent基础上拆分出多个角色，实现协作。这个阶段重点是通信和协调。

第六阶段：生产化。加上安全控制、并发处理、监控告警、评测体系。

每个阶段都建议动手写代码，光看不动手是学不会的。

8. 实操中的坑与经验

8.1 常见问题速查

8.2 几个容易踩的坑

第一个坑是过度设计。一开始就上多Agent、上复杂记忆、上各种花哨的机制，结果系统复杂到无法调试。我的建议是从最简单的方案开始，遇到瓶颈再演进。

第二个坑是忽视错误处理。Demo阶段一切顺利，生产环境各种异常。工具超时、返回格式不对、模型输出不符合预期，这些都要有预案。

第三个坑是不做评测。改了一版prompt，感觉效果好了，但到底好了多少？没有评测集就说不清楚。建议从项目第一天就建立评测集，每次改动都跑一遍。

第四个坑是忽视成本。Agent的token消耗比普通对话高很多，尤其是多轮循环和多Agent协作。一定要做成本监控和预算控制。

8.3 一些实用的技巧

技巧一：工具描述用few-shot。在工具描述里给一两个调用示例，模型选对工具的概率会明显提升。

技巧二：关键决策点加确认。对于有副作用的操作（下单、发邮件），让Agent先输出计划，人工确认后再执行。

技巧三：日志要详细。Agent的每一步思考、每一次工具调用、每一个返回结果都要记日志。出问题时这些日志是唯一的线索。

技巧四：灰度发布。新版本的Agent先小流量测试，观察指标正常后再全量。

技巧五：保留人工兜底。再好的Agent也可能出错，关键场景要保留人工介入的通道。

9. 我对Agent架构演进的理解

做了这么多Agent项目，我最大的体会是：Agent的复杂度应该与任务的复杂度匹配。单轮调用能解决的，不要用循环；单Agent能搞定的，不要上多Agent。每增加一层复杂度，就增加一份维护成本和出错概率。

从技术趋势看，Agent正在从“能跑通”向“跑得稳、跑得省、跑得安全”演进。早期的关注点是怎么让Agent完成任务，现在的关注点是怎么让Agent可靠地、经济地、安全地完成任务。这个转变意味着工程能力变得越来越重要，光懂模型不够，还要懂系统设计、懂并发、懂安全。

另外一个感受是：Agent的记忆和工具生态是下一个竞争焦点。模型能力逐渐趋同，差异化的地方在于谁能给Agent更好的记忆机制、更丰富的工具、更安全的执行环境。

最后分享一个我自己的习惯：每做一个Agent项目，我都会记录三个东西——架构决策记录（为什么这么设计）、踩坑记录（遇到了什么问题怎么解决的）、评测记录（每次改动的效果对比）。这些记录在后续项目中价值巨大，能帮你避免重复踩坑，也能帮你快速回顾设计思路。

Agent这个领域变化很快，但底层的东西变化没那么快。把单轮调用、循环调用、多Agent协作这些基础模式吃透，把记忆、安全、并发这些工程问题解决好，不管上层框架怎么变，你都能快速适应。