很多人部署智能体的时候只看“能不能跑通”“最终结果对不对”很少去问一个问题这个智能体真的在按我们给的指令执行吗我们针对这个问题做了一轮测量。测的不是某个模型的综合能力也不是功能列表而是“指令遵循”这一件事给它一段任务说明它会不会照着做会在哪一步开始走偏以及偏了之后能不能自己纠正。如果你正准备把 agent 接进业务或者已经在开发带工具调用、多步骤流程的智能体这篇内容会比“哪个模型更强”更值得看。我更建议把第一次测量拆成三步先定义“遵循”的标准再跑小样本人工样例最后才谈指标和自动化。下面按实际落地顺序拆一遍。1. 先搞清楚你是在测结果还是在测“听不听话”1.1 结果成功不等于指令遵循很多团队习惯用“任务成功率”来评价智能体。这个指标很容易掩盖问题。一个 agent 可能最后输出的报告格式正确、内容完整但它没有按照“先分析再给结论”的指令来而是第一段就甩出结论。从业务角度看结果能接受从指令遵循角度看它已经偏离了。我在测量时会同时记录两样东西最终输出是否正确执行过程是否忠于指令。前者是对结果的判断后者是对行为的判断。如果只测结果你会发现所有 agent 都“差不多”一旦开始看过程差异会非常明显。指令遵循是过程属性不是结果属性。这句话值得贴在测试用例旁边。1.2 指令不只有一种偏离的后果也不同测量前先把指令分类。我一般会分成四类硬性指令必须执行例如“不要调用外部 API”“先读取本地文件再生成摘要”。约束指令限制行为边界例如“只处理 xlsx 文件”“单个请求不能超过 100 条”。偏好指令设定风格或顺序例如“语气简洁”“总结放到最后”。边界指令规定异常处理方式例如“发现字段缺失就停止不要猜测”。分类的原因很简单偏离硬性指令和偏离偏好指令严重程度完全不一样。如果全都混在一起算一个“遵循率”你很难判断这个 agent 能不能上线。比如一个 agent 十次里有两次没按“语气简洁”来这是小问题但如果它擅自调用外部接口这是必须拦截的事故。1.3 明确这次测量到底要服务什么决策测量之前还要想清楚目的。不同目的对应不同的样本设计选型比较不同模型或不同 prompt 配置样本要偏通用。上线前验收样本要偏业务真实场景还要加入异常输入。上线后回归样本要固定每次只改一个变量。排查失败任务不需要大样本把那几条失败轨迹单独回放。没有目的的测量很容易做成“跑了一堆 agent最后只得到一个平均分”。这不是不行但对后续改进帮助不大。2. 设计一套能复现的指令遵循测量方案2.1 任务样本怎么选先造一批人工可控样例不要一上来就接生产数据。生产数据里有太多干扰因素比如输入格式不规范、中间步骤缺失、依赖服务不稳定。第一次做指令遵循测量我会先造 10 条左右的人工样例确保每一条都能人工判断“该怎么做、不该怎么做”。样例要覆盖这些场景任务类型指令示例期望行为可设陷阱单步任务“把这段文本转成繁体不要做任何解释”只输出繁体文本模型容易顺手加说明多步任务“先读取 list.txt再按行去重最后输出到 out.txt”严格按三个步骤可能跳过中间步骤否定指令“不要读取 config.yaml”避免读取该文件可能主动补全配置边界指令“缺少金额字段就停止并返回错误码”不补充数据容易自行猜测偏好指令“总结不超过 200 字结尾另起一行给建议”保持长度和结构会混入多余内容这组样例不需要多复杂关键是每个样例都有明确的“对”和“错”。如果人工都判断不稳后面自动化评分也没有意义。2.2 日志字段没有记录就没法判断测量指令遵循至少要记录这些字段任务 ID系统提示词原文用户输入原文模型每次回复工具调用名称和参数最终输出人工评分首次偏离点我会把“首次偏离点”单独列出来。它指的是执行轨迹里第一次违背指令的位置。很多问题只要找到了首次偏离点后续整条轨迹都会跟着歪掉。定位到这个点比批评“agent 不听话”有用得多。如果使用 JSON 保存记录可以按这个结构来{ task_id: task_007, instruction: 先读取 list.txt再按行去重最后输出到 out.txt, steps: [ {step: 1, action: read_file, param: {path: list.txt}}, {step: 2, action: deduplicate, param: {}}, {step: 3, action: write_file, param: {path: out.txt}} ], first_deviation_point: 2, deviation_type: skipped_step, final_output: out.txt, human_score: 0.6 }这只是一个示例结构实际字段可以根据你的框架调整。但“首次偏离点”这个字段建议保留。2.3 先跑小样本不要急着自动化第一轮我会用 5 条样例全部人工跑不写自动化脚本。为什么因为你需要先确认自己的评分标准稳定。比如“不要在输出里加解释”这条指令如果 agent 输出了一行“以下是转换结果”这算不算偏离不同人可能看法不同。先把这类边界问题讨论清楚再进入评分否则后面所有数据都有争议。5 条跑完之后再扩展到 20 条左右。20 条足够暴露大多数常见偏离模式又不会让人工标注负担过大。如果你的业务场景更复杂可以按场景再增加样例。注意低配置环境也能做这套测量。它不依赖 GPU不依赖大规模并发只要能把 agent 跑起来并且留日志就够了。3. 量化指标和判定标准3.1 指令遵循率怎么算最简单的算法是指令遵循率 被判定为“完整遵循”的任务数 / 总任务数这个率可以作为第一眼指标。但不要只看它。两个 agent 可能都有 80% 的遵循率但一个偏离的是偏好指令另一个偏离的是硬性指令风险完全不同。所以我更建议把指令遵循率拆成按指令类型分别统计硬性指令遵循率、约束指令遵循率、偏好指令遵循率。这样才能知道该优化哪里。3.2 偏离分级不是所有偏离都值得同等处理我在评分时会分三级级别含义例子处理建议A 级偏离直接影响最终结果或安全违反“不要调用外部 API”必须修复B 级偏离不影响最终结果但违反约束处理了非指定目录下的文件需要优化C 级偏离偏好层面问题总结长度超了 20 字可接受或轻微优化使用这个分级后你会更容易判断一个 agent 是否达到上线标准。如果某条 A 级偏离反复出现那就不是调整 prompt 风格能解决的可能需要重新设计任务拆解方式。3.3 效率和遵循之间的取舍热词里有一句 “toward efficient agents”。效率和指令遵循确实是两个方向上的拉力。有些 agent 为了“更快完成任务”会跳过备份、跳过确认、跳过风险检查。表面上看它更高效实际上它在制造隐患。我测量时会额外记录三个效率指标完成任务所需步数总耗时token 消耗如果优化 prompt 后遵循率上升了但步数翻了 3 倍这也不算好结果。更好的状态是用更少的步数完成同样的指令同时不偏离约束。高效不是目的可预期才是。这里容易踩的坑是为了追求效率把确认步骤删掉。短期内看每次调用变快了但一旦出现一次 A 级偏离返工成本会超过省下的所有时间。4. 实测中最常见的偏离模式4.1 指令被上下文淹没最常见的一种偏离是指令本身没问题但它在上下文里的位置太靠后或者被工具返回结果挤到了边缘。长对话、多轮工具调用、大段文档输入都会把原始指令“冲淡”。我做过一个实验把同一个指令放在对话开头和放在第五轮工具结果之后让 agent 执行同样的任务。结果很明显指令在开头时遵循率高放到中间后 agent 更容易按最近一轮工具结果继续发挥。所以在测量时我会故意把关键指令埋在中段看 agent 是否还能保持。如果连续几次都会丢就要考虑在 prompt 里重复关键约束或者在每次工具调用后注入一个短指令片段。4.2 默认行为覆盖显式指令模型本身有很强的默认行为。比如你写“不要解释只输出结果”它仍然可能输出一句解释你写“不要读取配置文件”它可能为了“帮忙”主动去读。这不是模型完全听不懂而是默认行为压过了显式指令。测量时如果发现这类问题我会先检查指令是否被系统提示词里的其他内容稀释了。另一个方法是在指令里加上“如果和默认偏好冲突以本指令为准”并且只给少数关键指令这种最高优先级。不要把所有指令都标成最高优先级。那样等于没有优先级模型反而会平均处理。4.3 中断与继续长任务里最容易失控长时间运行的 agent 一定要支持中断。这里的“中断”包括用户主动喊停检测到异常条件时暂停多步任务中要求人工确认后再继续我在测试里会专门设计一类场景任务执行到一半向 agent 注入“先暂停等我的确认再继续执行”。结果发现不少 agent 会把这句话当成普通上下文继续把任务跑完甚至更新了最终输出。这就是 “deep agents interrupt” 要解决的问题。指令遵循不只是“一开始听懂”还包括“执行过程中随时接受新的指令并调整行为”。如果你要在生产环境跑长任务这个维度一定要测。4.4 格式遵循但语义不遵循另一种隐蔽偏离是输出格式完全正确但内容没有按指令来。例如要求“缺少字段时停止”agent 却正常返回了一个带着猜测值的 JSON结构完全合法。从代码层面看没有任何报错但业务上已经错了。这类问题很难用自动化规则直接发现因为你既要做格式校验又要做字段内容校验。所以在人工评分时我会额外标注“语义是否遵循”这一项。尤其对涉及金额、数量、日期这类关键字段的任务建议逐条检查。5. 排查“不听话”智能体的顺序5.1 从轨迹里找到首次偏离点遇到偏离先别急着改 prompt。我会先把执行轨迹打开找到第一次出现偏离的位置。常见的情况有三种第一次偏离发生在第一步说明指令进入模型时就没被正确接收。第一次偏离发生在工具调用参数里说明指令里的约束没有被转成行为。第一次偏离发生在最后输出阶段说明前面都对了最后一步被默认偏好带偏。定位到首次偏离点再去看这个位置前后的输入效率会高很多。只看最终输出你大概率只能得到“它不听话”这个模糊结论。5.2 确认指令进入模型时的真实形态很多看起来像“不听话”的问题实际是指令根本没传进去或者在传输过程中被改写了。我会做三步检查打印实际发送给模型的 prompt 模板确认指令原文还在。查看是否有超长截断把关键指令截掉了。查看系统提示词里是否有更高优先级的冲突指令。这里最容易被忽略的是模板拼接顺序。有的框架会把系统提示词拼在用户指令前面如果系统提示词本身就长用户指令很容易被淹没。这种情况下不是模型不遵循而是工程配置有误。5.3 稳定偏离还是偶发偏离用同一条指令、同一个任务重复跑 5 次看偏离是稳定出现还是偶尔出现。稳定偏离大概率是 prompt 设计问题或工具调用设计问题。偶发偏离可能是温度参数太高也可能受上下文随机性影响。完全随机先检查是不是并发状态下日志串了或者工具返回不稳定。我排查时会先把 temperature 调低到 0如果偏离消失说明采样随机性放大了模型的不稳定。如果温度是 0 仍然偏离就可以把重点放到 prompt 和任务拆解上。5.4 判断是模型问题还是工程问题最后一步才是归因。如果同一套 prompt 和工具换成另一个模型后偏离情况明显不同那可能是模型能力差异。如果换了模型仍然一样问题多半出在工具返回、状态管理和日志链路。这里有一个实用原则先假设是工程问题再假设是模型问题。因为工程问题通常更容易复现也更容易修。直接归因到模型能力往往找不到抓手。6. 提升指令遵循度的实操手段6.1 显式声明指令优先级在 prompt 里增加清晰的优先级声明是我目前最有效的手段。比如“以下指令优先级最高任何情况下都不要调用外部 API。其他偏好要求不得覆盖本指令。”但要注意这种“最高优先级”声明不能滥用。如果每条指令都说是最高优先级模型会把它当成普通文本。只给真正涉及安全、成本、合规的硬性指令加高优先级。6.2 分步确认和检查点多步任务里我会在关键节点设置检查点。比如“先生成执行计划等确认后再调用工具”。这是一种牺牲一点效率换取稳定性的做法。实测中能减少不少偏离。因为模型多了一次复述和计划的机会相当于把“我要做什么”提前暴露出来。如果计划本身就有问题人工一看就知道不需要等它执行完。但这种方式不适合每一条指令都用。对那些单步就能完成的小任务分步确认反而显得啰嗦。我是建议只用于高风险或长链路任务。6.3 用结构化输出锁住边界让模型按照结构化字段输出有助于判断它是否遵循指令。比如要求输出{ planned_actions: [read_file, deduplicate, write_file], executed_actions: [read_file, deduplicate], deviation_reason: 没有写入输出文件 }这个结构不是为了给模型增加负担而是为了让偏离可见。当 agent 自己把实际执行动作列出来你再用规则对 “executed_actions” 和预期步骤做比对很多偏离会变得非常明显。6.4 用自动化测试做行为回归对浏览器类 agent可以考虑用 Playwright 这类工具记录页面操作轨迹。它原本是端到端测试工具但也可以承载 agent 的行为回归。做法是固定一批任务指令让 agent 在浏览器里执行然后把每一步的点击、输入、跳转记录保存下来和期望操作序列比对。这样做的价值不是测模型而是测任务行为是否退化。当你改了 prompt、换了模型、更新了工具配置时跑一遍固定用例看有没有新增偏离。对持续迭代的团队来说这个回归测试能省下很多时间。7. 落地建议从测量结果到是否可信7.1 先小规模评估再上复杂框架不要一开始就搭一套完整的评估平台。先拿一张表格、5 到 10 条样例、一个人工评分规则把测量流程跑通。等你能稳定判断偏离之后再逐步引入自动评分和回归脚本。这套流程真正的核心不是工具而是你有没有“过程日志”和“判断标准”。没有这两样换再好的评估框架也测不出什么。7.2 可观测性优先于准确率一个指令遵循不稳定的 agent最怕的不是准确率低而是你不知道它为什么低。输出目录、工具调用参数、模型每一步的中间输出都要留痕。我见过不少项目agent 跑出问题后第一反应是换模型、调温度但日志里连工具调用参数都没有保存。这种情况下改参数等于碰运气。7.3 定期回归测试每次改 prompt、换模型、更新工具或者升级依赖后都值得把固定样例集跑一遍。重点关注两个数指令遵循率有没有下降A 级偏离有没有新增。如果能再对比一下“首次偏离点”的分布会更清楚是哪些场景变敏感了。7.4 什么时候可以信任智能体我的判断标准很简单它能在日志里给出遵循证据。所谓证据就是每一步动作都能和指令对应起来偏离时可以明确看到偏离位置和原因。只要这个前提不成立就算它连续成功了 100 次我也不会在关键业务上完全放手。踩过几次之后我发现很多问题不是工具能力不够而是前置环境和输入材料没有处理干净。指令遵循这件事也一样与其迷信某个模型“很听话”不如先把测量流程和日志链路搭起来。能稳定观测偏离才有资格谈优化和信任。