从 Skills 到分层 Workflow：AI Agent 工程化的下一层抽象

很多 AI Agent 项目走到中后期，都会开始沉淀 skills。

一开始，这几乎是必然动作。写代码要有 TDD skill，排查问题要有 debug skill，提交前要有 review skill，写文档要有 writing skill。每一个 skill 都像是在给 Agent 补一块局部能力：让它在某类任务上更稳定、更专业、更符合团队习惯。

但系统一旦继续生长，一个更深的问题就会浮出来：skills 的数量增加，并不必然带来 Agent 行为的稳定性。

表面上看，这是一个能力组织问题；但在机制层面，它其实是一个工程控制问题。小规模时，问题是「有没有合适的 skill」；规模扩大后，真正的问题变成了：这些能力在什么阶段被调用，由什么责任视角调用，依据什么输入推进，留下什么产物，又由什么机制决定是否可以进入下一步。

这也是我设计 Unified Skills 时真正想解决的事情：不是再做一组 skills，而是把 skills 组织成一套分层 workflow。

更准确地说，skills 解决的是「怎么做」，而 workflow 解决的是「什么时候做、由谁做、做到什么程度算通过、失败时退回哪里、过程证据留在哪里」。当 Agent 开始承担连续工程任务时，真正要治理的就不再是能力本身，而是能力进入流程的方式。

1. Skills Library 的上限，不是能力不足，而是工程失稳

很多团队一开始搭建 skills library，逻辑都很自然：把常见问题抽成一组可复用方法论，需要时调用。

• 需要写测试时，调用 TDD skill；
• 需要调试时，调用 debug skill；
• 需要审查时，调用 review skill；
• 需要写作时，调用 writing skill。

这种方式当然有效。因为它把零散经验变成了可复用结构，让 Agent 至少在局部问题上不再完全依赖临场发挥。

但这套方式的上限也很清楚。问题不在于 skill 没价值，而在于工程工作从来不是一次技能调用，而是一条连续推进的责任链。

当任务复杂度上升，系统会开始暴露出四类典型失稳。

1.1 时序失稳：Agent 会跳步骤

Agent 很容易从一个模糊想法直接进入实现，然后在最后补一句「已验证」。skill 可以告诉它测试该怎么写，debug 应该怎么做，但 skill 本身并不能天然约束它：什么时候才有资格开始写，什么时候必须先澄清，什么时候必须先停下来做设计。

这意味着，skills library 解决了局部执行质量，却没有解决阶段推进合法性。系统依旧可能以一种「看起来很高效，实际上不断跳过前置条件」的方式运行。

1.2 责任失稳：Agent 会自证通过

更危险的问题，是 self-confirming loop。

同一个 Agent 可以自己理解需求，自己做设计，自己列计划，自己完成实现，再自己 review，最后得出「没有问题」的结论。问题不在于它不努力，而在于工程系统不能把「提出问题、执行任务、判断通过」全部交给同一个认知视角。

这是工程里最常见却最容易被忽视的风险：不是模型能力不够，而是责任边界没有切开。

1.3 证据失稳：过程不可追踪

一次对话里，Agent 看起来好像完成了很多工作：澄清了需求、查了资料、做了设计、列了计划、写了实现、通过了 review。

但几天之后回看，往往很难回答以下问题：

• 当时的需求边界到底是什么？
• 哪些外部资料被采纳，哪些被拒绝？
• 设计时讨论过哪些替代方案？
• 计划里哪些任务允许并行，哪些必须串行？
• review 审的是 spec 完整性，还是只是代码风格？
• ship 时有没有留下导出、同步、发布和回滚记录？

如果这些问题无法回放，那么整个流程看似完成，实际上却缺少可审计证据。它更像一场即时表演，而不是一个可复盘的工程过程。

1.4 治理失稳：skills 之间没有组织关系

TDD、review、debug 当然都可以是好 skill，但如果它们只是平铺在一个目录里，Agent 仍然要在运行时临场决定：先调哪个，什么时候切换，什么情况下跳过，失败后回到哪里。

而这个「临场决定顺序」的过程，本身就是最大的随机性来源。

所以，skills library 可以提升局部能力，但不能单独解决工程稳定性。因为它解决的是能力复用问题，不是流程治理问题。

2. Workflow 不是 Skills 的顺序表，而是阶段协议

从这个角度看，Unified Skills 的第一层升级，并不是多做几个 skill，而是把 skills 放进一个明确的阶段流里。

主路径不是「需要什么就调用什么」，而是：

/refine -> /design -> /plan -> /build -> /review -> /ship

这条路径背后的判断是：工程交付需要状态机，而不是自由联想。

2.1 /refine：把模糊想法收敛成可验证规格

/refine 的任务不是「继续聊一聊需求」，而是把模糊想法压缩成可验证的 spec。它关心的是：

• 问题是什么；
• 用户是谁；
• 成功标准是什么；
• 约束有哪些；
• 当前缺哪些外部事实；
• 最终产物类型是什么。

这一阶段如果没有收敛清楚，后面所有实现都可能在错误目标上越跑越快。

2.2 /design：在实现前冻结创作与体验判断

很多系统最容易犯的错，是把 design 偷偷塞进 build。也就是说，边做边想、边写边改、边实现边决定体验。

这在小任务里看起来无伤大雅，但在多产物系统里会迅速失控。UI、文章、deck、视觉稿这些产物，本质上都需要先完成创作和体验层面的判断，再进入生产。否则，build 阶段就会不断替代 design 阶段，最终让整个流程失去边界。

2.3 /plan：定义任务拓扑，而不是写一份待办清单

/plan 真正要做的不是列出一些 todo，而是定义任务拓扑：

• 哪些任务必须串行；
• 哪些任务可以并行；
• 哪些文件或模块允许写入；
• 哪些步骤完成后才能进入下一阶段；
• 哪些风险需要前置处理。

计划不是形式主义，它的意义在于把「工作如何展开」从运行时 improvisation，变成可审查的结构。

2.4 /build：消费已批准输入，而不是重新发明目标

/build 才是实现和内容生产真正发生的地方。但它最重要的纪律不是「认真执行」，而是：只消费已经批准的 spec、design 和 plan，而不是在实现过程中重新定义目标。

这是很多 Agent workflow 会失效的关键点。因为如果 build 可以随时回写目标、改写边界、替代 review，那前面的阶段就会全部失去约束意义。

2.5 /review：门控，而不是口头确认

/review 也不应该只是「帮我看看」。

真正的 review 是门控。它的职责不是鼓励，不是润色，也不是在明显缺失时给一句「整体不错」。它必须有能力阻断流程：只要发现 blocking 问题，就要明确退回 /build，必要时甚至退回 /plan 或 /refine。

2.6 /ship：交付完成，不等于实现结束

最后的 /ship 处理的不是代码本身，而是交付动作：发布、导出、同步、记录、回滚信息、交付痕迹。工程系统最容易被忽略的一点是：代码写完，并不等于交付完成。

交付真正结束，必须以可追踪的收尾动作为标志。

因此，workflow 的意义不在于给 skills 排一个顺序，而在于把每个阶段变成有输入、有输出、有门控的协议。它解决的不是「快点进入某种能力」，而是「任务如何合法地推进到下一状态」。

3. 真正的升级，不只是阶段流，而是纵向分层

如果只有阶段流，这个系统依然可能退化成一组更长、更复杂的 prompt。真正让 Unified Skills 变成工程系统的，不只是横向阶段，而是纵向分层。

我把它抽象成六层：

CANON -> Command -> Agent -> Skill -> Artifact -> Hook / validate

这不是六种文件分类，而是六种不同的系统职责。每一层都解决一个问题，同时拒绝解决另一个问题。一个方案是否成熟，不看它能不能跑通一次，而看它能不能被复用、治理和演化。

4. CANON：所有 Workflow 的宪法

最上层是 CANON.md。

它不是某个具体 skill，也不是项目说明书，而是所有阶段、角色和技能都必须继承的全局纪律。它定义的不是某类任务技巧，而是不可放松的底线：先陈述假设、控制范围、验证优先、遇到矛盾先停止并澄清、调试先找根因、不做 yes-machine。

这一层解决的是纪律统一，而不解决具体任务策略。

为什么它必须独立存在？因为如果没有 CANON，每个 skill 都会带着自己的隐含价值观。TDD skill 强调测试，debug skill 强调根因，review skill 强调质量，但它们之间缺少统一的行为合同。久而久之，整个系统会出现一种隐性腐蚀：局部方法论都很认真，整体行为却越来越不一致。

所以 CANON 的作用不是让技能更强，而是让所有局部方法论不能为了局部方便，绕过全局纪律。

这也是第一条原则：具体能力可以增加纪律，但不能放松纪律。

5. Command：阶段控制器，而不是快捷入口

Command 层回答的问题是：现在处在哪个阶段，这个阶段应该读什么、产出什么、通过条件是什么。

在 Unified Skills 里，Command 不是 prompt shortcut，而更像 workflow controller。

例如 /plan 的职责，不是「调用一个计划类 skill」，而是定义计划阶段的合法输入、合法输出和门控条件。它要消费已经批准的 spec 和 design，产出 03-plan.md，在大型任务里拆出子计划和并行矩阵，并明确写入范围和风险点。

这一层解决的是阶段推进协议，而不解决具体任务的方法论。

换句话说，Command 不负责告诉你「debug 怎么做」，也不负责告诉你「review 怎么看代码」；它负责回答的是：当前阶段是否具备进入条件，当前产物是否达到通过条件。

这也是第二条原则：workflow 需要阶段状态机，而不是能力快捷方式。

6. Agent：责任视角，而不是人格表演

Agent 层最容易被误解。

很多系统引入 agent，是为了让模型「扮演」产品经理、架构师、设计师、审查员。但如果角色只停留在语气层面，它最多制造一点表演感，并不能真正提升工程质量。

Unified Skills 里的 Agent 层，核心不是角色扮演，而是责任切分。

需求分析、任务计划、软件实现、规格审查、代码质量审查、发布判断，最好不要全部由同一个视角闭环完成。不是因为模型不能同时做这些事，而是因为工程系统不能把「提出问题、执行任务、判断通过」压在同一个认知回路里。

例如：

• review agent 不应该重新定义需求，它应该基于已批准的 spec 判断实现是否完整；
• software engineer agent 不应该在 build 阶段决定任务拓扑，它应该在 plan 的约束内实现；
• design reviewer 不应该只说「视觉不错」，它应该阻断缺少证据来源、模式综合和采纳/拒绝理由的设计稿。

这一层解决的是责任分离，而不解决阶段协议定义。

这是第三条原则：Agent 的核心价值是责任分离，不是人格化。

7. Skill：真正可复用的方法论单元

Skill 层是最具体的一层，也是最容易被过度简化的一层。

一个合格的 skill，不应该只是一段「请你认真做 X」的提示词。它必须至少说明：

• 什么时候进入；
• 什么时候退出；
• 具体步骤是什么；
• 哪些说法是常见借口；
• 哪些情况必须停止；
• 如何验证自己做完了。

这也是为什么 Unified Skills 里的 SKILL.md 往往不只是「做法说明」，而是会包含入口/出口、流程、红旗、常见说辞、验证清单，强纪律技能甚至会定义 Iron Law。

这一层解决的是方法论复用，而不解决整体工作流编排。

也就是说，Skill 负责回答「这一类事情怎么做」，但不负责回答「现在是不是该做这件事」。后者属于 Command 和 Agent 的职责。

这是第四条原则：Skill 是执行方法论，不是工作流总控。

8. Artifact：把过程变成证据链

如果只看对话，Agent 的工作很容易变成一段不可回放的即时表演。

今天看起来它澄清了需求、做了设计、写了计划、完成了实现、通过了 review；但过几天回头看时，很多关键信息已经散失在上下文里，既无法复盘，也无法迁移。

所以 Unified Skills 把 artifact 作为 workflow 的一层，而不是一组顺手保存的文档。

01-spec.md、02-design.md、03-plan.md、04-review.md、05-ship.md 这些文件，并不是文档洁癖，而是 Agent 行为的审计轨迹。它们记录的不是「写过什么」，而是「为什么这样推进、为什么这样取舍、为什么允许进入下一阶段」。

这一层解决的是过程审计与复盘，而不解决运行时拦截。

与此同时，artifact 也是多产物 workflow 成立的前提。软件、文档、文章、deck、视觉稿并不共享同一种构建路径。如果没有 artifact_type，系统就很容易用软件工程的方式处理所有产物，或者用内容创作的方式绕开软件质量门控。

这是第五条原则：没有 artifact，workflow 就缺少可审计证据。

9. Hook / Validate：把约定变成护栏

只靠提示词约束 Agent，是不稳定的。

提示词可以提醒模型不要做破坏性操作，但运行时 hook 才能拦截破坏性命令。文档可以要求技能命名规范、索引一致、根文档同步，但 validate 才能发现 README、AGENTS、skills-index、锁文件和 hooks 实现之间是否已经发生合同漂移。

这也是 Unified Skills 里 hooks 和 ./validate 的意义所在。

它们不负责替代思考，也不负责替代高层 review；它们负责把一部分纪律从「应该遵守」变成「违反就会暴露」。

这一层解决的是运行时护栏与维护期漂移暴露，而不替代高层判断本身。

这一点非常关键。高层纪律如果没有低层护栏，最终就只是建议。系统最容易发生的腐蚀，不是某个 prompt 突然写错，而是多个合同慢慢表面不一致：README 说一套，AGENTS 说一套，skills-index 还是旧的，hooks 实现又是另一套。等这些漂移积累起来，Agent 在不同入口读到的，就不再是同一个系统真相。

这是第六条原则：高层纪律必须有低层护栏，否则只是建议。

10. 两阶段 Review：分层门控的一个具体例子

分层 workflow 不是抽象口号，它必须体现在具体门控设计里。Unified Skills 里的 review，就是一个很典型的例子。

这里的 review 不是单阶段「代码看起来怎么样」，而是拆成两关。

10.1 第一关：Spec Compliance

第一关先检查实现是否覆盖了 spec 中定义的功能需求、边界条件、错误路径和验收标准。它关心的不是「写得漂不漂亮」，而是：实现了什么，是否把该做的事情做全了。

10.2 第二关：Code Quality

只有在第一关通过后，才进入第二关。第二关才讨论 correctness、readability、architecture、security、performance 等质量维度。它关心的是：这些功能是如何被实现的，代价和质量是否合理。

这个拆分看似简单，但它体现了分层 workflow 的价值。

如果功能都没实现完整，就急着讨论代码风格，审查资源会被浪费；如果功能缺失和质量问题混在一起，反馈也会变得模糊。两阶段 review 的作用，就是把问题类型切开：先确认做没做对，再确认做得好不好。

这不是让 review 更复杂，而是让门控更有顺序、更有边界、更有退回路径。

11. 从 Prompt 到 Workflow，再到治理结构

回到最开始的问题：AI Agent 工程化到底需要什么？

更长的 prompt 有用，但不够。更多的 skills 有用，但也不够。真正需要设计的，是 skills 之间的组织关系，以及这些组织关系如何进一步沉淀为治理结构。

也就是说：

• 用 CANON 定义不可放松的全局纪律；
• 用 Command 定义阶段状态机；
• 用 Agent 定义责任视角；
• 用 Skill 承载可复用方法论；
• 用 Artifact 留下过程证据；
• 用 Hook / validate 把规则变成护栏。

这套结构的目标，不是让 Agent 显得更复杂，而是让它在复杂任务里更可控。一个系统是否工程化，不看它能不能完成一次任务，而看它能不能稳定地推进、回退、审计和复盘。

所以，prompt 是表达，skill 是方法，workflow 是制度，而 layered workflow 才是治理结构。

所谓 Agent 工程化，真正工程化的不是生成能力本身，而是任务推进权、通过判定权、责任边界和证据链的分配方式。

这也是 Unified Skills 想表达的核心判断：AI Agent 的下一层抽象，不是继续堆 skills，而是把 skills 放进一套有阶段状态机、责任分离、证据链和运行护栏的分层 workflow。

进一步而言，真正成熟的 Agent 系统，不应该只是「会做很多事」，而应该知道：在什么阶段，由什么模块，以什么责任，依据什么证据，完成什么结果。

技术方案的价值，不在于提出一个新名词，而在于重新划清问题边界，并给出可落地的系统结构。对 Agent 来说也一样。真正的工程化，不是把能力堆得更多，而是让系统知道自己何时开始、何时停止、何时退回、何时交付。