agentacct：用本地工作收据审计你的编码代理，而不是听它自说自话

代理说你做完了，但你真的信吗

编码代理会告诉你任务完成了。它可能真的完成了，也可能只是把文件改了一半就声称完成。问题在于，你拿什么去核实。agentacct 解决的就是这个信任问题。它读取代理自己写在磁盘上的会话日志，把每个任务拆成工作步骤、使用的工具、改动的文件、运行的测试、消耗的时间和 token，然后生成一份工作收据。收据的核心不是代理说了什么，而是它做了什么，以及这些行为有多少被机器检查独立验证过。这个工具面向的是那些让 Claude Code 或 Codex 跑真实代码库、又不想盲目相信代理汇报的工程师。它不解决代理写错代码的问题，它解决的是你不知道代理到底干了什么的问题。

收据上的每个数字都带着来源

agentacct 的设计核心是区分代理的声称和机器的证明。每个检查结果按独立性分级：代理自己的声称最低，自报的检查次之，hook 观察到的退出码更高，CI 结果最高。这个分级不是装饰，它直接决定收据上怎么显示。代理说完成了，文件归入 Reported 栏；只有机器检查通过且时间戳晚于最近一次工作记录，任务才会标成 Verified。成本数字也一样，带 ≈ 的是估算，裸 $ 的是代理报告的原值。每个字段都标注了来源，来自客户端 hook、来自转录扫描、还是来自 MCP 记录。这种设计意味着一个代理永远没法把自己的声称伪装成验证，这是审计记录该有的样子。

数据流：从日志到收据，全程不出本机

agentacct 不自己记录任何东西，它读的是代理已经写好的日志。onboard 命令会检测你机器上的 Claude Code、Codex、OpenCode 和 Hermes 日志，建立一个全局存储，然后跑第一次用量同步。之后它启动一个后台同步和一个只监听 127.0.0.1 的本地 JSON API，端口是 8765。你可以在 macOS 应用里看收据，也可以用 agentacct tui 在终端里看实时仪表盘，或者让脚本轮询那个本地 API。整个数据流是单向的：代理写日志，agentacct 读日志，然后聚合。它不请求也不存储任何 provider API key，没有账号，没有云同步。这意味着一台机器上的数据只属于这台机器，代价是你没法在另一台机器上看到同一份收据。

安装和上手：一条命令，但有个坑

安装很简单，Python 3.11 以上，macOS 或 Linux，Windows 只能走 WSL。用 pipx install agentacct，然后 agentacct onboard 做一次全局安装，再 agentacct tui 启动终端仪表盘。onboard 默认是全局作用域，不往你的仓库写文件，它检测日志、建存储、跑首次同步，顺便启动后台同步和本地 API。这里有个明显的坑：MCP 服务器和 hook 是在会话启动时绑定的，所以跑 onboard 的那个代理会话本身不会被记录成第一个任务。你必须在任何仓库里新开一个代理会话，它才会开始被追踪。如果你偏好按项目隔离，可以用 agentacct onboard --scope project。没有 pipx 的话，先 brew install pipx，或者用 uv tool install agentacct。

证据分级不是摆设，是审计的骨架

agentacct 把每个检查按独立性分成四档，用不同的 pip 形状表示：空心、半实、实心、带环。绿色只保留给实时连接和外部验证过的证据。Sources 面板会显示每个数据源的导入健康状况、后台同步状态，还有一个 verifier 架子，专门放 CI 检查运行和人工审查，在独立证据真正进入存储之前，它老实标着 not connected。这个设计的直接后果是，如果你的工作流里没有 CI 或者人工审查，那么很多任务的证据等级会停留在较低档位。这不是工具的缺陷，而是它刻意保持的诚实。但如果你期望开箱即看到所有任务都 Verified，你会失望。

一个真正的局限：它只证明行为，不证明质量

agentacct 能告诉你代理跑了哪些命令、改了哪些文件、测试通过没有。它不能告诉你这些改动是否合理，代码风格是否一致，或者架构决策是否明智。证据分级里的 CI 那一档，需要你已经有 CI 系统并且能接入，如果项目没有 CI，那这一档永远是空的。另一个局限是归属置信度。agentacct 把用量和记录的工作步骤关联起来，每个关联都带一个 confidence 标签，exact、high、medium 或 low。当它无法证明某个关联时，它显示空白而不是猜一个数。这比瞎猜好，但也意味着你看到的收据可能带有很多未归属的缺口。它把缺失当作一个明确的状态，而不是用破折号或零填充。这种设计对审计友好，但对想要一个干净汇总数字的人来说，会显得很啰嗦。

替代方案：日志本身和云端看板

最直接的替代方案是什么都不用，直接翻代理自己的会话日志。Claude Code 和 Codex 都写了详细的转录，你能看到每一步。问题是日志是流水账，没有按任务聚合，没有成本计算，也没有证据分级。另一个方向是云端工具，比如一些商业的 AI 开发管理平台，它们会收集代理遥测数据到服务器上，提供漂亮的仪表盘和团队协作功能。区别在于，云端方案把日志副本传到别人的机器上，agentacct 坚持本地处理。云端方案的优势是跨机器统一视图和团队共享，agentacct 的优势是隐私和零依赖。如果你的团队需要共享审计视图，agentacct 的本地 JSON API 只监听 127.0.0.1，外部机器根本访问不了，你得自己另想办法转发。

维护成本和许可：MIT 下的自主权

agentacct 以 MIT 许可证发布，你可以自由修改和再分发，没有附加义务。仓库最近更新到 v0.10.2，版本号变化频繁，说明项目还在活跃迭代。维护成本主要来自代理日志格式的变化。Claude Code 或 Codex 更新后，日志结构可能变，agentacct 的解析逻辑就得跟着改。这意味着你需要关注上游版本，或者至少定期跑一次测试。项目有 GitHub Actions 的 tests workflow，但你没有理由相信每次提交都过测试。另一个成本是 onboarding 的 hook 和 MCP 绑定，它们需要在每个新会话里生效，如果你经常开新仓库，要确认 agentacct 的全局安装仍然被代理识别。总体而言，MIT 许可给了你足够的自主权，但你也得自己承担日志格式演进的跟进工作。

编辑结论

agentacct 适合那些已经依赖 Claude Code、Codex、OpenCode 或 Hermes，并且对代理的自述完成状态存疑的开发者。它不适合需要跨机器集中审计、或者希望自动获得云端 CI 验证结果的团队，因为后者需要额外接入。采用前应验证三件事：你的代理版本是否在支持列表内，onboard 能否正确识别你的日志目录，以及你能否接受证据分级中“未连接”状态长期存在。如果这些都能接受，agentacct 提供的本地工作收据比任何云端仪表盘都更接近审计记录的本质：它把代理的声称和机器的证明分开，并且从不假装两者相同。

官方来源

1. Official README
2. Project repository
3. Release notes