Backpass 能让 Claude Code / Codex 越用越好吗？公开测试、运行数据与宣传口径对照
Backpass 是一个面向 Coding Agent 的项目级记忆维护工具。它读取 Claude Code、Codex、OpenCode、Cursor CLI 等工具留下的本地会话记录，从重复出现的错误和规则缺口中生成对 AGENTS.md、CLAUDE.md 或项目 Skills 的修改建议。
它不直接修改文件。新增规则需要来自至少两个独立会话的证据，每项修改需要附带原始会话引用，最后由用户决定是否写入。项目把这个过程称为针对 Agent Memory 的"梯度下降"。
截至 2026 年 9 月 2 日，公开资料中已经出现了独立运行测试和 GitHub 用户实测，但还没有找到针对真实 Coding 任务的独立前后对照基准测试，例如比较使用 Backpass 前后的任务成功率、返工次数、Token、成本和耗时。
MrKeyoor 独立运行测试
网页地址：mrkeyoor.com/repos/backp...
MrKeyoor 在 2026 年 8 月 31 日对 Backpass 做了一次独立运行验证。测试使用提交 b8942cd，环境为全新的 Debian 容器，配置 3 个 CPU、8 GB 内存和 Node 工具链。
公开结果如下：
| 项目 | 测试结果 |
|---|---|
| 安装时间 | 15 秒 |
| 安装包数量 | 77 个 |
| 磁盘占用 | 49 MB |
| 测试数量 | 472 |
| 通过 | 472 |
| 失败 | 0 |
| 测试耗时 | 54 秒 |
| 源码文件 | 144 个 |
| 源码规模 | 约 27,780 行 |
| 仓库大小 | 1.3 MB |
MrKeyoor 还给出了几项评分：
| 项目 | 评分 |
|---|---|
| 安装体验 | 4/5 |
| 文档 | 5/5 |
| 社区 | 4/5 |
| 成熟度 | 3/5 |
测试者的结论是，Backpass 可以在受支持的环境中完成安装并运行项目自身测试，适合已经积累多次 Agent 会话、反复遇到相同 Agent 错误，并愿意人工审核规则修改的团队。
这次测试没有配置真实 Claude、Codex 或其他已登录 Agent，也没有让 Backpass 分析实际 transcript。测试页面明确说明，容器中没有密钥和已认证的 Agent 账户。因此，472 项测试验证的是项目代码及仓库测试能否运行，不包含 Backpass 修改 AGENTS.md 前后的 Coding 任务效果对照。
官方公开数据：历史 transcript 压缩 96%～99%
网页地址：github.com/kunchenguid...
Backpass 官方 README 给出的主要量化数据，不是 Coding Agent 开发质量基准测试，而是 Backpass 自身处理历史会话时的流程数据。
在历史 transcript 进入模型之前，Backpass 会先进行确定性压缩。用户和助手的主要对话被保留，工具调用被压缩成一行，长工具输出会被截断，部分框架注入内容会被删除。官方称这一过程通常能减少 96%～99% 的原始 transcript 内容。
官方还公开了几项默认参数：
| 项目 | 默认值 |
|---|---|
| 单次最多分析 transcript | 100 个 |
| 历史样本权重半衰期 | 14 天 |
| 新规则最低重复证据 | 2 个独立 session |
| 项目记忆文件预算 | 约 5,000 Token |
| Token 估算误差 | 官方称约 ±15% |
当 transcript 数量超过 100 时，Backpass 默认采用带时间权重的抽样，而不是分析全部记录。项目记忆文件的默认预算约为 5,000 个估算 Token。
这里的 96%～99% 是 Backpass 分析历史 transcript 时的内容压缩比例。官方页面没有把它定义为 Claude Code、Codex 后续开发会话的 Token 节省率，也没有给出"使用 Backpass 后 Coding Token 降低 96%～99%"的数据。
GitHub 用户实测：Windows 并发运行 100 个会话
网页地址：github.com/kunchenguid...
2026 年 8 月 31 日，一名 GitHub 用户在 Windows 11 上测试 backpass@0.1.15、acpx@0.13.2 和 Codex harness。
用户使用默认的 --jobs 4 处理 100 个 transcript。在运行过程中，出现了 3 次针对 ~/.acpx/sessions/index.json 的 EPERM 文件操作错误，随后 Backpass 将其中一次错误报告成"adapter does not support sessions"，最终进程以退出码 1 结束。
用户又将并发数改为 --jobs 1：
| 运行方式 | 实际创建的 session | EPERM | 最终结果 |
|---|---|---|---|
--jobs 4 |
100 | 3 次 | exit 1 |
--jobs 1 |
21 | 0 | exit 0，成功生成 proposal |
第二次运行复用了第一次产生的缓存，因此只创建了 21 个 session，而不是再次创建 100 个。报告者本人明确说明，这组数据符合并发竞争问题的特征，但由于并发数和实际 session 数同时发生变化，不能把它当作严格的因果证明。
这组数据测试的是 Windows 下 Backpass 的并发分析稳定性，不是使用 Backpass 后 Coding Agent 的任务成功率。
GitHub 用户实测：Windows 下 apply 无法完成
网页地址：github.com/kunchenguid...
同样在 2026 年 8 月 31 日，GitHub 用户对 Windows 下的 backpass apply 做了实际复现。
测试环境为：
| 项目 | 环境 |
|---|---|
| 系统 | Windows 11 |
| Node | v22.19.0 |
| Backpass | 0.1.15 |
| 同时验证 | 当时最新 main，提交 698d57f |
用户接受 Backpass 生成的修改后执行 backpass apply，程序在真正写入文件之前进入无限循环，只能通过 Ctrl-C 结束。
报告中进一步运行了路径复现代码。Git 返回的仓库根目录使用 /，Node path.join 生成的目标路径使用 ``。两种路径字符串无法相等。测试显示路径向上遍历 9 次 后到达 C:，随后停留在根目录继续循环。
报告者指出，apply 是 Backpass 将用户已经批准的修改真正写入项目的唯一入口，因此该问题会阻止 Windows 用户完成整个修改流程。该问题在页面记录时仍处于开放状态。
这项测试同样不涉及未来 Coding Agent 的质量变化，但提供了真实工作流中的运行结果。
作者公开说明：因果归因仍然困难
网页地址：github.com/kunchenguid...
Backpass README 单独列出了因果归因问题。作者指出，一次 Agent session 表现良好，并不能证明某条 AGENTS.md 规则导致了这个结果；模型也可能错误解释某条规则对自己的影响。
原文使用了很直接的表述：
"Causal attribution is genuinely hard."
中文含义是：因果归因确实很困难。
Backpass 当前使用四类机制降低这类错误：每项证据必须带原始引用；新增规则至少需要两个独立 session；负面错误证据拥有更高权重；最终修改需要人工审核。官方没有给出这些机制能够把误判率降低到多少的数据。
作者实际使用记录：每周运行一次
网页地址：blog.kunchenguid.com/p/your-agen...
作者 Kun Chen 在 2026 年 8 月 23 日的文章中介绍了自己的使用方式。
他会对活跃仓库大约每周运行一次 Backpass，阅读生成的修改建议，拒绝模型推断过度的建议，接受其他修改。作者描述自己的长期体验是，AGENTS.md 会逐步变得更精简、更有效。
文章还给出了 Backpass 当时的几个规则：历史 transcript 压缩约 96%～99% ；新的 gap 少于两个 session 时直接丢弃；单次梯度步骤最多提出 5 项修改；项目级常驻记忆可以设置例如 5,000 Token 的预算。
这篇文章没有提供同一批 Coding 任务在优化前后的对照数据，也没有给出成功率、返工次数、成本或开发耗时变化。
官方后续修改：连续加强证据与因果判断
网页地址：github.com/kunchenguid...
Backpass 在 2026 年 8 月 28 日至 29 日连续修改了与证据判断有关的逻辑。
| 版本 | 日期 | 相关修改 |
|---|---|---|
| 0.1.12 | 8 月 28 日 | 增加 gap identity 判断，并为删除 instruction 增加保护 |
| 0.1.13 | 8 月 29 日 | 将 gap domain 改为因果测试，并降低自动提取倾向 |
| 0.1.14 | 8 月 29 日 | 在审核界面增加 gap evidence funnel |
0.1.12 同时让 transcript 抽样变成确定性且可保持一致；0.1.9 则修改了证据缓存，使证据复用限制在当前 memory hash 下。
这些版本记录的是 Backpass 如何判断重复错误、如何复用历史证据以及如何防止不合适的规则删除，没有发布对应的 Coding Agent 前后效果基准测试。
总结
目前公开的独立测试首先验证了 Backpass 本身可以运行。MrKeyoor 在全新 Debian 环境中完成安装，472 项项目测试全部通过，0 项失败。但这次测试没有连接已认证的 Claude、Codex 等 Agent，也没有执行真实项目的优化前后 Coding 任务对照。
真实用户运行数据还显示出平台差异。在 Windows 11 的一次测试中，默认 --jobs 4 分析 100 个 session 时出现 3 次 EPERM，最终 exit 1；降低到单任务运行后完成 proposal，但第二次只实际创建了 21 个 session，报告者没有把它视为严格对照实验。另一项 Windows 实测则发现 backpass apply 在写文件前进入无限循环。
截至目前，公开的非官方测试还没有给出下面这些数字：
- Backpass 优化前后的 Coding 任务成功率；
- Agent 返工或人工纠正次数变化；
- 后续 Claude Code / Codex 输入或输出 Token 变化；
- 单个开发任务的模型成本变化；
- 完成相同任务所需时间变化。
因此，现有公开实测能够支持的范围是：Backpass 的代码和核心流程已经有人独立运行验证，也出现了真实用户工作流数据；但"经过 Backpass 修改的 AGENTS.md 能稳定提高 Claude Code 或 Codex 的开发质量"目前还没有独立 A/B 数据可以量化。
官方公开的 96%～99% 数字描述的是 Backpass 自身分析历史 transcript 时的压缩比例，与未来 Coding session 的 Token 消耗是两个不同指标，不能直接放在一起比较。
如果后续出现同一批 Coding 任务、同一模型、同一仓库下的前后对照测试，并公开成功率、Token、成本和返工次数，才能进一步量化 Backpass 对实际开发工作流带来的效果。