我的 AI 代理不断重新验证已经验证过的工作，所以我给它们添加了信任记忆
我在使用编程代理（Claude Code、Cursor，不管哪个）时反复遇到一个模式：会话 1：代理修复了一个认证模块。运行测试。42/42 通过。很棒。会话 2，第二天早上：另一个代理（或者同一个，但上下文是全新的）触及同一区域。它不知道昨天测试已经通过了。于是它重新读取文件，重新运行测试套件，重新得出相同的结论——消耗几千个 token 来重新发现已经存在的状态。在多个代理的设置中，每个文件、每个会话、每个代理都会放大这种消耗。代理没有已验证过的工作的记忆。一切都像是《土拨鼠日》。解决方案：将验证缓存为戳记（stamp）。一个戳记大约 15 个 token 的 JSON，随文件一起（Markdown 中的 YAML 前置元数据，图片中的 XMP，docx 中的 OOXML 部分，其他文件则使用侧边文件）：
# 会话 1 — 代理完成，为验证的内容打上戳记
$ akf stamp auth.py --agent claude-code --evidence "42/42 tests passed"
# 会话 2 — 任何代理、任何工具，在基于它构建之前先检查
$ akf check auth.py
OK trust=0.65 agent=claude-code evidence=test_pass age=1d claims=1
一行代码，读取大约 20 个 token，脚本化的退出码（0 = 信任，1 = 重新验证，2 = 无元数据）。促使我构建这个的数学计算：一个戳记成本约 15 token；重新验证成本 15,000。
真正重要的部分
证据是加权的，不是二元的。一个裸露的“AI 生成的”戳记无论模型声称多么自信，得分都很低——这是有意为之，它只是未经验证的推断。一次测试运行收据会提高分数。一次人工审核则提高更多：
$ akf stamp report.md --agent claude-code # 裸露
$ akf check report.md
LOW trust=0.21 reason=below_threshold # 不信任
$ akf stamp report.md --evidence "tests pass" # 已验证
$ akf check report.md
OK trust=0.65 evidence=test_pass
陈旧性是机械性的。如果文件被打上戳记后发生了变化，那么戳记就不再描述该文件了：
$ echo "quick edit" >> auth.py
$ akf check auth.py
STALE trust=0.65 reason=modified_after_stamp # exit 1 → re-verify
记忆会衰减。这一点让我惊讶于它的实用性。智能体（agent）的记忆文件有一个信任半衰期（trust half-life）——三个月前关于一个已重构代码库的事实，其权重不应与昨天的一样：
$ akf stamp memory/project-facts.md --preset memory --agent claude-code
# fresh: OK trust=0.75 age=2d
# two months: LOW trust=0.17 age=61d → agent re-verifies instead of trusting a stale memory
零投入模式。没有人会大规模手动打标签，包括我在内。akf init会配置一个git post-commit钩子和一个Claude Code钩子，这样智能体编写的每个文件都会自动被打上标签。
我要坦诚的地方
- 标签（stamps）是声称，而非证据。智能体可以在标签中撒谎，就像开发者可以在提交信息中撒谎一样。Ed25519签名可以标识“谁”做的，但“测试是否真的运行了”是一条问责追踪链条，而非密码学保障。
- 目前基于修改时间（mtime）判断陈旧性，在全新git检出时会出现误报。后续会改用内容哈希比较来修复。
- 这是一种元数据格式，因此存在标准的先有鸡还是先有蛋的问题。单用户价值（你自己的智能体在你自己的会话中使用）必须支撑它，直到网络效应形成——这正是
check命令必须自私地值得运行的原因。
尝试一下
pip install akf # 或: npm install akf-format
akf init # 为 git + Claude Code 配置钩子
akf quickstart # 60秒演示
有一个MCP服务器（https://pypi.org/project/mcp-server-akf/）（可与Claude Desktop/Code、Cursor及任何MCP客户端配合使用），一个GitHub Action（https://github.com/marketplace/actions/akf-certify），可在PR上发布信任报告，以及GitHub上的规范+SDK（https://github.com/HMAKT99/AKF）。采用MIT许可证。
我真心希望听到这个模型在哪里会失效——特别是来自运行多智能体流水线的人。