智体觉醒：重新认识AI Agent

第 1 章　智体觉醒：重新认识 AI Agent

1.1　一个被问了千百遍的问题：到底什么是 AI Agent？

2024 年初，如果你打开 Hacker News、知乎或者即刻，大概率会看到这样的标题：「AutoGPT 太可怕了，它能自己上网、写代码、做研究！」；到了年中，又会出现「Devin 横空出世，第一个 AI 软件工程师」；再到 2025 年初，Manus 把「通用 AI 助手」的 demo 刷遍了朋友圈。一时间，「AI Agent」这个词像雨后春笋一样冒出来，几乎所有的 AI 创业公司都把自己的产品冠以 Agent 之名，仿佛谁不用这个词就显得不够前沿。

但热闹归热闹，一个根本的问题却被掩盖在了喧嚣之下：到底什么是 AI Agent？它和我们已经用了好几年的 ChatGPT、Claude、文心一言，到底有什么本质区别？

如果你只是把 ChatGPT 当作一个聊天机器人，那你打开它，输入「帮我写一首关于春天的诗」，它吐出一首诗，你心满意足地关掉窗口——这是一个被动响应的过程：你问，它答，问答之间，机器人的「心智」归零，下一次对话从一张白纸开始。

但如果有一个 AI Agent 接到你的指令「帮我调研一下 2024 年新能源汽车市场前五大品牌的销量，并写一份投资分析报告」，它会自己做这些事情：

1. 把任务拆分成「找销量数据」「找品牌信息」「做对比分析」「写报告」四个子任务； 2. 调用搜索引擎 API 抓取最新的销量榜单； 3. 调用代码执行环境跑一段 Python 做数据可视化； 4. 把中间结果写进自己的记忆模块，方便后续引用； 5. 反复检查报告是否符合你的要求，如果发现数据过时，就再回到第 2 步重做； 6. 最终把 PDF 报告交到你手上，并问你：「需要我再调整哪部分？」

整个过程里，它不再是问答机，而是一个能感知环境、调用工具、自主决策、持续迭代的执行者。这就是 Agent 与 Chatbot 最大的区别：前者是「软件工程师」，后者是「问答引擎」。

在正式进入技术细节之前，我们先用一句话给 Agent 一个工作定义（working definition），后面整本书都会基于这一定义展开：

> AI Agent 是一个能够感知环境、形成目标、调用工具、并通过持续迭代来达成目标的人工智能系统。 它的核心不在于「能说什么」，而在于「能做成什么」。

这句话里有四个关键词：感知、目标、工具、迭代。我们会用整整一章来拆解它。

---

1.2　三种产品形态的工程分野：Chatbot、Copilot 与 Agent

在写代码之前，我们先把当前市面上与「大模型 + 对话」相关的产品形态梳理清楚。这一节是后面所有架构讨论的基石，因为只有先分清楚产品形态，才能搞清楚工程目标。

1.2.1　一个不太严谨但很好用的三分法

我把当下主流的大模型原生产品分成三类：

| 形态 | 英文名 | 核心定位 | 主导方 | 典型代表 | |------|--------|----------|--------|----------| | 问答机器人 | Chatbot | 被动响应单轮/多轮对话 | 用户主导 | 早期 ChatGPT、文心一言基础版 | | 副驾驶 | Copilot | 协助人类完成任务 | 人机协作 | GitHub Copilot、Cursor、Microsoft 365 Copilot | | 智能体 | Agent | 自主执行完整任务 | Agent 主导 | AutoGPT、Devin、Manus、Claude Computer Use |

这张表不是为了背诵，而是为了建立一个工程判断框架：当你设计一个产品时，先问自己——「我做的到底是 Chatbot、Copilot 还是 Agent？」三种形态对应的架构复杂度和工程挑战是完全不同的。

1.2.2　Chatbot 时代的工程范式

Chatbot 时代的工程范式可以概括为「提示词进来，文本出去」。整个系统大致是这样的：

```text [用户输入] → [Prompt 模板] → [LLM] → [后处理] → [返回文本] ```

工程上的核心关注点只有三个：

1. Prompt 工程：怎么写提示词让模型表现更好； 2. 上下文管理：怎么把多轮对话塞进有限的 context window； 3. 安全与对齐：怎么防止模型输出有害内容。

整个系统的「智能」基本由模型本身承担，工程师能做的事情相对有限。这也是为什么 Chatbot 时代的护城河往往在于「数据 + 微调 + 应用场景」。

1.2.3　Copilot 时代的工程范式

Copilot 比 Chatbot 多了一个关键能力：它能主动把内容塞进用户的编辑器、IDE、Office 文档里。比如 GitHub Copilot 不只是告诉你「这段代码应该这么写」，它直接把代码补全到你的光标位置；Microsoft 365 Copilot 不只是回答「这个 Excel 怎么算」，它直接在表格里生成公式并执行。

工程上的核心挑战变成了：

1. 编辑器集成：怎么把 LLM 的输出无缝对接到用户的编辑环境； 2. 实时性：Copilot 必须在用户敲键盘的节奏里给出建议，延迟不能超过几百毫秒； 3. 意图理解：怎么判断用户当前想要的是「补全」「解释」还是「重构」； 4. 可逆性：用户必须能轻松撤销 AI 的修改，否则信任建立不起来。

注意一个细节：Copilot 始终保持「人在回路中」（human-in-the-loop）。它不会自作主张地替你做决定，它更像是你的「结对编程伙伴」——你写一行，它帮你补全；你卡住了，它给你建议。

1.2.4　Agent 时代的工程范式

到了 Agent 时代，工程范式发生了根本性的跃迁。系统不再是一个「输入-输出」的黑盒，而是一个持续运行的执行循环：

```text ┌─────────────────────────┐ │ │ ▼ │ [目标] → [感知环境] → [思考决策] → [执行行动] → [观察结果] → ... → [目标达成] │ │ └─ 工具调用 ─┘ │ ▼ [记忆模块] ```

工程上的关注点爆炸式增长：

1. 任务规划：怎么把一个模糊的目标拆解成可执行的子任务； 2. 工具管理：Agent 可以调用成百上千个工具，怎么注册、选择、组合； 3. 记忆系统：短期上下文不够用，需要长期记忆、向量检索、知识图谱； 4. 执行环境：Agent 的「行动」发生在真实世界里，需要沙箱、权限控制、回滚机制； 5. 错误恢复：Agent 跑一半失败了怎么办，怎么重试、回滚、降级； 6. 可观测性：Agent 的决策链路必须可追溯，否则出了问题没人能 debug； 7. 成本控制：一个复杂任务可能跑几十上百次 LLM 调用，钱烧起来比想象中快得多。

这就是为什么「Agent 工程」会成为一个独立的学科。它不是 Chatbot 的简单升级，而是一套全新的软件工程范式。

1.2.5　一个具体的对比案例

为了让你更直观地感受三种形态的差异，我们用一个具体场景——「我想把公司官网的英文版翻译成中文版」——来对比三种产品的不同表现：

场景 A：用 Chatbot

你：帮我把 https://example.com 翻译成中文。 ChatGPT：抱歉，我无法访问外部链接。你可以粘贴网页内容给我。 你：（手动复制粘贴 5000 字） ChatGPT：以下是翻译结果……（翻译了一半 token 用完了） 你：（继续粘贴后半部分） ChatGPT：以下是后半部分的翻译…… 你：（手动拼接）……

整个过程你做了 5 次手动操作，跨了 3 个工具，ChatGPT 完全没有主动权。

场景 B：用 Copilot（以 Cursor 为例）

你在 Cursor 里打开英文 HTML 文件，光标停在第一行，按下 Cmd+K，输入「翻译成中文」。 Cursor 把翻译结果以 diff 的形式呈现给你，你可以逐段接受或拒绝。 如果只翻译了某一段，你可以选中那一段再翻译。 如果对某句话不满意，你可以圈出来让 AI 重新翻译。

整个过程你仍然在主导，但 AI 帮你完成了最累的「初稿」工作。

场景 C：用 Agent

你：把 https://example.com 的英文版翻译成中文，保持原有的 HTML 结构和图片资源不变，最后生成一个可以在浏览器直接打开的中文版文件。

Agent 收到任务后，自己做了这些事情：

1. 调用 `web_fetch` 工具抓取网页内容； 2. 解析 HTML 结构，识别需要翻译的文本节点； 3. 调用 `translate` 工具逐段翻译，同时保留 HTML 标签； 4. 调用 `image_caption` 工具为图片生成中文 alt 文本； 5. 把翻译结果重新组装成 HTML； 6. 启动一个本地 HTTP server，截图给你预览； 7. 问你「翻译风格是偏正式还是偏口语？如果有风格指南，请贴上来」； 8. 根据你的反馈重新调整部分段落的语气； 9. 把最终的 HTML 文件保存到 `output/index.html`。

整个过程你只在第 6 步和第 7 步做了两次确认，剩下 90% 的工作都是 Agent 自主完成的。

这就是 Chatbot、Copilot、Agent 在工程上的本质差异：主导权从「人」逐步转移到了「机器」，工程复杂度也呈指数级上升。本书后面所有章节，本质上都是在解决 Agent 时代的工程难题。

---

1.3　现代 Agent 的四大核心特征

光说「Agent 能自主执行任务」还不够，我们需要更精确地刻画它的能力边界。我把现代 LLM 驱动的 Agent 归纳为四大核心特征：自主性（Autonomy）、目标性（Goal-orientation）、工具使用（Tool Use）、持续迭代（Continuous Iteration）。这四个特征缺一不可，缺了任何一个，这个系统就不是一个完整的 Agent。

1.3.1　自主性（Autonomy）

自主性指的是 Agent 能够在没有人类实时干预的情况下，独立决定「下一步做什么」。这听起来简单，但实际上包含三个层次：

• **执行自主**：Agent 能够调用工具完成具体动作，而不仅仅吐出文本；
• **决策自主**：Agent 能够选择走哪条路径，而不是沿着预设的脚本执行；
• **目标自主**（最激进的形式）：Agent 能够自己设定子目标来达成最终目标。

来看一个例子。同样是「帮我订明天下午三点北京到上海的机票」：

• **没有自主性的脚本**：触发关键词 → 调用航班 API → 返回结果。这是一个死板的 chatbot。
• **有执行自主的 Copilot**：用户说「订机票」→ AI 调用 API → 给出结果 → 用户选择航班 → AI 完成支付。这还是人在每一步决策。
• **有决策自主的 Agent**：用户说「订明天下午三点北京到上海的机票」→ Agent 自己查航班、自己比较价格、自己选择性价比最高的、自己用你的账号下单、自己把行程加到日历里。整个过程你只需要最后确认一下「是否支付」。

真正的自主性还体现在异常处理上。如果航班 API 返回「该航班已售罄」，一个有自主性的 Agent 会自动换一班，而不是傻傻地把错误抛回给用户。它可能会这样思考：

> 「下午三点的直飞没了……要不要看看三点半的？或者高铁？……用户没指定具体航班类型，我倾向于换高铁，因为上海高铁只要 4.5 小时……但高铁需要单独确认用户的座位偏好……」

这种「自主决策 + 自主行动」的能力，是 Agent 区别于 Chatbot 的第一道分水岭。

1.3.2　目标性（Goal-orientation）

目标性指的是 Agent 的所有行为都指向某个明确的目标。这个目标可以是用户明确给定的，也可以是 Agent 自己根据高层目标分解出来的。

关键在于：目标必须是「可验证的」，而不是「可描述的」。

举个例子：

• ❌ 错误的目标：「帮我做一个漂亮的网站」（漂亮无法验证）
• ✅ 正确的目标：「帮我做一个网站，包含首页、产品页、联系我们三个页面，使用 Tailwind CSS，部署到 Vercel，访问速度不超过 2 秒」

一个合格的 Agent 在接到目标后，应该能够：

1. 把模糊目标分解为可验证的子目标：把「漂亮的网站」拆成「3 个页面 + Tailwind + Lighthouse 分数 > 90」； 2. 为每个子目标制定完成标准：「Lighthouse 分数 > 90」是可量化的； 3. 自我评估是否达成目标：Agent 在交付前自己跑一遍 Lighthouse，分数不够就回去优化； 4. 在无法达成时主动沟通：如果技术栈有冲突，主动问用户「是要放弃 Lighthouse 分数，还是放弃 Tailwind」。

这就是目标性与「指令跟随」（instruction following）的区别。指令跟随是「你说什么我做什么」，目标性是「你给方向，我想办法达成」。

1.3.3　工具使用（Tool Use）

工具使用是 Agent 能够「做事」的基础。一个没有工具的 LLM 只能「说」，不能「做」。但现实世界的任务几乎都需要与外部世界交互：查数据库、调 API、写文件、发邮件、操作浏览器……

我们可以把 Agent 的工具分成几类：

| 工具类别 | 典型例子 | 作用 | |----------|----------|------| | 信息获取 | `web_search`, `web_fetch`, `database_query` | 扩展 Agent 的「感知范围」 | | 计算执行 | `python_repl`, `shell_exec`, `sandbox` | 让 Agent 跑代码、做计算 | | 内容生成 | `image_gen`, `audio_gen`, `pdf_export` | 把结果变成可交付物 | | 系统操作 | `file_write`, `email_send`, `calendar_add` | 与现实世界交互 | | 复合工具 | `browser_use`, `computer_use`, `code_interpreter` | 上面几类的组合 |

真正有挑战的不是「让 Agent 能调工具」，而是「让 Agent 在合适的时候选择合适的工具」。这就是 Tool Selection（工具选择）问题，也是 Agent 工程的核心难点之一。

我们用一个具体的例子来说明。假设 Agent 接到任务「分析一下最近三个月比特币的价格走势」：

```python

一个理想的工具定义示例

tools = [ { "name": "fetch_btc_price", "description": "获取比特币的历史价格数据。输入起始日期和结束日期，返回每日收盘价。", "parameters": { "start_date": "string, ISO 格式", "end_date": "string, ISO 格式" } }, { "name": "run_python", "description": "在沙箱中执行 Python 代码，用于数据分析和可视化。", "parameters": { "code": "string, 要执行的 Python 代码" } }, { "name": "write_report", "description": "把分析结果写成 Markdown 报告。", "parameters": { "title": "string, 报告标题", "content": "string, 报告正文（Markdown 格式）" } } ] ```

Agent 的思考过程可能是这样的：

> 任务：分析最近三个月比特币价格走势。 > > 思考： > 1. 我需要获取最近三个月的价格数据 → 调用 `fetch_btc_price` > 2. 我需要算一些统计指标，比如均值、最大回撤、波动率 → 调用 `run_python` 跑 pandas > 3. 我需要画图，更直观 → 调用 `run_python` 用 matplotlib > 4. 我需要把分析写成报告 → 调用 `write_report` > > 计划确定，开始执行。

注意，整个过程里 Agent 在「思考」和「行动」之间反复切换。这种「思考-行动-观察」的循环（ReAct 模式）就是 Agent 工具使用的标准范式。我们在第 4 章会详细讲 ReAct，这里先建立直觉。

1.3.4　持续迭代（Continuous Iteration）

持续迭代是 Agent 区别于「一次性脚本」的关键。一个一次性的脚本只能跑一次，跑完就完了；而 Agent 必须能够根据中间结果不断调整自己的策略。

持续迭代包含三个层面：

1. 自我反思（Self-reflection）：Agent 在执行完一步后，回头审视「这一步做得对不对？有没有更好的方式？」。 2. 错误恢复（Error Recovery）：当某一步失败时，Agent 不是直接放弃，而是尝试别的路径。 3. 渐进式交付（Progressive Delivery）：Agent 不一定要等到完美才交付，可以先交一个能用的版本，再根据反馈逐步完善。

来看一个例子。Agent 接到任务「帮我写一个贪吃蛇游戏」：

• **第一次尝试**：用 Pygame 写了一个版本，