智能体干跑：不真调外部服务，也能验证决策对不对

一句话定义：智能体干跑（Tool Mocking / Dry-run） 是让智能体（Agent）照常完成"思考—选工具—填参数"的整套决策流程，但把真正的外部调用换成假的返回值，从而在不产生任何副作用的前提下检查它"想得对不对"。

打个比方：消防演习

大楼里的消防演习，警报照响、人照跑、集合点照点名，唯一不真的是——没有真的着火，也没有真的喷水。演习要验证的是"疏散路线对不对、负责人到没到位"，而不是"水管压力够不够"。智能体干跑就是这套逻辑：Agent 的推理循环、工具选择、参数拼装全部真实执行，只有最外层那一下"真的发出去"被替换掉。

具体做法通常是：把"查订单""发邮件""下单支付"这类工具（Tool）替换成桩实现（stub / mock），返回一份预先准备好的假数据。Agent 收到的还是一条正常的工具结果，于是它会继续往下走、继续做决策。整个过程留下的调用序列——先调谁、传了什么参数、什么条件下改道——就是一次"干跑轨迹"（trace），你可以直接拿它做断言。

和相邻概念的区别

关键差别在于"切在哪里"。单元测试切得太早，覆盖不到 Agent 的循环；端到端测试什么都不切，但慢、贵、且可能真的发出去一封邮件。干跑切在中间：循环保留，副作用归零。

一个容易被忽略的细节

Mock 的返回值必须"像真的"，尤其是失败分支。只 mock 成功结果，等于只考了顺风局。真正有价值的是喂给它超时、限流、空结果、字段缺失这些情况，看 Agent 会不会重试、会不会换工具、会不会老老实实说"我查不到"——这些恰恰是线上最容易翻车的地方。

对从业者的实际意义

第一，它能进 CI。没有外部依赖，跑得快、结果可复现，每次改提示词（prompt）或工具描述都能自动回归，不用担心把测试环境的订单真的发出去。第二，它把"模型不稳定"这个模糊问题拆成了可定位的断言：是选错了工具，还是参数填错了？轨迹一看便知。

对不写代码的职场人，可以这样理解：新员工上岗前先做一遍沙盘演练，流程走完整，客户合同不真发。演练过关不代表实战无敌——真实接口的鉴权变更、限流策略、返回格式调整，干跑都覆盖不到。所以干跑通过之后，仍要保留少量真实联调；各框架的具体配置方式与能力边界，以官方页面为准。

一句话收尾：干跑不证明系统能跑通，它证明的是——当外部世界按你预期的方式回应时，你的 Agent 会做出正确的选择。