4. Agent开发

4. Agent开发

本章导读：前 3 章你学会了 LangChain 的基础组件、链式编程和工具系统。本章进入 LangChain 最核心的能力——Agent（智能体）开发。你将掌握 create_agent 的完整用法，从最简 Agent 到多 Agent 协作系统，真正构建出能自主决策、调用工具、完成复杂任务的 AI 应用。

本章定位

Agent 是 LangChain 框架的精华所在。如果说前 3 章是在教你「怎么和模型对话」，那本章就是教你「怎么让模型干活」。

LangChain 对 Agent 的定义极其简洁：Agent = Model + Harness。模型负责推理，Harness 负责把推理转化为行动——自动调用工具、管理上下文、控制循环。create_agent 就是这个 Harness 的入口函数。

为什么 Agent 如此重要？因为现实世界的问题很少能靠一次对话解决。用户说「帮我查一下明天去北京的机票和酒店」，这背后涉及搜索航班、比价、查询酒店可用性、汇总结果等多个步骤。传统的链式编程（第 3 章的内容）需要你预先编排好所有步骤——但用户的需求千变万化，你不可能预判所有分支。Agent 的价值就在于让模型自己决定调用哪些工具、以什么顺序执行，这才真正称得上「智能」。

从链到 Agent 的认知跃迁

在第 3 章中，你学会了用链（Chain）把多个步骤串起来。链的本质是「人编排流程，模型执行步骤」——你明确知道第一步做什么、第二步做什么。这种模式适合流程固定的场景，比如「接收用户输入 → 构造 Prompt → 调用模型 → 解析输出」。

但 Agent 打破了这种限制。Agent 循环的核心是「模型自主决策」：模型根据当前上下文判断下一步该调用哪个工具，拿到工具结果后再继续推理，直到任务完成。你不再预先编排流程，而是定义一组工具和一个目标，让模型自己规划路径。

这个认知跃迁非常重要。很多初学者会把 Agent 写成「带 if-else 的链」，本质上还是在人工编排。真正的 Agent 应该是「模型驱动决策」，你的角色从「流程设计师」变成了「工具提供者」和「目标定义者」。

章节导读

4.1 Agent基础与create_agent

从「Agent 是什么」出发，掌握 create_agent 的 model、tools、system_prompt 三大核心参数。你会创建第一个完整可运行的 Agent，理解 Agent 的核心循环机制（推理→调用→反馈→再推理），并学会会话持久化让 Agent 记住上下文。本节是后续两节的基础，务必动手跑通所有代码示例。

核心收获：独立创建一个具备多工具调用能力的生产级 Agent，并理解 Agent 循环的底层机制。

4.2 工具调用进阶与中间件

让工具从「无状态函数」进化为「能感知上下文的能力单元」。你将掌握 ToolRuntime 机制（让工具访问会话状态和用户信息）、Pydantic 复杂 Schema 定义（让工具接收结构化参数）、以及中间件（Middleware）机制来拦截和修改 Agent 行为。中间件是 Agent 系统中「横切关注点」的标准解法——日志审计、输入过滤、性能监控都应该通过中间件实现，而不是散落在各个工具函数里。

核心收获：构建工具能感知用户身份、中间件能做日志审计和输入过滤的高级 Agent。

4.3 多Agent协作与LangGraph编排

当单个 Agent 的工具太多导致决策不准时，用「分而治之」的思路拆成多个专家 Agent，用 LangGraph 的 StateGraph 编排它们的协作流程。你将掌握三种典型架构：扇出分发（一个调度器把任务分给多个专家）、顺序流水线（前一个 Agent 的输出是后一个的输入）、迭代协作（多个 Agent 在循环中反复讨论直到达成共识）。本节是本章的高潮，也是整个教程中最有「工程深度」的部分。

核心收获：构建「调度器 + 专家池」模式的多 Agent 系统。

Agent 开发的常见误区

在深入具体内容之前，先指出三个初学者最容易踩的坑。这些坑不是理论上的，而是我在实际项目中反复见到的真实问题，希望你在学习过程中有意识地避免：

误区一：给 Agent 塞太多工具。 很多人的第一反应是「既然 Agent 能自动选工具，那我把所有能想到的工具都给它」。结果就是工具太多导致模型选错工具的概率大幅上升。我的建议是：单个 Agent 的工具数量控制在五个以内，超过五个就应该考虑拆分成多个专家 Agent（这正是 4.3 节要解决的问题）。

误区二：忽视 system_prompt 的设计。 create_agent 的 system_prompt 参数不是可选的装饰品，而是决定 Agent 行为质量的关键因素。一个模糊的 system_prompt（「你是一个有用的助手」）会导致 Agent 频繁调用不必要的工具。一个精确的 system_prompt（「你是一个航班查询助手，只能使用 search_flights 和 get_flight_detail 两个工具，在用户没有提供日期时必须先询问」）能让 Agent 的准确率从百分之六十提升到百分之九十以上。

误区三：把中间件当成「高级功能」忽略。 很多人觉得中间件是锦上添花，实际上在生产环境中，日志、监控、安全校验这些横切关注点如果不通过中间件统一处理，代码会变得极其混乱。4.2 节讲中间件不是炫技，而是教你写出可维护的 Agent 代码。

与前3章的关系

前3章为本章提供了全部的基础能力：

• 第1章的核心概念帮助你理解 Agent 中模型的定位——模型不是 Agent 的全部，Agent 是模型加工具加循环的组合体。
• 第2章的 LLM 集成和工具定义是构建 Agent 的直接原料，Agent 的 tools 参数就是第2章里定义好的工具函数。
• 第3章的链式编程提供了理解 Agent 的对比视角——链是人工编排的固定流程，Agent 是模型驱动的动态流程。理解了这个区别，你就理解了什么时候该用链、什么时候该用 Agent。

一个实用的判断标准：如果处理流程固定（比如「提取信息→格式化→存储」），用链就够了，更简单也更可控。如果处理流程不固定（比如「用户可能问天气、可能查订单、可能要求退款」），就应该用 Agent，让模型根据实际情况动态选择工具。两者不是替代关系，而是互补关系——在复杂系统中，往往是一部分用链、一部分用 Agent，甚至在 Agent 内部的工具执行逻辑中也会包含链式调用。

学习建议

1. 4.1 节必须亲手跑一遍。create_agent 的三个参数看似简单，但组合起来有很多细节（比如 system_prompt 的写法直接影响 Agent 的工具选择准确性）。
2. 4.2 节重点理解 ToolRuntime。这是很多教程不会讲到的进阶内容，但在生产环境中几乎必然会用到（比如工具需要知道当前用户是谁）。
3. 4.3 节建议画图理解 StateGraph。状态图的概念需要可视化才能直觉理解，不要纯看文字。

前置要求

• 已掌握本教程第 1-3 章内容
• 理解 Python 装饰器和类型标注
• 有基本的 API 调用经验

更新记录

• 2026-07-21：新增 4.1 / 4.2 / 4.3 三个二级节，基于最新 create_agent API 重写
• 2026-07-23：扩充章导读，增加认知跃迁论述、常见误区、与前章关系

关键词：LangChain框架精通, Agent开发, create_agent, ToolRuntime, 中间件, LangGraph, StateGraph, 多Agent协作
难度：进阶
预计阅读：50 分钟