绿色测试日志为什么可能已经失效：用 AET 绑定命令与当前代码

绿色测试日志回答的是一个历史问题：某条命令在某个时刻是否成功。它并不会自动回答另一个问题------仓库继续变化之后，这份结果是否仍适用于当前代码。

Agent Engineering Toolkit（AET）v1.18.0 把这两个判断分开记录：

execution status：命令当时是否真实执行成功；
freshness：那份执行结果现在是否仍适用。

下面从一个不联网、不调用模型的最小演示开始，再把同样的做法放进自己的仓库。

1. 安装并运行 exact release

不需要先污染全局环境，可以直接用 uvx 运行已发布版本：

bash 复制代码

uvx --from agent-engineering-toolkit==1.18.0 aet demo stale-proof --format json

我在 2026-07-30 的实际输出是：

json 复制代码

{
  "after_state": "RELEVANT_FILES_CHANGED",
  "before_state": "EXACT_MATCH",
  "demo_id": "stale-proof",
  "diagnostics": [],
  "execution_status": "PASS",
  "llm_calls": 0,
  "network_calls": 0,
  "overall_status": "PASS",
  "proof_path": null,
  "schema_version": "aet-demo-result/v1",
  "workspace_path": null
}

这里故意同时保留了两组信息：

execution_status 仍然是 PASS；
freshness 从 EXACT_MATCH 变成了 RELEVANT_FILES_CHANGED。

这不是自相矛盾。前者说明历史命令确实成功，后者说明相关文件后来发生了变化，旧结果已经不能证明当前代码。

2. 演示中的 fixture 做了什么

演示会创建一个临时 Git 仓库，其中只有一个 src/calc.py 和一个标准库 unittest。初始实现相当于：

python 复制代码

def add(left: int, right: int) -> int:
    return left + right

测试只验证加法：

python 复制代码

import unittest

from calc import add


class AddTest(unittest.TestCase):
    def test_add(self) -> None:
        self.assertEqual(add(2, 3), 5)

AET 先通过 quick_proof 运行：

bash 复制代码

python -m unittest discover -s tests

同时把 src/calc.py 与 tests/test_calc.py 声明为 relevant paths。第一次执行 quick_fresh 时，命令、Git workspace、HEAD、相关文件和环境都与 proof 一致，所以状态是 EXACT_MATCH。

随后演示把加法改成减法，但不重跑测试。第二次 quick_fresh 看到已声明的相关源码内容变化，于是返回 RELEVANT_FILES_CHANGED。

注意：AET 没有把历史 PASS 改写成 FAIL，也没有声称测试从未成功。正确动作是要求重跑受影响的检查。

3. 在自己的仓库记录 Quick Proof

假设真实项目的单元测试覆盖 src/app.py 与 tests/test_app.py，可以运行：

bash 复制代码

aet quick proof \
  --output .aet/proofs/unit-tests.json \
  --relevant-path src/app.py \
  --relevant-path tests/test_app.py \
  -- python -m unittest discover -s tests

这里的 -- 很重要：后面的内容是需要原样执行的 argv。AET 会记录实际命令与退出状态，并绑定：

当前 Git workspace 与 HEAD；
两个 relevant paths 的内容摘要；
声明的 artifact（如果使用 --artifact）；
命名环境输入的状态与 SHA-256（如果使用 --env-binding）；
proof 的创建时间与 schema version。

然后检查旧 proof 是否仍适用：

bash 复制代码

aet quick fresh \
  --proof .aet/proofs/unit-tests.json \
  --format json

quick fresh 是只读检查，不会重新运行测试命令。

Relevant paths 必须由维护者按真实覆盖范围声明。声明过窄可能漏掉会影响结果的变化；声明过宽则会造成不必要的失效和重跑。AET 不会根据退出码 0 猜测测试拥有"完整覆盖率"。

4. 常见失效和失败路径

Git 信息缺失

Freshness 依赖记录时的 workspace 基线。proof 缺少 workspace snapshot、workspace root 不存在、记录的仓库已经不可访问时，AET 返回 UNKNOWN，而不是猜测仍然有效。

Proof 损坏

下面的命令如果读不到文件，或 JSON / binding 不完整：

bash 复制代码

aet quick fresh --proof .aet/proofs/unit-tests.json

结果会保留为 UNKNOWN，诊断会说明无法读取 proof、binding 缺失或必需绑定不可用。不要把这种基础设施问题展示成绿色通过。

命令失败或超时

quick proof 负责执行显式 argv。命令非零退出时，execution status 不会被包装成通过；超时或无法形成完整必需绑定时也不能营销为 PASS。缺失信息继续保持 UNKNOWN。

路径越界

Relevant path 必须属于被记录的工作区。不要用它读取仓库之外的任意路径，也不要把 secret、未脱敏日志或私有历史写进 proof。AET 的默认边界是本地、确定性、只读优先。

5. 它和 CI 的分工

CI 负责真正执行测试、lint 和构建。AET 负责把"执行了什么、绑定了哪些路径、结果现在是否仍适用"变成可检查的证据。

默认 GitHub Action 不会替你执行 proof 中的任意命令。若要在 CI 中记录 Quick Proof，必须在 workflow 里显式写出允许执行的命令和 relevant paths；不要把 proof 文件当作可执行脚本。

AET 也不是 Agent，不判断代码语义，不生成一个笼统的"可信度总分"。公开状态保留 PASS、FAIL、UNKNOWN 与 NOT_APPLICABLE，让读者看到证据边界。

6. 最小验证清单

把它接入真实项目时，我会至少检查：

proof 中的 argv 是否与 CI 实际执行的命令一致；
relevant paths 是否覆盖真正影响结果的源码和测试；
proof 是否写在不会让自己失效的位置；
UNKNOWN 是否被保留，而不是被 UI 包装成成功；
代码变化后是否先跑 quick fresh，失效时再重跑对应检查。

这次演示只有一个 fixture 和一次可复现流程，能证明 v1.18.0 的 stale-proof 路径按声明工作，不能由此推导一般 Agent、模型或任意仓库的质量。

项目与原始材料：

源码：github.com/AdvancingTi...
v1.18.0 Release：github.com/AdvancingTi...
状态与权限边界：github.com/AdvancingTi...
stale-proof 案例：github.com/AdvancingTi...

绿色测试日志为什么可能已经失效：用 AET 绑定命令与当前代码

1. 安装并运行 exact release

2. 演示中的 fixture 做了什么

3. 在自己的仓库记录 Quick Proof

4. 常见失效和失败路径

Git 信息缺失

Proof 损坏

相关文件、产物或环境变化

命令失败或超时

路径越界

5. 它和 CI 的分工

6. 最小验证清单