LangChain 工具调用错误：arg1 参数异常解决方法

LangChain 代理在调用自定义工具时意外传入 `arg1` 参数，导致 `TypeError`，根本原因是工具签名未被正确识别——使用 `BaseTool` 子类时未声明 `args_schema`，而 LangChain v0.1+ 默认采用 Pydantic 模型解析参数，需显式定义输入结构。

在 LangChain（尤其是 v0.1.x 及以上版本）中，当 Agent 执行工具调用时，它不再简单地将字典解包为位置参数，而是基于工具的输入 schema 进行结构化解析。若你继承 BaseTool 但未定义 args_schema，LangChain 会 fallback 到一个默认行为：将传入的单个参数字典（如 {'arg1': '...'}）强行映射为名为 arg1 的关键字参数，从而引发 _run() 方法接收未声明参数的错误。

✅ 正确做法：为 BaseTool 显式声明 args_schema

你需要使用 Pydantic BaseModel 定义输入结构，并将其赋值给 args_schema 类属性：

from langchain.tools import BaseTool
from pydantic import BaseModel, Field

class SQLFilterInput(BaseModel):
    query_input: str = Field(..., description="用户自然语言查询，例如 '2023年8月计算机设备的平均温度'")

class SQLFilterTool(BaseTool):
    name = "filter_user_query"
    description = "根据用户自然语言问题生成结构化SQL过滤条件（用于后端数据筛选）"
    args_schema: type[BaseModel] = SQLFilterInput  # ← 关键！必须显式声明

    def _run(self, query_input: str) -> str:
        return sql_filter_vanna(query_input)

    async def _arun(self, query_input: str) -> str:
        # 注意：_arun 应为 async def，且返回 awaitable 或使用 asyncio.to_thread（如需同步函数）
        return await asyncio.to_thread(sql_filter_vanna, query_input)

⚠️ 注意事项：

• args_schema 必须是 pydantic.BaseModel 的子类，字段名需与 _run 方法参数名严格一致（此处为 query_input）；
• 若 _run 接收多个参数（如 query_input: str, db_name: str），则 SQLFilterInput 中需对应定义全部字段；
• async def _arun 的签名也应与 _run 保持语义一致（参数名可不同，但逻辑输入应匹配）；

✅ 更简洁方案：优先使用 @tool 装饰器（推荐）

正如答案中所示，@tool 是 LangChain 官方推荐的轻量级工具定义方式，它自动推导 schema（基于类型注解 + docstring），无需手动管理 BaseModel：

from langchain.agents import tool

@tool
def filter_user_query(query_input: str) -> str:
    """根据用户自然语言问题生成SQL过滤条件。

    例如输入："2023年8月计算机设备的平均温度" → 输出："WHERE device_type = 'computer' AND month = 8 AND year = 2023"
    """
    return sql_filter_vanna(query_input)

该方式自动注册为 Tool 实例，支持多参数、类型校验、描述提取，且与最新 Agent（如 OpenAIToolsAgent、ReactAgent）完全兼容。

? 补充说明：为什么之前能运行，现在报错？

• 你提到“几天前代码正常”，大概率是升级了 LangChain 版本（如从 0.0.x 升至 0.1.0+）；
• 旧版 LangChain 对 BaseTool 的参数解析较宽松，新版强化了 schema 驱动机制以提升可靠性与可调试性；
• @tool 装饰器在各版本中行为更稳定，是生产环境首选。

✅ 总结

选择 @tool 可大幅降低维护成本，避免隐式参数映射陷阱。如需扩展功能（如异步支持、自定义序列化），再考虑 BaseTool 并严格遵循 schema 规范。