An Evidence Contract for AI Agent Engineering Claims
A technical article argues that a complete explanation and a public repository do not by themselves validate an AI agent’s claimed capabilities. Using Open ETF Agent v0.5 as a case study, the author maps technical claims to implementation locations, fixed source versions, runnable targets, verification receipts, and narrowly defined behavior. The article also explains how structured coverage checks distinguish verification of existing records from an actual rerun of a bounded target. The v0.5 example covers explicit saving, revising, and forgetting with synthetic inputs; it does not demonstrate a complete account-level memory service or automatic semantic learning.
The framework gives readers a concrete way to identify which narrowly scoped claims are implemented, reproducible, and supported by matching verification evidence without treating a repository link as proof of an entire system.
技术文章很容易给人一种错觉：文章写得完整，GitHub 仓库也存在，技术方案就已经得到了验证。但这三件事并不等价。
假设你读到一篇 Agent 长期记忆文章：它介绍保存偏好、更新记忆、响应遗忘请求，最后附上开源仓库。你准备照着运行，却发现文章讨论了自动学习，示例只有手动保存；仓库已经升级，不知道文章说的是哪一版；README 写着测试通过，却没说验证了哪段行为。
这未必意味着文章写错了。更常见的问题是：技术主张、实际代码、运行版本和验证结果之间，缺少一条可以核对的关系。
最近整理 Open ETF Agent 的公开工程时，我尝试把这条关系明确下来。目标不是为每篇文章附上长长的测试报告，而是让读者能回答三个实际问题：它在哪里实现？我怎样运行？运行结果究竟证明了什么？
一、为什么只贴 GitHub 地址还不够？
最早写技术分享时，讲清方案、给出片段、最后贴一个仓库链接，通常就够了。但项目持续演进后，三个细节会逐渐变成问题。