引言：为什么Agent需要多次调用大模型？
单次调用的大模型如同一个“聪明但健忘的顾问”——你可以问它一个问题，它给出答案，但无法主动执行操作、无法从环境中获取反馈、无法自我修正。
Agent的核心突破在于 赋予大模型行动能力和循环思考能力 ，而这必然需要多次调用：
- 简单问答场景 ：仅需 1 次调用即可完成。用户提问，模型直接回答，无需额外操作。
- 查询天气并推荐穿衣场景 ：需要 2 至 3 次调用。第一次调用获取天气数据，第二次调用基于天气给出穿衣建议，可能还需要第三次调用进行最终整理。
- 自动数据分析场景 ：需要 5 至 10 次调用。包括读取数据、数据清洗、统计分析、图表生成、结果解读等多个步骤，每个步骤都可能涉及工具调用和结果反馈。
- 多轮对话式预订机票场景 ：需要 10 至 20 次调用。涉及日期查询、航班比价、乘客信息填写、支付确认等多个环节，每个环节都需要与用户确认和系统交互。
- 全自动软件开发场景 ：需要数十至上百次调用。包括需求分析、代码编写、单元测试、代码审查、修复bug、文档生成等完整开发流程。
总体架构：控制层与模型层的分离
设计图：Agent核心架构
设计要点：
- 控制器（Orchestrator） ：纯代码实现的状态机，是整个系统的“大脑中枢”，负责维护循环状态、判断何时终止、处理异常情况。它不依赖大模型，保证了控制的确定性和稳定性。
- 模型层 ：仅负责决策，是系统的“思考器官”。每次调用只做一件事——基于当前上下文决定下一步该做什么。模型不执行任何实际操作，也不存储任何状态。
- 工具层 ：封装所有外部能力，是系统的“手脚”。包括API调用、数据库操作、代码执行、文件读写等。工具层对模型完全透明，模型只需知道工具的名称和用途，无需了解实现细节。
- 记忆模块 ：管理短期对话历史和长期知识存储。短期记忆维护当前任务的完整上下文，长期记忆通过向量数据库实现相关知识的检索与注入。
核心驱动力：ReAct模式
流程图：单次循环的标准流程
ReAct模式示例
[调用 1]
Thought: 用户想知道北京天气，我需要先查询天气API
Action: get_weather(city="北京")
--- 系统中断，执行工具，返回结果 ---
[调用 2]
Observation: 北京，晴天，温度25°C，湿度40%Thought: 我已获取天气信息，现在可以给出穿衣建议
Action: recommend_clothing(temperature=25, weather="晴天")
--- 系统中断，执行工具 ---
[调用 3]
Observation: 建议穿着短袖T恤、薄外套
Thought: 所有信息已齐备，可以回答用户
Final Answer: 北京今天天气晴朗，温度25°C，建议穿短袖T恤，早晚可加薄外套。
关键技术实现
功能图：Function Calling机制
Function Calling工作原理
Function Calling是现代大模型（如GPT-4、Claude 3.5、Gemini）的原生能力，其核心价值在于：
- 确定性输出 ：模型输出结构化的tool_calls对象，而非自由文本，彻底解决了输出解析的不可靠问题
- 强制中断机制 ： 当模型决定调用工具时，API 会返回结构化的对象，而不是继续生成普通文本。系统可以在本轮调用结束后立即执行工具，并将结果追加到对话历史中，从而实现明确的“思考-行动”分离。
- 类型安全 ：工具参数通过JSON Schema定义，模型输出的参数自动符合类型约束，减少了类型转换错误
工具定义示例
工具定义的JSON Schema结构如下所示，包含工具名称、功能描述和参数定义三个核心部分：
工具定义示例：
{
"type": "function",
"function": {
"name": "get_weather",
"description": "获取指定城市的天气信息",
"parameters": {
"type": "object",
"properties": {
"city": {
"type": "string",
"description": "城市名称，如'北京'"
}
},
"required": ["city"]
}
}
}
当模型决定调用工具时，返回的tool_calls对象包含调用ID、工具名称和参数JSON：
模型返回的tool_calls示例：
{
"tool_calls": [{
"id": "call_abc123",
"function": {
"name": "get_weather",
"arguments": "{"city": "北京"}"
}
}]
}
系统执行工具后，需要构造一条tool角色的消息，将执行结果与调用ID关联，追加回对话历史：
工具执行结果的消息格式：
{
"role": "tool",
"tool_call_id": "call_abc123",
"content": "北京，晴天，温度25°C"
}
多智能体协作模式
当单个Agent无法高效处理复杂任务时，多智能体系统（Multi-Agent System）成为更优选择。每个Agent拥有独立的角色、工具集和提示词，通过协作完成复杂任务。
设计图：主管-工作者架构
多智能体调用流程
以下是一个“开发计算器应用”任务的完整协作时序，展示了6次大模型调用如何在多个Agent之间流转：
多智能体架构的核心价值
- 角色专业化 ：每个Agent专注于特定领域，提示词可以高度定制，工具集可以精准配置，输出质量更高
- 任务并行化 ：相互独立的任务可以由不同Agent同时执行，显著提升整体效率
- 自我纠错能力 ：通过审查Agent的介入，可以在正式交付前发现并修复问题，形成自我完善的闭环
- 可扩展性 ：新增能力只需增加对应的专业Agent，无需修改现有系统
工程实践中的关键问题
上下文管理
多次调用会导致历史消息迅速膨胀，必须实施管理策略：
- 策略一：摘要压缩
当历史消息超过预设阈值（如20条消息或10000 Token）时，系统会调用大模型对早期对话生成摘要。摘要保留核心信息和关键决策点，替代原始消息，后续调用只保留摘要加最近几轮完整对话。 - 策略二：滑动窗口
只保留最近N轮完整的“思考-行动-观察”循环，丢弃更早的内容。这种策略实现简单，但可能丢失重要上下文，适用于对历史依赖不强的任务。 - 策略三：RAG检索增强
将所有历史消息向量化存入数据库。每次调用前，根据当前问题检索最相关的历史片段，动态注入上下文。这种方式在长周期任务中表现优异，但实现复杂度较高。 - 策略四：混合策略
实际系统中通常采用组合策略：滑动窗口保证近期的完整性，摘要压缩处理中等距离的历史，RAG检索处理跨会话的知识。
重试与自我纠错机制
在实际运行中，各种错误难以避免：API限流、网络波动、模型输出格式异常、工具执行失败等。一个健壮的Agent必须具备完善的错误处理能力。
错误类型与应对策略：
- API限流错误 ：采用指数退避策略，首次等待1秒，后续依次等待2秒、4秒、8秒……直到达到最大重试次数。不同API的限流规则不同，需要针对性配置。
- 模型输出格式错误 ：当模型未按预期输出结构化内容时，系统会构造一条纠错提示，如“你输出的格式不符合要求，请按照{格式说明}重新输出”，将这条提示作为新的系统消息追加后重试。
- 工具执行失败 ：工具执行过程中可能抛出异常（如API密钥失效、参数类型错误等）。系统会捕获异常，将错误信息包装为Observation，如“工具返回错误：无效的城市名称”，让模型尝试修正参数后重试。
- 无意义循环检测 ：当模型连续多次执行相同操作且无进展时，系统会强制中断，返回当前已获得的最佳结果，避免无限循环和资源浪费。
性能优化与成本控制
随着调用次数增加，延迟和成本呈线性增长。以下是三个层面的优化策略：
调用层面优化
- 流式输出 ：通过SSE（Server-Sent Events）逐步返回模型生成内容，用户感知的首字延迟从秒级降至毫秒级，显著提升交互体验
- 并行调用 ：识别相互独立的子任务，如同时查询天气和航班信息，在同一轮循环中并发执行多个工具，将串行耗时变为并行耗时
- 缓存机制 ：对于重复的查询（如相同的天气查询、固定的计算任务），建立请求-响应缓存，相同输入直接返回缓存结果，避免重复调用
模型层面优化
- 模型路由 ：建立模型选择器，简单任务（如格式转换、文本提取）使用小模型（如GPT-3.5或本地部署的7B模型），复杂推理任务使用大模型。这种方式可降低60%以上的成本
- Prompt压缩 ：精简系统提示词，移除冗余描述，合并相似指令，将提示词Token消耗降低30%-50%
- 量化推理 ：使用量化版本的模型（如INT8、INT4量化），在推理速度和成本上获得显著提升，对部分任务场景精度影响可控
架构层面优化
- 异步执行 ：将模型调用设计为异步非阻塞模式，同一进程中可同时处理多个任务的等待状态，提高系统吞吐量
- 智能终止 ：构建早停机制，当模型连续多次输出的置信度较低，或连续多轮无实质进展时，提前结束循环返回结果
- 批处理 ：对于可批量处理的独立请求（如批量数据标注），将多个请求合并为一次调用，利用模型的原生批处理能力，单次成本远低于多次调用的总和
优化策略全景图 ：
总结
Agent实现多次调用大模型，本质上是构建了一个 认知循环架构 ，将大模型从“一次性回答工具”升级为“持续决策与行动系统”。
核心要素总结
- 循环控制 ：通过ReAct模式将单次推理扩展为“思考-行动-观察”闭环，配合状态机实现可控的多次迭代
- 决策输出 ：借助Function Calling或结构化输出约束，确保模型输出可被程序精确解析，消除自由文本带来的不确定性
- 工具集成 ：设计标准化的工具接口，将模型决策转化为实际执行，赋予模型操作外部世界的能力
- 记忆管理 ：通过摘要压缩、滑动窗口、RAG检索等策略，解决长对话上下文膨胀带来的成本和窗口限制问题
- 多智能体 ：采用主管-工作者架构分解复杂任务，通过专业化分工和协作，提升系统整体能力上限
未来趋势展望
随着大模型技术的持续演进，Agent的多次调用机制将呈现以下趋势：
- 更长上下文 ：百万级Token的上下文窗口正在成为主流，单次调用即可承载更多历史信息，减少因窗口限制导致的额外调用
- 更强的推理 ：模型原生推理能力的增强，将减少部分“为了思考而思考”的冗余调用
- 更智能的规划 ：模型将具备更高级的任务规划能力，能够一次性规划完整执行路径，减少试错和回溯带来的调用次数
- 更自然的交互 ：模型将在调用工具时自动判断何时需要用户确认、何时可以自主执行，使多轮调用更接近人类助理的自然交互方式
欢迎关注我的公众号(onething365)，最新的技术与你分享
