拓冰网站定制 
早期 LangChain 那种“Agent AgentExecutor Tools”的思路已经明显转向了Agent LLM Tools State Middleware Runtime LangGraph 执行循环一、先说结论如果让我用一句话概括当前 AgentLangChain 的 Agent本质上不是“一个会调用工具的大模型”而是一个由 LLM 驱动、以 State 为上下文、以 Tools 为行动能力、以 Middleware 为控制层、由 LangGraph 负责循环执行的动态决策系统。官方文档明确指出create_agent创建的是生产级 Agent并且底层使用LangGraph 构建图式 Agent Runtime。Agent 会在模型节点、工具节点以及中间件之间循环直到模型给出最终结果或者达到迭代限制。DeepSeek 给出Agent LLM Harness是一个非常好的上层抽象。而如果落到 LangChain 1.x 的工程实现可以进一步拆成Agent │ ┌──────────┴──────────┐ │ │ LLM Harness 决策/推理能力 │ ├── Tools ├── State ├── Middleware ├── Runtime ├── Memory ├── Guardrails ├── Streaming └── Execution Loop │ LangGraph这才是现在值得真正掌握的 Agent 架构。二、LangChain 对 Agent 的定义官方文档给出了非常关键的定义Agent 将语言模型与工具结合使系统能够推理任务、决定使用哪些工具并迭代寻求解决方案。这里面有三个动作理解任务 ↓ 决定下一步行动 ↓ 执行行动 ↓ 观察结果 ↓ 再次决定 ↓ ……也就是LLM ↓ Tool Call ↓ Tool Result ↓ LLM ↓ Tool Call ↓ Tool Result ↓ LLM ↓ Final Answer这就是经典的Agent Loop / ReAct Loop。官方文档也直接用 ReAct 描述这一过程模型在“推理—行动—观察”之间循环直到能够给出最终答案。三、真正理解 Agent关键不是create_agent很多初学者看到agentcreate_agent(model,toolstools)会觉得“这么简单Agent 不就是这个吗”其实完全不是。create_agent()更像一个装配器 / Agent Factory。你告诉它用哪个 LLM 有哪些工具 有什么系统提示 有什么状态 有哪些 Middleware 如何输出它组装出一个可以运行的 Agent。真正重要的是create_agent ↓ LangGraph Runtime ↓ Agent Loop ↓ Model ↕ Tools ↕ State所以可以把create_agent(...)理解为“创建一个 Agent Runtime”而不是“调用一个超级 Agent 函数”。四、Agent 最核心的东西循环这是学习 Agent 最应该吃透的一部分。假设用户帮我找目前最热门的无线耳机并确认库存。Agent 并不是用户 ↓ LLM ↓ 答案而是用户问题 ↓ ┌─────────────┐ │ LLM │ │ 当前应该做什么│ └──────┬──────┘ │ ↓ Tool Call │ ↓ ┌─────────────┐ │ Search Tool │ └──────┬──────┘ │ ↓ Search Result │ ↓ ┌─────────────┐ │ LLM │ │ 下一步做什么 │ └──────┬──────┘ │ ↓ Inventory Tool │ ↓ Inventory Result │ ↓ ┌─────────────┐ │ LLM │ │ 是否完成 │ └──────┬──────┘ │ ↓ Final Answer这就是 Agent。五、那么LLM 到底是怎么“决定下一步”的“LLM 明明只是文字输出它怎么决定下一步做什么”答案是不是 LLM 自己直接执行下一步。而是LLM │ │ 输出 Tool Call ↓ Agent Runtime │ 判断这是工具调用 ↓ Tool Node │ ↓ 执行 Python │ ↓ Tool Result │ ↓ 写入 State │ ↓ LLM例如模型输出的不是我现在去搜索一下。而是结构化的{tool:search_products,arguments:{query:wireless headphones}}Agent Runtime 看到这个 Tool Calltool search_products于是search_products(...)真正执行。所以LLM 负责“决策”Runtime 负责“执行”。这就是 Agent 和普通 LLM Chat 的根本区别之一。六、这也解释了前面的“LLM Harness”现在可以把这个概念讲得非常清楚LLM负责理解 推理 规划 选择工具 判断下一步 生成最终答案Harness负责状态管理 工具执行 循环控制 权限 错误处理 上下文管理 记忆 Middleware Human-in-the-loop 日志 监控 停止条件所以Agent │ ┌──────┴──────┐ │ │ LLM Harness │ │ │ ┌─────┼─────────┐ │ │ │ │ │ State Tools Middleware │ │ │ │ │ │ Runtime Guardrail │ │ │ └───────┴───────────────┘这比“Agent LLM Tools”准确得多。七、ToolsAgent 的“手和脚”LangChain 对 Tool 的设计也值得注意。普通 LLM输入 → 输出Agent输入 ↓ LLM ↓ 决定调用 Tool ↓ Tool ↓ 环境发生变化 / 获得信息 ↓ LLMTool 赋予 AgentAction 能力。例如tooldefsearch(query:str):...它本质上就是Tool Schema ↓ 告诉 LLM “你可以使用这个能力”模型看到search(query: string)之后就可以决定我要不要调用 search 调用什么参数 调用几次 什么时候停止八、非常重要Tool ≠ Function Calling这两个概念很多人混淆。Function Calling是模型能力LLM ↓ 产生结构化函数调用Tool是实际能力Tool ↓ 真正执行函数所以Agent │ ↓ LLM │ Function Calling │ ↓ Tool Call │ ↓ Tool Runtime │ ↓ Python/API/MCP可以把Function Calling 看成“发号施令”。而Tool 是“真正干活”。九、LangChain 现在特别强调“动态 Tools”这是官方文档非常值得注意的一个变化。过去tools[search,calculator,weather,database,email]Agent 永远看到这些工具。现在 LangChain 支持根据 State / Store / Runtime Context 动态决定当前给 Agent 哪些工具。例如用户未登录 ↓ 只能 search read_public_data 用户登录 ↓ 增加 read_private_data 管理员 ↓ 增加 write_data delete_data文档给出的 Middleware 示例就是根据认证状态、对话阶段、Store 中的 Feature Flag、用户角色等动态过滤工具。这个设计其实非常重要。因为工具不是越多越好。工具太多Context ↑ 模型选择困难 ↑ 错误率 ↑ 成本 ↑所以 Agent 开始从“我有什么工具”进化到“我当前应该暴露什么工具”这已经进入Context Engineering范畴了。十、MiddlewareLangChain Agent 最值得深入研究的部分如果已经理解 Tool Calling那么下一阶段最值得研究的是 Middleware。因为 Middleware 开始承担过去大量散落在 AgentExecutor、Callback、Prompt、业务代码里的控制逻辑。文档明确列出了 Middleware 可以做的事情模型调用前处理 State消息裁剪Context 注入修改 / 验证模型输出GuardrailsTool Error Handling动态模型选择动态工具选择日志监控分析可以把 Middleware 理解成Agent 的“控制平面”。十一、为什么 Middleware 很重要传统 AgentAgent │ ├── LLM │ ├── Tools │ └── Loop现在Agent │ ┌───────────┼───────────┐ ↓ ↓ ↓ before_model model after_model │ │ │ │ └────── Middleware ─────┘ │ ↓ Tool Call │ ↓ wrap_tool_call于是可以插入Context Engineering Security Permission Guardrails Retry Logging Model Routing Tool Routing Human Approval Cost Control而不用修改 Agent Loop 本身。这就是优秀 Harness 的典型特征核心循环稳定外围能力通过 Middleware 插拔。十二、Model 也可以动态选择这一点符合我最近关注的Routing / Cost / Latency例如简单问题 ↓ GPT-4.1-mini 复杂问题 ↓ GPT-4.1 超复杂任务 ↓ 更强模型LangChain 可以通过wrap_model_call在运行时修改request.override(modelmodel)官方文档给出的例子就是根据消息数量选择不同模型。因此Agent │ ├── Simple Task → Cheap Model │ ├── Medium Task → Normal Model │ └── Complex Task → Strong Model这已经不是单纯的 Prompt Engineering而是Agent Runtime Engineering。十三、StateAgent 的“工作内存”这是另外一个非常关键的概念。LangChain 文档明确指出所有 Agent 都有 State其中包含消息序列。除此之外还可以扩展自定义 State。例如classCustomState(AgentState):user_preferences:dict于是State ├── messages ├── user_preferences ├── task_status ├── authentication ├── intermediate_results ├── ...这就比chat history高级得多。十四、区分 State、Context、MemoryLangChain 其实给出了一个很好的工程化分层。1. State当前 Agent 执行过程中的状态本次任务 当前消息 中间结果 任务状态类似工作内存。2. Context运行时注入的信息user_id user_role permissions tenant environment feature flags它告诉 Agent“你现在是在什么环境下工作”3. Memory跨执行 / 跨会话保存的信息。例如用户喜欢技术解释 用户之前完成过什么任务 用户长期偏好 历史知识文档明确把 Agent State 中的信息称为短期记忆而跨会话持久化属于长期记忆体系。因此可以画成Agent │ ┌─────────┼─────────┐ │ │ │ State Context Memory │ │ │ 当前工作 当前环境 长期经验 │ │ │ └─────────┴─────────┘ ↓ LLM这个模型非常值得记下来。十五、Structured OutputAgent 不一定最终输出文本这是另外一个重要变化。Agent 不一定LLM → 一段文字还可以LLM ↓ Structured Output ↓ Pydantic Schema例如classContactInfo(BaseModel):name:stremail:strphone:str最后result[structured_response]得到结构化对象。LangChain 现在区分ProviderStrategy和ToolStrategy如果模型提供原生 Structured Output优先使用 ProviderStrategy否则可以使用 ToolStrategy。文档还说明 LangChain 1.0 在直接传入 schema 时会根据模型能力自动选择/回退。这对于做AI 应用工程非常重要。因为生产系统通常不能只接受“我认为这个学生可能存在……”而需要{knowledge_points:[],error_type:,confidence:0.92,recommendations:[]}十六、Streaming为什么 Agent 必须支持过程可见普通 LLM请求 ↓ 等待 ↓ 答案Agent请求 ↓ 思考 ↓ Search ↓ 结果 ↓ 分析 ↓ Database ↓ 结果 ↓ 最终答案如果用户只能看到…… …… ……体验会非常差。所以 Agent 需要Agent.stream()让用户看到正在搜索…… 正在分析…… 正在查询…… 正在生成……LangChain 的stream()可以把 Agent 执行过程中的 State / 消息逐步输出。十七、LangGraph 为什么出现了现在可以回答之前的一个问题LangChain 和 LangGraph 到底是什么关系可以理解成LangChain │ │ 提供 ↓ Models Tools Messages Agents Middleware Structured Output │ ↓ LangGraph │ │ 提供 ↓ Stateful Execution Runtime Graph Nodes Edges Persistence Streaming Human-in-the-loop而现在create_agent(...)本身就是建立在 LangGraph 之上的。LangChain 文档明确说明create_agent使用 LangGraph 构建图式 Agent Runtime。“LangChain 和 LangGraph 的代码实现是不是相互独立”现在可以更准确地理解不是简单的两个平行框架。当前 LangChain Agent 的高级 API 建立在 LangGraph Runtime 之上。十八、把 LangChain Agent 还原成最底层结构如果把所有 API 去掉我认为现在应该脑中保留这个模型┌──────────────┐ │ User │ └──────┬───────┘ ↓ ┌──────────────┐ │ State │ └──────┬───────┘ ↓ ┌──────────────────┐ │ Middleware │ │ Context / Guard │ │ Routing / Policy │ └────────┬─────────┘ ↓ ┌──────────────┐ │ LLM │ │ Decision │ └──────┬───────┘ ↓ Tool Call? ↙ ↘ Yes No ↓ ↓ ┌────────────┐ Final Answer │ Tool │ └─────┬──────┘ ↓ Tool Result ↓ State │ └─────────────→ LLM ↑ │ Agent Loop这就是 Agent。十九、所以 Agent 和 Workflow 的真正区别是什么WorkflowA → B → C → D路径主要由程序员决定。例如上传简历 ↓ OCR ↓ 提取信息 ↓ 生成评价 ↓ 输出Agent┌→ Search │ LLM → 决策 ────┼→ Database │ ├→ Calculator │ └→ API ↓ Result ↓ LLM ↓ 再次决策路径不是完全预先固定的。所以Workflow 的核心是“程序控制流程”Agent 的核心是“模型参与流程决策”。但注意不是所有任务都应该 Agent 化。确定性强的流程Workflow更合适。不确定性高需要观察 → 决策 → 行动 → 再观察的任务Agent更合适。二十、LangChain 这套设计真正的“哲学变化”这套 Agent 最重要的变化不是 API而是从“帮模型调用工具”变成“构建一个可控制的 AI Runtime”以前LLM Tools现在LLM Tools State Context Middleware Runtime Memory Structured Output Streaming Observability这就是从AI Demo走向AI Application Engineering二十一、这和 Deep Agents 是什么关系这个关系非常重要。可以这样理解AI Application │ ┌──────────┴──────────┐ │ │ Workflow Agent │ LangChain Agent │ LangGraph Runtime │ ┌─────┴─────┐ │ │ State Tools │ │ Middleware Context │ Agent Loop │ ↓ Deep AgentsDeep Agents 并不是另一种完全不同的 Agent。它是在 Agent Runtime 之上进一步解决长任务 复杂任务 任务拆解 上下文管理 文件系统 Subagents Skills Memory Human-in-the-loop等问题。Deep Agents Agent Harness 针对复杂长任务的一种进一步工程化这个理解是成立的。二十二、对于学习路线建议重新建立这张知识地图不要再把LangChain LangGraph Agent Deep Agents MCP Context Engineering Skills Memory看成一堆孤立知识点。应该这样理解AI Application │ ┌─────────────┴─────────────┐ │ │ Workflow Agent │ │ 固定流程 LLM参与决策 │ Agent Loop │ ┌───────────┴──────────┐ │ │ LangChain LangGraph │ │ Agent API / Tools Runtime / State │ │ └──────────┬───────────┘ │ Middleware │ ┌─────────────────┼──────────────┐ ↓ ↓ ↓ Context Memory Tools │ │ │ └─────────────────┼──────────────┘ ↓ Complex Agent ↓ Deep Agents │ ┌───────────────────┼─────────────────┐ ↓ ↓ ↓ Skills Subagents Filesystem │ │ │ └───────────────────┼─────────────────┘ ↓ Long-horizon Tasks二十三、真正应该记住的 8 个关键词不要死记 API。记这 8 个词概念一句话理解LLM决策大脑Tool行动能力Agent Loop决策→行动→观察→再决策State当前工作记忆Context当前运行环境MiddlewareAgent 控制层Runtime真正负责执行 AgentLangGraphStateful Agent Runtime然后再往上Deep Agents 在上述 Agent Runtime 之上 进一步解决复杂、长期、开放式任务。二十四、最重要的一个启示之前有一句非常关键的话Agent LLM Harness现在结合 LangChain可以把它升级成Agent LLM HarnessLangChain/LangGraph 是构建这个 Harness 的工程化框架。其中LLM 负责“想” Tools 负责“做” State 负责“记住当前工作” Context 负责“知道自己处于什么环境” Middleware 负责“管” Agent Loop 负责“不断想—做—观察” LangGraph 负责“跑起来” LangSmith 负责“看得见、调得动、评得了”这其实已经非常接近我一直在寻找的Agent 本质模型。尤其值得注意的是LangChain 当前文档已经把Middleware、State、动态模型、动态工具、结构化输出、Streaming、Runtime都放进 Agent 的核心体系而不是把 Agent 简化成一个LLM Tool的 Demo。最后给一个“学习优先级”如果继续深挖 LangChain建议顺序不要按官网菜单走而是① Agent Loop↓② Tool Calling↓③ State / Context↓④ Middleware↓⑤ LangGraph Runtime↓⑥ Memory↓⑦ Human-in-the-loop / Guardrails↓⑧ Structured Output↓⑨ MCP↓⑩ Deep Agents这样会从“会用 LangChain”逐渐进入“理解 Agent 是怎么运行的”再进入“能够自己设计 Agent Harness”这才是最值得建立的能力。 Agent 详解
早期 LangChain 那种“Agent AgentExecutor Tools”的思路已经明显转向了Agent LLM Tools State Middleware Runtime LangGraph 执行循环一、先说结论如果让我用一句话概括当前 AgentLangChain 的 Agent本质上不是“一个会调用工具的大模型”而是一个由 LLM 驱动、以 State 为上下文、以 Tools 为行动能力、以 Middleware 为控制层、由 LangGraph 负责循环执行的动态决策系统。官方文档明确指出create_agent创建的是生产级 Agent并且底层使用LangGraph 构建图式 Agent Runtime。Agent 会在模型节点、工具节点以及中间件之间循环直到模型给出最终结果或者达到迭代限制。DeepSeek 给出Agent LLM Harness是一个非常好的上层抽象。而如果落到 LangChain 1.x 的工程实现可以进一步拆成Agent │ ┌──────────┴──────────┐ │ │ LLM Harness 决策/推理能力 │ ├── Tools ├── State ├── Middleware ├── Runtime ├── Memory ├── Guardrails ├── Streaming └── Execution Loop │ LangGraph这才是现在值得真正掌握的 Agent 架构。二、LangChain 对 Agent 的定义官方文档给出了非常关键的定义Agent 将语言模型与工具结合使系统能够推理任务、决定使用哪些工具并迭代寻求解决方案。这里面有三个动作理解任务 ↓ 决定下一步行动 ↓ 执行行动 ↓ 观察结果 ↓ 再次决定 ↓ ……也就是LLM ↓ Tool Call ↓ Tool Result ↓ LLM ↓ Tool Call ↓ Tool Result ↓ LLM ↓ Final Answer这就是经典的Agent Loop / ReAct Loop。官方文档也直接用 ReAct 描述这一过程模型在“推理—行动—观察”之间循环直到能够给出最终答案。三、真正理解 Agent关键不是create_agent很多初学者看到agentcreate_agent(model,toolstools)会觉得“这么简单Agent 不就是这个吗”其实完全不是。create_agent()更像一个装配器 / Agent Factory。你告诉它用哪个 LLM 有哪些工具 有什么系统提示 有什么状态 有哪些 Middleware 如何输出它组装出一个可以运行的 Agent。真正重要的是create_agent ↓ LangGraph Runtime ↓ Agent Loop ↓ Model ↕ Tools ↕ State所以可以把create_agent(...)理解为“创建一个 Agent Runtime”而不是“调用一个超级 Agent 函数”。四、Agent 最核心的东西循环这是学习 Agent 最应该吃透的一部分。假设用户帮我找目前最热门的无线耳机并确认库存。Agent 并不是用户 ↓ LLM ↓ 答案而是用户问题 ↓ ┌─────────────┐ │ LLM │ │ 当前应该做什么│ └──────┬──────┘ │ ↓ Tool Call │ ↓ ┌─────────────┐ │ Search Tool │ └──────┬──────┘ │ ↓ Search Result │ ↓ ┌─────────────┐ │ LLM │ │ 下一步做什么 │ └──────┬──────┘ │ ↓ Inventory Tool │ ↓ Inventory Result │ ↓ ┌─────────────┐ │ LLM │ │ 是否完成 │ └──────┬──────┘ │ ↓ Final Answer这就是 Agent。五、那么LLM 到底是怎么“决定下一步”的“LLM 明明只是文字输出它怎么决定下一步做什么”答案是不是 LLM 自己直接执行下一步。而是LLM │ │ 输出 Tool Call ↓ Agent Runtime │ 判断这是工具调用 ↓ Tool Node │ ↓ 执行 Python │ ↓ Tool Result │ ↓ 写入 State │ ↓ LLM例如模型输出的不是我现在去搜索一下。而是结构化的{tool:search_products,arguments:{query:wireless headphones}}Agent Runtime 看到这个 Tool Calltool search_products于是search_products(...)真正执行。所以LLM 负责“决策”Runtime 负责“执行”。这就是 Agent 和普通 LLM Chat 的根本区别之一。六、这也解释了前面的“LLM Harness”现在可以把这个概念讲得非常清楚LLM负责理解 推理 规划 选择工具 判断下一步 生成最终答案Harness负责状态管理 工具执行 循环控制 权限 错误处理 上下文管理 记忆 Middleware Human-in-the-loop 日志 监控 停止条件所以Agent │ ┌──────┴──────┐ │ │ LLM Harness │ │ │ ┌─────┼─────────┐ │ │ │ │ │ State Tools Middleware │ │ │ │ │ │ Runtime Guardrail │ │ │ └───────┴───────────────┘这比“Agent LLM Tools”准确得多。七、ToolsAgent 的“手和脚”LangChain 对 Tool 的设计也值得注意。普通 LLM输入 → 输出Agent输入 ↓ LLM ↓ 决定调用 Tool ↓ Tool ↓ 环境发生变化 / 获得信息 ↓ LLMTool 赋予 AgentAction 能力。例如tooldefsearch(query:str):...它本质上就是Tool Schema ↓ 告诉 LLM “你可以使用这个能力”模型看到search(query: string)之后就可以决定我要不要调用 search 调用什么参数 调用几次 什么时候停止八、非常重要Tool ≠ Function Calling这两个概念很多人混淆。Function Calling是模型能力LLM ↓ 产生结构化函数调用Tool是实际能力Tool ↓ 真正执行函数所以Agent │ ↓ LLM │ Function Calling │ ↓ Tool Call │ ↓ Tool Runtime │ ↓ Python/API/MCP可以把Function Calling 看成“发号施令”。而Tool 是“真正干活”。九、LangChain 现在特别强调“动态 Tools”这是官方文档非常值得注意的一个变化。过去tools[search,calculator,weather,database,email]Agent 永远看到这些工具。现在 LangChain 支持根据 State / Store / Runtime Context 动态决定当前给 Agent 哪些工具。例如用户未登录 ↓ 只能 search read_public_data 用户登录 ↓ 增加 read_private_data 管理员 ↓ 增加 write_data delete_data文档给出的 Middleware 示例就是根据认证状态、对话阶段、Store 中的 Feature Flag、用户角色等动态过滤工具。这个设计其实非常重要。因为工具不是越多越好。工具太多Context ↑ 模型选择困难 ↑ 错误率 ↑ 成本 ↑所以 Agent 开始从“我有什么工具”进化到“我当前应该暴露什么工具”这已经进入Context Engineering范畴了。十、MiddlewareLangChain Agent 最值得深入研究的部分如果已经理解 Tool Calling那么下一阶段最值得研究的是 Middleware。因为 Middleware 开始承担过去大量散落在 AgentExecutor、Callback、Prompt、业务代码里的控制逻辑。文档明确列出了 Middleware 可以做的事情模型调用前处理 State消息裁剪Context 注入修改 / 验证模型输出GuardrailsTool Error Handling动态模型选择动态工具选择日志监控分析可以把 Middleware 理解成Agent 的“控制平面”。十一、为什么 Middleware 很重要传统 AgentAgent │ ├── LLM │ ├── Tools │ └── Loop现在Agent │ ┌───────────┼───────────┐ ↓ ↓ ↓ before_model model after_model │ │ │ │ └────── Middleware ─────┘ │ ↓ Tool Call │ ↓ wrap_tool_call于是可以插入Context Engineering Security Permission Guardrails Retry Logging Model Routing Tool Routing Human Approval Cost Control而不用修改 Agent Loop 本身。这就是优秀 Harness 的典型特征核心循环稳定外围能力通过 Middleware 插拔。十二、Model 也可以动态选择这一点符合我最近关注的Routing / Cost / Latency例如简单问题 ↓ GPT-4.1-mini 复杂问题 ↓ GPT-4.1 超复杂任务 ↓ 更强模型LangChain 可以通过wrap_model_call在运行时修改request.override(modelmodel)官方文档给出的例子就是根据消息数量选择不同模型。因此Agent │ ├── Simple Task → Cheap Model │ ├── Medium Task → Normal Model │ └── Complex Task → Strong Model这已经不是单纯的 Prompt Engineering而是Agent Runtime Engineering。十三、StateAgent 的“工作内存”这是另外一个非常关键的概念。LangChain 文档明确指出所有 Agent 都有 State其中包含消息序列。除此之外还可以扩展自定义 State。例如classCustomState(AgentState):user_preferences:dict于是State ├── messages ├── user_preferences ├── task_status ├── authentication ├── intermediate_results ├── ...这就比chat history高级得多。十四、区分 State、Context、MemoryLangChain 其实给出了一个很好的工程化分层。1. State当前 Agent 执行过程中的状态本次任务 当前消息 中间结果 任务状态类似工作内存。2. Context运行时注入的信息user_id user_role permissions tenant environment feature flags它告诉 Agent“你现在是在什么环境下工作”3. Memory跨执行 / 跨会话保存的信息。例如用户喜欢技术解释 用户之前完成过什么任务 用户长期偏好 历史知识文档明确把 Agent State 中的信息称为短期记忆而跨会话持久化属于长期记忆体系。因此可以画成Agent │ ┌─────────┼─────────┐ │ │ │ State Context Memory │ │ │ 当前工作 当前环境 长期经验 │ │ │ └─────────┴─────────┘ ↓ LLM这个模型非常值得记下来。十五、Structured OutputAgent 不一定最终输出文本这是另外一个重要变化。Agent 不一定LLM → 一段文字还可以LLM ↓ Structured Output ↓ Pydantic Schema例如classContactInfo(BaseModel):name:stremail:strphone:str最后result[structured_response]得到结构化对象。LangChain 现在区分ProviderStrategy和ToolStrategy如果模型提供原生 Structured Output优先使用 ProviderStrategy否则可以使用 ToolStrategy。文档还说明 LangChain 1.0 在直接传入 schema 时会根据模型能力自动选择/回退。这对于做AI 应用工程非常重要。因为生产系统通常不能只接受“我认为这个学生可能存在……”而需要{knowledge_points:[],error_type:,confidence:0.92,recommendations:[]}十六、Streaming为什么 Agent 必须支持过程可见普通 LLM请求 ↓ 等待 ↓ 答案Agent请求 ↓ 思考 ↓ Search ↓ 结果 ↓ 分析 ↓ Database ↓ 结果 ↓ 最终答案如果用户只能看到…… …… ……体验会非常差。所以 Agent 需要Agent.stream()让用户看到正在搜索…… 正在分析…… 正在查询…… 正在生成……LangChain 的stream()可以把 Agent 执行过程中的 State / 消息逐步输出。十七、LangGraph 为什么出现了现在可以回答之前的一个问题LangChain 和 LangGraph 到底是什么关系可以理解成LangChain │ │ 提供 ↓ Models Tools Messages Agents Middleware Structured Output │ ↓ LangGraph │ │ 提供 ↓ Stateful Execution Runtime Graph Nodes Edges Persistence Streaming Human-in-the-loop而现在create_agent(...)本身就是建立在 LangGraph 之上的。LangChain 文档明确说明create_agent使用 LangGraph 构建图式 Agent Runtime。“LangChain 和 LangGraph 的代码实现是不是相互独立”现在可以更准确地理解不是简单的两个平行框架。当前 LangChain Agent 的高级 API 建立在 LangGraph Runtime 之上。十八、把 LangChain Agent 还原成最底层结构如果把所有 API 去掉我认为现在应该脑中保留这个模型┌──────────────┐ │ User │ └──────┬───────┘ ↓ ┌──────────────┐ │ State │ └──────┬───────┘ ↓ ┌──────────────────┐ │ Middleware │ │ Context / Guard │ │ Routing / Policy │ └────────┬─────────┘ ↓ ┌──────────────┐ │ LLM │ │ Decision │ └──────┬───────┘ ↓ Tool Call? ↙ ↘ Yes No ↓ ↓ ┌────────────┐ Final Answer │ Tool │ └─────┬──────┘ ↓ Tool Result ↓ State │ └─────────────→ LLM ↑ │ Agent Loop这就是 Agent。十九、所以 Agent 和 Workflow 的真正区别是什么WorkflowA → B → C → D路径主要由程序员决定。例如上传简历 ↓ OCR ↓ 提取信息 ↓ 生成评价 ↓ 输出Agent┌→ Search │ LLM → 决策 ────┼→ Database │ ├→ Calculator │ └→ API ↓ Result ↓ LLM ↓ 再次决策路径不是完全预先固定的。所以Workflow 的核心是“程序控制流程”Agent 的核心是“模型参与流程决策”。但注意不是所有任务都应该 Agent 化。确定性强的流程Workflow更合适。不确定性高需要观察 → 决策 → 行动 → 再观察的任务Agent更合适。二十、LangChain 这套设计真正的“哲学变化”这套 Agent 最重要的变化不是 API而是从“帮模型调用工具”变成“构建一个可控制的 AI Runtime”以前LLM Tools现在LLM Tools State Context Middleware Runtime Memory Structured Output Streaming Observability这就是从AI Demo走向AI Application Engineering二十一、这和 Deep Agents 是什么关系这个关系非常重要。可以这样理解AI Application │ ┌──────────┴──────────┐ │ │ Workflow Agent │ LangChain Agent │ LangGraph Runtime │ ┌─────┴─────┐ │ │ State Tools │ │ Middleware Context │ Agent Loop │ ↓ Deep AgentsDeep Agents 并不是另一种完全不同的 Agent。它是在 Agent Runtime 之上进一步解决长任务 复杂任务 任务拆解 上下文管理 文件系统 Subagents Skills Memory Human-in-the-loop等问题。Deep Agents Agent Harness 针对复杂长任务的一种进一步工程化这个理解是成立的。二十二、对于学习路线建议重新建立这张知识地图不要再把LangChain LangGraph Agent Deep Agents MCP Context Engineering Skills Memory看成一堆孤立知识点。应该这样理解AI Application │ ┌─────────────┴─────────────┐ │ │ Workflow Agent │ │ 固定流程 LLM参与决策 │ Agent Loop │ ┌───────────┴──────────┐ │ │ LangChain LangGraph │ │ Agent API / Tools Runtime / State │ │ └──────────┬───────────┘ │ Middleware │ ┌─────────────────┼──────────────┐ ↓ ↓ ↓ Context Memory Tools │ │ │ └─────────────────┼──────────────┘ ↓ Complex Agent ↓ Deep Agents │ ┌───────────────────┼─────────────────┐ ↓ ↓ ↓ Skills Subagents Filesystem │ │ │ └───────────────────┼─────────────────┘ ↓ Long-horizon Tasks二十三、真正应该记住的 8 个关键词不要死记 API。记这 8 个词概念一句话理解LLM决策大脑Tool行动能力Agent Loop决策→行动→观察→再决策State当前工作记忆Context当前运行环境MiddlewareAgent 控制层Runtime真正负责执行 AgentLangGraphStateful Agent Runtime然后再往上Deep Agents 在上述 Agent Runtime 之上 进一步解决复杂、长期、开放式任务。二十四、最重要的一个启示之前有一句非常关键的话Agent LLM Harness现在结合 LangChain可以把它升级成Agent LLM HarnessLangChain/LangGraph 是构建这个 Harness 的工程化框架。其中LLM 负责“想” Tools 负责“做” State 负责“记住当前工作” Context 负责“知道自己处于什么环境” Middleware 负责“管” Agent Loop 负责“不断想—做—观察” LangGraph 负责“跑起来” LangSmith 负责“看得见、调得动、评得了”这其实已经非常接近我一直在寻找的Agent 本质模型。尤其值得注意的是LangChain 当前文档已经把Middleware、State、动态模型、动态工具、结构化输出、Streaming、Runtime都放进 Agent 的核心体系而不是把 Agent 简化成一个LLM Tool的 Demo。最后给一个“学习优先级”如果继续深挖 LangChain建议顺序不要按官网菜单走而是① Agent Loop↓② Tool Calling↓③ State / Context↓④ Middleware↓⑤ LangGraph Runtime↓⑥ Memory↓⑦ Human-in-the-loop / Guardrails↓⑧ Structured Output↓⑨ MCP↓⑩ Deep Agents这样会从“会用 LangChain”逐渐进入“理解 Agent 是怎么运行的”再进入“能够自己设计 Agent Harness”这才是最值得建立的能力。