摘要

  • LACNIC 公开的 Hackathon 仓库要求代理读取共享的 ai-harness，在 active 模式下还要先更新它，再进入会修改项目状态的会话；但 Git 树里只有一个指向 ../ai-harness 的 13 字节符号链接。
  • 因此，Hackathon 的提交能够证明本地入口文件和相对路径，却不能单独证明外部仓库的 URL、不可变提交或内容摘要。补救不必复制整套规则，只需为每次变更留下一份“外部指令凭证”。

一个只有 13 字节的对象，可以比一份长文档更有决定权。LACNIC 的 hackathon 仓库在当前 Git 树中把 ai-harness 记录为模式 120000 的对象，也就是符号链接。解码对应 blob，内容只有 ../ai-harness。

这种布局本身并不反常。把审查规则、测试方法和启动检查集中在共享框架里，可以让多个项目同时受益；修正一处，其他项目不必各自复制。9 月的新提交也显示出明显的约束意识：它区分 maintenance 与 active 两种模式，要求修改任务从干净的规范 checkout 开始，并明确不应在 linked worktree 中启动这种任务。

真正缺少的是版本身份。Hackathon 仓库能准确指出自己使用的是哪一个 AGENTS.md，也能证明链接的模式、大小和相对目标。仅凭这个提交，却无法知道某次运行时 ../ai-harness 目录里是哪一个仓库、哪一个提交，以及更新前后发生了什么。

这不是普通的参考资料缺口。9 月版 AGENTS.md 要求代理在执行任何命令之前，只读取 ai-harness/AGENTS.md 的第一行，并据此应用 AI_HARNESS_MODE。maintenance 模式下不得更新、同步或执行该框架；active 模式下则要运行 ./ai-harness/harness/framework/update-framework.sh，随后读取完整规则图，并在新的变更会话前通过 git-preflight。

换句话说，外部仓库参与决定三件事：当前有哪些规则、是否先更新、什么条件允许产生改动。如果两台机器的 Hackathon 提交完全相同，而相邻的 harness checkout 不同，它们就可能读到不同的模式行、更新脚本或预检规则。现有材料并没有证明这种分叉实际发生过。它只证明一个更窄的事实：项目 SHA 本身不足以重建完整的指令状态。

两次提交划出的证据边界

2026 年 7 月 12 日，提交 16c37db9fe6e1c1b0bc7260b744ee7595a10de67 以“chore: adopt shared ai-harness”为说明，加入了本地代理入口、相对链接以及项目专用模板。当时的规则已经要求在新会话前无交互更新公共框架，然后读取 harness 的规则图。

9 月 8 日，提交 a68504f87dd5226238bb65b62b89d40419ed7c1f 扩充了这一约定：加入两种模式，限制 maintenance 模式可以读取和写入的范围，并说明预检要求规范且干净的 checkout。改动随后合并为 6f9f60846acb30d4dcbf3969908743671c4a2921。

合并树把 AGENTS.md 绑定到 blob 34e8fb06a0d71b939283dea4d77381ff029ad981，也把 ai-harness 链接绑定到 blob 2244dfc17eaa1d54869e0bb3ff01ff258c6b0a0e。这两项身份足以复核 Hackathon 仓库内部保存的对象。第二个 blob 却只说明路径是 ../ai-harness；它不是另一个仓库的提交指针。

本地入口没有给出外部仓库 URL、标签、不可变提交或内容摘要。这并不意味着 LACNIC 没有其他配置手段。开发机镜像、私有安装脚本或运维手册完全可能在别处锁定它。公开证据只能支持这样的表述：只拿到 Hackathon 仓库及其提交的人，无法从中取得那份锁定证明。

“保持最新”与“可以复盘”并不冲突

把 harness 固定不动并不是合理目标。共享框架之所以有价值，正因为它能迅速吸收新的检查和修正。需要分开的，是运行时选择与事后记录。

系统可以在会话开始时选择“最新已批准版本”。一旦选定，就记录外部仓库地址和不可变提交。如果更新脚本把版本从 A 移到 B，凭证同时保留 A、B 和更新结果。这样既不牺牲新鲜度，也不会丢失重建现场的能力。

软件溯源提供了一个适度的参照，而不是对 LACNIC 的合规要求。SLSA 1.2 把 provenance 描述为可验证信息，用来穿过供应链中不断移动的环节，追溯一个制品在何处、何时、如何产生。代理规则集不必然等同于构建制品，LACNIC 也没有声称这里采用 SLSA。可借用的原则只有一个：移动依赖的最终解析身份应当随结果一起保存。

一份足够小的外部指令凭证

凭证可以比规则正文短得多。它至少应记录 Hackathon 提交、链接 blob、外部仓库 URL 与不可变提交、实际读到的 AI_HARNESS_MODE、update-framework.sh 执行前后的 harness 版本、git-preflight 的版本与结果、规范 checkout 和 worktree 身份、时间，以及发起运行的人员或自动化身份。

如果更新失败，凭证应说明任务是停止，还是继续使用旧版本。如果模式行改变，应记录转换。如果后来发现规则有误，应追加一条修正记录，指向受影响的运行，而不是悄悄改写历史。它不需要公开秘密、提示词或完整工作环境；需要保存的是产生约束力的规则身份。

这份记录也能让审查更高效。两次结果不同时，团队可以先排除 harness 版本差异，再讨论代码、数据或模型。预检通过的原因能够复现，旧结果也能分辨究竟属于旧项目、旧 harness，还是两者同时变化。

公开仓库没有证明安全事故、错误输出或生产部署。它呈现的是一个更克制的治理问题：外部规则已经重要到可以选择模式、触发更新并控制一次变更是否获准。既然规则能决定行动，规则的版本就应成为行动身份的一部分。

来源