去年一个做AI招聘平台的团队发了一篇公开复盘他们把生产环境里的 LangChain 卸掉了改成了直接调用 Anthropic 原生 SDK。效果立竿见影——p50 延迟从 2.1 秒降到 1.4 秒p95 延迟从 4.8 秒降到 3.2 秒。这个案例被很多人转发评论区清一色“LangChain 就是过度封装”、“直接调 API 不香吗”。但很少有人追问一句他们卸掉 LangChain 之前用 LangChain 做了什么答案是他们用 LangChain 的 Tools Agent 搭了一套招聘筛选系统对接了 7 个不同的数据源和 4 个第三方 API。在没有 LangChain 的情况下这套系统根本不可能在两周内上线。工具本身有成本但工具解决的问题是你自己手写代码时更大的成本。目录一、大模型什么都懂但什么都做不了二、本质是让 LLM 从“大脑”变成“大脑手脚”三、Tools 机制拆解怎么给大模型装“手脚”四、Agent 机制拆解怎么让大模型自己“决定用哪只手”五、一个测试场景的完整案例六、对你意味着什么七、最后问你一个问题一、大模型什么都懂但什么都做不了ChatGPT 刚出来的时候很多人觉得“以后不用写代码了跟 AI 说一声就行”。现实很快打脸。你跟 GPT-4 说“帮我查一下明天北京的天气然后对比一下后天发邮件告诉我结果”。它能告诉你思路但查不了天气、发不了邮件。它知道怎么查、怎么发但它做不到。大模型的知识边界在参数里行动边界在物理世界和数字系统的接口上。这就是 LangChain Tools 和 Agent 要解决的问题。Tools 给大模型装上了“手”——能查数据库、能调 API、能执行代码。Agent 给大模型装上了“大脑的决策层”——能自己判断什么时候用什么工具、按什么顺序用。很多人一上来就纠结“LangChain 重不重”、“要不要直接调 API”。但他们忽略了一个更基本的问题你需要的是一套可扩展的“工具调用体系”还是一个一次性脚本如果是后者直接调 API 确实更快。但如果是前者——你需要让大模型动态地、组合地调用多个工具——没有 LangChain 这类框架你自己要写的胶水代码比你想象的多得多。大模型的短板从来不是“不知道”而是“做不到”。Tools 解决的是“做到”的问题。二、本质是让 LLM 从“大脑”变成“大脑手脚”先搞清楚一个概念。LangChain 官方对 Agent 的定义很直接用户给 Agent 一个输入消息Agent 进入循环——调用工具、把工具返回结果和 AI 消息加入状态、继续调用直到它决定不再调用任何工具并最终结束。这个循环看似简单但背后解决了一个核心问题大模型本身没有“行动能力”它只会生成文本。Tools 把“行动”封装成可被大模型调用的函数Agent 把“什么时候调用什么工具”的决策权交给了大模型自己。本质上这是在 LLM 外面包了一层“执行器”。LLM 负责推理和决策执行器负责干活。LangChain Agent 框架通过模块化设计把智能 Agent 拆解为三个核心部分工具链Tools、推理引擎Reasoning Engine和执行控制器Execution Controller。工具链是“手脚”——能做什么。推理引擎是“小脑”——怎么做决策。执行控制器是“神经系统”——怎么协调。这三层缺一不可。很多人觉得 LangChain “重”是因为他们把这三层全用了。但如果你只需要“手脚”Tools你可以只用 Tools 层不用 Agent。如果你只需要“小脑”推理你也可以单独用 Prompt 模板。框架重不重取决于你怎么用。Tools 解决“能做什么”Agent 解决“什么时候做”。两个加在一起大模型才有了真正的行动能力。三、Tools 机制拆解怎么给大模型装“手脚”3.1 Tool 的本质是什么在 LangChain 里一个 Tool 本质上就是一个带描述的函数。大模型不直接执行代码。它通过“函数调用”Function Calling协议告诉系统“我想调用这个函数参数是这些”。系统收到指令后在本地执行这个函数把结果返回给大模型。所以 Tool 的核心不是“怎么实现功能”而是“怎么让大模型知道有这个功能、知道什么时候用它”。关键在三个地方name工具的名字要简洁明确description描述这个工具做什么、什么时候该用。大模型靠这个判断要不要调它args_schema参数的结构定义告诉大模型需要传什么参数、什么类型description 写不好工具永远不会被调用。arg_schema 定义不清晰大模型传的参数永远是错的。3.2 三种定义方式方式一tool 装饰器最推荐from langchain_core.tools import tooltooldef get_weather(city: str) - str:“”“获取指定城市的当前天气。参数:city: 城市名称例如 ‘北京’, ‘上海’。“””# 实际场景中替换为 API 调用weather_data {“北京”: “晴天25°C”,“上海”: “多云28°C”,}return weather_data.get(city, f{city} 暂无数据)函数的 docstring 自动成为工具的 description。这是最简洁的方式适合 80% 的场景。方式二继承 BaseTool需要复杂逻辑时适合需要复杂初始化、状态管理或错误处理的场景。方式三Tool 类实例化快速封装现有函数适合快速把已有的函数包装成 Tool不改动原函数代码。3.3 Tool 设计的两条铁律铁律一单一职责。 一个 Tool 只做一件事。登录就是登录查库存就是查库存。不要写一个“万能工具”试图覆盖所有场景。铁律二输入输出都要结构化。 输入用 Pydantic BaseModel 定义 schema输出用 JSON 或明确的字典结构。大模型不懂“随意格式”它只认 Schema。四、Agent 机制拆解怎么让大模型自己“决定用哪只手”有了 Tools下一个问题是谁来决定什么时候用哪个 Tool这就是 Agent 的事。4.1 ReAct 循环推理-行动-观测Agent 的核心执行模式叫 ReAct——Reasoning Acting。具体流程是推理Reasoning 面对用户的问题Agent 先思考“我需要做什么、用什么工具”行动Acting 调用对应的 Tool获取结果观测Observation 分析 Tool 返回的结果判断任务是否完成如果没完成回到步骤 1继续循环这个循环一直持续到 Agent 认为任务完成或者达到最大迭代次数。4.2 上下文工程Agent 可靠性的关键为什么同样的 Agent有时候工作得很好有时候一塌糊涂LangChain 团队在一篇官方博客里点出了核心原因上下文工程Context Engineering 。进入模型的内容决定了模型输出什么。要让 Agent 更可靠你需要对“进入模型的东西”有完全的控制权。具体来说你需要控制Agent 的“状态”里包含什么——不只是对话消息还可以包含连接字符串、用户信息、运行时配置发给模型的提示词是什么——不是写死的字符串而是可以动态生成的函数模型调用前做什么、调用后做什么——比如对话太长时先做摘要再送给模型这些控制点就是 LangChain 1.0 引入的 Middleware 机制要解决的问题。4.3 动态工具选择不是所有工具都要同时可见另一个容易被忽略的设计不是所有工具都要在一开始全部暴露给 Agent。LangGraph 支持动态工具调用——你可以在运行的不同阶段控制哪些工具可见。为什么重要强制执行工作流要求先调用认证工具才能暴露敏感操作引导推理开始时只给少量工具任务推进后再扩展提升可靠性减少早期因工具过多导致的错误路径这就像给一个新手厨师做饭——先给他刀和砧板等他切完了再把锅和灶给他。一次给太多工具他反而不知道从哪里下手。五、一个测试场景的完整案例说一个我实际做过的案例。需求自动化测试一个涉及“登录→查询订单→验证金额”的流程。传统做法写一个 Python 脚本里面硬编码三步的 API 调用、参数构造、断言逻辑。大概 150 行代码。问题是换一个环境测试环境→预发布环境API 地址变了要改 5 处。换一个用户token 获取方式变了要改 3 处。用 LangChain Tools 的做法定义三个 Tooltooldef login(username: str, password: str) - dict:“”“用户登录返回 token 和 user_id”“”# 调用登录 APItooldef query_orders(token: str, user_id: str) - list:“”“查询用户的订单列表需要 token 和 user_id”“”tooldef verify_amount(order_id: str, expected: float) - bool:“”“验证订单金额是否等于期望值”“”然后创建一个 Agent把这三个 Tool 传进去。给 Agent 的指令是“用 test_user 登录查询他的订单验证第一笔订单的金额是否等于 99.9”。Agent 自动完成调用 login拿到 token 和 user_id把 token 和 user_id 传给 query_orders拿到订单列表取第一笔订单的 ID调用 verify_amount对比维度传统脚本LangChain Tools Agent代码量150 行3 个 Tool约 60 行 1 句自然语言换环境改 5 处硬编码改 1 个环境变量新增场景重写脚本复用 Tool改自然语言指令可维护性低逻辑耦合高Tool 独立关键不是省了多少行代码。关键是当业务逻辑变化时你改的是 Tool 的实现还是整个流程的编排前者是“修一个零件”后者是“重造一台机器”。Tool 是积木Agent 是搭积木的人。你只需要定义好积木搭积木的事交给 Agent。六、对你意味着什么对在校生你现在学的测试理论里大概率还没有“AI Agent”这个章节。但等你毕业的时候这会是测试工程师的标配能力。不是让你现在就去精通 LangChain而是让你看懂一个趋势测试执行正在从“写脚本”变成“定义工具描述意图” 。看得懂这个变化你就比同龄人领先一步。对初级工程师你可能已经会用 Postman 调接口、用 Pytest 写用例了。下一步的能力升级点是把“调接口”封装成 Tool把“写用例”变成“给 Agent 下指令” 。核心不是学 LangChain 的 API是学会“工具化思维”——把一切可重复的操作变成可被大模型调用的标准接口。对中级工程师你现在面临的问题是团队效率的天花板。当测试场景越来越复杂、回归范围越来越大时靠堆人写脚本是不可持续的。Tools Agent 提供了一条路把测试能力拆解成可组合的 Tool让 Agent 根据需求动态组装 。这不是“更快的脚本”这是“不用写脚本的测试”。方法论层面的升级才是你该关注的点。七、最后问你一个问题你现在的测试代码里有多少是“可被大模型调用的工具”有多少是“一次性写死的流程”如果你的答案是“大部分是流程”那问自己第二个问题当业务变更时你是改代码还是重新描述意图这两个问题的答案决定了你的测试资产是在持续积累还是在持续贬值。