Add `ToolArgValidationMiddleware` — a new agent middleware that validates LLM-generated tool-call arguments

快速结论：这不是一个运行时报错，而是关于 Add `ToolArgValidationMiddleware` — a new agent middleware that validates LLM-generated tool-call arguments 的功能请求（feature request）。如果你在找官方的工具参数校验中间件，结论是 LangChain 核心库暂时不会合并该中间件，需要改用社区独立包。

适用环境：Issue 中确认的包为 langchain，工具为 LangChain create_agent() / agent middleware 体系。Issue 未提供操作系统、Python、CUDA、显卡等环境信息。

最快修复方案：暂无确认的一步修复方案。Issue 中明确验证过的首选处理方式是：该中间件已由作者发布为独立包 langchain-tool-args-validation-middleware（PyPI 0.1.0），可作为 create_agent() 的 middleware 参数直接使用；核心库合并请求未通过。

注意事项：独立包属于社区实现，不在 LangChain 核心团队维护范围内，版本兼容性与长期维护需要自行评估。Issue 中给出的 pip install YOUR-PACKAGE 与 from YOUR_PACKAGE import YOURMODULE 是官方维护者示范用的占位写法，替换时应以实际包名和模块名为准。

问题场景

用户在使用 LangChain 构建 agent（尤其是通过 create_agent() 组装模型与工具）时，希望在做工具调用前校验 LLM 生成的 tool-call 参数是否满足工具 schema。典型触发场景包括：

LLM 生成缺必填字段、类型错误、夹带空值或多余 key 的 tool-call 参数，直到工具节点执行才暴露错误。
使用 MCP 工具，JSON Schema 复杂，模型没有针对该 schema 微调过。
多步 agentic loop 中，一次错误的 tool call 让整个任务跑偏。
Human-in-the-loop 工作流中，格式明显错误的参数被提交给用户审批。

用户希望有一个标准、可复用的中间件，在模型边界（工具执行或 HITL 之前）完成校验与重试，而不是自己写校验逻辑或接受工具层失败。

报错原文

Add `ToolArgValidationMiddleware` — a new agent middleware that validates LLM-generated tool-call arguments

该条为 Issue 标题中的功能描述文本，并非运行时报错堆栈。Issue 正文中未附加任何异常输出或 traceback。

原因分析

这不是 bug，而是功能缺失（feature gap）。最可能的原因是：LangChain 核心库当前没有内置的参数校验中间件，用户需要一个在 wrap_model_call / awrap_model_call 层拦截模型响应、对每个 tool call 做 schema 校验并在失败时回灌错误信息让模型自我修正的组件。

Issue 中提出的技术方案要点为：

继承 AgentMiddleware，实现 wrap_model_call 与 awrap_model_call。
首次调用时从 request.tools 惰性解析并缓存工具 schema。
Pydantic 类工具（@tool 创建或带 BaseModel 的 args_schema）用 BaseModel.model_validate 校验。
MCP / dict-schema 工具（args_schema 为原始 JSON Schema dict）用 jsonschema（软依赖，默认 Draft7Validator，可配置）校验。
校验失败时追加描述错误的 ToolMessage 并重新调用模型，重试循环全部位于 model node 内部，只有最终合法的 AIMessage 进入 graph state。
可配置项：max_retries（默认 2）、strip_empty_values（默认 True，递归移除 None / {} / []）、json_schema_validator_class（默认 None → Draft7Validator）。

环境排查

确认你使用的 LangChain 包：Issue 标注为 langchain。
确认 AgentMiddleware 中间件接口的可用性——维护者在 Issue 中表示该接口是公开且稳定的。
确认模型接入方式（Issue 示例使用 anthropic:claude-opus-4-6，仅作演示）。
若采用独立包方案，确认 PyPI 包 langchain-tool-args-validation-middleware 的版本（Issue 中发布版本为 0.1.0）与本地 LangChain 版本的兼容性。
若使用 dict-schema / MCP 工具校验路径，确认 jsonschema 软依赖是否已安装。
Issue 未提供操作系统、Python、CUDA、PyTorch、显卡等信息，无需在这些方向排查。

解决步骤

先明确预期：该中间件不会被合入 langchain 核心库。维护者给出的理由是仓库已经非常拥挤、依赖面大，每新增一个中间件都会增加核心团队的维护负担。
按维护者建议，将方案作为独立包发布到 PyPI 使用。维护者示范的接入形式如下（注意 YOUR-PACKAGE / YOURMODULE / key=value 为占位符，需替换为实际值）：

pip install YOUR-PACKAGE

from langchain.agents import create_agent
from YOUR_PACKAGE import YOURMODULE

agent = create_agent(
    model="anthropic:claude-opus-4-6",
    tools=[...],
    middleware=[
        YOURMODULE(
            key=value,
            ...
        ),
    ],
)

采用作者实际发布的独立包：langchain-tool-args-validation-middleware，可通过 GitHub 仓库 Serjbory/langchain-tool-args-validation-middleware 或 PyPI 0.1.0 获取，并按上方的 middleware=[...] 方式接入 create_agent()。
如果你已有自己的实现（Issue 中出现了 PR #36699 与 PR #36722 两条实现线索），注意 PR #36722 的提交者被建议无需继续，因为 PR #36699 已包含同作者的实现思路；最终该方向仍以独立包形式落地。
若你的场景对校验延迟敏感，可优先尝试在部署侧缓存已校验的 schema、编译 validator，或对高频调用做抽样校验——这些是评论中提出的生产建议，非 Issue 官方验证结论。

验证方法

接入中间件后，构造一个参数不合法的 tool call（例如缺少必填字段、类型错误或夹带 None / {} / [] 空值），观察中间件是否在模型边界拦截、追加错误 ToolMessage 并触发模型重试，且只有最终合法的 AIMessage 进入 graph state、工具节点未收到非法参数。Issue 中作者称其实现通过了 14 个单元与端到端测试，覆盖 Pydantic v1/v2 与 JSON Schema 校验；如需确认独立包是否正常工作，建议以其仓库中的测试用例为基准自测。