I Built AgentCheck Because “The Coding Agent Said Done” Wasn’t Enough

我开发了 AgentCheck，因为“AI 编程助手说完成了”还远远不够

AI coding agents are getting surprisingly good at writing code. I use them regularly, and they can handle increasingly large tasks: refactoring code, adding features, updating dependencies, modifying configuration, creating migrations, and touching files across an entire repository. But I kept running into the same problem after the agent finished: How do I independently verify what it actually changed? AI 编程助手在编写代码方面表现得令人惊讶。我经常使用它们，它们能够处理越来越复杂的任务：重构代码、添加功能、更新依赖、修改配置、创建数据库迁移，以及修改整个代码库中的文件。但在助手完成工作后，我总是遇到同一个问题：我该如何独立验证它到底修改了什么？

The agent usually gives me a perfectly reasonable summary. Something like: Done. Implemented the requested changes, updated the tests, and cleaned up the affected code. Useful? Absolutely. Enough for me to commit without checking? Not really. So I built AgentCheck. 助手通常会给我一个看起来非常合理的总结。比如：“已完成。实现了请求的更改，更新了测试，并清理了受影响的代码。”有用吗？当然有用。但足以让我不经检查就直接提交吗？并不行。所以我开发了 AgentCheck。

The Problem Happens After “Done”

问题出现在“完成”之后

After a coding agent finishes a task, I still find myself manually checking things like: Which files actually changed? Were any files deleted? Did configuration change? Were dependencies added or updated? Was a database migration introduced? Did anything that looks like a secret appear? Were related tests changed? Is the overall change set larger or riskier than expected? 当编程助手完成任务后，我仍然发现自己需要手动检查以下事项：哪些文件发生了实际更改？是否有文件被删除？配置是否发生了变化？是否有依赖被添加或更新？是否引入了数据库迁移？是否有看起来像密钥（Secret）的内容出现？相关的测试是否已更新？整体变更集是否比预期的更大或风险更高？

Of course, Git already gives us the raw information. I can run: git status, git diff, git diff --stat. Then inspect individual files. And I still do that. But once coding agents become part of your normal workflow, repeating the same verification process after every task starts to feel like something that should be structured. That was the idea behind AgentCheck. 当然，Git 已经为我们提供了原始信息。我可以运行 git status、git diff、git diff --stat，然后检查各个文件。我确实还在这样做。但一旦编程助手成为你日常工作流的一部分，在每次任务后重复同样的验证过程，就会让人觉得这应该是一个结构化的流程。这就是 AgentCheck 背后的设计初衷。

What AgentCheck Does

AgentCheck 的功能

AgentCheck creates a trusted checkpoint before your coding agent starts working. Then, after the agent finishes, it compares the current Git-visible repository state with that checkpoint. The basic workflow is deliberately small: AgentCheck 会在你的编程助手开始工作前创建一个可信的检查点。当助手完成工作后，它会将当前 Git 可见的仓库状态与该检查点进行对比。其基本工作流被刻意设计得非常简洁：

agentcheck start
Let your coding agent work (Codex, Claude Code, Cursor, another AI-assisted coding tool, or technically even a human).
When the work is finished: agentcheck
agentcheck start
让你的编程助手开始工作（无论是 Codex、Claude Code、Cursor、其他 AI 辅助编程工具，甚至从技术上讲，人类也可以）。
工作完成后：运行 agentcheck。

AgentCheck then produces four sections: Changes, Findings, Risk, and Verdict. AgentCheck 随后会生成四个部分：变更（Changes）、发现（Findings）、风险（Risk）和结论（Verdict）。

The important part is that this result comes from the repository state itself — not from the coding agent’s explanation of what it believes it changed. 最重要的一点是，这些结果直接来源于仓库的实际状态，而不是基于编程助手对自己所做更改的描述。

Why Not Just Ask Another LLM to Review It?

为什么不直接让另一个大模型来审查？

This was one of the main design decisions. There are already many AI code-review tools, and some of them are very capable. But that wasn’t the problem I wanted AgentCheck to solve. If one LLM changes my repository, I didn’t necessarily want the verification layer to be: LLM changes code → another LLM reviews the first LLM. I wanted a smaller and more predictable layer: Coding agent → Actual Git-visible changes → Deterministic checks → Human review → Commit. 这是核心设计决策之一。市面上已经有很多 AI 代码审查工具，其中一些非常强大。但这并不是我希望 AgentCheck 解决的问题。如果一个大模型修改了我的仓库，我不希望验证层变成：“大模型修改代码 → 另一个大模型审查第一个大模型”。我想要的是一个更小、更可预测的层级：编程助手 → 实际的 Git 可见变更 → 确定性检查 → 人工审查 → 提交。

So AgentCheck does not use an LLM for its analysis. The checks are deterministic. Given the same repository state, AgentCheck should produce the same result. 因此，AgentCheck 在分析时不使用大模型。这些检查是确定性的。在相同的仓库状态下，AgentCheck 应该产生相同的结果。

What Does It Currently Look For?

它目前检查什么？

The first public version intentionally keeps the scope limited. AgentCheck can currently highlight things such as: 第一个公开版本有意限制了范围。AgentCheck 目前可以突出显示以下内容：

Database migration changes
Production configuration changes
Dependency changes
Deleted files
CI/CD-related changes
Unusually large change sets
Possible secrets
Situations where production code changed but related tests do not appear to have changed
数据库迁移变更
生产环境配置变更
依赖项变更
已删除的文件
CI/CD 相关变更
异常庞大的变更集
可能泄露的密钥（Secrets）
生产代码已更改但相关测试似乎未更改的情况

These signals feed into a transparent risk score and a restrained verdict. The goal is not to say: “This code is correct.” AgentCheck cannot know that. The goal is closer to: “These are the parts of this change set that probably deserve your attention before you commit.” 这些信号会汇总成一个透明的风险评分和一个审慎的结论。其目的不是为了说：“这段代码是正确的”（AgentCheck 无法判断这一点），而是为了指出：“这是变更集中在提交前可能需要你关注的部分。”

A Checkpoint Without Touching Your Real Git Index

不触碰真实 Git 索引的检查点

One technical requirement was particularly important to me: AgentCheck should not modify the developer’s actual Git index, working tree, or history. The checkpoint implementation uses Git’s tree/index model with a temporary alternate index. 有一个技术要求对我来说尤为重要：AgentCheck 不应修改开发者的实际 Git 索引、工作区或历史记录。检查点的实现利用了 Git 的树/索引模型，并使用了一个临时的替代索引。

This means the developer can already have staged changes, unstaged changes, tracked deletions, or non-ignored untracked files when the checkpoint is created. Those pre-existing changes become part of the baseline rather than being incorrectly attributed to the coding agent. The real Git index remains untouched. 这意味着当创建检查点时，开发者可以已经拥有暂存的更改、未暂存的更改、已追踪的删除项或未被忽略的未追踪文件。这些预先存在的更改会成为基准的一部分，而不会被错误地归因于编程助手。真实的 Git 索引保持不变。

Local-First Was Another Requirement

“本地优先”是另一个要求

AgentCheck currently has: no backend, no account, no source-code upload, no telemetry, no LLM API requirement. The verification happens locally. AgentCheck 目前具备以下特点：无后端、无需账户、无需上传源代码、无遥测、无需 LLM API。验证过程完全在本地进行。

Coding-Agent Independent

独立于编程助手

I developed AgentCheck primarily using Codex, but I intentionally avoided coupling AgentCheck to any specific coding-agent product. It doesn’t need to understand the agent session. It doesn’t need an agent plugin. It doesn’t need the agent to tell AgentCheck when it is finished. AgentCheck only cares about the resulting repository changes. So the same workflow can sit after Claude Code, Codex, Cursor, or any other coding agent. 我开发 AgentCheck 时主要使用了 Codex，但我刻意避免将 AgentCheck 与任何特定的编程助手产品绑定。它不需要理解助手的会话，不需要助手插件，也不需要助手告知何时完成。AgentCheck 只关心最终的仓库变更。因此，同样的工作流可以应用于 Claude Code、Codex、Cursor 或任何其他编程助手之后。

CLI and VS Code

CLI 和 VS Code

AgentCheck is currently available as both a CLI and a VS Code extension. AgentCheck 目前提供 CLI 和 VS Code 扩展两种形式。