上下文工程与六层工作法：为什么 AI 说“已完成”不代表任务真完成

一句话先说清楚

GPT 说「已经完成」，不代表任务真的完成。

这句话是我在研究 Agent 工作流时反复撞到的现实。模型会非常自信地告诉你「已生成」「已校验」「已部署」，但只要你多问一句——用什么验证的？在哪个真实环境里验证的？——很多「完成」就站不住了。

所以我把自己的 AI 工作方式整理成两件事：上下文工程解决「喂什么」，六层工作法解决「怎么让结果可验收」。

上下文工程：先检索，再推理

我在学习上下文工程时，记下了一句很朴素的原则：

Retrieval before Reasoning。不是：Everything before Reasoning。

很多人用 AI 的方式是「把能找到的资料全贴进去，让它自己看」。问题是：

• 窗口不是越大越好：资料越多，噪声越多，关键信息越容易被稀释；
• 成本和延迟是真实的：上下文长度、缓存、吞吐、推理强度都会影响花费和速度；
• 聊天订阅和 API 计费不是同一个口径：不能拿一个场景的体验去推另一个场景的成本。

更好的做法是按任务检索：先判断这一步需要哪几份资料，请求前筛一遍，再决定要不要给模型更多「思考预算」。

我的三个检查问题

1. 这一步任务，最少需要哪些信息？
2. 哪些资料是「事实」，哪些只是「观点」或「历史讨论」？
3. 如果结果错了，我能从上下文里追溯到原因吗？

六层工作法

把一个业务任务交给 AI，我会按这六层拆：

前五层决定 AI「能不能做」，第六层决定你「敢不敢用」。

验证器：最容易被省略、也最值钱的一层

验证器不是一句「请检查你的答案」。它至少包含：

• 真实业务测试集：用真实场景里的样本，而不是模型自己编的例子；
• 覆盖异常情况：正常、缺项、冲突、异常、重复、越权——每一类都要有样本；
• 审批与失效检查：涉及报价、外发、付款、发布的动作，必须停在有权限的人面前；
• 留痕：通过率、失败原因、人工复核花了多少时间，这些才是下一轮改进的依据。

离线测试 ≠ 端到端完成

我见过不少「测试全部通过」的交付包，细看才发现：测试跑在模拟数据上，没有连接真实平台，没有读回真实的 ID 和状态。这些测试有价值，但它证明的是「逻辑大致通顺」，而不是「业务已经跑通」。

把这两件事分开说，是对自己和对客户最基本的诚实。

Agent 的数量不是重点

研究 Loop、Graph、Harness 这些 Agent 组织方式时，我最后的结论很简单：

• 每个环节有没有清晰的输入和输出；
• 有没有状态可以追踪；
• 失败了怎么办；
• 按风险设计谁来审批。

一个设计清楚的总控 Agent 加几个 Skill，往往比十几个职责模糊的 Agent 更可靠。

经验也需要验证

最后一条是关于「积累」的：一次成功，不能自动变成永久规则。记录经验时，我会写下适用条件、证据、例外和验证状态。修一个局部错误时，也要检查它影响到的其他依赖。

小结：上下文工程让 AI 看到对的东西，六层工作法让结果可以被检查。而「完成」这个词，应该由验证器说了算，而不是由模型说了算。