引言：这篇文章要解决的问题
"企业要不要做智能体"已经不再是一个需要争论的问题。真正卡住大多数团队的是下一个问题——从哪里开始。立项会上常见的场景是：业务部门描述了一个宏大的自主智能体愿景，技术部门估算出一个看不到边界的工作量，双方都觉得对方不够务实，项目就此搁置半年。半年后 AI 技术又变了一轮，讨论重新开始。
本文不讲智能体的技术原理，学习中心已有多篇文章覆盖模型架构、微调与部署。本文只回答一个工程问题：企业智能体应该怎样起步。结论先给出——从一个 Skill 开始，而不是从一个 Agent 开始。下面解释这个结论的依据，以及如何执行它。
一、为什么第一步不该是 Agent
先厘清术语。在菲咏造智的能力分层里，三层能力的定义是明确的：
- Skill · 技能：让 AI 稳定做好一件具体的事。周期是数周级。
- Workflow · 工作流：把一段既定业务流程自动化，关键节点保留人工审核。周期是数月级。
- Agent · 智能体：给定目标后自主规划、调用能力、使用工具，遇边界交还人类。周期是季度级。
三者不是三种产品，而是同一条能力链上的三个成熟度。一个企业直接从第三层起步，会遇到三种典型的失败模式。
1.1 失败模式一：没有可被调用的能力，智能体无事可做
Agent 的本质是"规划 + 调用"。它的价值取决于手上有多少可靠的工具可以调。如果企业内部一件具体的事（比如从合同 PDF 中抽取关键条款）都还没有被 AI 稳定完成过，那么给它一个"自主处理合同评审"的目标，它规划出的每一步都会落空。先有能力，才有调度能力的智能体，顺序不能颠倒。
1.2 失败模式二：验收标准无法定义，项目无法结束
一个 Skill 的验收标准是可以写清楚的：在 300 条真实样本上，关键条款抽取的准确率不低于某个数值，单条处理耗时不高于某个数值。而一个自主智能体的验收标准往往写成"能够智能地处理各类合同场景"——这句话无法证伪，也就无法验收。项目于是永远处在"还需要再调一调"的状态，直到预算耗尽。
1.3 失败模式三：出错代价不可控，业务方不敢用
Agent 具备自主行动能力，这意味着它的错误会直接作用在业务上。在没有任何历史准确率数据的情况下，业务负责人不会签字让它接管真实流程。结果是项目做完了，停在演示环境里，没有人敢开给一线用。这是最可惜的一种失败——技术上完成了，组织上没有被接纳。
二、如何挑选第一个 Skill：四条判据
确定从 Skill 起步之后，下一个问题是选哪一个。候选场景通常不缺，业务部门能一口气列出二十个。真正需要的是筛选标准。下面四条判据可以直接拿去打分，四条全部满足的场景，就是第一个 Skill 的理想候选。
2.1 判据一：这件事今天由人在做，且做法能被说清
如果一件事今天没有人做，它就没有基线，你无法证明 AI 做得更好。如果一件事有人做但说不清判断依据（"看经验"、"凭手感"），那么你既写不出提示词，也无法评估结果。优先选择那些有作业规范、有培训手册、新人上岗需要背规则的岗位任务——规则能被写进培训手册，就大概率能被写进能力定义。
2.2 判据二：输入形态相对稳定
同样是"从单据中抽取信息"，如果单据来自三家固定供应商的三种固定模板，难度是可控的；如果单据来自两千家门店的手写照片，难度会高一个量级。第一个 Skill 不是用来展示技术上限的，是用来建立组织信心的。把最难的输入形态留到第二个、第三个 Skill。
2.3 判据三：存在可对照的标准答案
这是最容易被忽略、却最关键的一条。你需要一批"人做出来的正确结果"作为对照集。历史工单、已归档的审批记录、老员工整理过的表格，都是现成的标准答案。如果一个场景连一百条对照样本都凑不出来，它就不适合做第一个 Skill——不是技术做不了，是你无法向管理层证明它做得对。
2.4 判据四：出错能被发现，且能被回滚
第一个 Skill 应该放在"错了有人能看出来、看出来之后能改回去"的位置。生成初稿供人修改，是好位置；直接对外发送客户通知，不是。这一条决定了业务方敢不敢真的把它接进流程——而不接进真实流程的试点，产生不了真实数据。
三、把第一个 Skill 做成一次可验收的工程
选定场景之后，接下来的工作有明确的顺序。这个顺序本身就是防止项目失控的机制。
3.1 先定验收指标，再动手开发
在写第一行代码之前，把三件事写进文档并让业务方签字确认：这个能力吃什么（输入形态）、产出什么（输出形态）、以什么标准算通过（指标口径）。指标口径尤其容易出分歧——"准确率 90%"这句话，在"字段级准确"和"整份文档全对"两种口径下，可能相差三十个百分点。口径没对齐的指标等于没有指标。
3.2 准备测试集，而不是准备演示样例
演示样例是挑出来的漂亮案例，测试集是随机抽出来的真实数据，两者的作用完全不同。测试集应当覆盖常见情况、边缘情况和已知的难例，并且在开发过程中保持封存——只在评估时使用。这一点在工程上等价于机器学习里的"测试集不参与训练"，在组织上则等价于"考卷不能提前给"。
3.3 试点：与人工结果做三项对比
试点阶段在真实业务的小范围内运行，与人工结果逐条对照，产出三项对比数据：准确率、耗时、成本结构。这三项数据是整个项目最关键的证据——它既是扩大范围的依据，也是"不达标就不扩大"这条纪律的执行基础。菲咏造智的六步交付方法论（诊断、设计、构建、试点、上线、迭代）把试点单列为一步，原因正在于此。
3.4 明确"不达标怎么办"
试点没达标不是失败，是信息。达标线以下通常有三种走向：调整口径（发现指标定得不合理）、缩小范围（在更窄的子场景上先达标）、或者判定该场景暂不适合（把资源转向下一个候选）。把这三种走向提前写进方案，试点就不会变成一场没有退出机制的消耗战。
四、从 Skill 长成 Workflow，再长成 Agent
第一个 Skill 跑通之后，能力不是停在那里，而是开始生长。理解生长路径，有助于在第一步就做出不会返工的设计决策。
4.1 何时该往 Workflow 走
当你手上有三到五个相邻的 Skill，并且它们在业务上本来就是前后衔接的（比如：采集卖点、生成图文、合规检查、多平台分发），就到了做 Workflow 的时候。Workflow 的核心设计不是把 Skill 串起来这么简单，而是决定人工审核节点放在哪里。一般规律是：放在不可逆动作之前（发布、发送、支付、变更状态），以及放在准确率最低的环节之后。
4.2 何时该往 Agent 走
当一段流程的分支太多、无法用固定编排穷举，且业务方能够明确授权一个目标（而不只是描述一串步骤）时，才到了 Agent 的时机。典型信号是：业务方在描述需求时说的是"我要的是异常都被处置掉"，而不是"第一步做什么第二步做什么"。此时 Agent 手上应当已经有一批经过验证的 Skill 可供调用，它要解决的是编排问题，不是能力问题。
4.3 让能力可复用，而不是一次性定制
这是第一步就要做对的设计决策：每一个 Skill 都应当被定义成有明确输入输出的独立单元，而不是嵌死在某个业务系统里的一段逻辑。菲咏造智把自有产品线拆解为 70+ 项原子能力、按 Skill / Workflow / Agent 三层组织，正是为了让同一条能力能在不同流程、不同部门之间复用。完整清单可以在菲咏造智 · 能力库页面按层级与行业两个维度筛选查看，入口在 /agent-services 下。
五、四个常见误区
- 误区一：先采购平台，再想场景。平台能力和业务场景的匹配度只有在真实场景里才能验证。先用一个具体场景把链路走通，再决定平台形态，顺序反过来风险小得多。
- 误区二：把 POC 做成演示。演示追求"看起来行"，试点追求"数据上行"。演示做得越漂亮，越容易掩盖真实数据分布上的问题。
- 误区三：追求全自动，拒绝人审。保留人工审核不是技术不够，而是风险设计。成熟的工作流通常长期保留关键节点的人审，只是把人从"全部处理"变成"处理例外"。
- 误区四：以为选型是最重要的决策。在第一个 Skill 阶段，数据质量、口径定义和场景选择对结果的影响，通常远大于底层模型的选择。
六、一份可以直接用的起步清单
把上面的内容压缩成一张可执行的清单，适合直接带进立项会：
- 列出 10 到 20 个候选场景，按第二节的四条判据逐条打分。
- 选出得分最高的一个，明确它属于 Skill 层，不要在第一轮做跨层的事。
- 写清输入形态、输出形态、指标口径三件事，让业务方签字确认。
- 从历史数据中抽取不少于 100 条对照样本，封存为测试集。
- 设定试点范围、试点周期，以及"不达标怎么办"的三种走向。
- 试点结束后产出准确率、耗时、成本结构三项对比数据。
- 达标则扩大范围，并开始识别相邻的第二、第三个 Skill。
总结
企业智能体的落地难点不在模型，在于把一个开放式的技术愿景转换成一连串可验收的工程动作。从一个 Skill 开始，本质上是把不确定性切成能被管理的小块：范围小到能在数周内看到结果，风险小到业务方愿意接进真实流程，证据强到足以支撑下一轮投入。
当你手上积累了一批被验证过的能力，Workflow 与 Agent 就不再是需要重新立项的宏大工程，而是这些能力的自然编排。这条路径比"一次做成一个智能体"要慢一些，但它每一步都有可交回给管理层的东西——而这恰恰是大多数企业 AI 项目最缺的。