LangChain Middleware：Agent 里的 AOP 治理层

一、Agent 不是只会调用工具就够了

在大模型应用刚开始落地时，很多人会把 Agent 理解成“模型 + 工具调用”。模型根据用户问题判断要不要调用工具，工具执行后再把结果交给模型，最后生成回答。这个理解没有错，但它只覆盖了 Agent 最基础的运行闭环。

一旦 Agent 从 Demo 走向真实业务系统，问题会马上变复杂。

模型调用失败了怎么办？工具调用超时了怎么办？模型反复调用工具导致成本失控怎么办？用户输入里包含手机号、邮箱、API Key 等敏感信息怎么办？某些工具是否需要人工审批？多个工具都能执行时，模型是否有权限调用所有工具？一次 Agent 执行过程里调用了几次模型、几次工具、耗费多少 token，又如何追踪和审计？

一这些问题不属于某一个具体 Tool，也不应该散落在业务代码里。它们更像 Java 后端系统里的日志、权限、限流、重试、事务、监控等横切能力。

所以，LangChain Middleware 的价值不是“多了几个 hook”，而是给 Agent 执行流程提供了一层治理能力。它在 Agent 的模型调用、工具调用和状态流转过程中插入拦截逻辑，把业务推理和工程治理拆开。LangChain Middleware 很像 Spring 里的 AOP。

二、没有 Middleware 的 Agent 会遇到什么问题

（1）横切逻辑会重复

比如每个工具都要记录调用日志、参数摘要、耗时、异常；每个模型调用都要统计 token、处理超时、支持重试；每个高风险工具都要做权限判断。

如果这些逻辑写在每个 Tool 或每个 Agent 里，代码很快会膨胀，而且不同 Agent 的治理策略很难保持一致。

（2）Agent 行为不可控

Agent 的执行路径不是完全固定的。模型可能多次调用工具，也可能因为工具返回不清晰而不断重新请求模型。

如果没有统一的调用次数限制、工具调用限制、上下文裁剪和失败兜底，Agent 很容易出现成本失控、上下文超限或工具循环调用。

（3）生产治理没有统一入口

企业级 AI 应用必须考虑安全、审计、权限、PII 脱敏、模型 fallback、人工审批、可观测性。

这些能力如果没有统一入口，就只能靠业务代码到处补丁式处理，最后系统会变得难以维护。

Middleware 要解决的就是这个问题：在 Agent 执行图中提供统一的拦截点。

三、Middleware 在 Agent 执行流程里的位置

LangChain 1.x 之后，create_agent 创建出来的 Agent 并不是一个简单函数，而是运行在 LangGraph 之上的执行图。这个图里包含模型节点、工具节点、状态更新和循环判断。

Middleware 会被注入到这个执行图的关键位置

四、和 Spring AOP 的类比

在 Spring AOP 中，@Around 最强，因为它可以决定目标方法是否继续执行。

LangChain 里也是一样。wrap_model_call 和 wrap_tool_call 是治理模型调用和工具调用的关键入口。例如模型失