QA 工程师自建工具链：验证 AI 编程 Agent 的实际工作成果

AI 编程智能体有一项特别擅长的、但并非写代码的本事：断言。"测试通过了。""文件已更新。""修复已推送。"如果你真正用智能体做过实际工作，就会知道这些声明有时候……过于乐观了。

我是一名 QA 工程师，每天都在用 Devin。某天我厌倦了手动核对智能体的声明是否与现实相符，于是做了一个 QA 工程师该做的事：写了一套测试工具。然后是评估套件。然后是策略层。然后是决策层。二十个本地优先工具下来，整套系统跑在一台内存受限的笔记本上，没有任何遥测数据流出本机。

这是现有工具的简要说明、背后的原因以及我学到的东西。

差距所在：智能体断言，QA 验证

触发点很简单。一次智能体会话报告"已修复，全部绿灯"——而磁盘上的文件却给出了相反的答案。没有恶意；智能体是从自己的叙事出发做报告，而不是从客观事实出发。经典的 QA 问题：声明和状态是两个不同的产物，只有其中一个才是证据。

让一切成为可能的洞见：智能体 CLI 已经在本地写好了结构化的遥测数据——会话文件、工具调用状态、token 使用量。证据一直就在磁盘上。我只是需要停止相信故事，开始读取日志。

五个工具，一条流水线

工具按顺序组合：理解 → 验证 → 测量 → 控制 → 判断。

devin-internals-spec — 理解。在信任工具输出之前，你需要了解契约：文件格式、退出码以及运行时本身的行为规则。这就是规范层——下游所有内容都据此读取。

devin-qa-pack — 验证。对实际智能体工作进行 QA 审计：文件 diff 是否存在、测试是否运行过、commit 是否存在、push 是否落地、验证命令是否执行。声明对照 tool_call_state 检查，而不是对照智能体的叙事。47 个测试用例，在 Ubuntu 和 Windows 上 CI。这就是一切开始的地方。

devin-evals — 测量。一旦验证工作正常，你就可以问更难的问题：在这个类型的任务上，智能体表现如何？黄金任务、评分量规、跨会话的回归追踪。

devin-bridge — 控制。意图和执行之间的策略门控——基于 ACP 的控制，带有 --devin-only 模式，强制"此会话只做它被限定范围内的操作"。

poordjaevin — 判断。这是我最引以为傲的部分。接收任务描述，输出一个校准后的置信度分数：我应该信任这次委托吗？校准过程是个有趣的故事——判断器通过在真实会话数据上迭代改进，将 ECE 从 0.170 降到了 0.071。（ECE = 期望校准误差：当判断器说"80% 置信"时，它应该大约 80% 的时间是正确的。大多数置信度分数做不到这一点。现在我的基本做到了。）它还是一个真正的 MCP server——poordjaevin serve——所以智能体可以在飞行中咨询它。

"本地优先"实际上为你买了什么

每个工具都遵循相同的契约：读取本地智能体状态、写入本地产物、暴露稳定的 CLI、在可选基础设施缺失时优雅降级。不需要必选的守护进程、不需要 SaaS 仪表盘、不需要遥测。

devin-history — 跨会话记忆：在所有过去的会话上进行可搜索的 SQLite（7+ 条可 grep 的智能体考古命令）

devin-metrics — 遥测数据聚合，获取随时间推移的质量信号

devin-memory + devin-search + devin-graph — 记忆存储、检索，以及基于会话、项目和决策的知识图谱

devin-doctor — 跨 Windows/Linux 的环境诊断

devin-backup — 快照 + 验证 + 恢复智能体状态

devin-janitor + devin-redact — 清理和密钥删除，让状态可以安全迁移

devin-office — 有趣的那个：一个实时电路板仪表盘，从本地存储渲染真实会话、子智能体和工具调用。纯视觉、只读、零遥测——也是制作很棒演示 GIF 的素材。

构建这整套系统的三个教训

**1. 智能体自身的遥测数据是一个尚未开发的 QA 数据源。**会话文件和工具调用状态是大多数人忽略的结构化证据。读取它们能将"信任智能体"变成"验证智能体"——而验证才是让大规模委托变得安全的东西。

**2. 校准 > 置信度。**一个自信地犯错判断器比没有判断器更糟糕。ECE 的迭代（0.170 → 0.071）需要真实的标注结果，而不是调 prompt。如果你构建任何类型的 AI 决策层，请明确测量校准度。

**3. Devin-only 模式比集成更重要。**每个工具都可以独立工作，只需存在智能体 CLI 即可。Obsidian、Slack、MCP——都是可选的。生态必须在一个只有 Devin 安装的锁定企业盒子中存活下来，因为很多真实工作就是在那里发生的。

试试看 / 拆解它

所有内容均采用 MIT 许可证，跨平台，有英语和葡萄牙语（巴西）文档：

Profile/catalog: github.com/Icaro0310

Website: icaro0310.github.io

从这里开始：devin-qa-pack（验证器）或 poordjaevin（校准后的判断器——pip install poordjaevin / uv tool install poordjaevin）

留给评论区的一个真诚问题：如果你在真实工作中运行 AI 智能体——Copilot、Devin、Cursor、Claude Code——你现在如何验证它们的声明？手动抽查？CI 门控？还是什么都不做？我猜"什么都不做"是最常见的答案，而这套系统的诞生部分源于我意识到自己的答案竟然就是这个，这让我感到恐惧。