8.0
热点
AI SCORE
编程提效2026-08-24 05:08
AgentCheck：验证AI编程代理实际改动了哪些文件
dev.to · AI#AI编程#代码审查#工程实践
Editor brief · 编辑速览
开源工具AgentCheck帮助开发者在AI编程代理声称完成后独立核查：实际变更了哪些文件、是否新增依赖、是否引入数据库迁移、是否有敏感信息暴露。
AI 编程 Agent 写代码的能力已经越来越强了。
我平时也在用，它们能处理的任务越来越复杂：重构代码、增加功能、更新依赖、修改配置、创建迁移文件、跨整个仓库修改文件。
但每次 Agent 完成之后，我都会遇到同一个问题：
如何独立验证它到底改了些什么？
Agent 通常会给我一个听起来很合理的总结。
完成。已实现所需更改，更新了测试，清理了相关代码。
这够让我直接提交而不检查吗？
于是我写了 AgentCheck。
编程 Agent 完成任务后，我发现自己仍在手动检查这些事情：
哪些文件真正被改了？ 有没有文件被删除？ 配置是否被改了？ 依赖有没有新增或更新？ 有没有引入数据库迁移？ 有没有出现看起来像密钥的东西？ 相关测试有没有改？ 整体变更集是否比预期更大或风险更高？
当然，Git 本身已经给了我们这些原始信息。
git status
git diff
git diff --stat
然后逐个检查文件。
但一旦编程 Agent 成为日常工作流的一部分，每次任务后重复相同的验证流程就开始让人觉得应该结构化了。
这就是 AgentCheck 的初衷。
AgentCheck 在编程 Agent 开始工作之前创建一个可信的检查点。
然后，在 Agent 完成后，它将当前 Git 可见的仓库状态与该检查点进行比较。
基本工作流程刻意保持简洁：
agentcheck start
然后让你的编程 Agent 开始工作。
另一个 AI 辅助编程工具
或者严格来说甚至可以是人类。
工作完成后：
agentcheck
AgentCheck 然后生成四个部分：
Changes
Findings
Risk
Verdict
AgentCheck
Changes
────────────────────────────
2 modified
1 created
0 deleted
0 renamed
A packages/example/new-file.ts
M package.json
M src/example.ts
Findings
────────────────────────────
⚠ Dependency change detected.
Risk
────────────────────────────
Score: 3 — MEDIUM
Verdict
────────────────────────────
REVIEW RECOMMENDED
重要的是，这个结果来自仓库状态本身——而不是来自编程 Agent 对它认为自己改了什么的解释。
这是其中一个主要的设计决策。
现在已经有许多 AI 代码审查工具，其中一些非常强大。
但那不是我希望 AgentCheck 解决的问题。
如果一个 LLM 改变了我的仓库，我不一定想让验证层变成：
LLM 改代码
↓
另一个 LLM 来审查第一个 LLM
我想要一个更小、更可预测的层：
编程 Agent
↓
Git 实际可见的变更
↓
确定性检查
↓
人工审查
↓
提交
所以 AgentCheck 在其分析中不使用 LLM。
检查是确定性的。
给定相同的仓库状态，AgentCheck 应该产生相同的结果。
第一个公开版本刻意将范围限制在较小规模。
AgentCheck 目前可以高亮显示以下内容：
数据库迁移变更 生产配置变更 CI/CD 相关变更 异常大的变更集 生产代码改了但相关测试似乎没改的情况
这些信号会输入到一个透明的风险评分和一个克制的判定中。
0–2 → LOW
3–6 → MEDIUM
7+ → HIGH
目标不是说：
这段代码是正确的。
AgentCheck 无法知道这一点。
目标更接近于：
以下是此变更集中在提交前可能值得你关注的部分。
有一个技术需求对我特别重要：
AgentCheck 不应该修改开发者的真实 Git 索引、工作树或历史。
检查点实现使用 Git 的 tree/index 模型和一个临时的备用索引。
当前仓库状态
↓
临时 Git 索引
↓
git write-tree
↓
检查点树
随后，AgentCheck 创建当前状态的另一个表示并进行对比：
检查点树
↓
diff
↑
当前树
这意味着开发者在创建检查点时已经可以拥有：
未被忽略的未跟踪文件
那些已存在的变更会成为基线的一部分，而不是被错误地归因于编程 Agent。
真实的 Git 索引保持不变。
AgentCheck 目前有：
不上传源代码 不需要 LLM API
验证在本地进行。
这也保持了工作流的简洁：
npm install -g @agentcheck/cli
agentcheck start
# 编程 Agent 开始工作
agentcheck
如果你更喜欢在编辑器内查看结果，也可以使用 VS Code 扩展。
我主要使用 Codex 开发 AgentCheck，但我刻意避免将 AgentCheck 耦合到任何特定的编程 Agent 产品。
它不需要理解 Agent 会话。 不需要 Agent 插件。 不需要 Agent 告诉 AgentCheck 何时完成。
AgentCheck 只关心最终产生的仓库变更。
所以同样的工作流可以放在以下工具之后：
Claude Code
Codex
Cursor
其他编程 Agent
这种分离对我很重要。
编程 Agent 会变化。
Git 仓库是事实的来源。
AgentCheck 目前提供 CLI 和 VS Code 扩展两种形式。
npm install -g @agentcheck/cli
agentcheck start
agentcheck
VS Code 扩展在编辑器内暴露了相同的审查模型：
CHANGES
FINDINGS
RISK
VERDICT
VS Code 扩展刻意只是一个相同确定性核心上的薄薄 UI 层，而不是一个独立的分析引擎。
AgentCheck 采用 Apache License 2.0 开源。
https://github.com/emreordu/agentcheck
https://www.npmjs.com/package/@agentcheck/cli
https://www.npmjs.com/package/@agentcheck/core
https://marketplace.visualstudio.com/items?itemName=agentcheck.agentcheck-vscode
第一个版本主要是为了证明检查点和确定性验证模型。
对于下一个版本，我目前正在探索：
稳定、版本化的审查报告模型 机器可读的 JSON 输出 更多可操作的确定性发现 详细的新增/删除/更新的依赖信息 VS Code 内更好的发现到 diff 导航
我刻意想要避免的一件事是把 AgentCheck 变成一个巨大的 AI 代码审查平台。
我希望核心思想保持简单：
独立验证实际发生了什么变更。
AgentCheck 仍处于早期阶段。
目前对我最有用的反馈不是：
编程 Agent 说"完成"后你仍在手动检查什么？
AgentCheck 有没有漏掉你期望它高亮的内容？
它是否产生了噪音发现？
检查点工作流在实践中是否别扭？
在审查期间什么样的确定性信号会真正帮助你？
你主要会从 CLI 还是 VS Code 使用它？
如果你在真实仓库中使用 Claude Code、Codex、Cursor 或其他编程 Agent，我很想知道这种方式如何适应你的工作流。
告诉我它哪里做错了。
不要相信"完成"。验证结果。