· AGENT-OS-7-LAYERS · 2026.05.09 · 8 MIN ·

Verification · 校验层 · 防止 Agent 自信地错 + 给系统做季度回顾

Agent OS 7 层里业内最弱的一层 — 仅 OpenAI Codex 内建 /review,其他工具都靠用户自己写。8 周保鲜期定律 + 月度 retrospective 可粘贴 prompt + 每个 Skill 的 1 分钟 verification checklist 模板。 · by 思扬

AI · HERO seed:3020260509 Agent OS 7 层里业内最弱的一层 — 仅 OpenAI Codex 内建 /review,其他工具都靠用户自己写。8 周保鲜期定律 + 月度 retrospective 可粘贴 prompt + 每个 Skill 的 1 分钟 verification checklist 模板。

FIG.00 — cover · ai-generated · placeholder

它回答的问题: 怎么知道 Agent 没有「自信地错」? 它在哪: 每个 Skill / Agent 配 3-5 项 1 分钟内能跑完的检查 + 周/月 retrospective 它读取的时机: 高风险任务的输出后、定期回顾时

原文金句

★ 「The worst thing that happens with your agent OS isn’t that it fails, it’s that it works confidently and wrongly and you ship the output before you noticed.」 「你的 Agent OS 最糟糕的不是它失败, 而是它信心十足地、错误地工作, 然后你还没注意到就把输出发出去了。」 (#315-316,00:21:32,745 → 00:21:41,490)

★ 「Without it, your OS has a shelf life of maybe 8 weeks before everything goes stale. With it, your OS compounds even further and forever.」 「没有它, 你的 OS 大概只有 8 周左右的保鲜期就会全面过时。有了它, 你的 OS 会持续复利, 而且会一直复利下去。」 (#341-342)

它在解决什么真问题

Agent 不会告诉你它错了。它会用一样自信的语气、一样流畅的表达, 给你一份完全错误的结果。这是 LLM 的本质特征, 不会因为模型变强而消失。

Verification 层的本质是: 给每个高风险输出配上「快速质检清单」, 给整个 OS 配上「定期 retrospective」。

业内 Stage 1 调研结论:

⚠️ Verification 是 7 层里业内最弱的一层。在我们调研的 9 款 agentic 工具(Claude Code / Cursor / Codex / OpenCode / Copilot / Windsurf / Antigravity / Workspace Agents / Hermes)中:

只有 OpenAI Codex 内建 /review 一级 verification primitive

Google Antigravity 通过「Artifacts」 (任务列表 / 截屏 / 浏览器记录) 实现 evidence-by-construction

其他所有工具(Claude Code / Cursor / OpenCode / Copilot / Windsurf / Workspace Agents / Hermes)都靠用户自己写 hooks / 外部 CI / 手动 prompt

这意味着这一层 大部分要靠你自己搭。这一篇会给你一套即插即用的最小 Verification 套件。

两类 Verification

Nufar 在视频里把这一层拆成两件事:

单次输出的 Verification (#317-326)

针对当下的某次任务输出, 跑 3-5 项快速检查:

起草邮件 → 语气匹配 + 事实正确性
数据分析 → 核对数字
pre-read → 是否覆盖了所有参会人

「我建议你至少做三到五项检查。很多时候这些检查一分钟内就能跑完, 却能在事后帮你省掉大量烦恼。而且随着练习, 检查会越做越快。」 (#321-323)

实操起步: 每个高频 Skill 在 SKILL.md 末尾追加一个「## Verification Checklist」段, 列 3-5 项 1 分钟内能跑的检查。

系统层面的 Retrospective (#328-336)

针对整个 Agent OS, 定期回顾:

哪些 Skill 从来没被调用?(可能要修 description, 也可能直接删)
哪些 Context 文件已过期?(更新或归档)
哪些 Agent 需要更新指令?(随着你工作变化, agent 也要变)

「你完全可以直接在工具里做这件事。你完全可以直接问它:有什么是没在被使用的、等等。」 (#338)

落地步骤(分两条节奏)

节奏一 · 每个 Skill 加 Verification Checklist(15 分钟 / 个 Skill)

打开你的 skills/<name>/SKILL.md, 在末尾追加:

## Verification Checklist

**自动检查**(我或 agent 在产出时跑):
- [ ] 输出格式符合 SKILL 顶部声明的 schema
- [ ] 引用的来源全部在 context/ 或 memory/ 中真实存在
- [ ] 没有出现奉承性套话(「这是个好问题」「您提到的」等)

**人工检查**(我必须扫一眼):
- [ ] 语气匹配我的 voice match 模板
- [ ] 事实(数字、日期、人名)逐一对照来源

节奏二 · 每月 OS Retrospective(60 分钟 / 月)

每月最后一个周五, 30-60 分钟做一次 Agent OS 回顾。用这套 prompt:

请扮演我的 Agent OS 审计员。 基于我当前的 OS 文件结构, 回答:

1. **Skills 审计**:
   - 过去 30 天我哪些 Skill 调用了 ≥ 3 次?
   - 哪些 Skill 调用了 0 次?为什么?(description 不够强 / 实际不需要 / 已被工具内建吸收)
   - 哪些 Skill 输出质量明显低于其他?

2. **Context 审计**:
   - 哪些 context 文件 30 天没更新?它们是否仍准确?
   - 我有哪些情境最近重复跟你解释过, 应该写成新的 context 文件?

3. **Memory 审计**:
   - decisions.md 是否覆盖了过去 30 天的所有重大决策?
   - 我看到 memory 里有 N 条「过期」的事实, 你帮我列出来。

4. **Connections 审计**:
   - 哪些 MCP server 我装了但从来没用?
   - 哪些权限我开了但其实用不到?(可以收回)

5. **Identity 审计**:
   - 我的 hard rules 还成立吗?有哪些应该新增 / 移除?

输出: 一份 Markdown 报告, 顶部 5 条 「立刻可做的修整」 + 详细分析。

把输出存到 memory/retrospectives/2026-05-31.md, 把那 5 条立刻可做的修整 today 就改进 OS。

8 周保鲜期 — 为什么是这个数字

Nufar 说没有 retrospective, OS 的保鲜期大概 8 周 (#341)。译者交叉验证:

Everyday AI Substack 在 Agent OS Demystified Part 4 中也得出类似结论(独立观察): 没有维护的 agent OS, 8-12 周后变成负资产 — 文件多、指引矛盾、agent 表现反而劣化。

8 周这个时间点不是魔法数字, 是观察:

你的工作优先级 8 周会变一次
你的 stakeholder 列表 8 周会换 1-2 个人
工具 8 周会出 1-2 个新 feature, 让你的某些 hand-rolled 实现变多余

设月度 retro = 比 8 周略短, 跑赢腐烂速度。

常见坑

坑	现象	怎么避
不做 verification	发了个错数字给 board	高风险 Skill 必带 checklist
Checklist 太长	25 项检查每次都不做	3-5 项, 1 分钟内能跑完
只 verify 单输出, 不做 retro	8 周后整个 OS 烂掉	月度 retro, 写日历提醒
Retrospective 写完不改	列了 10 条修整, 一条没动	每次只要求自己「立刻可做的 5 条」, 当天动手
把 verification 全压给 agent 自己	agent 自己说「我已经检查过了」, 你信了	Agent 的「自我检查」是 verification 的最弱形式, 加人工

🟢 译者点评

🟢 这一层是 7 层里被讲得最简短、但实际重要性最高的一层。视频里 Nufar 在这层用了不到 3 分钟, 但她讲到「8 周保鲜期」时一句话点破了所有 OS 倡导者最不愿承认的事 — 你做的所有努力, 没有 retrospective 的话, 大概率两个月后毫无价值。

🟢 Codex 的 /review 是这一层的产品级范式, 值得借鉴。不在 Codex 上的人, 可以手动写一个「review」slash command 调用一组检查。我用 Claude Code 的 hook 实现过类似的:PostToolUse 触发时跑一组 lint / fact-check, 输出问题列表追加到当前会话。工作得很好。

🟢 Retrospective 这条建议, 真正难的不在「跑」, 在「真的去改」。我自己的实践是: retro 报告写好后, 当天必须动手改至少 1 项, 不到 30 分钟也行 — 否则 retro 沦为仪式, OS 继续腐烂。

🟢 这是我建议你「第一次跑这套精读」时第一个搭起来的层之一(在 Identity / Context 之后立即)。不是排到第六个等 5 层都搭好。因为没有 retro, 后面 5 层都白做。

🔗 立刻去做

→ 完成上面节奏一(给至少 1 个 Skill 加 checklist), 然后读 07 Automations · 自动化层 — 让 OS 在你不在场时跑(可选)。

🔗 延伸阅读

Codex /review 文档 — Codex 唯一内建的 verification primitive
Google Antigravity — Artifacts — evidence-by-construction 的产品形态参考
Claude Code Hooks 指南 — PreToolUse / PostToolUse / Stop 钩子做自定义 verification
Agent OS Demystified Part 4 (Everyday AI Substack) — 8 周保鲜期的独立观察