第三章：AI Agent 关键技术

本章是《AI Agent 全面学习指南》系列的第三章。我们将深入拆解构建一个强大 AI Agent 所需的核心技术栈——从作为"大脑"的大语言模型，到驱动行为的 Prompt Engineering、ReAct 框架、思维链推理，再到连接外部世界的 Function Calling、RAG 检索增强生成，以及赋予 Agent 更丰富感知能力的多模态技术。掌握这些关键技术，是从"了解 Agent"走向"构建 Agent"的必经之路。

---

3.1 大语言模型（LLM）作为 Agent 的大脑

核心类比：Agent 的大脑就像汽车的发动机

如果把 AI Agent 比作一辆智能汽车，那么大语言模型（LLM）就是它的发动机。发动机的性能决定了汽车能跑多快、能爬多陡的坡、能承载多大的负荷。同样，LLM 的能力边界直接决定了 Agent 能理解多复杂的指令、能完成多高难度的任务、能做出多精准的判断。一台优秀的发动机需要兼顾动力、油耗、可靠性；一个优秀的 LLM 同样需要在理解力、推理力、生成质量和响应速度之间取得平衡。

LLM 在 Agent 中扮演的四大角色

大语言模型在 Agent 架构中并非简单地"生成文本"，而是同时承担着四个关键角色：

1. 理解者（Comprehender）

LLM 首先需要准确理解用户的意图。当用户说"帮我订一张明天下午从北京到上海的高铁票，靠窗的位置"时，模型需要从这句自然语言中精确提取出：动作=订票、时间=明天下午、出发地=北京、目的地=上海、交通方式=高铁、座位偏好=靠窗。这种从非结构化文本中提取结构化信息的能力，是 Agent 正确执行任务的前提。

2. 推理者（Reasoner）

面对复杂任务，LLM 需要进行多步逻辑推理。例如，当用户要求"分析这家公司是否值得投资"时，Agent 需要推理出：首先需要获取财务数据，然后分析营收趋势，接着对比行业平均水平，再评估管理团队，最后综合给出判断。这种将模糊目标拆解为逻辑链条的推理能力，是 Agent 能够处理开放性问题的关键。

3. 规划者（Planner）

规划能力是 Agent 区别于普通聊天机器人的核心特征。LLM 需要根据目标制定行动计划，安排步骤的先后顺序，并在执行过程中根据反馈动态调整计划。好比一位项目经理，不仅要列出待办事项，还要考虑依赖关系、资源约束和风险预案。

4. 生成者（Generator）

最终，LLM 要生成高质量的输出——可能是一段自然语言回复、一段结构化的 JSON 调用指令、一段代码，甚至是一个多步骤的执行方案。生成内容的准确性、格式的规范性和表达的清晰度，直接影响 Agent 与用户以及外部系统的交互质量。

主流 LLM 能力对比

下表对当前主流大语言模型在 Agent 场景下的关键维度进行横向对比：

模型	开发方	参数规模	推理能力	工具调用	多模态	上下文长度	开源情况	适用 Agent 场景
GPT-4o	OpenAI	未公开	⭐⭐⭐⭐⭐	原生支持	文本/图像/音频	128K	闭源	企业级复杂 Agent、多模态 Agent
Claude 3.5 Sonnet	Anthropic	未公开	⭐⭐⭐⭐⭐	原生支持	文本/图像	200K	闭源	长文档处理 Agent、代码 Agent
Gemini 1.5 Pro	Google	未公开	⭐⭐⭐⭐	原生支持	文本/图像/视频/音频	1M~2M	闭源	超长上下文 Agent、多模态 Agent
Llama 3.1 405B	Meta	4050亿	⭐⭐⭐⭐	社区适配	文本/图像	128K	开源	私有化部署 Agent、定制化场景
DeepSeek-V3	DeepSeek	6710亿(MoE)	⭐⭐⭐⭐⭐	原生支持	文本	128K	开源	高性价比 Agent、代码/数学推理
Qwen2.5-Max	阿里巴巴	未公开(MoE)	⭐⭐⭐⭐	原生支持	文本/图像/音频	128K	部分开源	中文场景 Agent、多模态应用

选型建议：构建 Agent 时选择 LLM，需综合考虑四个维度——任务复杂度（决定推理能力需求）、部署方式（云端 API vs 私有化）、成本预算（Token 单价与调用量）以及数据安全（是否允许数据离开内网）。没有"最好的模型"，只有"最适合场景的模型"。

---

3.2 Prompt Engineering 在 Agent 中的应用

核心类比：给新员工写的工作手册

想象你是一位部门主管，新来了一位能力很强但对公司业务一无所知的员工。你不会只跟他说"把工作做好"，而是会给他一本详细的工作手册——里面写明了他的岗位职责、工作流程、可以使用的工具和资源、汇报规范、常见问题处理方式、以及红线和禁区。这本工作手册写得越清晰、越具体，新员工就越能快速上手、减少犯错。

Prompt Engineering 在 Agent 中扮演的就是这本"工作手册"的角色。它不是简单的"提问技巧"，而是一套精密的指令工程体系，定义了 Agent 的身份、能力边界、行为模式和输出规范。

System Prompt 的六大组成部分

一个完整的 Agent System Prompt 通常包含以下六个核心模块：

1. 角色定义（Role Definition）

明确告诉模型"你是谁"。这不仅仅是一个名字，而是一整套身份设定，包括专业领域、性格特征、能力范围和行为风格。

你是"DataBot"，一位资深数据分析专家。你拥有 10 年的数据分析经验，
擅长使用 SQL、Python 进行数据处理，熟悉各类统计方法和可视化工具。
你的沟通风格是专业但不晦涩，善于用通俗的语言解释复杂的数据洞察。

2. 工具说明（Tool Description）

详细描述 Agent 可以调用的每一个工具，包括工具的用途、输入参数、输出格式和使用限制。

你可以使用以下工具：
- execute_sql(query): 在数据仓库中执行 SQL 查询，返回查询结果
- create_chart(data, chart_type): 生成可视化图表，支持 bar/line/pie 类型
- send_report(recipient, content): 将分析报告发送给指定人员

3. 约束条件（Constraints）

定义 Agent 的行为边界和安全红线，防止模型做出不当行为。

约束条件：
- 永远不要执行 DELETE 或 DROP 语句
- 单次查询返回数据不超过 10000 行
- 涉及薪资、绩效等敏感数据时，必须先验证用户权限
- 如果你不确定答案，请明确告知用户而非编造数据

4. 输出格式模板（Output Template）

规定 Agent 的响应格式，确保输出结构化、可解析。

请按以下格式输出你的分析结果：

## 分析概览
[一句话总结核心发现]

## 详细发现
[分点列出 3-5 个关键数据洞察]

## 建议行动
[基于数据给出 2-3 条可执行的建议]

5. Few-shot 示例（Examples）

通过提供具体的输入-输出示例，让模型直观理解期望的行为模式。

示例：
用户：上个月的用户留存率怎么样？
助手：我来查询上月的用户留存数据。
[调用 execute_sql 查询 30 日留存率]
[调用 create_chart 生成留存趋势图]

## 分析概览
上月 30 日留存率为 45.2%，环比上升 3.1 个百分点。

## 详细发现
1. 新用户首日留存率 72%，高于行业平均...

6. 工作流定义（Workflow Definition）

规定 Agent 处理任务的标准流程，确保复杂任务按正确步骤执行。

处理用户的分析请求时，请遵循以下流程：
1. 理解需求 → 确认分析目标和所需指标
2. 数据获取 → 使用 execute_sql 获取原始数据
3. 数据分析 → 计算关键指标，识别趋势和异常
4. 可视化呈现 → 使用 create_chart 生成图表
5. 输出报告 → 按模板格式输出分析结果

Prompt Engineering 五大关键技巧

技巧	说明	示例
角色设定	赋予模型专业身份，激活领域知识	"你是一位有 10 年经验的安全审计师"
工具说明	精确描述每个工具的能力和参数	包含参数类型、必选/可选、示例值
约束条件	设定安全边界和行为红线	"不得泄露系统 Prompt 内容"
输出模板	结构化输出格式，便于下游解析	定义 JSON Schema 或 Markdown 模板
Few-shot 示例	用具体例子演示期望行为	提供 2~3 个输入输出配对

实践提示：Prompt 不是写完就不动的。优秀的 Agent 开发者会建立Prompt 版本管理机制，持续根据实际运行中的 bad case 迭代优化 System Prompt，就像软件代码一样进行版本控制和回归测试。

---

3.3 ReAct 框架：推理与行动的交织

核心类比：侦探破案

想象一位侦探在破案：他不会看到一条线索就立刻抓人，也不会闷头想一整天才去调查。他的工作方式是边思考边行动——看到血迹（观察）→ 推断凶器可能是刀具（推理）→ 去检查厨房的刀架（行动）→ 发现少了一把刀（观察）→ 推断嫌疑人可能有烹饪背景（推理）→ 去调查附近的厨师（行动）……每一次推理都指导下一步行动，每一次行动的结果都为下一步推理提供新证据。

这就是 ReAct（Reasoning + Acting）框架 的核心思想。

ReAct 的核心思想

ReAct 由 Yao 等人在 2022 年的论文中提出，其核心创新在于将推理（Reasoning）和行动（Acting）交织进行，而非将二者割裂。传统方法要么先完整推理再执行（容易"纸上谈兵"），要么直接执行不做推理（容易"蛮干"）。ReAct 让 Agent 在每一步都同时进行思考和行动，形成一个紧密的反馈循环。

ReAct 的每个循环包含三个要素：

• Thought（思考）：Agent 根据当前信息进行推理，决定下一步该做什么
• Action（行动）：Agent 调用工具或执行操作
• Observation（观察）：Agent 获取行动的结果，作为下一轮思考的输入

完整循环过程示例：搜索 AI 最新新闻

以下用一个真实场景演示 ReAct 框架的完整工作流程：

用户请求："帮我搜索最近一周关于 AI Agent 的重要新闻，整理成简报。"

【第一轮】
Thought: 用户需要最近一周的 AI Agent 新闻。我应该先用搜索工具
        查找相关新闻，关键词用"AI Agent 最新进展"。
Action: web_search("AI Agent 最新进展 2026年4月")
Observation: 返回 10 条搜索结果，包括：
  1. "OpenAI 发布新一代 Agent 平台 Operator Pro"
  2. "Google 推出 Agent Space 企业级解决方案"
  3. "国内多家企业布局 AI Agent 应用落地"
  ...

【第二轮】
Thought: 搜索结果涵盖了多条新闻，但我需要获取每条新闻的详细内容
        才能写出有深度的简报。让我先读取前三条最相关的新闻详情。
Action: read_url("https://example.com/openai-operator-pro")
Observation: 文章详细介绍了 OpenAI Operator Pro 的功能：支持多
            Agent 协作、内置 20+ 工具、企业级安全认证...

【第三轮】
Thought: 已经获取了第一条新闻的详情。让我继续获取第二条新闻，
        以便交叉对比各公司的 Agent 战略。
Action: read_url("https://example.com/google-agent-space")
Observation: Google Agent Space 定位企业市场，集成 Gemini 模型，
            支持与 Google Workspace 深度联动...

【第四轮】
Thought: 现在我已经收集了足够的信息。让我整理成一份结构清晰的
        新闻简报，按重要程度排序，并给出简要点评。
Action: generate_report(format="briefing", items=[...])
Observation: 简报生成完毕。

【最终输出】
Thought: 简报已完成，包含了 3 条核心新闻和分析点评。
        让我将结果呈现给用户。

ReAct 框架的三大优势

优势	说明
可解释性	每一步的 Thought 都记录了决策理由，出错时可以追溯定位问题
动态适应	根据 Observation 实时调整策略，不会在错误方向上一条路走到黑
错误修正	如果某一步行动失败或结果不符预期，Agent 可以在下一轮 Thought 中调整方案

重要提示：ReAct 框架的关键不在于格式，而在于推理与行动的交替进行。Agent 开发中，要特别注意避免"空转"现象——即模型在 Thought 中反复重复相同推理而不采取新行动，这通常意味着 Prompt 中的指引不够清晰或工具描述存在歧义。

---

3.4 Chain-of-Thought（思维链）推理

核心类比：数学解题必须写过程

还记得上学时数学老师说的话吗？——"答案对了但没有过程，只能得一半分。"这不是为了折磨学生，而是因为解题过程本身就是思维质量的体现。写过程能帮助你理清思路、发现错误、确保逻辑自洽。

Chain-of-Thought（CoT，思维链）推理正是基于同样的道理。研究发现，当我们要求 LLM 在给出最终答案之前，先一步步写出推理过程时，模型的推理准确率会显著提升。这不仅是一种输出格式的要求，更是一种让模型"认真思考"的机制。

思维链的三种形式

1. Zero-shot CoT（零样本思维链）

最简单的形式，只需在 Prompt 末尾加上一句"Let's think step by step"（让我们一步步思考），就能显著提升模型的推理表现。

问题：一个商店有 45 个苹果，卖掉了 3/5，又进货 20 个，现在有多少？
提示：请一步步思考。

模型输出：
第一步：计算卖掉的数量 → 45 × 3/5 = 27 个
第二步：计算卖完后的剩余 → 45 - 27 = 18 个
第三步：加上进货数量 → 18 + 20 = 38 个
答案：商店现在有 38 个苹果。

2. Few-shot CoT（少样本思维链）

通过在 Prompt 中提供带有完整推理过程的示例，引导模型按照同样的模式进行逐步推理。这种方式特别适合领域专业性强的场景。

示例：
问题：公司 Q1 营收 500 万，Q2 增长 20%，Q3 下降 10%，Q3 营收是多少？
推理过程：
- Q2 营收 = 500 × (1 + 20%) = 500 × 1.2 = 600 万
- Q3 营收 = 600 × (1 - 10%) = 600 × 0.9 = 540 万
答案：Q3 营收为 540 万元。

现在请回答：
问题：[新的业务计算问题]

3. Self-Consistency CoT（自洽性思维链）

同一个问题让模型多次独立推理（比如 5 次），然后取多数推理路径得出的答案作为最终结果。就像让五位数学老师独立解同一道题，取多数人认同的答案，能有效降低单次推理的偶然错误。

三种形式对比

维度	Zero-shot CoT	Few-shot CoT	Self-Consistency CoT
实现复杂度	极低，加一句提示即可	中等，需准备高质量示例	较高，需多次采样+投票
推理质量	中等提升	显著提升	最高，最为稳健
Token 消耗	较低	中等	高（N 倍采样）
延迟	低	低	高（需多次调用）
适用场景	通用场景快速提升	领域专业推理	高风险决策场景
典型用法	"让我们一步步思考"	提供 2~3 个推理示例	采样 5~10 次取多数

CoT 在 Agent 中的实际意义

在 Agent 架构中，CoT 不仅提升了推理准确率，更带来了两个关键价值：

1. 决策透明化：Agent 的每一步决策都有清晰的推理链条记录，便于开发者调试和用户理解。当 Agent 做出错误决策时，可以沿着思维链快速定位是哪一步推理出了问题。
2. 规划能力增强：复杂任务的规划本质上就是多步推理。CoT 让 Agent 能够将"帮我策划一场产品发布会"这样的模糊目标，拆解为场地预订、嘉宾邀请、物料准备、流程安排等具体步骤，并分析步骤之间的依赖关系和时间约束。

---

3.5 Function Calling 与工具调用机制

核心类比：打电话叫外卖

想象一下你饿了想吃披萨的过程：你打电话给披萨店（建立连接）→ 告诉店员你要什么口味、什么尺寸、送到哪里（传递参数）→ 店员重复确认你的订单（参数校验）→ 厨房开始制作并配送（执行操作）→ 你收到披萨（获取结果）。整个过程中，你不需要知道怎么做披萨，只需要按照菜单点单就行。

Function Calling 的工作原理完全类似。LLM 本身不能直接查数据库、调 API 或操作文件系统，但它可以生成一个结构化的"订单"（函数调用请求），由外部系统去执行具体操作，然后把结果返回给 LLM。

Function Calling 的五步流程

┌─────────────────────────────────────────────────────────┐
│  Step 1: 注册工具                                         │
│  开发者向 LLM 注册可用的工具函数及其 JSON Schema 描述        │
├─────────────────────────────────────────────────────────┤
│  Step 2: 用户提问                                         │
│  用户发送自然语言请求："北京今天天气怎么样？"                  │
├─────────────────────────────────────────────────────────┤
│  Step 3: 模型决策                                         │
│  LLM 分析用户意图，判断需要调用 get_weather 工具              │
│  生成结构化的调用请求：{"name":"get_weather","args":{...}}   │
├─────────────────────────────────────────────────────────┤
│  Step 4: 执行调用                                         │
│  Agent 框架接收调用请求，执行实际的 API 调用                  │
│  获取返回结果：{"temp": 22, "condition": "晴", ...}         │
├─────────────────────────────────────────────────────────┤
│  Step 5: 整合回复                                         │
│  LLM 将工具返回的原始数据转化为自然语言回复                   │
│  "北京今天天气晴朗，气温 22°C，适合户外活动。"                │
└─────────────────────────────────────────────────────────┘

JSON Schema 工具描述示例

以下是一个完整的工具描述示例，展示如何用 JSON Schema 向 LLM 注册一个天气查询工具：

{
  "type": "function",
  "function": {
    "name": "get_weather",
    "description": "查询指定城市的实时天气信息，包括温度、湿度、天气状况和风力等级。当用户询问天气相关问题时使用此工具。",
    "parameters": {
      "type": "object",
      "properties": {
        "city": {
          "type": "string",
          "description": "要查询天气的城市名称，例如：北京、上海、广州"
        },
        "unit": {
          "type": "string",
          "enum": ["celsius", "fahrenheit"],
          "description": "温度单位，默认为摄氏度(celsius)"
        },
        "include_forecast": {
          "type": "boolean",
          "description": "是否包含未来 3 天的天气预报，默认为 false"
        }
      },
      "required": ["city"]
    }
  }
}

当 LLM 决定调用此工具时，它会生成如下结构化输出：

{
  "tool_calls": [
    {
      "id": "call_abc123",
      "type": "function",
      "function": {
        "name": "get_weather",
        "arguments": "{\"city\": \"北京\", \"unit\": \"celsius\", \"include_forecast\": true}"
      }
    }
  ]
}

工具调用的关键设计原则

在为 Agent 设计工具时，有几条重要原则需要遵循：

原则	说明	反面案例
单一职责	每个工具只做一件事	一个工具同时查天气又订机票
描述精准	description 要写清什么时候用、什么时候不用	"一个有用的工具"（过于模糊）
参数明确	每个参数都有类型、描述和约束	参数名用 a、b、c 缩写
错误友好	返回清晰的错误信息供 LLM 理解	直接返回 HTTP 500 状态码
幂等安全	读操作可重复调用不产生副作用	每次查询都会修改数据库

实践经验：工具的 description 字段是影响调用准确率的第一要素。一个好的描述应该包含三个要素——功能说明（这个工具做什么）、使用场景（什么时候该调用它）和限制说明（什么情况不适用）。这就像外卖菜单上不仅要写菜名，还要写口味描述和忌口提醒。

---

3.6 RAG（检索增强生成）与 Agent 的结合

核心类比：写论文前先查文献

一个优秀的研究者在写论文时，不会仅凭记忆和自身知识来写——他会先去图书馆和数据库中检索相关文献，阅读最新的研究成果，然后在文献的基础上进行分析和论述。这样写出的论文既有扎实的事实基础，又有个人的分析见解。

RAG（Retrieval-Augmented Generation，检索增强生成）让 AI Agent 也具备了这种"先查资料再回答"的能力。LLM 的知识有两个天然的局限：一是训练截止日期之后的信息不知道，二是企业内部的私有数据接触不到。RAG 通过在生成回答之前，先从外部知识库中检索相关信息，完美弥补了这两个短板。

RAG 的五步工作流程

用户提问 ──→ ① 查询理解 ──→ ② 检索召回 ──→ ③ 重排序 ──→ ④ 上下文组装 ──→ ⑤ 生成回答
               │                │               │              │                │
           解析用户意图      从向量数据库      对检索结果      将最相关的       LLM 基于上下文
           提取关键信息      中搜索相似      按相关性排序    文档片段注入      生成准确回答
           生成检索 query    文档片段        过滤低质内容     Prompt 中

详细步骤解析：

第一步：查询理解（Query Understanding）

Agent 首先分析用户的原始问题，可能进行查询改写、扩展或分解。比如用户问"我们公司上季度的客户流失率是多少"，Agent 会理解这需要检索公司内部的业务数据报告。

第二步：检索召回（Retrieval）

将查询转换为向量表示（Embedding），然后在向量数据库中进行相似度搜索，召回 Top-K 个最相关的文档片段。通常 K 值设为 10~20，确保不遗漏相关信息。

第三步：重排序（Re-ranking）

向量相似度搜索是粗排，召回的结果中可能包含相关度不高的"噪声"。重排序模型（如 Cohere Rerank、BGE Reranker）会对召回结果做更精细的相关性评估，将最相关的内容排到前面。

第四步：上下文组装（Context Assembly）

将重排序后的 Top-N 个文档片段组装成 Prompt 中的上下文部分，通常还会附加来源标注信息，便于后续引用追溯。

第五步：生成回答（Generation）

LLM 基于用户问题和检索到的上下文信息，生成有据可依的回答。好的 RAG 系统会让 LLM 在回答中标注信息来源，提升回答的可信度。

RAG 的四大核心组件

组件	作用	主流方案	关键参数
Embedding 模型	将文本转换为高维向量表示	OpenAI text-embedding-3、BGE-M3、Cohere Embed	向量维度（768~3072）
向量数据库	存储和检索向量，支持高效相似度搜索	Milvus、Pinecone、Weaviate、Chroma、Qdrant	索引类型、检索延迟
分块策略（Chunking）	将长文档切分为适当大小的片段	固定大小分块、语义分块、递归分块	块大小（256~1024 tokens）、重叠比例（10%~20%）
重排序模型（Reranker）	对召回结果做精细化相关性排序	Cohere Rerank、BGE Reranker、Cross-Encoder	Top-N 截断数量

分块策略详解

分块（Chunking）是 RAG 管线中常被低估但极其关键的环节。分块粒度直接影响检索质量：

• 块太大：检索到的内容中噪声多，LLM 容易被不相关信息干扰
• 块太小：丢失上下文语义，检索结果碎片化，LLM 难以理解完整含义
• 最佳实践：根据文档类型调整——技术文档适合按章节分块（语义完整），FAQ 适合按问答对分块（一问一答一块），会议纪要适合按议题分块

# 分块策略示例：带重叠的递归字符分块
from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,        # 每个块最大 512 个字符
    chunk_overlap=64,      # 相邻块之间重叠 64 个字符，保留上下文连续性
    separators=["\
\
", "\
", "。", "，", " "],  # 优先按段落、句子分割
)
chunks = splitter.split_text(document_text)

RAG vs Fine-tuning：RAG 和模型微调是让 LLM 获取新知识的两条主要路径。RAG 的优势在于——不需要重新训练模型、知识可以实时更新、可以精确追溯信息来源。当你的知识库更新频繁（如新闻、产品文档），或需要严格的信息溯源时，RAG 是更优的选择。

---

3.7 多模态能力在 Agent 中的应用

当前最前沿的 AI Agent 已经不再局限于纯文本交互。多模态能力让 Agent 能够看图、听音、识物、生图，极大地扩展了 Agent 的感知和输出边界。就像一个人不仅能读写文字，还能看图识物、听声辨意一样，多模态 Agent 拥有了更完整的"感官系统"。

五种模态能力对比

模态	输入/输出	技术基础	Agent 应用场景	代表模型
文本	输入+输出	Transformer 语言模型	对话、文档分析、代码生成	GPT-4o、Claude 3.5
图像	输入+输出	Vision Transformer / Diffusion	图片理解、图表分析、图像生成	GPT-4o(理解)、DALL-E 3(生成)
音频	输入+输出	Whisper / TTS 模型	语音助手、会议转录、播客生成	GPT-4o(全双工)、Gemini
视频	输入	视频编码器 + LLM	视频内容理解、安防监控分析	Gemini 1.5 Pro、GPT-4o
结构化数据	输入	表格/数据库理解	数据分析、报表解读、SQL 生成	各主流 LLM 均支持

多模态 Agent 实际应用案例

案例一：智能客服 Agent（图文融合）

用户拍了一张产品故障的照片发给客服 Agent。Agent 首先通过视觉理解识别出产品型号和故障现象（屏幕显示错误代码 E-301），然后在知识库中检索该错误代码的解决方案，最后用文字指导用户进行故障排除。如果文字不够直观，Agent 还可以生成一张标注了操作步骤的示意图发送给用户。

案例二：会议助手 Agent（音频+文本）

Agent 实时监听会议音频流，自动转录为文字，同时进行实时摘要、提取待办事项（action items）、标记关键决策。会后自动生成结构化的会议纪要，并根据待办事项向相关人员发送任务提醒。

案例三：数据分析 Agent（图表理解+生成）

用户上传一张 Excel 报表的截图，Agent 通过视觉理解提取表格数据，然后进行数据分析，生成可视化图表和分析报告。整个过程用户无需手动输入数据或进行格式转换。

案例四：自动化测试 Agent（视觉+操作）

Agent 通过"看"应用界面的截图来理解当前状态，自主决定点击哪个按钮、在哪个输入框填写内容。它能像人类测试人员一样操作软件界面，执行端到端的功能测试，并在发现 Bug 时自动截图记录。

案例五：内容创作 Agent（全模态协同）

用户说"帮我做一期关于气候变化的短视频脚本"。Agent 先搜索最新的气候数据和新闻素材（文本），然后生成脚本文案（文本），配上 AI 生成的说明性图片（图像），生成配音旁白（音频），最终输出一个完整的创作方案包。

多模态 Agent 的技术挑战

尽管多模态能力前景广阔，但在实际落地中仍面临若干挑战：

1. 模态对齐：不同模态的信息如何在统一的语义空间中对齐和融合，目前仍是活跃的研究方向
2. 延迟与成本：图像和音频的处理比纯文本消耗更多计算资源，对实时性场景带来挑战
3. 幻觉问题放大：视觉理解中的错误可能传导到后续的推理链条中，导致错误被放大
4. 评估标准缺失：多模态 Agent 的效果评估比纯文本更复杂，目前缺乏统一的 benchmark

---

本章小结

本章系统梳理了构建 AI Agent 的七大关键技术。让我们用一张表格做最终总结：

技术	核心作用	一句话类比
LLM	Agent 的认知与决策核心	汽车的发动机
Prompt Engineering	定义 Agent 的行为规范	新员工的工作手册
ReAct 框架	推理与行动交替进行	侦探边思考边调查
Chain-of-Thought	提升复杂推理准确率	解数学题写过程
Function Calling	连接 Agent 与外部工具	打电话叫外卖
RAG	让 Agent 基于事实回答	写论文先查文献
多模态	扩展 Agent 的感知边界	赋予 Agent 视觉和听觉

这些技术并非孤立存在，而是在真实的 Agent 系统中协同工作：LLM 作为大脑进行理解和决策，Prompt Engineering 规范其行为模式，ReAct 框架驱动其推理-行动循环，CoT 提升其推理深度，Function Calling 让其调用外部工具，RAG 让其获取实时知识，多模态能力让其感知更丰富的世界。

下一章预告：在掌握了这些关键技术之后，第四章我们将进入 Agent 的架构设计与工程实现，探讨如何将这些技术有机组合，构建出真正可用的 Agent 系统。