一个反复出现的开局错误
过去一年里，我们接触的企业几乎都在问同一个问题：我们想上一个智能体，应该从哪里开始？问题本身没有错，错的是它隐含的假设——把智能体当成一个可以整体采购、整体上线、整体验收的东西。
真实情况是，一个能自主完成业务目标的智能体，内部是由许多更小的动作拼起来的：读懂一份非结构化的文档、从系统里取一段数据、按规则做一次判断、生成一份符合口径的材料、把结果写回业务系统、在拿不准的时候把决定交还给人。 这些动作里的任何一个不稳定，整个智能体就会在演示里表现完美、在生产里持续出错。
于是项目常常走成这样：立项时目标很大，三个月后交付了一个只能在特定样例上跑通的演示；业务方失去耐心，技术团队疲于解释，最后归因为「模型能力还不够」。 但复盘下来，绝大多数卡点并不在模型，而在于没有人先把那些小动作一个一个做稳、并且沉淀下来。
换一个起点
不要问「我们的第一个智能体做什么」，先问「我们业务里，有哪几件事值得让 AI 稳定地做好、并且做好之后还会被反复用到」。 前一个问题指向一次性交付，后一个问题指向可以累积的资产。
能力库不是产品清单，是可复用的最小单位
「能力库」这个词很容易被理解成一份软件目录——列着你买过或做过的几套系统。但那不是能力库，那是资产台账。 真正的企业 AI 能力库，颗粒度要比一套系统小得多：它的最小单位是一条能力，一条能力必须能说清楚它吃什么、产出什么。
举个例子。「合同智能审查系统」不是一条能力，它是一个项目；「从合同 PDF 中抽取关键条款，输出结构化字段与原文定位」才是一条能力。 前者无法被复用——它绑定了特定的界面、流程和角色；后者可以被复用——采购在用、法务在用，明天做供应商准入的时候还能接着用。
这个差别决定了成本曲线的形状。按项目组织，每个新需求都是从零开始，第五个项目和第一个项目一样贵； 按能力组织，第一个项目沉淀出若干条能力，第二个项目里有一半是拼装已有能力，边际成本随时间下降。AI 能力复用的价值不体现在第一个项目上，而体现在第二个项目上——这也是为什么它容易被忽略，因为立项时看不到。
判断一条能力写得够不够「原子」，有一个很朴素的检验：把它单独念给一位业务负责人听，对方能不能立刻判断「这个能不能用在我这里」。 如果对方还要追问三句才明白你在说什么，那它多半还是一个含糊的卖点，不是一条能力。
Skill、Workflow、Agent：能力库的组织骨架
能力库如果只是一张平铺的清单，很快就会失控。我们在实践中把能力按三层组织，这三层同时也是推荐的推进顺序：
Skill · 技能
让 AI 稳定做好一件具体的事。周期是数周级，验证方式明确：给一批真实样本，看准确率与稳定性。
Workflow · 工作流
把一段既定业务流程自动化，关键节点保留人工审核。周期是数月级，价值来自端到端的节拍变化。
Agent · 智能体
给定目标后自主规划、调用能力、使用工具，遇到边界交还人类。周期是季度级，前提是下面两层已经稳。
这三层不是营销分类，而是风险与周期的分层。Skill 层的失败是局部的，一条抽取能力不准，换个提示词、补一批样本就能迭代； Agent 层的失败是全局的，规划链条上任一环节出错，都会以难以复现的方式表现出来。 先在 Skill 层把不确定性消化掉，再往上走，本质上是把不可控的风险切成可控的小块。
我们把这套组织方式和目前沉淀的 70+ 项可组装能力整理成了一个公开的清单，可以按层级和行业筛选， 你可以直接对照着看哪几条与自己的业务相关：菲咏造智 · 能力库。
先建能力库的四个理由
一、把「不确定」限制在可承受的范围内
企业引入 AI 最大的隐性成本，是为不确定性买单。一条 Skill 做不成，损失是几周；一个 Agent 做不成，损失是一个季度加上业务方的信任。 先做 Skill，等于用小额、多次的试错替代一次性的大额押注。
二、让工作量估算第一次变得可信
「这个需求要多久」是所有 AI 项目里最难回答的问题，因为没人知道模型在你的数据上表现如何。 但当你已经有一批跑在生产里的能力时，估算方式就变了：新需求可以被拆成「已有能力 × N + 新增能力 × M」， 已有部分的工期是已知的，只需要为新增部分留出不确定性缓冲。估算精度的提升不来自经验，来自存量。
三、组织的学习曲线被保留下来
按项目推进时，知识留在参与项目的那几个人脑子里，人一走就归零。按能力推进时，每条能力都带着自己的输入定义、输出格式、 评测样本和失败案例——这些是组织资产，而不是个人经验。第二个业务部门想用同一条能力时，不需要重新经历一遍踩坑过程。
四、把数据边界的讨论提前到正确的时点
数据能不能出企业、哪些字段可以进模型、日志留存多久——这些问题在做智能体时会一次性全部涌上来，通常导致项目停摆。 而在能力粒度上，这些问题是逐条讨论的：这一条只读公开产品文档，那一条要碰客户身份信息，两者的处置方式完全不同。 逐条谈，合规部门给得出结论；打包谈，只会得到一个「再研究一下」。
第一批能力怎么选：四个信号
能力库不是一次建成的，起步阶段挑三到五条就够。我们建议按下面四个信号在自己的业务里筛：
值得优先做成能力的四个信号
- 高频重复：同一件事每周都要做很多遍，且做法基本一致。
- 输入输出清晰：能一句话说清吃什么、产出什么，不需要大段前提说明。
- 有现成的对错标准：存量数据里能找到「正确答案」，可以用来评测，而不是靠人主观感觉好不好。
- 跨部门可复用：不止一个团队会用到，或者未来的相邻场景大概率会用到。
四个信号同时成立的事情，通常几周内就能看到明确结论；只满足一两个的，先放进候选池，不要作为首发。 特别提醒：不要把「最难的那件事」作为第一条能力。第一条能力的真正任务是让组织建立起对这条路径的信心， 并跑通从需求到评测到上线的完整链路，难度应该排在第二位。
三个常见误区
误区一：先招人再谈能力
不少企业的第一步是组建 AI 团队，然后让团队去找场景。这个顺序会让团队在很长时间里没有可交付物，也很难向管理层证明价值。 更稳的顺序是先确定两到三条能力，用它们来定义需要什么样的人。
误区二：把评测留到最后
「先做出来看看效果」听起来务实，实际上会让项目失去方向盘。评测集应该和能力定义同时产生——哪怕只有几十条人工标注的样本， 它的作用是让「变好了还是变差了」成为一个可以被回答的问题。没有评测集的迭代，是在赌运气。
误区三：认为能力库必须自研
能力库的价值在于「可组装、可复用、可评测」，不在于每一行代码是谁写的。合理的做法是：通用能力尽量复用已有的成熟实现， 把自研预算集中在真正带来差异的业务判断逻辑上。这也是我们把已有产品线整体重切成原子能力的原因—— 让企业能够按需取用其中的一部分，而不是被迫整套采购。
数据边界、私有化部署与合规前提
企业侧最关心的三个约束，几乎总是这三个：数据能不能出去、系统能不能自己管、出了问题谁负责。 能力库的组织方式恰好让这三个约束变得可谈：
数据边界可以逐条设定。一条只处理公开信息的能力，和一条要接触业务核心数据的能力， 可以采用完全不同的部署形态与留存策略，不必按最严格的口径统一处理，避免整体成本被最敏感的那一条拉高。
私有化部署因此成为一种可以分阶段进行的选择。数据敏感度高的能力优先在企业自有环境内运行， 其余能力保持灵活；随着团队运维经验积累，再逐步扩大范围。我们支持完整的私有化部署形态，也支持这种混合推进的节奏。
合规前提方面，面向公众提供服务的生成式能力涉及国家算法备案等要求，这类事项应该在能力设计阶段就纳入考虑， 而不是等到上线前才发现需要补办。
一份可以直接用的判断清单
如果你正准备启动第一个 AI 项目，或者正在为一个卡住的智能体项目找出路，可以先用下面这份清单自查一遍：
启动前自查
- 我们要做的这件事，能不能拆成三到五条各自独立可验证的能力？
- 每条能力的输入输出，能不能用一句话写清楚？
- 每条能力有没有一份哪怕只有几十条样本的评测集？
- 这些能力里，有几条在半年内会被第二个部门用到？
- 涉及的数据分别属于哪个敏感级别，各自的部署形态是否已经确定？
- 如果第一条能力失败了，我们损失的是几周，还是一个季度？
六个问题里如果有三个以上答不上来，那么现阶段更适合做的不是智能体，而是先把能力这一层建起来。 这不是降低目标，而是把同一个目标拆成能被验证的阶段——Agent 层依然是终点，只是不应该是起点。
常见问题解答
Q: 我们规模不大，也需要建能力库吗？
A: 规模小反而更需要。能力库的核心作用是避免重复投入，团队越小，重复投入的代价越明显。 规模小的团队可以从两条能力起步，不必追求覆盖面。
Q: 先建能力库会不会拖慢智能体上线的时间？
A: 从单个项目看会慢一点，从半年维度看通常更快。因为智能体上线的真正瓶颈不是搭框架， 而是逐个把底层动作调稳定——这部分工作无论如何都要做，区别只在于是否沉淀下来供下一次使用。
Q: 能力库和我们已有的业务系统是什么关系？
A: 是补充关系，不是替代关系。能力通过接口被已有系统调用，业务流程与权限体系仍然由原系统承载， 这样引入成本最低，也不会造成第二套操作入口。
Q: 怎么判断一条能力算不算「做成了」？
A: 三个条件同时满足：在评测集上达到约定指标、在真实业务里连续运行一段时间没有需要人工兜底的重大失误、 以及第二个使用方接入时不需要重新开发。第三条最容易被忽略，但它才是复用价值的验证。