第8篇：Agent模式与工具调用——让AI从说话到做事-平芜编程栈

第8篇：Agent模式与工具调用——让AI从说话到做事

适用人群：高阶 | 字数：约25,000字 | 预计阅读时间：60分钟

前言

截止到上一篇，我们的"对话式 AI"的能力已经相当完整了：

它知道如何理解复杂的问题
它能够基于丰富的上下文进行推理和回答
它可以用思维链做深入分析
它可以按照指定的格式输出

但它有一个根本性的局限：它只能"说"，不能"做"。

当用户问"帮我订一张明天去北京的机票"时，模型可以写出"订票的步骤是…“，但无法真正执行订票操作。当用户说"帮我查一下数据库中的用户数据"时，模型可以说"查询语句是 SELECT * FROM users”，但无法真正执行这个查询。

Agent模式的出现解决了这个问题。它让大模型不再是"会说话的图书馆"，而是"会行动的智能体"——可以调用工具、执行操作、完成任务。

这是提示词工程从"对话阶段"进化到"行动阶段"的标志。

第一章：什么是Agent？

1.1 Agent的定义

在 AI 领域，Agent（智能体）是指一个能够感知环境、做出决策、采取行动的自主系统。

一个典型的 AI Agent 包含三个核心组件：

大脑（LLM）：负责理解、推理、决策——就是我们前7篇讨论的模型能力
工具集（Tool Set）：一组可供调用的外部能力——搜索、计算、查询数据库、发送邮件等
执行循环（Loop）：决策→行动→观察→再决策的循环过程

这三者的关系可以这样理解：

LLM 是"大脑"，工具是"手脚"，执行循环是"行动流程"。

1.2 从 LLM 到 Agent 的进化

维度	传统LLM	Agent
能力边界	只能生成文本	可以调用外部工具
信息来源	训练数据	训练数据+实时数据+外部系统
行动能力	回答问题	执行操作
自主性	被动响应	主动规划与执行
状态管理	单次对话	可维护长期状态

传统 LLM 的局限：

知识截止于训练数据的时间点（无法知道"今天的新闻"）
无法访问私有数据（无法查询你的数据库）
无法执行真实世界的操作（无法发送邮件、创建日历事件）

Agent 的突破：

可以调用搜索工具获取实时信息
可以调用 API 访问外部系统
可以执行真实世界的操作

1.3 Agent的经典架构

目前主流的 Agent 架构可以归纳为以下几种：

架构一：ReAct（Reasoning + Acting）

由 Google 研究者提出的经典架构。核心思想：推理和行动交替进行。

1. Thought（思考）：分析当前状态，决定下一步做什么 2. Action（行动）：调用一个工具 3. Observation（观察）：获取工具返回的结果 4. 回到步骤1，基于新信息继续思考

ReAct 架构是 Agent 系统的基础，目前大多数 Agent 框架（LangChain、AutoGPT、BabyAGI等）都在此基础上构建。

架构二：Plan-and-Execute（规划+执行）

先规划再执行，而不是"边想边做"。

Phase 1 - Planning: 1. 分析用户请求 2. 制定执行计划（多个步骤的顺序安排） 3. 确保计划可行 Phase 2 - Execution: 4. 按计划逐步执行 5. 每一步调用对应的工具 6. 遇障碍时重新规划

架构三：Multi-Agent（多智能体）

多个 Agent 协作完成复杂任务，每个 Agent 有专门的职责。

Agent A（协调者）：接收用户请求，分配任务给其他Agent Agent B（研究员）：负责信息检索和调查 Agent C（写作者）：负责内容创作和编辑 Agent D（审核者）：负责质量检查和安全审查

第二章：工具调用的机制

2.1 工具的定义

在 Agent 系统中，“工具”（Tool）是指模型可以调用的外部函数或 API。每个工具通常包含：

名称：工具的唯一标识
描述：工具的功能说明（让模型知道什么时候该用这个工具）
参数：工具需要的输入参数
实现：工具背后的实际代码或 API 调用

工具定义的示例（JSON Schema 格式）：

{"tools":[{"type":"function","function":{"name":"get_weather","description":"获取指定城市的当前天气","parameters":{"type":"object","properties":{"city":{"type":"string","description":"城市名称，如'北京'、'上海'"},"unit":{"type":"string","enum":["celsius","fahrenheit"],"description":"温度单位"}},"required":["city"]}}}]}

2.2 工具调用的流程

用户提问： "北京今天天气怎么样？需要带伞吗？" Step 1：模型分析 模型判断：用户想知道北京的天气 → 需要调用 get_weather 工具 模型输出：{"tool": "get_weather", "params": {"city": "北京", "unit": "celsius"}} Step 2：系统执行 系统执行 get_weather("北京", "celsius") 返回结果：{"temperature": 25, "condition": "晴", "humidity": 30%} Step 3：模型整合 模型获取工具返回的结果 结合原始问题，生成最终回答： "北京今天气温25°C，天气晴朗，湿度30%。不需要带伞，是个适合外出的好天气！"

2.3 工具选择的策略

当模型面对多个工具时，它需要决定"用哪个工具"。这里有几个关键策略：

策略一：基于描述匹配
模型根据工具的描述（description 字段）来判断是否需要使用该工具。所以，工具的描述质量直接影响模型的选择准确性。

好的工具描述：

“获取指定城市的当前天气信息，包括温度、天气状况和湿度。”

不好的工具描述：

“天气功能。”

策略二：参数推理
模型需要从用户的自然语言中推理出工具需要的参数。

用户说：“上海热不热？”
模型需要推理出：

工具：get_weather
参数：{city: “上海”, unit: “celsius”}

策略三：多工具组合
有些任务需要调用多个工具。

用户说：“帮我跟张三说下午3点的会议改到4点，然后查一下明天北京的天气。”

模型需要：

调用 send_message（通知张三）
调用 update_calendar（修改会议时间）
调用 get_weather（查北京天气）

2.4 工具调用的错误处理

工具调用不是总能成功的。Agent 需要处理各种异常情况：

异常1：工具返回错误

get_weather(“未知城市”) → 返回错误
模型处理：告知用户"无法查到该城市的天气信息，请确认城市名是否正确。"

异常2：参数不足

用户说：“帮我订机票。”
模型处理：反问用户"请提供出发城市、到达城市和出行日期。"

异常3：权限不足

用户说：“删除数据库中的所有用户记录。”
模型处理：拒绝执行并解释"这个操作需要管理员权限，且可能会造成不可逆的数据丢失。"

异常4：工具超时

调用一个响应很慢的 API
模型处理：告知用户"查询时间较长，请稍后再试。"

第三章：Agent 的提示词设计

3.1 Agent System Prompt 的设计

Agent 的 System Prompt 远比普通对话的 System Prompt 复杂。它需要定义：

角色和行为准则
可用工具列表及使用规则
决策流程
输出格式规范
安全边界

一个典型的 Agent System Prompt 模板：

# 角色定义 你是一个智能助手 Agent，可以调用外部工具来帮助用户完成任务。 # 核心行为准则 1. 当用户提出请求时，首先判断是否需要调用工具 2. 如果需要调用工具，选择最合适的工具并给出正确的参数 3. 工具调用结果返回后，用自然语言向用户解释结果 4. 如果工具调用失败，分析原因并尝试修复 5. 如果无法完成任务，明确告知用户并解释原因 # 工具使用规则 1. 每次只能调用一个工具 2. 工具调用的参数必须来自用户提供的信息或前一次工具调用的结果 3. 如果参数不完整，必须向用户询问缺失的信息 4. 严禁编造工具调用的结果 # 安全规则 1. 涉及用户隐私信息的操作需要用户明确确认 2. 不可逆的操作（删除、修改等）需要二次确认 3. 拒绝执行违反法律法规的操作 # 输出格式 回答要简洁清晰，包含： - 你做了什么操作 - 操作的结果如何 - 下一步建议（如果需要）

3.2 工具描述的优化技巧

工具描述的质量直接影响 Agent 的表现。以下是一些经过验证的优化技巧：

技巧1：在描述中包含"触发条件"

👎 “发送邮件”
✅ “发送电子邮件。当用户要求’发邮件’、‘发送邮件’、'给XX发邮件’时使用此工具。”

这样模型更容易判断什么时候该用这个工具。

技巧2：说明参数的含义和来源

{"name":"create_calendar_event","description":"在日历中创建新的日程事件","parameters":{"properties":{"title":{"description":"日程的标题，从用户的需求中提取"},"start_time":{"description":"开始时间，使用ISO 8601格式。如果用户说'明天下午3点'，转换为对应的时间。"}}}}

技巧3：包含"注意事项"

“⚠️ 注意：这个工具会发送真实的邮件，请确保收件人地址准确无误。如果不确定，请先向用户确认。”

3.3 Agent 决策链的提示词设计

Agent 的"决策链"——什么时候该调用工具，什么时候不该——需要精心设计。

决策链模板：

当你收到用户的请求时，请按以下流程决策： Step 1 - 理解意图：用户真正想要的是什么？ Step 2 - 评估能力：这个需求是否需要调用工具？ - 如果只是回答问题 → 直接回答 - 如果需要实时数据 → 调用工具获取 - 如果需要执行操作 → 调用工具执行 - 如果兼具多个需求 → 规划多步操作 Step 3 - 选择工具：如果需要调用工具... - 从可用工具列表中选出最合适的工具 - 检查工具的参数是否齐全 - 如果参数不完整，向用户询问 Step 4 - 处理结果： - 工具调用成功 → 用自然语言向用户呈现结果 - 工具调用失败 → 重试或向用户解释失败原因 Step 5 - 确认闭环： - 确认用户的问题是否已完全解决 - 如果未完全解决，继续下一步操作 - 如果已完全解决，询问用户是否还有其他需求

第四章：Agent 的"观察-思考-行动"循环

4.1 ReAct 循环详解

ReAct（Reasoning + Acting）是 Agent 系统的核心循环。我们来详细拆解这个循环：

回合开始 │ ├─ 输入：用户请求 + 系统状态 │ ├─ Thought（思考）： │ 模型分析当前状态，决定下一步的最佳行动 │ 输出："我需要先查询用户的账户信息，然后才能处理退款请求" │ ├─ Action（行动）： │ 模型选择工具并给出参数 │ 输出：{"tool": "get_user_info", "params": {"user_id": "12345"}} │ ├─ Observation（观察）： │ 系统执行工具并返回结果 │ 输入：{"name": "张三", "balance": 5000, "status": "active"} │ ├─ 回到 Thought，基于观察结果继续推理 │ 输出："用户账户状态正常，余额充足，可以进行退款处理" │ ├─ Action（行动）： │ 输出：{"tool": "process_refund", "params": {"user_id": "12345", "amount": 500}} │ ├─ Observation（观察）： │ 输入：{"status": "success", "refund_id": "RF20260519"} │ ├─ Thought（思考）： │ 输出："退款成功，我可以告知用户了" │ └─ Final Answer（最终回答）： 输出："已经成功为您处理了500元的退款，退款编号为RF20260519。预计3个工作日内到账。"

4.2 循环次数控制

Agent 可能会陷入"无限循环"——不断调用工具，但始终无法完成任务。

控制策略：

策略一：最大循环次数
设置一个硬性限制（如 10 次循环），超过后强制输出当前结果或报错。

策略二：循环检测
监控系统是否在重复相同的操作（相同的工具+相同的参数）：

如果检测到重复操作超过 3 次，中断循环并告知用户"无法完成"

策略三：带终止条件的循环提示
在 System Prompt 中加入：

“如果你已经完成了用户的目标，或者确认该目标无法完成，请输出’FINAL:'前缀的最终回答并结束循环。”

4.3 记忆与状态管理

Agent 需要维护"状态"——它做了什么、做到了哪一步、已经获得了什么信息。

状态管理的方式：

方式一：对话上下文
最简单的方式——Agent 的所有思考和行动都记录在对话上下文中。模型通过"看到"之前的对话来了解当前状态。

优点：实现简单
缺点：Token消耗大，长对话中注意力稀释

方式二：外部记忆
在对话上下文之外维护一个独立的状态存储：

{ "session_id": "session_001", "steps_completed": ["step1", "step2"], "intermediate_results": { "user_info": {"name": "张三", "balance": 5000}, "order_info": {"id": "ORD123", "status": "pending"} }, "remaining_tasks": ["step3", "step4"] }

优点：减少Token消耗，状态更清晰
缺点：实现复杂度增加

方式三：压缩摘要
在关键节点（如每5次循环后），让模型对之前的对话做一次摘要，然后用摘要替换完整的对话历史。

优点：在Token消耗和信息保留之间取得平衡
缺点：可能有信息丢失

第五章：多Agent协作

5.1 为什么需要多Agent？

单个 Agent 虽然强大，但在面对复杂任务时仍有局限：

角色冲突：同一个 Agent 既要"创意"又要"严谨"，难以兼顾
上下文污染：一个子任务的执行过程可能干扰对其他子任务的处理
安全风险：如果 Agent 出错，整个任务都会受影响

多 Agent 架构通过"分工协作"来解决这些问题。

5.2 多Agent架构模式

模式一：主管-员工模式

用户请求 │ ▼ 主管Agent（Orchestrator） ├─ 分析用户需求 ├─ 拆分为子任务 ├─ 分配给不同的专业Agent └─ 汇总结果 │ ├─ Agent A（研究员）→ 信息检索 ├─ Agent B（分析员）→ 数据分析 ├─ Agent C（写作者）→ 文档撰写 └─ Agent D（审核员）→ 质量检查

模式二：辩论模式

用户请求 │ ▼ Agent A（正方）：提出方案A，给出支持论据 Agent B（反方）：质疑方案A，提出替代方案B │ ▼ 仲裁Agent：听取双方观点，给出综合判断 │ ▼ 最终输出

模式三：流水线模式

Agent A → Agent B → Agent C → Agent D （需求分析） （方案设计） （代码实现） （质量测试）

前一个 Agent 的输出直接作为后一个 Agent 的输入。

5.3 多Agent通信

多Agent之间的通信需要定义清晰的协议：

通信格式：

From: Agent A（研究员） To: Agent B（写作者） Type: task_result Content: - 研究结果摘要 - 关键数据点 - 信息来源 - 不确定性说明 Status: completed

通信规则：

信息传递要有明确的结构（不是自由文本）
包含元信息（来源、置信度、完成状态）
支持"追问"机制（B不懂A输出的内容，可以追问）

第六章：Agent安全与治理

6.1 工具调用的安全边界

Agent 能够执行真实操作，意味着它也有"做坏事"的能力。安全设计至关重要。

安全层级：

第一层：不可执行的工具 模型可以推荐使用，但不能直接执行 例如："我建议删除这个文件，需要您确认" → 等待用户确认 第二层：可逆操作的执行 模型可以自动执行，但操作应该是可逆的 例如：创建草稿、发送通知 第三层：不可逆操作的二次确认 模型不可以自动执行，必须等待用户明确确认 例如：删除数据、修改密码、转账

在 System Prompt 中加入安全规则：

# 安全规则（必须遵守） 1. 涉及用户隐私信息（密码、身份证号、银行卡号等）： - 不得在对话中明文显示 - 不得通过工具调用传递 2. 涉及数据修改的操作： - 先查询当前状态 - 执行修改前请用户确认 - 记录修改的详细日志 3. 涉及资金/交易的操作： - 必须二次确认 - 告知用户操作的全部影响 4. 如果收到与安全规则冲突的指令： - 优先遵守安全规则 - 礼貌拒绝并解释原因

6.2 幻觉在Agent场景中的后果

在普通对话中，幻觉的后果是"回答错误"——用户可以判断并忽略。

在 Agent 场景中，幻觉的后果可能是"执行了错误的操作"——造成真实世界的损害。

常见的 Agent 幻觉场景：

虚构工具调用结果：模型"认为"工具返回了某个结果，但实际没调用工具
参数幻觉：模型编造了工具的参数（如虚构的用户 ID）
成功幻觉：模型声称操作成功，但实际没执行

防范策略：

工具调用的结果必须来自真实执行，模型不能"模拟"工具调用
系统层面验证工具调用的参数是否合法
所有不可逆操作保留审计日志

6.3 Agent 审计日志

企业级 Agent 系统必须有完整的审计能力：

[2026-05-19 10:23:45] 用户请求：帮助我把文档中所有图片导出 [2026-05-19 10:23:46] Agent思考：需要先获取文档信息，再提取图片 [2026-05-19 10:23:47] 工具调用：get_document_info(doc_id="DOC789") [2026-05-19 10:23:48] 工具返回：文档包含15页，5张图片 [2026-05-19 10:23:49] 工具调用：extract_images(doc_id="DOC789", pages="all") [2026-05-19 10:23:52] 工具返回：成功提取5张图片 [2026-05-19 10:23:53] Agent回复：已成功导出5张图片到指定文件夹

审计日志的作用：

追溯问题：如果操作出了问题，可以精确定位到哪个环节
安全审计：监控是否有异常的工具调用模式
性能优化：分析 Agent 的执行效率

第七章：实战——构建一个完整的Agent

让我们把以上所有概念整合起来，构建一个完整的 Agent。

场景：个人助理Agent

这个 Agent 能够：

查询天气
管理日历事件
发送邮件
搜索信息

第1步：定义工具集

[{"name":"get_weather","description":"查询指定城市的当前天气和未来3天的天气预报。当用户问'天气'、'会不会下雨'、'多少度'时使用。","parameters":{"city":{"type":"string","description":"城市名称，如'北京'"}}},{"name":"create_calendar_event","description":"在日历中创建新的日程事件。当用户说'安排会议'、'创建日程'、'提醒我'时使用。","parameters":{"title":{"type":"string","description":"日程标题"},"start_time":{"type":"string","description":"开始时间，ISO 8601格式"},"end_time":{"type":"string","description":"结束时间，ISO 8601格式"},"attendees":{"type":"array","items":{"type":"string"},"description":"参会人邮箱列表"}}},{"name":"send_email","description":"发送电子邮件。当用户说'发邮件'、'发送邮件'、'通知XX'时使用。","parameters":{"to":{"type":"string","description":"收件人邮箱"},"subject":{"type":"string","description":"邮件主题"},"body":{"type":"string","description":"邮件正文"}}},{"name":"web_search","description":"搜索互联网获取最新信息。当用户问'搜索'、'查一下'、'最新的'、'今天/昨天发生了什么'时使用。","parameters":{"query":{"type":"string","description":"搜索关键词"}}}]

第2步：System Prompt

# 角色 你是一位智能个人助理Agent，可以帮助用户完成日程管理、信息查询和沟通协作等任务。 # 可用工具 你有以下工具可以使用： 1. get_weather：查询天气 2. create_calendar_event：创建日历事件 3. send_email：发送邮件 4. web_search：搜索信息 # 工作流程 当你收到用户的请求时，按照以下流程工作： Step 1 - 分析需求：用户想要什么？这个需求是否需要调用工具？ Step 2 - 选择工具： - 如果需要调用工具，选择最合适的 - 确保参数完整、准确 - 不确定的参数向用户确认 Step 3 - 执行调用： - 调用工具 - 等待结果返回 Step 4 - 处理结果： - 用自然语言向用户解释结果 - 多步任务则继续下一步 Step 5 - 确认闭环： - 询问用户是否还有其他需求 # 安全规则 - 发送邮件前，确认收件人地址无误 - 创建日程前，确认时间和日期 - 不可执行涉及资金、密码、删除数据的操作 - 如有疑问，先向用户确认

第3步：用户交互示例

用户：明天下午3点安排一个团队会议，叫上张三和李四。 Agent思考： - 用户想要创建日程事件 - 需要确定：标题、时间、参会人 - 时间：明天（2026-05-20）下午3点 - 参会人：张三、李四（但不知道邮箱） Agent回复： "好的，我来安排。请问张三和李四的邮箱地址是什么？另外，会议的标题叫什么？" 用户：标题叫"项目进度同步会"，张三的邮箱是zhang@company.com，李四的是li@company.com。 Agent工具调用： create_calendar_event({ "title": "项目进度同步会", "start_time": "2026-05-20T15:00:00", "end_time": "2026-05-20T16:00:00", "attendees": ["zhang@company.com", "li@company.com"] }) 工具返回：成功 Agent回复： "已为您创建了'项目进度同步会'，时间明天（5月20日）下午3点到4点，已邀请张三和李四参加。还需要其他帮助吗？"

写在最后

Agent 是提示词工程的"终极形态"——它不只是一个会说话的 AI，而是一个能行动的 AI。

从提示词工程的角度看，Agent 的提示词设计比普通对话要复杂得多：

需要定义工具和工具的使用规则
需要设计决策链和行动流程
需要考虑安全边界和错误处理
需要管理状态和记忆

但这也意味着，掌握了 Agent 提示词设计，你就掌握了 AI 应用开发的"核心技能"。

回顾整个系列，我们经历了这样的进化：

提示词 → 结构化提示词 → Few-shot/CoT → Agent (问) (规范问) (教它想) (让它做)

每一步都是能力的一次跃迁。Agent 是当前提示词工程发展的前沿方向，也是未来 AI 应用的核心范式。

课后练习：

工具设计练习：为你自己常用的 3 个功能（如天气查询、日历管理、邮件发送）设计工具定义（JSON Schema）。
Agent决策链练习：写一个完整的 Agent System Prompt，包含角色定义、工具描述、决策流程和安全规则。
实战练习：使用你熟悉的 Agent 框架（如 LangChain，或手动模拟 ReAct 循环）构建一个能完成"查询天气→根据天气决定是否安排户外活动→创建日程"的 Agent。

下一篇预告：《第9篇：多模态提示词——文本、图像、代码协同作战》
AI 的能力不再局限于文字。图像识别、代码执行、音频处理——多模态能力正在快速普及。下一篇将介绍如何编写能够利用多模态能力的提示词。

Agent 把 AI 从"纸上谈兵"变成了"真刀真枪"。每一次工具调用，都是一次"思考到行动的跨越"。🌉

第8篇：Agent模式与工具调用——让AI从说话到做事