核心要点
- 不同业务场景需要不同 agent harness，middleware 是定制核心循环的关键机制。
- LangChain 的 AgentMiddleware 提供 before_agent、before_model、wrap_model_call、wrap_tool_call 等钩子。
- 它让开发者可以在不重写整个 agent loop 的情况下，插入记忆加载、PII 检查、重试、缓存、工具管控等逻辑。
- 本质上，middleware 是把“可定制 harness”做成产品化接口。
原文链接 English Original — LangChain Blog, by Sydney Runkle
这篇文章讨论的是一个非常实际的问题：当你基于 LangChain 或 Deep Agents 构建 agent 时，往往并不满足于“默认 loop”，你总想在执行前后插一点自己的逻辑。问题在于，instructions 和 tools 很容易改，但一旦需求涉及 agent core loop，本来就难了。LangChain 给出的答案就是 AgentMiddleware。 作者先回到 agent harness 的基本定义：agent 是围绕模型搭建的一套系统，负责连接环境、数据、记忆和工具。其核心形式虽然简单——LLM 在循环中调用工具——但真正的业务系统几乎总会在这个循环周围加入规则。比如，调用模型前先裁剪历史；工具执行后检查返回；运行开始前加载 memory；或者根据请求动态切换模型和工具集。 Middleware 的价值在于，它把这些“想改 loop 但又不想重写引擎”的需求，抽象成了标准钩子。文中列出的四类钩子很典型：before_agent 用于启动前准备，before_model 用于每次模型调用前的预处理，wrap_model_call 用于包裹整个模型调用过程，wrap_tool_call 则负责包裹工具调用。通过这些接口，开发者能很自然地加入缓存、重试、权限控制、上下文注入、输出拦截等行为。 这实际上体现了 harness engineering 的一个重要方向：不是每个团队都要自己重写 agent runtime，而是需要一个足够开放的扩展点体系。 Middleware 就是这种扩展点。它让底层 harness 保持稳定，同时让上层业务可以按需插入行业规则、合规策略和工程保障。 从工程实践看，这篇文章等于在说：可用的 agent 框架，不只是“能跑起来”，更要“能被团队定制”。而 middleware，正是这种可定制性的主要承载层。