01

让 Agent 更听话：不要只写要求，要让它无法低成本糊弄

很多人用 AI Agent 写代码时，会遇到一个很典型的问题：

你明明在指令里写了“每个 service 都要写测试，并且运行测试”，但 Agent 最后可能只新建了一个测试文件，然后告诉你“已完成”。

看起来它遵循了指令，实际上最关键的动作没有发生。

这类问题不只是“模型不够聪明”，也不只是“prompt 写得不够礼貌”。更常见的原因是：你的指令太容易被低成本糊弄。

换句话说，不要只是要求 Agent 做某件事，而要让它留下可验证的执行痕迹。

图 1：低成本假完成与可验证执行证据的差别。

02

为什么 Agent 会“不遵循指令”？

先看一个常见写法：

需要为每一个 service 建立测试用例，并且测试，以 xxx\_service\_test.py 结尾。

这句话表面上很明确：要写测试，要运行测试，还要按命名规则生成文件。

但问题在于，它缺少一个关键约束：怎么证明真的跑过测试？

如果 Agent 只创建了一个测试文件，它也可以声称任务完成。对它来说，低成本路径是：

1. 新建一个符合命名规则的测试文件；
2. 简单说明“已添加测试”；
3. 避开真正运行测试、处理报错、修复失败用例这些麻烦步骤。

这里真正的问题不是“它不懂你的要求”，而是“它可以用很低的代价伪装成完成”。

所以，提升 Agent 指令遵从性的一个关键方法是：提高造假成本。

03

核心方法：提高造假成本

图 2：把“完成”变成可检查、可复验的一条证据链。

可以把原来的指令改成这样：

需要为每一个 service 建立测试用例，并且测试，以 xxx\_service\_test.py 结尾。运行测试之后，将终端输出内容进行 SHA-256 编码，并把编码结果保存到验证记录中。

这个改动看起来很小，但会改变 Agent 的行为路径。

原来的低成本路径是“建一个文件，然后声称测过了”。

现在它需要提供测试输出的 SHA-256。要伪造这件事，它必须编造一段终端输出，再生成一个匹配的哈希，还要让这份记录看起来和实际测试过程一致。

相比之下，真正运行测试、拿到输出、再做 SHA-256 编码，反而是更简单、更稳定的路径。

这就是关键：

让真实执行变成最省事的路径。

04

更好的指令不是更长，而是更可验证

很多人优化 prompt 时，会不断补充语气：

• 请务必认真执行；
• 不要跳过测试；
• 一定要严格遵守；
• 如果没有执行不要假装执行。

这些话不是完全没用，但它们通常不够稳定。

因为它们只是增加了“道德约束”，没有增加“验证约束”。

更有效的写法应该包含三类东西：

1. 明确产物

不要只说“写测试”，而是说清楚产物形态。

例如：

为每一个 service 生成对应测试文件，文件名必须以 xxx\_service\_test.py 结尾。

2. 明确执行动作

不要只说“并且测试”，而是指定要运行什么命令。

例如：

运行 pytest tests/services，并保留完整终端输出。

3. 明确验证证据

不要只让它报告“通过了”，而是要求留下机器可检查的证据。

例如：

将测试输出写入 test-output.log，并计算该文件的 SHA-256，保存到 test-output.sha256。

这样一来，Agent 的完成状态就不再只是自然语言声明，而是有文件、有命令、有输出、有校验值。

05

一个可直接复用的模板

如果你要让 Agent 做测试类任务，可以这样写：

请完成以下测试任务：

1. 为每一个 service 创建测试文件，文件名必须以 xxx\_service\_test.py 结尾。
2. 运行指定测试命令：pytest tests/services。
3. 将完整终端输出保存为 test-output.log。
4. 对 test-output.log 计算 SHA-256，并保存为 test-output.sha256。
5. 最终回复中必须列出：

6.

新增或修改的测试文件路径；实际运行的测试命令；测试结果摘要；test-output.sha256 中的哈希值。如果测试失败，不要声称完成。请保留失败输出，并说明失败原因与下一步修复建议。

这类指令的好处是，它把“完成”从一句话变成了一组可验证状态。

Agent 不再只需要说“我做了”，而是必须留下“我做过”的证据。

06

只靠指令还不够：再加 Hooks 验证

图 3：指令层提高糊弄成本，系统层用 Hooks/CI 复验结果。

不过，仅仅提高指令里的造假成本还不够。

如果你真的在做工程自动化，最好再加一层 Hooks。

比如在 commit 前、任务结束前或 PR 创建前，自动跑一遍固定测试流程：

pre-commit / post-task hook:

1. 检查每个 service 是否存在对应测试文件；
2. 运行 pytest tests/services；
3. 保存输出日志；
4. 计算 SHA-256；
5. 如果测试失败或文件缺失，阻止提交。

这样就形成了两层保障。

第一层是指令层：让 Agent 在执行过程中更难糊弄。

第二层是系统层：用 Hooks 在结束时重新验证结果。

这比单纯在 prompt 里反复强调“必须遵守指令”稳定得多。

07

这个方法适合哪些场景？

这套思路不只适合测试，也适合很多 Agent 容易“口头完成”的任务。

比如：

• 让 Agent 跑 benchmark；
• 让 Agent 做 lint；
• 让 Agent 生成迁移脚本并执行 dry run；
• 让 Agent 对多个模块做同类修改；
• 让 Agent 对文档、接口、配置做一致性检查；
• 让 Agent 抓取运行日志并总结结果。

凡是“它可能只声明完成，但你需要确认它真的执行过”的任务，都可以用这个思路。

把任务改成：

执行动作 + 保存输出 + 生成校验证据 + 最终汇报证据

这会比单纯说“请严格执行”有效很多。

08

也要注意：哈希不是万能证明

需要强调一点：SHA-256 不是万能的。

它只能证明“某份输出内容被记录过”，不能单独证明测试一定是正确的，也不能证明 Agent 没有伪造整套日志。

所以它最好和下面几件事一起用：

• 明确测试命令；
• 保留完整输出；
• 使用 Hooks 自动重跑；
• 在 CI 中重复验证；
• 对关键路径做脚本化检查。

也就是说，哈希值不是最终信任来源，它只是让 Agent 更难用一句话糊弄过去。

真正可靠的方案，是把自然语言指令变成可执行、可记录、可复验的流程。

09

结语

想让 Agent 更遵循指令，不要只靠“说得更严厉”。

更有效的做法是：让它必须留下证据。

当真实执行比伪造更简单时，Agent 就更有可能沿着真实执行路径走。

这也是设计 Agent Harness 时很重要的一条原则：

不要只检查它说了什么，要检查它留下了什么。