2026 年，Agent 开发完成了从"演示"到"生产"的转折：代码评审 Agent 跑在 CI 流水线里，数据分析 Agent 接上了真实报表。转折的底层前提并不神秘——2025 年 10 月 LangChain 与 LangGraph 相继发布 1.0，框架 API 进入稳定期，模型的推理能力与工具调用可靠性也跨过了工程及格线。但对工程师来说，从"会调大模型 API"到"能交付一个可靠的 Agent 系统"，中间仍然隔着一套完整的知识体系，这正是《AI Agent 开发》系列（共 30 篇）要填的坑。
本文是系列第 1 篇，只做一件事：把地图铺开。你会建立三个心智模型——Agent 与 Chatbot、Copilot 的边界在哪里，ReAct 循环如何运转，2026 年的技术栈分几层——并据此看懂后面 29 篇各自在地图上的位置。系列代码基线为 Python 3.11+、LangGraph 1.2.x、langchain-core 1.6.x。本文按"形态演进 → ReAct 范式 → 技术栈分层 → 框架分工 → 路线图"组织全文。
1、从 Chatbot 到 Agent
第一代形态是 Chatbot：一问一答，模型唯一的输入是聊天记录，唯一的输出是文本。第二代是 Copilot：模型可以调用宿主程序预先暴露的少数能力，比如补全一段代码、改一处措辞，但方向盘始终在人手里——发起什么、采纳什么，都由人决定。第三代才是 Agent：你给它目标而不是指令，它自己拆解步骤、挑选工具、根据中间结果修正路线。
区分三者的是三条能力边界，缺一条就还不是 Agent：
- 自主规划：把目标拆成步骤，自己决定下一步做什么
- 工具使用：调用搜索、数据库、执行器去改变外部状态
- 记忆：会话内保持上下文，跨会话积累信息与偏好
| 形态 | 交互模式 | 能力边界 | 典型代表 |
|---|---|---|---|
| Chatbot | 一问一答 | 仅文本生成 | 早期问答机器人 |
| Copilot | 人主导，AI 辅助 | 单步建议，不自主决策 | GitHub Copilot |
| Agent | 人给目标，AI 执行 | 规划、工具、记忆齐备 | Deep Research、编码 Agent |
判断一个系统是不是 Agent，不看它接没接大模型，看它能不能自己决定下一步做什么。
两条务实提醒。其一，边界是渐变的：不少"Agent 产品"实为 Copilot 换皮，验收时拿上面三条逐条对照即可识破。其二，方向反过来也成立——不是所有任务都值得上 Agent。Anthropic 在 Building Effective Agents 一文中的判断至今仍是共识：固定流程能解决的用工作流，让模型动态决策的循环才留给 Agent，因为后者的 token 成本与不确定性都高一个量级。
2、ReAct 范式
Agent 的运转内核几乎都指向同一个范式：ReAct (Reasoning and Acting)，出自 ReAct 论文（Yao 等人，2022 年）。思路朴素得惊人：让模型在"思考"与"行动"之间交替——思考决定下一步行动，行动返回观察结果，观察喂回模型触发下一轮思考，循环往复直到模型认为可以给出最终答案。
先看剥掉所有框架细节后的伪代码，一个 Agent 的内核只有十几行。
# ReAct 循环骨架：推理与行动交替，直到模型给出最终答案
messages = [system_prompt, user_task]
while True:
response = llm.invoke(messages) # 思考：分析现状，决定下一步
messages.append(response)
if not response.tool_calls: # 不再要求行动，任务完成
return response.content # 返回最终答案
for call in response.tool_calls: # 行动：执行模型指定的工具
result = tools[call.name].invoke(call.args)
messages.append(ToolMessage(result)) # 观察喂回，进入下一轮
解读：这个 while 循环就是所有 Agent 框架的心脏，LangGraph 的 create_react_agent、CrewAI、OpenAI Agents SDK，内核都是它的变体。与 2022 年原论文靠正则从自由文本里抠出 Action 不同，今天的模型通过 Function Calling 直接输出结构化的 tool_calls 字段，工具调用从"碰运气"变成"可依赖"，这是 Agent 能进生产的第一个前提。
以"检查生产环境依赖是否落后"这类任务为例，一次完整循环的消息轨迹如下。
用户 检查生产环境 langgraph 版本是否落后于最新版
思考 需要先拿到最新版本号，再读本地依赖文件
行动 web_search("langgraph pypi latest version")
观察 最新版本 1.2.16
思考 版本号已到手，接着读取本地依赖声明
行动 read_file("pyproject.toml")
观察 langgraph==1.1.0
思考 信息齐全，可以回答了
回答 本地 1.1.0 落后最新 1.2.16，建议升级后跑回归测试
解读这段轨迹有两个关键点。第一，模型每一步只做一个小决策——先查什么、再读什么，规划是循环中"长"出来的，而不是预先写死的，这正是第 1 节说的自主规划。第二，观察是纠错的来源：如果第一次搜索没找到版本号，模型会换个关键词重试。代价也在这里——每一轮都要把全部历史重新发给模型，token 消耗随轮数线性增长，这是后面讲记忆压缩与上下文管理的伏笔。
3、2026 技术栈分层
把一个生产级 Agent 拆开，2026 年的主流技术栈可以清晰地分为五层，自下而上如下。
┌────────────────────────────────────────────────┐
│ 观测层 LangSmith · evals · 成本监控 │
├────────────────────────────────────────────────┤
│ 记忆层 Checkpointer（短期）· Store（长期） │
├────────────────────────────────────────────────┤
│ 工具层 Function Calling · MCP 开放协议 │
├────────────────────────────────────────────────┤
│ 编排层 LangGraph 状态机 + LangChain 组件 │
├────────────────────────────────────────────────┤
│ 模型层 GPT-5 · Claude 4.5 · Gemini 3 等 │
└────────────────────────────────────────────────┘
模型层是发动机。闭源阵营的 GPT-5、Claude 4.5、Gemini 3 与开源阵营的 Qwen、DeepSeek 各有取舍，但一个常见误区是把它当成 Agent 可靠性的决定因素。模型决定能力上限，工程上真正的瓶颈大多在编排——同一个模型，编排好坏结果天差地别。
编排层是本系列的主战场，负责把模型、工具、记忆组装成可控流程。这里的关键分工是：LangChain 提供标准组件（统一的模型接口、prompt 模板、工具定义），LangGraph 提供状态机引擎，第 4 节展开细讲。
工具层解决"手脚"问题，两条腿走路。私有工具走 Function Calling，各厂商 API 原生支持；跨应用共享工具走 MCP (Model Context Protocol)——开放协议让"工具一次封装、所有 Agent 复用"成为现实，MCP 规范在 2026 年 7 月的最新修订进一步把它改造成无状态、可缓存的远程协议。可以类比 USB 之于外设：没有统一协议之前，每个外设都得为每台主机单独写驱动。
记忆层最容易被低估。短期记忆是会话内的消息历史，靠 Checkpointer 持久化与恢复；长期记忆是跨会话的偏好与知识，靠带命名空间的 Store。一个没有持久化的 Agent，进程一重启就"失忆"，谈不上生产可用。
观测层是仪表盘。LangSmith 记录每一步的输入输出与延迟，evals 用数据集评估每次改动是否变好。判断很直接：Agent 的决策由模型生成、天生非确定，没有 trace 你无法调试它，没有 evals 你无法安全地迭代它。
4、LangChain 与 LangGraph 分工
初学者最常见的困惑：LangChain 和 LangGraph 是竞争关系吗？不是。一个准确的比喻：LangChain 是零件库，LangGraph 是整车控制系统。LangChain 给你标准化的发动机、轮子、传感器——统一的模型接口让你一行代码切换厂商，@tool 装饰器让任何函数变成模型可调用的工具；LangGraph 决定什么时候给油、什么时候换挡——把流程建模为图，节点是步骤，边是流转，条件边做分支，Checkpointer 让执行随时可暂停、可恢复。
两者的关系是嵌套而非互斥：LangGraph 图里的每个节点，内部用的就是 LangChain 组件。LangChain 1.0 之后官方定位也很明确——简单固定管线用 chain，Agent 与复杂工作流用 LangGraph。零件没有控制系统跑不起来；只有控制系统没有标准零件，每个接口都得自己造。
生态里其他玩家各有生态位，定位一览如下。
| 框架 | 定位 | 一句话判断 |
|---|---|---|
| LangGraph | 生产级状态工作流 | 事实标准，控制粒度最细，学习曲线最陡 |
| CrewAI | 角色扮演式多 Agent | 原型最快，框架替你做的决策也最多 |
| OpenAI Agents SDK | 轻量极简 | 深度绑定 OpenAI 生态的最短路径 |
| MS Agent Framework | AutoGen 继承者 | .NET 与 Azure 企业场景的默认选项 |
| Pydantic AI | 类型优先 | 把类型安全带进 Agent 开发 |
| Google ADK | Google 生态配套 | Vertex AI 部署的顺路选择 |
| Mastra | TypeScript 全栈 | 前端团队的 Agent 框架 |
本系列主线选 LangGraph，不是因为最简单，而是因为它把控制权交还给开发者：状态可见、流转可条件化、每步可中断可回放——这些是生产系统的硬需求，也是"快速原型"框架刻意藏起来的复杂度。第 25 篇会做完整横评，这里先给结论：原型期选什么都行，上线前认真考虑 LangGraph，细节可翻 LangGraph 官方文档。
5、系列路线图
30 篇按六个模块加一个收官实战推进，每个模块解决一类问题。
| 模块 | 篇目 | 核心内容 |
|---|---|---|
| 一、全景与基础 | 01～05 | 环境搭建、LLM 调用、Prompt 与结构化输出、工具调用 |
| 二、LangGraph 核心 | 06～13 | 图模型、State、控制流、手写 ReAct、人机协同、持久化、流式 |
| 三、RAG 检索增强 | 14～18 | 向量检索、RAG 流水线、混合检索、Agentic RAG、GraphRAG |
| 四、MCP 与工具生态 | 19～22 | 协议详解、Server 开发、Agent 接入、工具设计模式 |
| 五、进阶架构 | 23～26 | 记忆系统、多 Agent 架构、框架横评、前沿形态 |
| 六、生产化 | 27～29 | 评测观测、安全护栏、部署运维 |
| 收官实战 | 30 | 数据分析 Agent 端到端串联全系列 |
三条主线贯穿全程。控制权主线：从预构建的 create_react_agent 起步，到第 9 篇不借助预构建手写 ReAct——在那之前你在用别人的抽象，之后你理解每个抽象为什么存在。可靠性主线：从"跑通了"到可评测（第 27 篇）、可防御（第 28 篇）、可回滚（第 29 篇）。生态主线：从单进程的函数工具，到第 20 篇把你的工具封装成 MCP Server 开放给任何 Agent 使用。
预读提示：如果你只想尽快写出第一个 Agent，跟着第 2 篇走就够了；如果你更想理解 Agent 的本质，也可以直接跳到第 9 篇手写 ReAct 再回头补基础，这是一条被反复验证过的路线。
6、总结
回到开篇的问题：Agent 到底是什么？一句话心智模型——模型是发动机，ReAct 循环是运转方式，工具是手脚，记忆是状态，观测是仪表盘；LangChain 供零件，LangGraph 管装配，MCP 让工具跨系统流通。这个模型装得下本系列要讲的全部内容，也足以用来审视市面上任何一个 Agent 产品。
行动建议：对于想系统入门的工程师，建议从下一篇开始动手——用 uv 初始化项目、配置 API Key、跑通第一个会调工具的 Agent，两小时内可见效果；对于正在选型的团队，建议拿一个真实流程用 LangGraph 搭最小工作流，重点体验 interrupt 中断与时间旅行回放，再和现有方案在"可中断、可观测、可评测"三个维度上对比，差距自见分晓。
