霍格沃兹测试开发学社
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 的做法：定义三个 Tool：然后创建一个 Agent，把这三个 Tool 传进去。给 Agent 的指令是：“用 test_user 登录，查询他的订单，验证第一笔订单的金额是否等于 99.9”。Agent 自动完成：调用 login，拿到 token 和 user_id把 token 和 user_id 传给 query_orders，拿到订单列表取第一笔订单的 ID，调用 verify_amount对比：
发布于 北京
分享
评论
赞
未登录
友善发言
评论
加载中
