作者注：本文用 5 个步骤讲清如何设计 Agent 验收关卡，让长时间运行的智能体有明确的终点、可靠的反馈和可控的成本。
Agent 连续运行几小时甚至几天后，交回来的结果看似完整，却没人敢直接合入，这是很多开发团队遇到的难题。本文将介绍 Agent 验收关卡的 5 步设计法，帮助你在启动长任务之前，把“做完”定义成机器可以反复检查的标准。
2026 年 10 月 27 日，CentOS 创始人之一 Gregory Kurtzer 公布了 Ginux 项目。据报道，他在 11 天内主要依靠一个持续运行的 Codex 任务，留下约 13.9 万行代码，让这款独立内核启动 Rocky Linux 10 并运行 systemd。有人追问他如何把跑偏的 Agent 拉回正轨，他的回答很简单：关卡设得多。
这不是又一篇提示词技巧合集，本文关注的是长任务真正依赖的工程结构：目标、关卡、证据、回归和停止条件。
核心价值：读完本文，你将能为自己的项目写出一套 Agent 验收关卡，并判断哪些环节交给机器，哪些决定必须留给人。
Agent 验收关卡核心要点
Agent 验收关卡是一组预先定义、可以重复执行的检查点。它告诉 Agent 当前结果是否达标，也告诉人类哪些证据值得审查。
| 要点 | 说明 | 价值 |
|---|---|---|
| 验收标准前置 | 启动长任务前写清楚终点和阶段目标 | 减少 Agent 用局部成功代替整体完成 |
| 关卡可执行 | 用命令、脚本、CI 或真实运行结果判定 | Agent 无需等待人工即可自行迭代 |
| 检查系统行为 | 关注程序实际运行时的表现 | 发现“看起来可信”的错误输出 |
| 人机分层负责 | 人定架构与验收，Agent 做实现与回归 | 人不再成为循环中最慢的环节 |
| 预算可控 | 提前设定失败次数、用量和暂停条件 | 避免长任务在错误方向上持续消耗 |
Ginux 案例中的 Agent 验收关卡
Kurtzer 没有把“写一个内核”直接交给 Agent，而是选择了 Linux 用户空间程序能否运行、systemd 能否启动这样的硬性关卡。systemd 依赖大量系统组件，又是启动和运行整个系统的核心进程，因此很适合用来检验内核是否真的可用。
这个项目运行在两个相互配合的循环中。外部循环由人主导，从愿景、架构与约束、验收关卡，一直到审查实际行为并决定修正或验收；内部循环由 Agent 完成，反复执行实现、构建并在 QEMU 中运行、测量分析故障、修订和回归测试。
Kurtzer 还特别提醒，许多故障会产生很可信的输出，实际却违反语义、隔离要求或生命周期行为。如果缺少关卡，最后很容易得到表面能运行、结构却很薄弱的代码。
为什么 Agent 验收关卡要自动运行
Cursor 工程师 Lauren Tan 也把验证视为使用 Agent 时最重要的技能。她所说的验证，包括让 Agent 真正运行代码、采集 CPU 跟踪或堆快照、打开 iOS 模拟器，并按用户的方式操作应用。
她公开称自己每月可以把 4000 个 PR 合入生产环境。即使每个 PR 只由人检查 5 分钟，累计也要约 333 小时，所以这种规模下的检查系统必须能在无人介入时运行。这个极端案例存在不少争议，但它说明了一个普通团队同样适用的道理：Agent 能检查自己的输出，才能持续工作；不能检查时，它只能把 diff 交给你然后停下。
配图中的双循环可以直接迁移到日常项目。如果想用不同模型分别承担实现与审查，可以通过 API易 apiyi.com 接入，再把模型调用纳入内部循环。
Agent 验收关卡快速上手：5 步设计法
下面用一个常见任务作为示例：让 Agent 把一个旧版 REST 服务迁移到新框架，并保持现有客户端不受影响。你可以把示例中的检查项替换成自己项目的构建、测试和部署流程。
第 1 步：为 Agent 验收关卡定义系统级终点
先写一句可以被观察的话，用来描述任务结束时系统应当发生什么。“完成服务迁移”过于模糊，“使用同一批回放请求，新旧服务的状态码和关键响应字段保持一致”则可以被验证。
好的终点通常来自真实使用路径。Ginux 的终点是 Rocky Linux 10 运行到 systemd 的 multi-user.target，Web 应用的终点可以是核心用户流程跑通，数据任务的终点可以是输出结果与基准数据集一致。
第 2 步：把 Agent 验收关卡拆成五层
单一的最终测试反馈太慢，Agent 失败后也很难定位问题。建议按照运行成本从低到高设置关卡，让便宜的检查先拦住明显错误。
| 关卡层级 | 检查内容 | 示例 | 失败后的动作 |
|---|---|---|---|
| L1 静态约束 | 格式、类型、依赖边界 | 禁止模块交叉导入 | Agent 立即修复 |
| L2 单元行为 | 函数和模块逻辑 | 核心单元测试 | Agent 定位并修复 |
| L3 集成契约 | 接口、数据库、外部依赖 | 接口契约测试 | Agent 对比差异后修订 |
| L4 系统运行 | 完整服务的真实行为 | 启动服务并回放请求 | Agent 收集日志和性能数据 |
| L5 人工验收 | 架构、风险和业务取舍 | 审查证据包并决定是否合入 | 人给出新约束或停止任务 |
Lauren Tan 的 Dune 架构提供了 L1 的极端例子。她通过 600 多个 PR 重构项目，并用 CI 校验依赖图，确保 Electron 的 main 和 renderer 目录不会交叉导入，同时禁用 useEffect、禁止写注释。这些规则未必适合你的代码库，但把团队约束写成自动检查的做法值得借鉴。
第 3 步：把 Agent 验收关卡写成可执行卡片
每道关卡都应该有一张简短的卡片，放在 Agent 启动时能读取的项目文档中。卡片写清楚后，Agent 不需要猜测“什么叫通过”，人也能据此追溯证据。
| 字段 | 填写要求 | 服务迁移示例 |
|---|---|---|
| 关卡名称 | 用行为命名 | 回放请求一致性 |
| 运行环境 | 固定版本和依赖 | 隔离测试环境，使用固定数据快照 |
| 执行入口 | 提供一条明确命令 | make gate-replay（示例命令） |
| 通过判据 | 使用可比较的结果 | 状态码和关键字段全部一致 |
| 证据产物 | 保存可复查的文件 | 差异报告、服务日志、性能记录 |
| 保护规则 | 标明不可修改的内容 | 验收样本和判定脚本只读 |
| 失败策略 | 说明下一步动作 | 同一错误连续 3 轮未解决则暂停 |
其中，保护规则最容易被忽略。Agent 倾向于选择眼前最省事的路径，如果它能修改验收样本或放宽判定脚本，测试结果就会失去意义。建议把这部分放在受保护目录，并在 CI 中检查相关变更。
第 4 步：让 Agent 验收关卡进入自动回归循环
把内部循环写进任务说明：先完成一个小改动，运行当前层级关卡，读取失败证据，修订后再运行之前已经通过的关卡。这里的回归很重要，否则 Agent 修好一处后，可能会悄悄破坏另一处。
每轮结束时，让 Agent 记录改动内容、运行的关卡、结果和未解决问题。长任务的上下文会不断增长，这份记录能帮助后续会话快速恢复状态，也便于人类判断它是在持续推进还是原地打转。
验收关卡还要防范“假通过”。下面几种情况在长时间运行时尤其常见：
| 假通过类型 | 典型表现 | 对应防线 |
|---|---|---|
| 测试被修改 | 失败用例被删除或判定被放宽 | 验收文件只读，CI 检查变更 |
| 只测试快乐路径 | 正常请求通过，异常场景崩溃 | 增加故障注入和边界样本 |
| 模拟替代真实依赖 | Mock 全绿，集成环境失败 | L4 必须运行真实服务 |
| 输出像对但语义错 | 日志完整，生命周期行为错误 | 比较状态、时序和副作用 |
| 局部成功掩盖风险 | 单项指标提升，整体稳定性下降 | 每个里程碑运行全量回归 |
第 5 步：为 Agent 验收关卡设置人工决策点和停止条件
人的工作应集中在 Agent 难以替代的判断上。Kurtzer 负责架构、Linux 兼容性目标、操作模型、故障解读和停止决定；在对 Agent 生成的代码不满意时，他甚至会关掉 IDE，克制亲手修改的冲动，转而提供新的指引。
建议至少设置三类暂停条件：同一关卡多轮失败、Agent 试图改动受保护内容、任务用量接近预算。暂停后的审查重点也应前移到证据包，先看系统行为和风险，再决定是否深入阅读 diff。
快速上手建议：先选一个能在一天内完成的小里程碑，只写 3 到 5 张关卡卡片。API易 apiyi.com 提供本文涉及的 GPT、Claude 等系列模型的 API 调用，并兼容 OpenAI 与 Anthropic 接口格式，现有工具通常只需按文档调整接口地址和密钥，具体可用型号可在 API易 价格页确认。
Agent 验收关卡如何改变长任务成本
长任务的成本不能只看“一共用了多少 token”。报道中提到，Cursor 主页统计的 token 至少包含普通输入、模型输出、缓存写入和缓存读取四类，价格差异很大。社区曾用同一份 1.5 万亿 token 用量估算账单，不同算法的结果相差甚远，主要分歧就来自计费口径和缓存占比。
| 计费项 | 长任务中的主要来源 | 控制方法 | 价格口径 |
|---|---|---|---|
| 普通输入 | 任务说明、日志、代码片段 | 只传失败相关证据 | 以 API易 价格页实际数据为准 |
| 模型输出 | 代码、分析和修订计划 | 限定每轮输出范围 | 以 API易 价格页实际数据为准 |
| 缓存写入 | 新增或变化的稳定上下文 | 保持项目规则结构稳定 | 以 API易 价格页实际数据为准 |
| 缓存读取 | 多轮复用的上下文 | 观察命中情况，避免频繁改动前缀 | 以 API易 价格页实际数据为准 |
公开案例的总费用可以用来理解项目规模，但不能直接换算成单价。Ginux 的 API 调用费报道约为 8000 美元，Nicholas Carlini 用 16 个并行 Claude 智能体构建 C 编译器的实验约花费 2 万美元。这些数字背后的模型、缓存和任务结构都不同，你的项目仍需单独测算。
更稳妥的做法是先跑一个完整里程碑，记录四类 token 用量和关卡失败次数，再按 API易 价格页 https://docs.apiyi.com/models 的当前数据计算。这样得到的预算来自自己的任务形态，比直接套用别人的平均单价更可靠。
上图想说明的是，关卡本身也会消耗资源，但它能把失败提前暴露。对于普通团队，目标应是用有限预算换取足够的置信度，而不是追求每个改动都运行最昂贵的完整验证。
Agent 验收关卡常见问题 FAQ
Q1：什么是 Agent 验收关卡？
它是预先定义的可执行检查点，用于判断 Agent 的阶段成果是否达标。一个完整的关卡包含运行环境、执行入口、通过判据、证据产物和失败策略。
Q2:Agent 验收关卡和普通 CI 有什么区别？
CI 是常见的执行载体，验收关卡则是更完整的任务控制设计。它除了判断代码能否通过测试，还要定义系统行为、证据、回归范围、人工决策点和暂停条件。
Q3：什么时候必须设计 Agent 验收关卡？
当任务需要多轮修改、跨多个模块、运行时间较长，或者错误输出不易肉眼发现时，就应该提前设计。一次性的小脚本可以简化，但至少也要明确一条可运行的验证方式。
Q4：有了 Agent 验收关卡，还需要人工 Code Review 吗？
需要。自动关卡适合判断已知标准，人类仍要负责架构选择、风险取舍和最终验收。Kurtzer 也强调，判断结果是否完整、局部成功是否带来系统级风险时，经验依然至关重要。
Q5：如何通过 API 接入模型来运行这套流程？
1. 在 API易 apiyi.com 注册并创建 API Key。
2. 查阅文档中心 `docs.apiyi.com`，确认接口地址和调用方式。
3. 根据工具选择 OpenAI 或 Anthropic 接口格式完成配置。
4. 在 `https://docs.apiyi.com/models` 确认模型型号和价格后，再启动小规模试跑。
Q6：预算有限时，怎样精简 Agent 验收关卡？
优先保留低成本的 L1 和 L2 关卡，让它们在每轮运行；L3 和 L4 放到功能完成或里程碑节点执行。Jellyfish 对 1.2 万名开发者的统计显示，典型用户每月约使用 5100 万 token，与极端案例差距巨大，因此应根据任务风险确定验证频率。模型费用请以 API易 价格页实际数据为准。
Q7:Agent 验收关卡有哪些局限？
关卡只能覆盖被定义的风险，测试全绿也不等于代码适合长期维护。Ginux 能够启动 Rocky Linux 10，距离生产级内核仍有很长的路，硬件支持、接口稳定、安全审查和社区维护都不是一次运行能证明的。社区对高频 PR 模式的批评也提醒我们，要持续关注代码的可维护性。
Agent 验收关卡核心要点 Key Takeaways
- 先定义终点：用可观察的系统行为描述任务完成，避免模糊目标。
- 关卡要分层：从静态约束逐步推进到真实运行和人工验收。
- 证据要留存：每次运行都保存日志、差异报告和性能记录。
- 判定不可改：验收样本和脚本应受保护，防止 Agent 走捷径。
- 回归常态化：修复新问题后，重新运行已通过的相关关卡。
- 人类掌握决策：架构、风险、停止和最终验收由负责人判断。
- 成本先试跑：通过 API易 apiyi.com 小规模验证，再按价格页测算预算。
总结：从 Agent 验收关卡开始构建自主工作流
Agent 能否长时间自主工作，取决于它是否拥有清晰的目标和可靠的反馈。设计 Agent 验收关卡时，可以牢记三点：
- 把“完成”变成可执行标准：让 Agent 依靠运行结果判断进度。
- 让机器处理高频验证：用分层关卡、自动回归和证据包缩短反馈周期。
- 把关键判断留给人：由负责人决定架构方向、风险边界和停止时机。
建议从下一个中等规模任务开始，先写关卡卡片，再启动 Agent。需要测试不同模型时，可以通过 API易 apiyi.com 使用兼容 OpenAI 与 Anthropic 格式的接口完成接入，配置方法见文档中心 docs.apiyi.com，模型价格和计费口径以 https://docs.apiyi.com/models 的实际数据为准。
📚 参考资料
- InfoQ – Ginux 项目报道:Codex 构建 Linux 兼容内核的过程与验收方式
- 链接：
infoq.cn/article/OiyNEtFwV05opvsLTcvK -
说明：包含 HDAE 双循环、项目规模和局限性分析
-
InfoQ – Cursor 工程师 token 账单报道：高强度 Agent 工作流与成本争议
- 链接：
infoq.cn/article/q9iebpvFozfy4bgCYUyE -
说明：包含验证闭环、Dune 架构和社区批评
-
Ginux 技术报告:Gregory Kurtzer 发布的项目技术报告
- 链接：
zenodo.org/records/23682548 -
说明：适合深入了解研究目标、方法和结果边界
-
Ginux GitHub 仓库：项目源码
- 链接：
github.com/gmkurtzer/ginux -
说明：可查看项目代码和开源许可信息
-
API易文档与价格页：接口配置和模型价格说明
- 文档链接：
docs.apiyi.com - 价格链接：
https://docs.apiyi.com/models - 说明：模型型号、价格和计费口径请以页面实际数据为准
作者:APIYI 技术团队
技术交流：欢迎访问 API易 apiyi.com 与我们交流 Agent 工程实践，更多接入资料可查阅 docs.apiyi.com 文档中心。
