上个月我们跑一个 agent 任务，它做得很漂亮：生成了正确的文件，自己检查了一遍，确认无误。然后它开始收尾，执行 cleanup，把产物删掉了。verifier 再跑的时候找不到文件，任务失败。
这个 bug 修起来很快：加一条规则，验证通过后禁止再动最终产物。但真正让我停下来想的是另一件事，团队复盘时，每个人对这个问题的第一反应都不一样。有人说“这是执行错误”，有人说“这是验证没做好”，还有人说“模型太蠢了，不该删自己的产出”。
都对，又都不够。
说“执行错误”的人，修法可能是改 prompt 让模型更小心。说“验证错误”的人，修法可能是加强检查步骤。但真正有效的修复不在这些地方，它应该在执行控制层加一个 output guard，在验证层加一个 publish state 冻结。这些修复跟让模型更聪明完全不在同一个维度上。
这个差异让我重新意识到两件事：分层（layering）和分类（taxonomy）。它们很像，都会帮我们整理复杂信息，但解决的问题不同。分层帮你找到问题在系统结构里的位置，分类帮你识别它属于哪一类问题。顺序很重要：先分层，再分类，最后定动作。
分类的盲区：缺少结构位置#
分类很有用。一个好的分类体系能把零散失败变成问题族。比如分析 agent 失败时，我们常用：理解错误、规划错误、检索错误、执行错误、验证错误、记忆错误。看到一个失败案例，问它属于哪一类，已经比只说失败了好得多。
但回到 cleanup 的例子：归为验证错误或执行错误都没错，可它没有回答真正关键的问题：任务成功条件是否清楚？执行控制层是否强制 submit 前检查？验证通过后产物是否被保护？
分类告诉我们这是什么问题，但没有告诉我们问题发生在哪个结构位置。同一个验证错误，落在 prompt 层和落在执行控制层，修法完全不同。
分层：先找到结构位置#
分层是一种纵向观察。它不是把问题分成若干类别，而是把系统拆成不同抽象层级，判断每一层的职责、依赖和影响。
以 agent 系统为例，可以这样分层：用户意图层、任务定义层、规划层、记忆层、技能层、工具层、执行控制层、环境层、验证层。这套分层不是唯一答案，关键不在层名，而在于每层都有明确职责。一个有用的分层，至少能回答四个问题：这一层负责什么？它依赖下层提供什么？它向上层暴露什么？它出错时应该在哪一层修？
回到 cleanup 的例子。先分层，问题立刻变得清晰：
- 规划层：agent 把 cleanup 当成合理收尾步骤
- 工具层：删除命令没有识别关键产物
- 执行控制层：没有 protected output guard
- 验证层：验证成功后没有冻结 publish state
- 环境层：最终文件状态被破坏
再分类：这是验证层和执行控制层交界处的验证后状态破坏，agent 曾经达到正确状态，但后续动作破坏了已验证产物。
最后定动作：短期在 prompt 或 skill 里明确要求验证后不再修改最终产物；结构上在执行控制层记录 publish state，拦截 post-success destructive action；长期凡是存在最终产物的任务，验证成功后应将产物路径标记为 protected output。
真正强的问题分析，会把分层和分类结合起来。不是泛泛地说这是验证错误，而是问这是哪一层里的验证错误。同一个验证后状态破坏落在不同层，表现和修法完全不同：规划层里是 agent 把 cleanup 安排在验证之后，没有意识到它是破坏性动作，修法是改 prompt 或 skill；工具层里是删除命令不区分临时文件和 protected output，修法是改 tool schema 或增加产物标记；执行控制层里是没有 submit gate、没有在验证通过后锁定产物路径，修法是改 harness 机制；验证层里是验证只检查了当前是否正确，没有设置保持正确的约束，修法是加 publish state 冻结。
这个二维视角逼着我们把模糊判断变成精确诊断。你不再说“模型不行”，而是说“规划层缺少对 post-verification 动作的安全意识，结构修复应落在执行控制层”。
常见误区#
分层和分类听起来简单，实际用起来有几个容易踩的坑。
把现象当分类。 结果错不是分类，是复述现象。验证层的代理验证，agent 检查了文件存在，但没有检查 evaluator 真正关心的字段，这才是分类。
把分类当根因。 执行错误，所以改执行，这种判断跳过了最关键的一步。表面是执行错误，上游可能是任务定义层没有定义不可删除的 final artifact，结构修复应落在执行控制层或工具层。
分层只列名词。 模型层、工具层、环境层这些名字本身没有信息量。必须说清每层负责什么、依赖什么、出错时怎么修。
过度分层。 如果一层不能带来新的判断或修复动作，它只是噪声。好的分层应该让问题更容易定位，而不是让分析更复杂。
一个诊断清单#
遇到复杂问题时，问自己五个问题就够了：
- 它发生在哪一层？
- 它依赖下层提供什么？
- 它向上层暴露成什么？
- 这一层里的问题类型是什么？
- 最小有效修复应该落在哪一层？
五个问题覆盖了从定位到分类到行动的完整路径。不需要背流程，不需要填大表，问完分析基本就到位了。
回到开头那个 cleanup 的故事：agent 不是不够聪明，而是我们没在正确的层上设防。先分层，再分类，修法自然就对了。