第一章 引言：为什么是 Agent 时代¶
导读¶
本章回答三个问题：
- 什么是 AI Agent？它的边界在哪、和传统 Workflow / Copilot 怎么区分？
- Agent 在 LLM 应用演化中处于什么位置？它解决了什么、又留下什么新问题？
- 学习这本书的合理预期是什么？四周计划能把你带到哪？
读完本章你不会立刻能"调起一个 Agent"——那个能力要等到第六章 ReAct 和第七章 Function Calling 跑通之后才有。但读完本章你应该能看懂任何一篇 Agent 相关技术新闻中出现的名词——ReAct、Function Calling、MCP、多 Agent、规划与反思——并能在心里给它们排好顺序，知道哪个概念在哪个章节展开。本章是全书 17 章的"目录页"，后面每一章都对应这里提到的一个概念。如果你已经熟悉 LLM 应用基础（读过姊妹书或做过 ChatGPT/RAG 项目），可以直接跳到 1.2 开始读；如果你完全没接触过 LLM 工程，建议从 1.1 三波浪潮开始建立时间线直觉。
1.1 从 ChatGPT 到 Agent：LLM 应用的三波浪潮¶
要理解 Agent，最好的方法不是去看它的定义，而是看它从哪里来。LLM 落地到工程产品中，已经走过了两波浪潮，目前正进入第三波。每一波浪潮都解决了上一波遗留的核心问题，同时留下新的工程债，把产业往前推一步。
第一波：对话（2022-2023）¶
2022 年 11 月 ChatGPT 发布，随后 Claude、Gemini、文心、通义、Kimi 等陆续出现。这一波的产品形态是"对话框"：用户输入一段文字，模型回复一段文字，背后是一个无状态的 LLM 推理调用。整个系统最简单的实现只需要 20 行代码——OpenAI SDK 加一个网页表单。
第一波解决的问题是：LLM 本身怎么用？ 答案是把它包装成一个会聊天的网页。在 ChatGPT 之前，GPT-3 已经存在两年，但只有少数研究者通过 API 调用，且 GPT-3 的 prompt 风格是"few-shot 示例 + 续写"，对普通用户极不友好；ChatGPT 把它包装成对话，让任何人都能用自然语言交互。这一步看起来只是产品工程，但其实是 LLM 走向大众化的关键一步。
第一波留下的新问题是：模型知识截止、不会算术、不能上网。 你问它"今天的天气"它会瞎编，你问它"7432 × 9128"它会说错，你问它"我们公司最新的退款政策"它根本不知道。从工程师视角看，这些不是"模型能力问题"而是"系统设计问题"——纯靠模型本身无法解决，必须把模型和外部世界连起来。这种"连接外部世界"的工程思路，直接催生了第二波。
第二波：RAG（2023）¶
2023 年开始流行 RAG（Retrieval-Augmented Generation，检索增强生成）。RAG 的核心思路是：模型答不上来，那就先去外部知识库找一段相关文档，再把文档塞进 prompt 里让模型基于文档回答。Perplexity、Bing Chat、各种企业内部知识库机器人、LangChain 早期教程，基本都建立在 RAG 之上。RAG 把"信息检索"这个老问题（搜索引擎做了 20 年）和"自然语言生成"这个新问题（LLM 出现后才有的）拼在一起，用 LLM 把检索结果改写成答案。
第二波解决的问题是：让 LLM 能基于外部数据回答。 不再依赖模型预训练时见过的内容，而是基于"现在检索到"的内容回答，从而解决"知识截止"和"私有数据"两个问题。一个企业内部的客服机器人，可以基于公司内部文档（退款政策、产品手册、HR 制度）回答，而不需要专门训练一个模型——这件事在 RAG 出现之前几乎不可能做到。
第二波留下的新问题是：只能检索、不能行动。 RAG 本质上是"搜索 + 总结"——它能告诉你文档里写了什么，但不能替你执行任何操作。你问它"帮我给客户发封邮件道歉"，它会把邮件草稿写好，但发不出去；你问它"帮我重启一下线上那台卡死的机器"，它根本碰不到那台机器；你问它"把这周的销售数据整理成表格发我"，它能写出来该做什么，但执行不了。RAG 让 LLM"看得见"外部世界，但没有让它"动得了"——这种"看得见但动不了"的局限，正是第三波要突破的。
第三波：Agent（2024+）¶
2024 年起，行业重心转向 Agent。Devin（号称第一个 AI 软件工程师）、OpenAI Operator（能操作浏览器的 Agent）、Cursor（编程 Agent）、各种"客服 Agent""数据 Agent""研究 Agent"集中爆发。Agent 的核心特征是：LLM 不再只输出文本，而是输出"调用什么工具"的决策，并观察工具结果，循环多步直到完成一个真实任务。 这种"决策 + 行动 + 观察 + 再决策"的闭环，正是控制论里的反馈控制（feedback control）思想在 LLM 时代的复现。
第三波解决的问题是：让 LLM 能行动。 把"模型生成文本"升级为"模型生成行动 + 观察结果 + 再生成行动"的循环，从而让 LLM 能调用 API、操作数据库、控制浏览器、写代码并执行。从产品视角看，Agent 让 LLM 从"内容生成器"升级成"任务执行器"——前者卖的是 token，后者卖的是"完成的任务"。这种商业模式的变化比技术变化更根本。
第三波会留下什么新问题？目前看至少有三个：可控性差（循环可能跑飞、step 爆炸、误调工具）、成本爆炸（多步 × 大模型 token，长上下文问题让成本随步数线性上升）、评测困难（任务成功率怎么定义、子目标验证、副作用作弊）。这些问题正是本书后面章节要展开讨论的——Agent 框架、记忆系统、评测与安全，都是为了应对这三波浪潮结束后留下的工程债。
一句话总结这三波：对话让 LLM 能说，RAG 让 LLM 能查，Agent 让 LLM 能做。 注意这三波不是替代关系——今天的生产系统常常同时用三波的技术：一个客服 Agent 内部可能有对话界面（第一波）、有 RAG 检索（第二波）、有 agent loop（第三波），三者协同工作。
1.2 什么是 AI Agent¶
Agent 这个词在 AI 学界已经用了几十年（罗素《人工智能：一种现代方法》里就大量出现），但 2024 年流行起来的"AI Agent"有更具体的含义。学界传统意义上的 agent 强调"自主感知环境并采取行动"——扫地机器人、游戏 AI、自动驾驶系统都属于这个范畴。而 2024 年工程语境下的"AI Agent"特指**以 LLM 为决策核心的 agent**——和传统 RL agent 的本质区别在于决策器是 LLM 而不是策略网络。本书采用一个工程导向的最简定义：
Agent = LLM + 工具 + 循环。
具体说，一个 Agent 系统包含三个不可缺少的要素：
- LLM 作为决策器：每一步由 LLM 决定"接下来调用什么工具、传什么参数、还是直接回复用户"。LLM 的作用是把"用户意图"和"当前观察"映射成"下一步行动"。
- 工具作为能力扩展：通过 Function Calling（函数调用）暴露给 LLM 一组可调用的函数，比如查天气、查数据库、发邮件、跑代码。工具是 LLM 触达外部世界的"手脚"。
- 循环作为多步执行机制：LLM 调工具 → 工具返回结果 → LLM 看到结果再决定下一步 → 直到任务完成或达到步数上限。循环让 Agent 能处理"看一步做一步"的多步任务。
为什么这三者一个都不能少？
- 没有 LLM，系统退化成传统 Workflow——流程是写死的，决策权在工程师手里，遇到分支只能 if/else。这种系统在"分支数有限"的场景下能用，但一旦分支多到无法枚举（比如"帮用户修复任意 bug"——bug 的种类和修复路径都无法事先列举），就完全没法用。LLM 的价值在于把"分支决策"从代码里挪出来交给模型，让系统具备处理未预见情况的能力。
- 没有工具，LLM 只能"说话"——它能告诉你"我应该去查天气"，但它没法真的去查；它能写出 SQL，但没法执行 SQL；它能给出"应该给客户发这封邮件"的草稿，但发不出去。这种系统在演示里很惊艳，但在生产里没有任何"对外界产生影响"的能力。工具是让 LLM 从"语言模型"变成"行动模型"的关键。
- 没有循环，系统退化成单轮 Function Calling——LLM 调一次工具就结束，不能根据工具结果再调整下一步。这种系统适合"问一句就答一句"的简单任务，但遇到"先查用户最近订单 → 再查退款政策 → 再生成道歉邮件 → 再发出去"这种多步任务，单轮调用根本不够。循环是让 Agent 能"看一步走一步"的关键。
用一个更紧凑的定义：Agent 是一个以 LLM 为决策核心、通过工具调用与外部世界交互、并以循环方式完成多步任务的系统。
注意这个定义里没有出现的词：自主（autonomous）、智能（intelligent）、规划（planning）、反思（reflection）。这些是高级 Agent 才有的特征，不是 Agent 的必要条件。一个最朴素的 Agent 就只是"LLM 调工具 + 循环"，至于调得多聪明、能不能规划、会不会反思，是后续章节的话题。把"基础 Agent"和"高级 Agent"分开看，有助于在工程中保持克制——不要一上来就追求完全自主，先让最小循环能稳定跑。
1.3 Agent vs Workflow vs Copilot¶
Agent 这个概念在工程语境里经常和 Workflow、Copilot、Chatbot 混在一起。市面上每家公司都说自己在做 Agent，但仔细一看：有的是 Workflow 套了层 Agent 皮，有的是 Copilot 起个 Agent 名，有的是真 Agent。本节用一张表把它们分清：
| 概念 | 决策主体 | 流程 | 例子 |
|---|---|---|---|
| Chatbot | LLM | 无流程 | 早期 ChatGPT |
| Workflow | 人预设 | 固定 | n8n / Zapier |
| Copilot | 人主导 | 半固定 | GitHub Copilot |
| Agent | LLM 主导 | 动态 | Devin / Operator |
理解这张表的关键是看三个维度：
决策主体是谁？ Workflow 是工程师在部署前写死了每一步——节点 A → 节点 B → 节点 C，运行时不会变；Copilot 是用户在交互中决定每一步——用户写代码、AI 补全，决策权仍在人；Agent 是 LLM 在运行中动态决定下一步——人只给一个目标，怎么达成由模型决定。这个差异决定了三类系统的灵活性上限：Workflow 灵活性等于工程师想象力，Copilot 灵活性等于用户操作能力，Agent 灵活性等于 LLM 推理能力。
流程是否动态？ Workflow 完全静态（DAG 在部署时就定好），Copilot 半动态（用户人脑导航，AI 在每一步辅助），Agent 完全动态（LLM 根据每步观察结果决定下一步走哪，连路径都无法事先预测）。这意味着：Workflow 可以画出来给产品经理看，Copilot 可以让产品经理猜大概路径，Agent 路径只有跑起来才知道——这种"路径不可预测"是 Agent 工程化的最大难点。
能力边界在哪？ Chatbot 只输出文本，Workflow 只在预设节点间搬运数据，Copilot 在用户主导下做局部任务（一段代码、一封邮件草稿），Agent 自主完成端到端任务（从"修这个 bug"到"提交 PR"全流程）。
注意：这四种形态不是替代关系，是互补关系。 一个真实的客服系统可能是这样：Chatbot 负责闲聊 → Workflow 负责走工单流（创建工单、分派、SLA 倒计时）→ Copilot 在客服人员处理复杂工单时辅助（生成回复草稿、查找相似工单）→ Agent 在工单需要调用多个系统时自主完成（查订单、查库存、走退款流程、发通知）。生产环境里很少见到"纯 Agent"，更多是四种形态的组合——把不同形态放在最合适的环节，比追求"全 Agent 化"更现实。
工程师做选型时的判断标准：如果分支可枚举，用 Workflow；如果人在场决策，用 Copilot；如果分支不可枚举且无人值守，才用 Agent。 用 Agent 去做 Workflow 能做的事，是过度工程——你花了一周搭的 Agent，可能不如 50 行 n8n 流程稳定；用 Workflow 去做 Agent 才能做的事，是死路一条——你枚举不完的分支会让 Workflow 越来越臃肿，最后维护成本比 Agent 还高。选型不是越先进越好，是匹配场景才好。
1.4 软件栈视角¶
理解 Agent 在整个 AI 工程生态里的位置，最有用的工具还是"分层心智模型"。我们复用姊妹书《LLM 从 0 到 1》里的 5 层 AI 软件栈——这套分层在 LLM 时代之前就已经成型，Agent 的出现只是把其中"应用层"和"框架层"的内容更新了：
- 应用层：用户接触的产品形态——Cursor（编程 Agent）、Operator（浏览器 Agent）、客服 Agent、Devin（通用软件工程 Agent）。这一层的产品直接面向终端用户，决定用户感知到的"Agent 能做什么"。
- Agent 框架层：开发者用来组装 Agent 的库与协议——LangGraph（基于图的 Agent 编排）、CrewAI（多 Agent 角色协作）、AutoGen（微软的多 Agent 对话框架）、OpenAI Swarm（OpenAI 的轻量级多 Agent handoff）、MCP（Anthropic 推出的工具调用协议）。这一层是本书重点。
- 模型层：GPT-4o / Claude / Llama-3 / Qwen / DeepSeek 等模型权重，以及它们的训练 / 对齐方法。本书必要时下钻到这一层（比如讲 Function Calling 时会涉及模型如何被训练来调工具），但不深入训练细节。
- 运行时与编译层：CUDA、TensorRT、vLLM、Triton、FlashAttention——把模型高效跑到硬件上。本书基本不涉及，但当讲到 Agent 部署的延迟 / 吞吐权衡时会提到。
- 硬件层：GPU / TPU / NPU / 网络 / 存储。本书不涉及，但工程师应该知道"显存够不够"是部署 Agent 时绕不开的问题。
本书覆盖应用层与 Agent 框架层，必要时下钻到模型层。 这意味着：本书不会讲 CUDA kernel 怎么写、FlashAttention 的 IO 复杂度怎么算、vLLM 的 PagedAttention 实现——这些是姊妹书的主题。本书讲的是：站在应用层往下看，怎么用 Agent 框架把模型、工具、记忆、规划拼成一个能跑的 Agent。这种"自上而下"的视角，决定了本书会花大量篇幅讲框架之间的对比、协议（如 MCP）的设计、记忆系统的选型——这些是工程师真正需要做的决策。
为什么 Agent 必须放在应用层和框架层之间，而不是直接搭在模型层上？因为如果你直接用 OpenAI SDK 调 GPT-4o 写 Agent，你会发现很快就需要重新实现循环控制、工具调用解析、错误重试、上下文压缩、记忆持久化、多 Agent 协作——而这些正是 Agent 框架层帮你封装好的东西。Agent 框架层的存在意义，就是让你不用每次都从零写一个 agent loop。理解了这一点，你就会明白为什么 2024 年一夜之间冒出几十个 Agent 框架——大家都在抢"框架层"这个位置，因为谁占了这层，谁就掌握了"Agent 时代的基础设施"。
理解分层的另一个工程价值是**故障下钻**：当你的 Agent 输出错误结果时，按层排查：是应用层的 prompt 设计问题？是 Agent 框架层的循环控制问题？是模型层的模型能力不够？是运行时层的 token 截断？是硬件层的 OOM？每一层都有不同的排查工具——应用层用 prompt trace，框架层用 LangSmith / Langfuse 这类可观测平台，模型层用 eval set，运行时层用 nvidia-smi，硬件层用 dmesg。本书第十三章"评测与安全"会专门讲这种分层调试方法。
1.5 Agent 工程的挑战¶
Agent 听起来很美，但工程上落地时四个挑战立刻浮现：
挑战一：可控性¶
Agent 的核心是循环，但循环本质上是不可控的。一个常见失败模式是"step 爆炸"：Agent 在某一步调用了工具 A，得到结果不理想，于是它换种参数再调一次 A，又不行，再调一次……循环可以无限进行下去。还有一种失败模式是"工具错配"：Agent 该调工具 A 却调了 B，B 返回错误，Agent 看到 B 的错误又去调 C，C 又触发别的副作用。
可控性问题的本质是：LLM 的决策不是确定性算法，是概率采样。同样一个输入，Agent 可能走出完全不同的路径，其中一些路径会陷入死循环、调用不必要的工具、甚至误调有副作用的工具（比如删数据库）。
工程上应对可控性的方法包括：步数上限（硬性截断）、人工审核（关键步骤暂停等用户确认）、沙箱执行（工具调用只影响隔离环境）、状态机约束（限制 Agent 只能在某些状态间转移）。这些都会在后续章节展开。
挑战二：成本¶
Agent 是多步循环，每一步都要调一次 LLM，每次调用都要消耗 token。一个 Agent 完成一个任务可能调 10 次 LLM，每次输入几千 token（包括完整对话历史 + 工具描述 + 工具结果），输出几百 token——一次任务可能烧掉几万 token，是单轮对话的几十倍。
更严重的是**长上下文问题**：Agent 跑得越久，对话历史越长，每一步的输入 token 就越多，成本随步数线性甚至二次上升。一个跑 50 步的 Agent，最后几步的输入可能已经几万 token，单步成本是第一步的十倍以上。
应对成本问题的方法包括：上下文压缩（用摘要替换旧消息）、记忆外置（把不需要每步都看的内容存到外部存储）、模型路由（简单步骤用便宜模型、复杂步骤用贵模型）、缓存（相同输入直接复用上一次结果）。本书第九章"记忆与上下文工程"会专门讨论。
挑战三：评测¶
单轮 LLM 调用评测已经够难——同一问题模型可能给出不同答案，BLEU/ROUGE 这种 n-gram 指标又不能反映语义。Agent 评测更难：一个任务是"帮我把这个 CSV 文件清洗后导入数据库"，怎么算成功？是数据库里有数据就算？还是数据正确才算？还是不仅正确还要走的步数少、花的 token 少？
任务成功率（task success rate）是 Agent 评测最常用的指标，但**定义任务成功本身就需要工程努力**：需要把任务拆成可验证的子目标、需要让验证逻辑能从环境状态读出结果、需要避免 Agent 通过副作用作弊（比如直接改数据库表让它"看起来对了"）。
本书第十三章会讨论 Agent 评测的几种方法：基于规则验证（直接检查环境状态）、基于 LLM 评审（用另一个 LLM 当裁判）、基于人工评估（成本高但可靠）。
挑战四：安全¶
Agent 能调用工具，工具能产生真实副作用——删数据、发邮件、转账、部署代码、操作浏览器。这意味着 Agent 的安全风险比纯对话 LLM 高一个数量级。
主要风险包括：
- 工具滥用：Agent 调用了不该调用的工具（比如只是查天气却顺手把数据库删了）；
- Prompt Injection：外部内容（比如被检索到的网页）里嵌入恶意指令，劫持 Agent 行为；
- 数据泄露：Agent 在工具调用时把私有数据传给外部 API；
- 权限放大：Agent 持有的工具权限比实际需要的大，被攻击时危害更大。
工程上的应对是**纵深防御**：沙箱执行 + 最小权限 + 人审关键操作 + 输入输出过滤 + 审计日志。本书第十三章会展开。
这四个挑战——可控性、成本、评测、安全——贯穿全书。前面章节讲怎么搭 Agent，第十三章讲怎么让它跑得稳、跑得安全。
1.6 学习路径建议¶
如果你是工程师刚进入 Agent 领域，推荐四周学习路径。这套路径背后的逻辑是：先建词汇（让你看懂术语）→ 再建肌肉记忆（让你能跑通最小循环）→ 再建协议直觉（让你理解为什么需要 MCP）→ 最后选方向（让你在某个垂直领域成为专家）。每一周都对应本书某些章节，可以对照阅读。
第一周：建词汇表（读完本书前 5 章）¶
不要急着写代码。第一周的目标是把"ReAct、Function Calling、MCP、多 Agent、规划、反思、记忆、RAG、Tool Use"这些名词在自己脑子里建立起映射——每个名词指什么、解决什么问题、属于软件栈哪一层、和相邻概念怎么区分。本书前 5 章（引言 + LLM 速通 + Prompt 工程 + 推理 API + RAG 基础）就是为你建这张词汇表写的。读这一周时不要纠结代码片段，重点是看懂每章的"小结"和"工程实战要点"——这两节是浓缩的判断力。如果某章的小结你看不懂，回去翻该章正文；如果某章的小结你看完无感，说明你还没建立对应的工程直觉，建议结合自己工作中的场景思考一遍。
第二周：跑通 ReAct 最小循环¶
用 OpenAI SDK 或 LangChain 写一个能跑通 ReAct 循环的最小 Agent：一个 LLM、两三个工具（比如查天气 + 查股票 + 算术）、一个最多 5 步的循环。亲自让它跑起来，看它怎么决定调哪个工具、怎么把工具结果塞回 prompt、怎么在步数上限内给出答案。这一步的关键不是做出有用的 Agent，而是建立"Agent 跑起来到底长什么样"的肌肉记忆。本书第六章 ReAct 和第七章 Function Calling 会给出可复制的代码骨架。重点观察失败模式：故意问它无法回答的问题，看它怎么在步数上限内结束；故意给它返回错误的工具结果，看它怎么误判——这种"故意制造故障"的练习，比让它跑通更有价值。
第三周：跑通 MCP server¶
MCP（Model Context Protocol）是 Anthropic 提出的工具协议，正在成为 Agent 接工具的事实标准——OpenAI、Cursor、Zed 等公司陆续宣布支持。第三周的目标是用 MCP SDK 写一个最简单的 server（暴露一两个工具，比如查本地文件、跑 SQL 查询），然后让一个 MCP client 调用它。这一步的关键是理解"工具协议"为什么需要存在——为什么不直接用 OpenAI Function Calling，而要走 MCP？答案是：Function Calling 是模型层的接口（描述工具的 schema），MCP 是协议层的接口（怎么发现工具、怎么传输调用、怎么处理流式结果）。两者层次不同，本书第十章会展开。
第四周：选细分方向深入¶
Agent 领域已经大到无法全栈精通，第四周选一个方向深入。下面四个方向是当前工程上最活跃的：
- 代码 Agent：读 Cursor、Aider、Continue 的开源代码，理解代码库索引、diff 应用、测试驱动闭环、长上下文管理。本书第十四章会剖析 Cursor 的真实架构。
- 浏览器 Agent：读 Browser Use、WebVoyager、Skyvern 的源码，理解 DOM 操作、视觉定位、页面等待、iframe 处理。这一方向的安全风险最高（要登录账号、操作真实网站）。
- 多 Agent：读 CrewAI、AutoGen、Swarm 的源码，理解 handoff、角色协调、消息总线、共享状态。这一方向最容易过度设计——能用单 Agent 解决的别上多 Agent。
- 评测：读 SWE-bench、WebArena、GAIA 的论文与代码，理解任务设计、环境搭建、成功率统计、防作弊。这一方向最被低估，但工程价值最高——没有评测，就没有改进的反馈信号。
选定方向后，本书相应章节会给出进一步阅读路径。不要试图把所有方向都学到能写框架的程度——那是 6 个月的工作量，而你的真实目标只是"在团队里成为那个懂 Agent 的人"。能在一个方向上做出有用的东西，比在四个方向上都跑通 demo 更有工程价值。
工程实战要点¶
- Agent 不是更聪明的 LLM，是 LLM + 工具循环：把"模型变强"和"系统变全"分开，前者靠研究、后者靠工程；
- 先 Function Calling，再 ReAct，最后才上多 Agent：跳级会让简单问题复杂化；
- 步数上限必设：没有上限的 agent loop 一定会烧光你的预算；
- 沙箱 + 人审是底线：任何有真实副作用的工具调用，要么在沙箱里跑，要么等人审；
- 评测要从任务成功率入手：不要纠结 BLEU 这种 n-gram 指标，直接定义"任务完成/未完成"。
小结¶
- LLM 应用走过三波浪潮：对话（2022-2023）→ RAG（2023）→ Agent（2024+），每波解决上一波的问题又留下新挑战；
- Agent = LLM + 工具 + 循环，三者缺一不可；
- Agent 与 Workflow、Copilot、Chatbot 的差异在于"决策主体"和"流程是否动态"；
- 在 5 层 AI 软件栈里，Agent 位于应用层与模型层之间的"Agent 框架层"；
- Agent 工程的四大挑战：可控性、成本、评测、安全；
- 学习路径：建词汇表 → 跑通 ReAct → 跑通 MCP → 选细分方向深入。
代码片段：最小 Agent 骨架¶
下面这段代码是用 OpenAI SDK 写的最小 Agent 骨架，包含工具定义、agent loop、步数上限、工具执行——约 30 行。读完前 5 章后你应该能看懂每一行。
from openai import OpenAI
client = OpenAI()
tools = [{
"type": "function",
"function": {
"name": "get_weather",
"description": "查询指定城市天气",
"parameters": {
"type": "object",
"properties": {"city": {"type": "string"}},
"required": ["city"]
}
}
}]
def execute_tool(call):
if call.function.name == "get_weather":
import json
args = json.loads(call.function.arguments)
return f"{args['city']} 今日 22°C 多云"
return "unknown tool"
def agent_loop(question, max_steps=5):
messages = [{"role": "user", "content": question}]
for step in range(max_steps):
resp = client.chat.completions.create(
model="gpt-4o", messages=messages, tools=tools
)
msg = resp.choices[0].message
messages.append(msg)
if not msg.tool_calls:
return msg.content
for call in msg.tool_calls:
result = execute_tool(call)
messages.append({"role": "tool", "tool_call_id": call.id, "content": result})
return "达到最大步数"
这段代码包含了 Agent 的全部三要素：client.chat.completions.create 是 LLM 决策器，tools 列表是工具能力扩展，for step in range(max_steps) 是循环。第六章和第七章会基于这个骨架展开。
练习题¶
- 用一句话解释 Agent 与单轮 LLM 调用的核心区别。
- 列出 LLM 应用的三波浪潮及其代表产品。
- Agent 的三要素是什么？为什么缺一不可？
- Agent vs Workflow vs Copilot 的差异？
- Agent 工程的四大挑战是什么？
- 为什么"步数上限必设"？给一个失败场景。