本章内容
- 了解什么是 LLM Agent，以及何时使用
- LLM Agent 的组成部分
- 从零开始构建一个 Agent
2023 年大型语言模型（LLM）的兴起，以及 2024 年检索增强生成（RAG）技术的进步，让人工智能领域发生了重大变化。现在，我们又站在新一波创新的中心：Agent 的爆发式兴起。LLM Agent 是一种系统，它把大型语言模型作为推理引擎，自主做出决策并执行动作，以达成预定目标。本质上，LLM 就是 Agent 的“大脑”。
你也许对 LangGraph、CrewAI、AutoGen、OpenAI Agents、Google ADK（Agent Development Kit）等框架并不陌生。不过，我们不会一上来就用这些框架，而是教你从零开始构建 Agent。这些框架当然强大，也会最终成为你的工具箱成员；但真正的创新和解决问题的能力，来自对核心原理的深刻理解。本书希望通过 Python 代码，让你直接体验并内化 LLM Agent 的底层工作方式。这样的“从零开始”并不只是获取知识，更是在为复杂问题建立直觉，并在面对任何技术挑战时拥有不动摇的信心。有了这套扎实的基础，你能看穿任何框架的内部机制，甚至成为创造前所未有新型 LLM Agent 的人。
我们将先构建最基础形态的 LLM Agent，然后逐步加入记忆、规划、反思等模块，让它越来越聪明。在演进完单体 Agent 后，我们会搭建多智能体系统（MAS），让多个 Agent 协同工作。最后，我们将讨论 LLM Agent 开发中至关重要的监控与评估。
开工吧。
1.1 理解 LLM Agent
本书的核心主题——LLM Agent究竟指什么？基于前面对 Agent 的定义，LLM Agent 是一种系统，它把大型语言模型作为推理引擎，自主做决策、执行动作，以实现指定目标。本质上，LLM 是 Agent 的“大脑”。但 LLM 到底是什么，它如何胜任这个角色？而一个 LLM Agent 又由哪些部分构成？
1.1.1 什么是 LLM？
LLM（Large Language Model，大型语言模型）指在海量数据上训练得到的语言模型，通常覆盖互联网上几乎所有可公开获取的文本。尽管现代 LLM 已经演化出多模态能力——可同时处理图像、音频、视频与文本——本书聚焦文本型 LLM及其应用。
LLM 的核心原理看似朴素：通过大规模文本学习，预测下一个词。文本可被视为词的序列，前文中的模式有助于预测后续内容。比如句子“因为放暑假了，我没有去____”，多数人会自然填入“学校”。通过在多样化文本模式上的训练，LLM 形成对语言结构、语境与语义的直觉式理解。
早期也有基于规则或强化学习的“智能体”尝试。但 LLM 的独特之处在于其泛化能力——无需为特定任务再训练，就能处理广泛的任务。图 1.1 展示了 LLM 泛化能力的代表性例子：
- 图 1.1(a)：在“把英文翻译成韩文”的指令下，并给出两个示例（apple、orange），模型正确翻译“banana”——这属于少样例学习（few-shot） 。
- 图 1.1(b)：只给出“把英文翻译成韩文”的指令，没有示例，模型也能翻译“banana”——这属于零样例学习（zero-shot） 。
**推理模型（reasoning models）**近来备受关注：它们在给出结果前，会先分析任务或拟定计划。这种泛化上的进步，使 LLM（以及基于它的 Agent）在应对复杂、陌生问题时更为高效。图 1.1(c) 可见，模型不会立刻给出答案，而是先生成以 <think> 开头的“思考”标记。
1.1.2 什么是 LLM Agent？
LLM Agent 到底是什么？它与普通 LLM 或传统软件有何不同？我们从一个具体例子入手。
最具代表性的 LLM Agent 类型之一是研究型 Agent。当用户提出“总结 2024 年诺贝尔物理学奖得主的研究”这样的请求时，研究 Agent 会启动：从多个来源收集信息、分析结论，并产出一份综合报告。
如图 1.2 所示，研究 Agent 并不是直接从训练数据里吐出答案，而是会主动检索 2024 年诺奖的最新信息，识别获奖者（例如 Geoffrey Hinton 和 John Hopfield），查阅其学术论文，并参考诸如深度学习维基百科条目等资料，最后把这些信息综合成一份条理清晰的最终报告，说明其成果以及对 AI 领域的影响。
图 1.2：用户请求经由研究 Agent，分支成多次检索与综合流程。
LLM Agent 与 LLM、传统软件的差异
之所以称其为“Agent”，关键在于两种能力：工具使用与动态决策。
首先，不同于只能处理（多模态）输入并生成文本输出的纯 LLM，LLM Agent 可以通过工具与外部世界交互：它能进行网页搜索、阅读文档、为复杂计算执行代码、访问数据库等。这让 Agent 的能力远超纯文本生成。
其次，传统软件一般遵循预定逻辑路径，而 LLM Agent 会根据上下文做动态决策。一次研究任务，可能只需一次搜索，也可能需要阅读多篇学术论文、多个维基页面，并沿着“信息线索”层层深入。所需步骤数量并非事先确定，而是取决于问题复杂度以及过程中发现的信息。
图 1.3：LLM Agent 的决策循环，是“LLM 决策—工具使用”反复迭代的过程。
图 1.3 展示了其内部机制——一个持续循环的过程：
- LLM 评估当前上下文并判断是否需要工具；若需要更多信息，它会根据缺口选择合适的工具。
- 执行所选工具：如检索“2024 Nobel Physics”、查询“Hinton、Hopfield”、查找学术论文、访问维基进行背景了解等。
- 工具结果会回灌进 LLM 的上下文，丰富其对主题的理解，使后续决策更明智。
- LLM 决定继续还是停止。若认为信息已足以完整回答用户问题，就生成最终报告；否则回到第 1 步，继续下一轮。
这种“推理—行动—观测”的迭代，让 Agent 能处理复杂度不可预知的任务：从一次检索即可解答的简单问题，到需要几十个信息来源的复杂研究。
LLM Agent 的核心定义
据此，我们可以定义：LLM Agent 是一种系统，它以大型语言模型为推理引擎，能够自主做决策并执行动作，以实现指定目标。
更具体地说，LLM Agent 是一个**根据给定目标与上下文，依据 LLM 的输出决定下一步动作，并判断目标是否达成（终止条件）**的程序。研究 Agent 的例子正好说明：它不断决定下一步搜索什么（动作），评估信息是否足够（目标评估），并决定何时停止收集、产出报告（终止）。
这个定义凸显了与其他系统不同的两个要点：
- Agent 的核心职能是探索“如何达成目标” 。用户只需说明要做什么（如“总结诺奖研究”）以及其意义，而 Agent 负责“怎么做”——搜哪些来源、收集哪些信息、何时停止。就像人类解决问题一样，我们不断决定下一步行动、评估结果、判断是否达成目标。这种“选动作—判完成”的循环，是任何 LLM Agent 的基本结构。
- 这一结构与业界标准实现一致。Google ADK、OpenAI Agents SDK、LangGraph、PydanticAI、SmolAgents 等主流框架，基本都遵循相似范式：选择下一步动作、执行、评估结果、重复。通过亲手实现这套核心结构，你将获得跨框架可迁移的洞见，无论生产中选用哪种工具，都能自信地构建真正的工程化 Agent 系统。
在全书中，我们都将以此定义为基础来展开。需要强调的是：并非所有基于 LLM 的系统都具备同等程度的“能动性（agency）”。
1.1.3 不同程度的“能动性”（Agency Levels）
把 LLM 更深入地嵌入代码、让其更主动参与，就能提高系统的自主性（agency） 。这可以通过多种交互范式实现，每种方式在控制权与灵活性上各不相同。
图 1.4 展示了七个不同层级的能动性，从左到右自主性逐步增强。之所以越往右自主性越高，是因为 LLM 在决策过程中掌握的控制权越多。图中三行分别表示三种控制维度：谁产生当前步骤的输出、谁决定下一步、以及谁决定可供选择的步骤集合。
图 1.4 LLM 应用中的能动性层级演进。
最左端是传统软件（Code） ：开发者手写每一个“步骤”（可视作一个函数，输入→输出）。在这个范式中，开发者规定每一步的输入输出关系、决定下一步接哪一步，且系统里不存在开发者未明确实现的新步骤。
LLM Call 是最基础模式：直接调用 LLM 产生某一步的输出，相当于把这个步骤的执行委托给模型。基于此，Chain（链式）把多个 LLM Call 以预定义顺序连接起来——流转由开发者设计，LLM 逐步执行。由于 LLM（和人类一样）更擅长狭窄且清晰的子任务，把复杂任务拆成小步骤通常比“一个提示词包打天下”效果更好。
更动态的是 Router（路由器） 模式：给定一组预定义选项，让 LLM 依据上下文选择下一步，从而获得更自适应的流程。
Tool Use（工具使用） 更进一步：让 LLM 决定是否使用外部工具以及选哪一个。由于 LLM 只能产出文本，不能直接与外部系统交互或获取实时数据，开发者需要把外部能力封装成可调用工具。LLM 再基于上下文决定要不要用、用哪个。
Multi-step（多步/可终止） 模式让 LLM 决定程序是否继续运行或终止。例如需在满足某条件后停止，LLM 负责判断条件是否满足，并在满足时结束——常见实现是 while 循环结构。
自主性最高的是Tool Creation（工具创造） ：LLM 不仅选择工具，还会自行生成新工具（通常是产出代码、定义新函数）。系统能力因此可以动态扩展，而不依赖预先写死的逻辑。
由于自主性层级不同，“何时算 Agent”也有不同看法。Andrew Ng 教授指出：与其争论什么才是“真正的” Agent，不如承认系统的agentic 程度有不同层级。也有人主张达到一定自主性就可称为 Agent。Anthropic 的区分是：workflow 由开发者定义全部步骤并据此使用 LLM；而 agent 则是“由 LLM 动态主导自身流程与工具使用，并保持对完成方式的控制”的系统。
1.1.4 为什么要学习 LLM Agents？
LLM Agent 能显著提升个人与企业的生产力并带来新机会。对个人而言，它可自动化日常重复或耗时任务，尤其是“信息搜集与组织”类工作——这是 Agent 最擅长的：调研与归纳，可大幅节省时间。
例如这个多步调研问题非常适合 Agent：
“如果 Eliud Kipchoge 能无限维持他马拉松世界纪录的配速，从地球跑到月球（近地点距离）需要多久？”
要回答它，需要：检索 Kipchoge 与马拉松纪录、在维基找到地月近地点距离、做单位换算与计算，并按要求输出结果。人类当然能做，但需要在多站点间切换、抽取维基数据点、手算/编程计算，耗时且易错。
许多日常/工作任务都与之同构：从多来源收集数据→处理分析→给出可执行洞察。比如：
- 对比投资方案（市场数据、财务计算、趋势分析）
- 研究旅行目的地（位置信息、评价、预算测算）
- 竞品分析（数据搜集、对比、综合）
商业潜力也同样巨大：例如商品发现 Agent，跨电商比参数/价格/评价；个性化购物助手，理解偏好并在预算与条件内自动检索方案。
个人可直接用 OpenAI、Google Gemini、Perplexity Deep Research 等服务；若需与私有系统整合或使用私密数据，你就可以用本书介绍的实现技术构建自定义 Agent。
LLM/LLM Agent 尤其适合难以用固定规则覆盖的任务，即依赖上下文的方法选择。过去这类任务常需人工介入（例如必须综合法律/政策判断）。借助 Agent，企业能优化成本、显著提升体验，甚至打开原本不可行的新业务。在复杂决策、难维护的规则系统、非结构化数据处理等传统自动化薄弱环节，Agent 表现尤为出色。
1.1.5 什么时候该用 Agent？
Agent 很“香”，但不要逢题就上 Agent。就像不会用重型 Web 框架去做一页静态站点一样，选对“武器”才能高效、可控。原因在于 Agent 的天然权衡：
- 成本更高：多次 LLM 调用的 API 费用远超一次调用；
- 时延更大：每一步推理都会带来额外秒级延迟；
- 错误易级联：早期失误会在后续放大，导致整体质量下滑。
这些限制在生产系统里至关重要（分毫必争）。一个 0.01 美元能搞定的客服问答，用需要 10 次调用的 Agent 就是 0.10 美元——10 倍差距，规模化后成本惊人。因此，何时用/不用 Agent不仅是技术决策，更是商业决策。
先判断：任务是否需要 LLM？
在考虑 Agent 之前，先判断任务是否需要 LLM。LLM 带来额外计算成本与错误风险；若用更简单、确定性的方式能解决，就没必要上 LLM。
两条判断准则：
- 大量非结构化数据：若需处理文本/图像/音频等非结构化数据，是 LLM 的好场景（多模态 LMM 本质仍基于 LLM）。
- 输入多样性：如果用户输入很有限、任务范围很窄，使用其他 ML 模型可能更省钱；若可能任务数量小且预定义，硬编码通常比 Agent 在成本与延迟上更优。
再判断：是否需要 LLM Agent？
即便确定需要 LLM，也不代表一定需要 Agent。很多任务一次 LLM 调用就很好——翻译、摘要、分类、简答等。只有当任务需要多步骤、路径间决策、动态使用工具时，Agent 才展现价值。
判断是否需要 Agent 的三条标准：
- 任务复杂度：若难以预估需要多少步、难以直接编码实现，Agent 更合适。比如“查 A 地区人口”是定值问题；而“分析 LLM Agents 将如何塑造未来”涉及广泛信息搜集与复杂综合，难以静态编排。
- 任务价值：Agent 可能更贵、更慢，因此产出价值应覆盖这份额外的算力成本与时延。
- 错误成本与可探测性：LLM 会犯错，调用越多风险越高。若错误代价高（金融/法务/医疗等），Agent 未必合适；且能否发现错误很关键。若需要强领域知识，用户/开发者可能意识不到 Agent 的错误，导致无感失败。
小结：能用“单次 LLM”或“确定性代码”解决，就别上 Agent；当任务复杂多步、路径不确定、需用工具且价值足够、错误可控/可检测时，再选择 Agent。
1.2 从简单到复杂地构建 LLM Agent
从基础 Agent 到复杂的多智能体系统，有一条在业界逐渐成型的自然演进路径。我们将先构建最基础形态的 LLM Agent，然后逐步加入记忆、规划、反思等模块，让它更“聪明”。在单体 Agent 进化之后，我们会构建多智能体系统，让多个 Agent 协作。最后，以监控与评估作为收尾，讨论在 Agent 开发中的关键实践。
图 1.5 展示了从简单 LLM 交互到复杂多智能体系统的渐进式旅程。我们的路径是有组织的：先把 LLM 作为推理引擎来理解（第 2 章），再引入“工具”，让 LLM 能在真实世界采取行动（第 3 章）。这两者构成基础，在第 4 章形成基础 Agent，实现自主 Agent 决策环路核心的 ReAct（Reasoning + Acting） 模式。
图 1.5：从基础的 LLM-工具集成（第 2–4 章），到记忆、规划、反思等高级能力（第 5–8 章），再到多智能体协同（第 9 章）的架构渐进增强。
在此基础上，我们按部就班地增强 Agent 能力：第 5 章加入知识工具（通过 RAG 获取领域知识），第 6 章加入记忆（从过往经验中学习）。第 7 章引入规划能力，把复杂任务拆解为可管理的步骤；第 8 章加入反思，用于自评与迭代改进。
终点是第 9 章的多智能体系统：多个高级 Agent 通过一个多智能体编排器协同工作，实现任务分派、并行处理与协同求解，模拟人类团队解决复杂问题的方式。
在这一旅程中，各章层层递进，系统能力不断增强，同时始终遵循 LLM Agent 的核心原则：自主决策与目标达成。
1.2.1 构建基础 Agent
最简单的 LLM Agent 是 ReAct（推理 + 行动） Agent，它由一个 LLM 与若干**工具（Tools）**组成。工具是扩展 Agent 能力的外部函数，如：网页搜索、代码执行环境、数据库查询、文件操作、API 调用、邮件/消息发送等。ReAct Agent 不只是“直接回答”，而是不断重复以下闭环：推理（LLM 决定下一步）→ 行动（执行所选工具）→ 观察（把行动结果作为新上下文反馈给 LLM） 。
图 1.6：基础 Agent 的运行循环，展示了自主推理与工具使用。
要让 LLM Agent 真正有价值，它必须能采取真实行动。工具使用（Tool Use）允许 LLM 从一组可用工具中选择并执行外部能力（API、函数、数据库查询、其他软件等）。模型通常通过训练/微调学会在特定语境下选对工具：例如，“首尔今天天气？”应触发天气 API，“给 A 发邮件”应调用邮件 API。我们可以给 Agent 提供一份可动态使用的工具清单，让它依据任务与上下文自主选择与执行合适工具——这是与真实世界交互、完成实事的核心能力。
ReAct Agent 将 LLM 与工具使用结合，基于上下文选择工具、循环执行，直到目标达成。LLM 作为决策引擎，分析当前情境，依据需求与可选项决定下一步用哪个工具。
举例：我们问 ReAct Agent——“告诉我苹果公司股票价与谷歌股票价相乘的结果。”系统提供两个工具：网页搜索与计算器。LLM 首先识别需要股价信息，于是选择“网页搜索”获取 AAPL 与 GOOG 的股价，并把结果反馈给 LLM。随后 LLM 判断数据已齐，接着需要数学运算，于是选择“计算器”进行相乘。得到结果后，LLM 判断目标已达成并结束流程。
工具选择依赖 LLM 的推理能力——它通过自然语言理解把任务需求与合适工具进行匹配，像人类为任务挑选合适工具一样。
ReAct Agent 简洁而有力，但受限于提供的工具集合。为突破限制，CodeAct（代码 Agent）受到关注：它能生成并执行代码来“创造工具”。这类 Agent 也常被称为代码 Agent。
我们将在第 2 章更深入地理解 ReAct 的关键组件——LLM；第 3 章在代码层面讲解工具使用；第 4 章我们会亲手实现 ReAct 与 CodeAct，直观看到它们的能力。
1.2.2 构建更聪明的 Agent
虽然 ReAct Agent 很强，但其“思考-行动-观察”的简单闭环不足以处理复杂、长上下文问题。对于多步骤的长期目标，引入规划（Planning）与过程管理会更高效；具备长期记忆，能在需要时提取关键经验与信息；此外，具备**反思（Reflection）**能力——识别错误并据此调整策略——对更智能高效的运行至关重要。
就像人类解决复杂问题时会“制定计划、回忆经验、反思纠错”，LLM Agent 同样需要这些更高层的“认知能力”。
图 1.7：具备认知能力的 Agent
长期记忆（Long-term Memory）
人类遇到新问题会从记忆中调取相似经历或相关知识。基础 ReAct Agent 只能基于当前对话上下文、最近的行动与观察来决定下一步——就像每次与用户都是第一次见面。这导致它难以记住并利用以往交互中的信息或用户偏好。比如，用户曾经声明偏好某种报告格式，但下次生成报告时，基础 Agent 无法回忆并应用。
Agent 的记忆通常分为短期与长期：短期记忆包含当前会话内的数据：用户请求、LLM 输出、工具结果；长期记忆存放与用户或过往任务相关、但不在当前对话中的信息（仍与上下文相关）。加入长期记忆后，Agent 能复用先前成功策略并规避失败策略；关于用户的知识累积还可带来更个性化的响应，并对相似问题更快更高效。
实现长期记忆常用 RAG（检索增强生成） ：从外部知识库（如向量数据库）检索相关信息并注入到提示中，让 LLM 参考最新或专业知识，从而显著提升质量与事实一致性。关键在于：要让 LLM 生成高质量结果，必须只提供相关信息——这也是 RAG 中“检索（Retrieval）”的意义。第 5 章我们系统介绍 RAG，第 6 章展示如何把长期记忆与 ReAct Agent 集成。
规划（Planning）
ReAct Agent 根据当下情境决定下一步，具有很好的反应性（Reactive）。但若要达成最终目标，仅靠即时反应往往效率不高：只盯眼前，可能看不见全局路径、找不到最优路线，或不断重复无用动作——就像开车只看下个路口、不看地图。人类无计划地行动往往会做很多冗余工作；Agent 没有计划也容易走错路、不得不推倒重来，成本与时延随之上升。
规划让 Agent 能先行定义达到目标所需的子任务/行动序列。利用 LLM 的推理，Agent 可以生成一条任务完成的路线图。比如“从城市 A 到城市 B 订最便宜的行程”：无规划的 Agent 可能随机尝试“查机票/查火车”，而有规划的 Agent 会给出系统化步骤：
- 查询机票价格
- 查询火车价格
- 查询大巴价格
- 跨交通方式比最低价
- 预订最便宜选项
这种结构化方法显著减少低效。我们将在第 7 章详细讲解规划模块。
反思（Reflection）
反思是 Agent 评估自身表现、回顾工作流程的能力。人类不会机械执行计划，而是不断停下来评估“是否跑偏”“计划是否仍合理”“有没有更优策略”。通过反思/自我修正，我们会调整计划、更新关键信息、重新审视策略有效性。
ReAct 中的“观察”更像即时反馈；而反思是更显式的额外步骤，让 Agent 回看整体流程或其中片段并进行分析。例如，代码执行报错时，一个具备反思能力的 Agent 不仅记录错误，还会分析原因：“由于错误使用某库导致，下次应换函数或调整参数。”若 Agent 长期无法推进目标，它可能得出结论——当前策略有问题——并改弦更张。
反思的收益包括：
- 纠错与性能改进：通过自我分析与更正，避免重复犯错，性能逐步提升。
- 策略灵活性：当现有策略无效时，能修订或放弃并探索替代方案。
- 知识与记忆更新：反思得到的洞见可写入长期记忆（语义/程序性），供未来任务使用。
第 8 章我们将更详细地介绍反思模块。
通过引入规划、长期记忆、反思——这些类似人类问题求解的“认知功能”——LLM Agent 能从“简单反应器”进化为能系统性、智能且高效地解决复杂问题的系统。要想让 Agent 理解长上下文、从经验中学习、并自主改善行为，这些要素不可或缺，它们共同构成真正自治系统的基础。
1.2.3 多智能体系统（Multi-agent systems）
到目前为止，我们讨论了如何通过规划、长期记忆与反思来增强单个 LLM Agent 的智能与解题能力。不过，在真实场景中，问题往往过于复杂或规模过大，单个 Agent 难以独立承担。
LLM Agent 会根据提示中的指令与上下文进行理解并做出决策。但当任务非常复杂时，提示会变得极长，或需要的工具过多，LLM 可能难以完全理解信息并准确决策，从而导致 Agent 的准确率下降。例如，把“新产品的规划、营销策略制定、技术文档撰写、客户支持脚本编写”这类高度专业且复杂的任务全部交给一个 Agent 同时完成，通常既低效又容易出错。同样地，让一个 Agent 在上百个 API 中做选择，也更容易犯错。
为更有效地处理这种复杂性，我们采用多智能体（Multi-Agent）方法。这很像把大型项目拆分给不同的专业人员协作完成：将复杂任务拆解为多个子任务，并让各司其职的专长型 Agent 协同以实现总体目标。
假设任务是软件开发。图 1.8 展示了“构建一款任务管理的移动 App”这一复杂目标，如何拆分为具备角色化指令与工具的专业 Agent。一个多智能体系统可能会划分为：软件工程师、产品经理（PM）、设计师、QA 工程师等角色，每个角色交由不同的 Agent 负责。
这些 Agent 可以基于同一个 LLM，但会被赋予不同的系统提示与专属工具。如图所示：PM Agent 使用网页检索与图像生成做市场研究；设计师 Agent 使用线框生成器与UI 组件库；工程师 Agent 使用代码解释器与 GitHub API。例如，工程师 Agent 的提示可能是：“作为编写整洁高效代码的专家，请实现下一个模块”；而 PM Agent 的提示可能是：“定义产品需求并确定优先级”。工作流中，信息会按序从“需求定义→设计→开发→测试”流转，并由 QA 的反馈回路把问题回传给 PM 以便迭代改进。
图 1.8：用于软件开发任务的多智能体角色分工。
需要注意的是，当 Agent 之间的交互不受限、且可用工具很多时，多智能体系统的输出质量可能变得不可预测。尽管如此，从复杂性管理与专业化分工的角度看，多智能体依然是扩展 LLM Agent 能力的强大模式。第 9 章我们将详细深入多智能体方法。
1.2.4 Agent 监控与评估
要在真实环境中开发并部署 Agent，必须持续监控与评估它是否按预期工作、错误发生在哪里、整体表现如何。鉴于其交互与决策过程复杂，监控与评估是开发与运维中的关键环节。
Agent 监控：窥视“引擎盖”下的过程
理解 Agent 在任务执行过程中的内部状态，对于调试与性能改进至关重要。通常会使用**日志与链路追踪（tracing）**来记录并可视化运行期的各类事件。
一个 Agent 监控系统通常会记录：
- LLM 交互：提交给 LLM 的提示（prompt），LLM 的响应（自然语言回复、中间推理步骤、工具选择决策等）。
- 工具/API 调用：被调用工具的名称、输入参数、执行结果（成功或错误）。
- 决策过程：内部如何制定计划、选择了哪些工具、沿着哪条行动路径推进。
- 交互日志：与用户的对话历史、与其他 Agent 的消息往来。
- 状态变更：Agent 内部状态或外部环境的改变（如数据库更新）。
收集到的监控数据可用于：
- 调试：当 Agent 任务失败或行为异常时，日志与追踪能定位具体出错步骤并进行修复。
- 性能分析：测量各步骤的时延、LLM 调用成本、工具使用成本，识别瓶颈并优化。
- 行为分析与审计：理解 Agent 在特定情境下为何做出某个决定，确保遵循政策/规则，开展安全合规审计。
Agent 评估
准确把握 Agent 解题智能、交互能力与工具使用能力，是成功开发与运营的核心。学术界与产业界提出了多种基准（benchmark）从不同维度进行评测——从真实复杂问题的理解与解题，到在真实代码仓库中测试编程能力，再到精确评估工具使用与用户交互的基准。每种基准都提供了客观标准，帮助比较能力、发现改进点。此外，还有各种补充性基准，以揭示 Agent 的潜力与局限。
但标准化基准并不能穷尽全部。要真实反映现实环境的复杂与不可预测性，需要更全面、多维的评估方法：
- 端到端评估（E2E） ：从用户初始请求到最终产出的整体流程评估，检验实际成败。
- 中间阶段评估：评估关键中间步骤的产出，常能更快定位问题根因。
此外，许多难以用自动化指标量化的定性因素——如对话自然度、用户满意度、创意质量——需要人工评估。一个设计良好的评估方案对优化性能与保障可靠性不可或缺。
总之，评估是诊断与改进 Agent 性能、最终为用户交付真实价值的核心过程。第 10 章我们将探讨多种基准与评估方法，并对第 1–9 章构建的 Agent 进行直接评测。
1.2.5 阅读本书的前置准备
本书完整讲解如何用纯 Python 从零实现 LLM Agent。为充分理解内容与动手练习，建议读者具备以下基础：
必备准备
- Python 基础
需熟悉以下要点：
- 变量、数据类型、列表、字典等基础数据结构
- if、for/while 等控制流
- 函数的定义与调用
- 面向对象（OOP）基础（类/对象）
若尚不熟悉，建议先学习入门级 Python 教程。
- 开发环境搭建
为顺利完成练习，需要本地 Python 环境：
- 安装较新的 Python（推荐 3.12+）
- 准备代码编辑器/IDE（推荐 VS Code）
- 了解如何用
pip或uv安装依赖
- API Key 与外部服务
- OpenAI API Key：访问 GPT 模型（示例主要使用）
- Tavily API Key：用于研究型 Agent 的网页检索
- 具备基础的 REST API 与 HTTP 请求概念
- 成本考量
- OpenAI：完成全书练习的总成本预计 < 10 美元
- Tavily Search API：免费档每月 1000 次搜索，足够完成本书练习
书中会提供降本与高效测试的小技巧。
完成以上准备后，就可以开启本书的 LLM Agent 开发之旅了。第 2 章将奠定我们贯穿全书的 LLM 基础。
1.3 小结
- LLM Agent 是一种程序：在给定目标与上下文下，依据 LLM 的输出决定下一步行动并评估目标是否达成（终止条件） 。
- LLM 具有出色的泛化能力：通过 few-shot、zero-shot 与“思维 token”式推理，无需针对每个任务单独再训练即可处理多样任务。
- 自主性（Agency）等级从简单代码执行到完全自治系统逐步提升：当 LLM 对任务执行、行动选择、可选步骤的控制越多，自治程度越高。
- 适合使用 LLM Agent 的任务：涉及非结构化数据分析、需要多步且步骤数不可预测、任务价值足以覆盖成本时延、且错误可被发现并校正。
- 从零构建 Agent 能带来：对核心原理的深刻理解、上下文流的清晰可见、调试能力的显著提升，以及超越现有框架限制、构建定制解决方案的灵活性。
