为什么需要分层
"我们要做一个 AI 助手"——这句话在不同人嘴里指的东西可能完全不同。有人指的是一个能自动写文案的功能，有人指的是一条从下单到发货的自动化链路，有人指的是一个能自己判断该干什么的系统。三者的工作量、风险和验收方式相差极大，但在需求文档里它们常常共用同一个词。
能力分层的作用，就是给这场对话提供一套共同的坐标。菲咏造智把 AI 能力分成三层：Skill · 技能、Workflow · 工作流、Agent · 智能体。本文讲清三层各自的边界、如何判断自己该从哪一层切入，以及层级选错会付出什么代价。
一、三层能力的定义边界
1.1 Skill · 技能：让 AI 稳定做好一件具体的事
Skill 的关键词是"一件事"和"稳定"。它的输入输出形态明确，边界清晰，可以被单独测试和单独调用。典型例子：从合同 PDF 抽取关键条款、按品牌调性生成商品文案、把录音转成带标签的工单、对作业批改并标注错因、从单据识别信息并纠偏收货地址。
判断一件事是不是 Skill，有一个简单的检验：你能不能用一句话说清它吃什么、产出什么。如果需要用一段话描述条件分支，那它已经不是 Skill 了。Skill 的典型建设周期是数周级。
1.2 Workflow · 工作流：把一段既定流程自动化，关键节点保留人审
Workflow 的关键词是"既定流程"和"人工审核"。它把多个 Skill 按业务顺序编排起来，并在关键节点插入人的判断。典型例子：新品上架流程——采集卖点、生成图文、合规检查、人工确认、多平台分发；或者尽调材料到评估报告、招生咨询到入学转化、接单调度到异常闭环。
Workflow 的核心不是"把 Skill 串起来"这个动作，而是三个设计决策：人审节点放在哪里、异常如何流转、失败如何回滚。这三件事决定了它能否真正接进业务系统。Workflow 的典型建设周期是数月级。
1.3 Agent · 智能体：给定目标后自主规划
Agent 的关键词是"目标"和"自主"。它不再执行固定编排，而是接受一个目标，自行规划步骤、调用能力、使用工具，遇到超出授权边界的情况再交还人类。典型例子：物流异常处置助手——盯在途异常、判断影响面、生成改派与沟通方案、执行并复盘；或者风险监测与预警助手、学习陪伴与答疑助手、店铺运营与选品助手。
Agent 的建设周期是季度级，且它的成熟度高度依赖底层可调用能力的丰富程度。一个没有能力可调的 Agent，规划得再好也只是在空转。
二、四条判断标准
面对一个具体需求，用下面四条标准依次判断，通常能得到明确的层级归属。
2.1 标准一：任务边界是否确定
问自己：这件事的"完成"有没有一个明确的定义？"把这份合同里的付款条款抽出来"有明确完成态，属于 Skill。"处理好这个客户的诉求"没有明确完成态，需要判断诉求是什么、涉及哪些系统、该走哪条流程——它至少是 Workflow，可能是 Agent。
2.2 标准二：流程是否已经固化
问自己：这段流程今天在人工执行时，步骤是不是稳定的？如果业务部门有 SOP、有流程图、有明确的交接节点，那么它适合做 Workflow——固定编排就能覆盖大多数情况。如果同样一件事，三个人做出三种不同的路径，且都合理，那么固定编排会不断遇到例外，此时要么先把流程本身梳理固化，要么考虑 Agent。
2.3 标准三：分支数量是否可穷举
这是区分 Workflow 与 Agent 的关键。Workflow 用显式编排表达分支，因此要求分支数量在可维护范围内。当你发现编排图上的条件判断超过某个规模，每加一个业务规则就要改动多处编排时，说明这段业务的复杂度已经超出固定编排的表达能力，该考虑让 Agent 在运行时规划。
2.4 标准四：授权边界是否说得清
Agent 具备自主行动能力，因此必须回答一个问题：它可以自己做哪些动作，哪些动作必须交回人类。如果业务方无法清楚地划出这条线，那么现在做 Agent 就是在制造不可控风险。此时正确的做法是退回 Workflow，用显式的人审节点把边界画出来，运行一段时间积累数据后，再逐步扩大授权。
三、切入顺序：为什么建议自下而上
三层不是三选一，而是一条生长路径。绝大多数企业的合理顺序是自下而上：先做几个 Skill，再编排成 Workflow，最后在能力足够丰富时构建 Agent。理由有三个。
- 反馈周期：Skill 数周级、Workflow 数月级、Agent 季度级。从最短的周期开始，组织能更快看到证据，投入决策的风险更小。
- 能力复用：下层能力是上层的原材料。先建的 Skill 不会因为后来做了 Workflow 而作废，它会被调用。反过来则不成立——直接做的 Agent 里嵌死的逻辑，很难被别的流程复用。
- 组织接纳：人对 AI 的信任是逐步建立的。让业务方先在低风险场景里看到稳定表现，后续扩大授权的阻力会小得多。
唯一值得考虑跳层的情况是：企业已经有大量成熟的内部 API 与数据服务，AI 只需要承担规划与调度角色。此时下层"能力"其实早已存在，只是形态不是 AI 而已。
四、层级错配的两类代价
4.1 选高了：项目无法收敛
把本该是 Skill 的需求做成 Agent，会得到一个验收标准模糊、周期不断延长、业务方不敢启用的系统。它的问题不是不能工作，而是无法证明自己在工作。这类项目通常以"再观察一段时间"结束，然后被静默下线。
4.2 选低了：用编排硬扛复杂度
把本该是 Agent 的需求做成 Workflow，短期看是安全的，长期会积累成维护负担：编排图越来越大，每个新增业务规则都要改多处，例外流程占比不断上升，最终维护成本超过它节省的人力。识别信号很明确——当"处理例外"的工作量开始超过"处理常规"时，层级选低了。
五、一张自查表
把需求带进下面这张表，逐行回答，落点通常就清楚了：
- 能用一句话说清吃什么、产出什么吗？能 → 倾向 Skill。
- 今天人工执行时有稳定 SOP 吗？有 → 倾向 Workflow。
- 分支能被穷举并画进一张编排图吗？不能 → 倾向 Agent。
- 业务方能划清"可自主执行"与"必须人审"的边界吗？不能 → 退回 Workflow。
- 手上已有多少可调用的能力？很少 → 无论需求多复杂，先补 Skill。
六、三层如何在行业里对应到具体场景
抽象定义之外，看一眼同一个行业在三层上分别长什么样，会更容易定位自己。以物流供应链为例：L1 层是单据识别与地址纠偏，L2 层是接单调度到异常闭环，L3 层是在途异常自主处置。三者共享底层能力，成熟度依次递进。
菲咏造智把自有产品线与行业场景合并拆解为 70+ 项原子能力，每一条都标注了所属层级、输入形态与输出形态，并覆盖金融、教育、物流、餐饮、零售五个方向。想按层级或行业筛选查看具体条目，可以访问菲咏造智 · 能力库，入口在 /agent-services 下的能力库页面。用它对照自己的业务清单，通常能较快找到第一批候选。
总结
Skill、Workflow、Agent 不是三种可以自由挑选的方案，而是同一条能力链上按成熟度排列的三个位置。选层的本质是回答"我的业务现在处在哪个位置"，而不是"我想要哪个听起来更先进"。
用任务边界、流程固化程度、分支可穷举性、授权边界四条标准判断，用自下而上的顺序推进，你会发现每一层的投入都在为下一层积累原材料——这比反复重建要经济得多。