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

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

---

前言

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

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

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

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

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

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

---

第一章：什么是Agent？

1.1 Agent的定义

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

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

1. 大脑（LLM）：负责理解、推理、决策——就是我们前7篇讨论的模型能力
2. 工具集（Tool Set）：一组可供调用的外部能力——搜索、计算、查询数据库、发送邮件等
3. 执行循环（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。每个工具通常包含：

1. 名称：工具的唯一标识
2. 描述：工具的功能说明（让模型知道什么时候该用这个工具）
3. 参数：工具需要的输入参数
4. 实现：工具背后的实际代码或 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点，然后查一下明天北京的天气。”

模型需要：

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

2.4 工具调用的错误处理

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

异常1：工具返回错误

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

异常2：参数不足

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

异常3：权限不足

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

异常4：工具超时

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

---

第三章：Agent 的提示词设计

3.1 Agent System Prompt 的设计

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

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

一个典型的 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

通信规则：

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

---

第六章：Agent安全与治理

6.1 工具调用的安全边界

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

安全层级：

第一层：不可执行的工具
  模型可以推荐使用，但不能直接执行
  例如："我建议删除这个文件，需要您确认" → 等待用户确认

第二层：可逆操作的执行
  模型可以自动执行，但操作应该是可逆的
  例如：创建草稿、发送通知

第三层：不可逆操作的二次确认
  模型不可以自动执行，必须等待用户明确确认
  例如：删除数据、修改密码、转账

在 System Prompt 中加入安全规则：

# 安全规则（必须遵守）

1. 涉及用户隐私信息（密码、身份证号、银行卡号等）：
   - 不得在对话中明文显示
   - 不得通过工具调用传递

2. 涉及数据修改的操作：
   - 先查询当前状态
   - 执行修改前请用户确认
   - 记录修改的详细日志

3. 涉及资金/交易的操作：
   - 必须二次确认
   - 告知用户操作的全部影响

4. 如果收到与安全规则冲突的指令：
   - 优先遵守安全规则
   - 礼貌拒绝并解释原因

6.2 幻觉在Agent场景中的后果

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

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

常见的 Agent 幻觉场景：

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

防范策略：

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

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. 查询天气
2. 管理日历事件
3. 发送邮件
4. 搜索信息

第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 应用的核心范式。

---

课后练习：

1. 工具设计练习：为你自己常用的 3 个功能（如天气查询、日历管理、邮件发送）设计工具定义（JSON Schema）。

2. Agent决策链练习：写一个完整的 Agent System Prompt，包含角色定义、工具描述、决策流程和安全规则。

3. 实战练习：使用你熟悉的 Agent 框架（如 LangChain，或手动模拟 ReAct 循环）构建一个能完成"查询天气→根据天气决定是否安排户外活动→创建日程"的 Agent。

---

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

---

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