Signal #33：Coding Agent 的质量验证正在覆盖执行过程

让 Coding Agent 修复一个 Bug，它阅读代码、定位问题、修改文件，最后运行测试。几分钟后，Agent 告诉你任务完成了，所有测试通过，看起来一切顺利。

但如果仔细检查执行过程，可能会发现一些问题：它没有遵守仓库的开发规范，运行了与任务无关的命令，或者访问了本来不需要读取的文件。这些问题未必会影响最终的测试结果。代码可以是正确的，完成代码的过程却未必符合要求。

10 月初，我关注到三篇几乎同时发布的论文，分别从仓库规范、Agent 执行行为和 Harness 测试三个角度研究这个问题。把它们放在一起看，会发现一个值得关注的变化：Coding Agent 的质量验证，正在覆盖更完整的执行链路。

先看一个真实案例。在 Django 项目中，开发规范要求使用 assertIs 判断布尔值，但一个 Coding Agent 在修复问题时使用了 assertTrue。代码功能正确，整个测试套件也成功通过，然而这个补丁违反了 Django 明确规定的贡献规范。

这是论文 《Correct Code, Broken Contributions?》 展示的案例。研究者提出 SWE-CC 评测基准，从 12 个真实开源项目中提取出 823 条可自动检查的工程规范，覆盖代码风格、测试流程、Git 操作和贡献要求等内容，再通过 500 个软件开发任务评估 Coding Agent。

结果发现，即使 Agent 生成了功能正确的补丁，仍然违反了 43.1% 的适用仓库规范。 这里的 43.1% 是规范违规比例，并不代表 43.1% 的任务失败。更值得注意的是，近一半的违规发生在中间执行步骤，只检查最终提交的代码，根本发现不了这部分问题。

为什么会这样？其中一个原因是 Agent 不一定会主动寻找项目规范。研究发现，即使明确要求 Agent 搜索相关规则，真正发起规则检索的执行也只有 28.9%。

这其实很贴近真实开发。一个成熟的代码仓库，除了功能实现，还存在大量工程约定：哪些模块可以修改、哪些测试必须运行、提交信息有什么要求，以及哪些操作需要经过审批。这些规则往往分散在 CONTRIBUTING.md、AGENTS.md、项目文档和工程配置里。Agent 能读懂代码，不代表它已经掌握这些规则。

SWE-CC 的价值，在于尝试将自然语言描述的仓库规范转化为可执行的检查规则，同时检查最终代码和执行过程。它也让我们重新审视一个问题：过去依赖开发者理解和遵守的工程规范，是否已经真正进入 Agent 的执行与验证流程？

既然最终测试无法发现所有问题，那么保留 Agent 的执行记录是不是就够了？

Coding Agent 通常会保存消息和工具调用记录，我们可以看到模型使用了什么工具、执行了哪些命令，以及收到了什么结果。但一次工具调用背后，还可能启动其他程序、读取更多文件，或者访问外部网络。Agent 自身记录的轨迹，未必完整覆盖这些行为。

另一篇论文 《AgentSpy: Making AI Agent Behavior Observable》 研究的正是这个问题。研究者让 Agent 在隔离环境中运行，从系统调用和网络流量层面记录它及其子进程的真实操作，包括执行的命令、访问的文件以及连接的网络地址。

研究使用 77 个任务和三种模型开展实验。其中有 88 组任务与模型的组合，在三次重复运行中均通过了最终测试。但进一步检查这些成功任务的执行记录时，研究者仍然发现：

这些结果来自特定实验环境，与任务无关的活动也不一定具有恶意，但它们揭示了一个容易被忽视的问题：我们通常会检查 Agent 有没有完成预期动作，却很少检查它有没有执行不该执行的动作。

例如，让 Agent 修改一个页面，它最终正确完成了页面修改。但在过程中，它是否读取了其他业务模块的敏感配置？是否执行了超出必要范围的命令？是否访问了未经授权的服务？这些问题，光看最终页面和测试结果无法回答。

AgentSpy 提供了一种思路：通过独立于模型的系统级观察，记录实际执行行为，再依据明确的规则检查是否符合约束。当然，这类监控也存在边界。例如，尚未产生外部操作的某些潜在风险，系统调用监控可能无法直接识别。因此，执行记录还需要与任务上下文、权限规则和其他检查手段结合，才能形成更可靠的判断。

前两篇研究关注 Agent 生成的代码和执行行为，第三篇研究则把视角转向了运行 Agent 的系统本身。

论文 《Complex Agents, Shallow Tests》 提出了一套针对 Agent Harness 的测试方法 HarnessTester。

Harness 可以理解为模型外部的执行框架。模型负责判断下一步要做什么，Harness 则负责组织上下文、解析工具调用、执行操作、处理返回结果和维护执行状态。例如，当模型决定调用某个工具时，Harness 需要正确解析参数、执行工具，并将结果交还给模型。

我们经常讨论如何设计更好的 Harness，让 Agent 能够执行复杂任务、持续运行，并在失败后恢复。但如果 Harness 自己存在 Bug，又该如何发现？

研究团队分析了 10 个真实 Agent 系统，发现与模型输出直接交互的关键 Harness 代码，其现有测试的平均行覆盖率和分支覆盖率都不足一半。这些代码恰好承担着模型输出解析、工具调度和状态处理等重要职责。

研究者因此提出 HarnessTester，专门针对 Agent 与 Harness 之间的交互契约构造测试。最终，这套方法在真实 Agent 系统中发现了 122 个缺陷，其中 88 个此前未知，69 个新缺陷获得开发者确认。

其中一个案例很有代表性。Browser Use 会保存 Agent 的执行历史，为避免敏感信息泄漏，保存前需要对相关字段进行脱敏。但研究者发现，当敏感值位于多层嵌套的列表参数中时，原有逻辑可能无法完整处理，导致敏感信息以明文形式进入历史文件。这个问题后来得到了修复。

为什么此前的测试没能发现？因为触发这个问题，需要构造符合真实运行结构的模型输出、动作参数和历史记录对象，并让敏感信息恰好出现在嵌套列表中。单独测试脱敏函数，很可能遗漏这种跨对象、跨环节的交互情况。

这也是 Agent Harness 测试的特殊难点：模型输出具有不确定性，但 Harness 需要对各种可能的输出做出可靠处理。模型生成了异常的工具参数，Harness 能否正确处理？工具调用失败后，是否能够恢复？敏感信息进入复杂数据结构时，是否仍然能够得到保护？

Agent 的能力可以依赖概率模型，支撑 Agent 执行的关键机制则需要充分的工程验证。

读完这三篇论文，我一直在想：当我们说一个 Coding Agent 的任务成功了，到底在衡量什么？

当前常见的评测方式，是让 Agent 执行任务，再通过测试判断结果是否正确。这种方式当然有价值，但随着 Agent 承担更多研发工作，单一的任务成功率已经很难完整描述一次交付的可靠性。

结合这几项研究，我倾向于将 Coding Agent 的质量拆成三个相互关联、但需要分别衡量的维度。

第一，任务成功率：Agent 有没有把事情做对？ 关注功能是否符合需求、测试是否通过、最终产物是否满足验收标准。这是结果层面的验证，也是最容易建立自动化评测的部分。

第二，执行合规性：Agent 有没有按照要求完成任务？ 关注仓库规范、必要的测试流程、文件访问边界、工具操作和权限约束。它需要结合执行证据进行判断，不能只根据最终产物推断。

第三，Harness 可靠性：执行 Agent 的系统能否正确处理各种情况？ 关注工具调用、异常处理、状态恢复、敏感信息保护等关键机制。这个维度主要属于 Agent 平台自身的系统质量，不能简单作为每次任务的单独得分。

这三个维度并不适合直接合成为一个看似精确的总分。例如，一个 Agent 功能测试全部通过，却违反了高风险权限约束，显然不能因为任务成功率高就放行。同样，一个 Harness 经过了充分测试，也不能保证它运行的每项业务任务都正确。

这也是我从本周研究中得到的主要判断：Coding Agent 的验收，需要逐步从检查任务结果，扩展到检查执行证据和运行机制。

而且，验证不能只发生在任务结束时。任务开始前需要确定约束和权限，执行过程中需要保留必要证据并阻止高风险操作，任务完成后再检查结果与执行过程。不同类型的任务可以采用不同的验证强度：只读的代码解释任务要求可以轻一些，涉及生产配置、数据库或自动发布的任务则需要更严格的控制。

这里提出的三个维度，目前更适合作为一个用于研究和实践的分析框架。它并非已经成熟的行业标准，具体指标、证据来源和验收门槛，还需要在真实研发任务中不断校准。尤其需要注意，当执行证据不足时，应当区分「已经通过验证」和「尚无法确认」，避免将缺少证据默认视为可靠。

回到文章开头。Coding Agent 修好了 Bug，测试全部通过，这仍然是一件值得高兴的事。但当它开始承担更多研发责任时，我们还需要进一步确认：它是否遵守项目规范，是否执行了超出任务范围的操作，以及支撑它运行的 Harness 是否可靠。

静态检查、权限控制、审计日志、契约测试等方法，早已存在于成熟的软件研发体系中。如今，越来越多的研发步骤交给 Agent 自主推进，原本依赖开发者理解和遵守的工程约束，需要逐步成为 Agent 能够获取、系统能够执行、结果能够检查的内容。

本周三篇研究从不同角度提供了新的评测与验证方法。它们还不足以证明业界已经建立完整成熟的 Agent 质量保障体系，但暴露的问题十分具体，也为后续工程实践提供了方向。

随着 Coding Agent 承担更完整的研发任务，我们需要验证的，也是一条更完整的执行链路。

代码通过测试，回答的是结果是否符合预期。对于一个准备承担更多研发责任的 Agent，我们还需要知道它是怎么完成这项工作的，以及我们凭什么相信这个过程。