咨询 | Anthropic：要造Skills，不要造Agents；对于咨询公司来说，为什么Skills是天然匹配，而且能形成可进化的知识库？

过去一年，很多咨询公司在谈“Agent 战略”，却很少有人真正把注意力放在更关键的一层：Skills。

Anthropic 的 Barry 和 Mahesh 其实讲了一句对咨询行业极有杀伤力的话：与其一遍遍造新的 Agent，不如围绕同一个通用 Agent，不断沉淀和复用 Skills；也就是把“可执行的咨询方法论”放进一个个文件夹里，让 AI 真正长出行业与领域的手艺。

今天我们结合该视频，来谈下咨询公司该如何落地Skills。

一、为什么在咨询公司里，Skills 比 Agents 更友好

对大部分咨询公司来说，“造 Agent”听上去像造一条新业务线：要对接一堆系统，要设计对话流程，还要说服合伙人和一线顾问改变习惯，一上来就是组织级改造。

结果往往是：PPT 很炫，真正落地的用例却寥寥。

Skills 的思路恰好相反，它有点像“把你本来就会的咨询套路，规整成一个能被 Agent 调用的文件夹”。在 Anthropic 的设计里，一个 Skill 本质上就是一个有结构的目录：里边有说明文档（skill.md）、有脚本、有模版、有素材，必要的时候再调用；平时可以乖乖躺在文件系统里，不占用模型上下文。

对咨询公司来说，这有几个天然优势。

第一，它尊重“方法论先于技术架构”的现实。Agent 脚手架再精致，没有行业经验、项目 know-how，永远是“一个很聪明但不懂业务的实习生”。而 Skills 被明确定义为包装“procedural knowledge”（操作性知识）的载体；即你平时在项目上是怎么做尽调、怎么搭行业模型、怎么跑访谈脚本的。

第二，它对组织的侵入性小。你可以从一个部门、一条业务线开始，把现有 Excel 模板、访谈提纲、分析脚本、PPT 结构，慢慢整理成一套 Skills 库，而不必先搭一个庞大的“全公司 Agent 平台”。大企业更兴奋的地方，恰恰是用 Skills 去教 Agent 自家那套怪异的内部软件和工作方式，而不是再建一个新系统让所有人迁移过去。

第三，它友好到连“不会写代码的顾问”都能参与建设。Anthropic 观察到，很多 Skills 来自财务、法务、HR 这些非技术岗位，他们只是用 markdown + 少量脚本，把自己日常的操作路径写清楚，让 Agent 照做。 咨询公司里最值钱的是项目经理和各行业的“微专家”，如果他们不必学编程就能写 Skills，你真正调动的是整个公司的智力资本，而不是几个人的工程能力。

下图是Anthropic自己的写PPT Skills。

从这个意义上说，Agent 更像“新员工管理体系”，Skills 则更像“方法论手册 + 工具箱”。前者需要组织重构，后者可以从一两个文件夹、几条项目经验开始，悄无声息地渗透进每次投标、每轮访谈、每版 deliverable。

二、Skills 如何变成咨询公司的集体知识库，并持续进化

咨询最可惜的一件事，是知识沉淀极度分散：做完一个项目，一堆 PPT、Excel、访谈笔记散落在文件夹里，下一个项目换一批人，又从头再来。哪怕有“知识管理系统”，更多也只是 PDF 墓地，而不是活的能力。

Skills 给了一个更“工程化”的解决方案。视频里有一个观点很值得咨询行业借用：他们把 Skills 想象成“组织和 Agent 共同维护的、会进化的能力知识库”，随着团队使用 Claude、纠正它、向它解释更多机构知识，这个技能库会一点点变厚，然后同一组织里的所有 Agent 都能用。

你可以想象一条简单的演化路径。

一开始，只是一个“行业报告写作 Skill”。内容也许很朴素：如何搭一个 30 页行业研究汇报的框架，每一章需要什么数据、什么图表、什么典型案例，用 markdown 写清楚，再配上若干宏或 Python 脚本做基础数据处理。

接着，某个项目组觉得这个结构对“出海战略项目”不够用，于是复制这套 Skill，增加了一些关于海外市场监管、汇率风险、当地竞争格局的模块。这个版本的 Skill 随项目迭代，慢慢收集了一批“踩坑教训”和“高评项目”的实践经验。

再后来，知识管理团队介入，开始像管理软件一样管理 Skills：建立版本号、记录变更、为关键 Skill 写自动化测试（例如：给定一组输入，Agent 生成的研究大纲是否符合某些质量标准）。Anthropic 自己也提到，他们在思考如何像对待软件一样，对 Skills 做评估、版本追踪和依赖管理，让 Agent 行为更可预测。

这其实打开了咨询知识管理的新范式： 知识不再只是“可以被搜索的文档”，而是“可以被执行的能力单元”；项目上每一次纠错、每一次重构框架，不再只是顾问脑中的经验，而是可以写回 Skills，成为下一批项目的默认起点。人和 Agent 在共同写“公司版的行业操作系统”。

从我们给部分咨询与专业服务机构做 AI 转型的经验来看，真正起飞的时刻往往不是“上了一个新模型”，而是当团队第一次意识到：“原来我们这些散在 PPT 里的路线图、访谈套路，是可以被写成一个 Skill，让 AI 永久保留并不断完善的。”那一刻，知识库终于从“文档仓库”变成了“能力平台”。

如果你所在的公司已经在做知识沉淀，但总感觉“不好用、没人看”，可以认真考虑：是不是应该从“写PPT”转向“写 Skills”。

三、为什么 Skills 是顾问快速理解一个新行业的最佳入口

咨询项目有一个经典尴尬：甲方说，“我们这个行业很复杂，你们能听懂吗？”

乙方笑着说，“给我们两周，我们先做一版行业扫描。”

背后真实情况是：顾问需要在极短时间内从 0 到 60 分，够用就行。而传统方式是：疯狂看报告、扫研报、盯政策，再用自己的结构化能力“打包成一个故事”。AI 很强，但如果只是一个通用 Agent，它的状态更像那个比喻：“300 IQ 的数学天才 Mahesh，却不懂 2025 年的税法。”你不希望它“从第一性原理”去推演一个行业监管体系，那成本太高。

Skills 的价值，恰恰在于把“如何快速进入一个行业”本身，变成一个可重用的能力包。

想象这样一个行业入门 Skill，它不只是告诉 AI“请你帮我调研新能源车行业”，而是写清楚：

• 第 1 步，优先获取哪些公开数据源、哪些机构的研究是首选；
• 第 2 步，使用哪些 MCP 工具或 API 连接业内数据库、新闻源；
• 第 3 步，为新顾问生成一个“入门 3 日学习路径”：哪几份报告先精读，哪些概念必须掌握，给出小测验问题让顾问自测理解；
• 第 4 步，结合公司过往项目经验，列出“这个行业做项目常见的坑”和“甲方最在意的 5 个 KPI”，并配上内部过往交付物作为范例（经过脱敏和权限控制）。

Anthropic 在 Skills 刚上线五周后，就快速推出了针对金融服务和生命科学垂直领域的产品，每个垂直都是“同一个 Agent + 一组 MCP 连接 + 一束 Skills”。 这其实就是一个模板：用少量高度定制的 Skills，把通用 Agent 调教成“懂行的顾问助理”。

对咨询顾问本人来说，这还有一个额外好处：你的学习路径被“外化和标准化”了。过去是你跟着项目经理瞎摸索，现在是 Agent 拿着行业 Skill 带着你“刷副本”：每天给你安排固定的阅读、提问和小作业，你给它反馈，它再把更 refine 的理解写回 Skill。

你会感受到的是：这个“AI 同事”每天都在变聪明，不再重复犯同样的行业认知错误，而你自己的成长也变得更可见、更体系化。

从职业发展角度看，这种“行业入门 Skill”还有一个微妙的意义： 当你离开这家咨询公司的时候，行业理解是你带走的；但方法论、模板、学习路径，已经沉淀为公司的 Skills 资产，可以不断帮助下一代顾问。双方都更坦然。

四、如果咨询公司要做 Skills，最直接可上手的路径是什么？

很多咨询合伙人会问：“听上去很美，但我要从哪一步开始？我既不想搞一年大项目，也不想只停留在概念。”

结合视频里的架构和我们在咨询公司落地 AI 转型的实践，我们建议一个尽可能“轻但真实”的起点。

第一步：选一个“使用频率高 + 可标准化”的场景，别一上来就想解决所有问题。 比如：行业扫描、竞品研究、访谈纪要结构化、投标书初稿生成，这些都是咨询公司每周都会发生的工作，而且流程相对固定，非常适合做成第一个 Skill。

第二步：用“写项目 playbook”的方式写 Skill，而不是先纠结模型。 Anthropic 的设计刻意让 Skill 本质上就是“一个文件夹 + 一个 skill.md”，对非技术人员友好。 你可以让一位资深顾问坐下来，像写项目操作手册一样，把步骤、判断标准、常用模版写清楚，再由 AI 或工程同事把其中可自动化的部分变成脚本或小工具。

重点不是代码有多复杂，而是：这个 Skill 是否真实还原了你们做事的路径。

第三步：先在一个小团队内，跑几轮真实项目，允许 Agent 和顾问共同修改 Skill。 不要指望一版就标准化整个公司。你更应该把前几轮使用视为“内测期”，鼓励顾问在项目中边用边骂边改，把自己的改动和反馈写回 Skill。

Anthropic 也把 Skills 的演化看成类似软件开发，要有版本记录、行为追踪，甚至自动化评估。 对咨询公司来说，这意味着你需要有人负责“维护这套行业能力”，但这份工作本身会逐渐变成公司的核心资产管理工作，而不是“额外负担”。

第四步：真正考虑如何在组织层面管理 Skills，而不是只做一个 cool demo。 当你有了 5〜10 个好用的 Skills（比如几大行业、几个关键职能），就需要开始思考：权限如何控制（哪些 Skills 只内部分组可见）、如何在知识管理系统里统一入口、如何为每个 Skill 设定“owner”和维护节奏。 这一层如果做不好，很容易重蹈“知识库无人问津”的覆辙；但如果做得好，你就拥有一个“可执行的行业方法论资产池”，而不是一堆难以搜索的遗留文档。

我们这边这两年也在陪跑几家头部咨询和专业服务机构做类似的事情：从一个极小的用例切入，帮他们把原本散落在 SharePoint、知识库里的方法论打包成 Skills，用通用 Agent 串起来，先在一个 BU 或一条行业线上跑通，再慢慢扩展。

如果你在公司里正负责 AI 转型、知识管理、或者某条业务线的数字化升级，也欢迎在公众号后台留言，或者通过邮件和我们交流你们目前的困惑和想法，我们可以一起拆一拆：你们现有的资产，能否用 Skills 这种方式“重塑”为真正会用、用得动的 AI 能力。

最后，回到那句略带挑衅的话

“Don’t build agents, build skills instead”。

对咨询公司来说，也许更贴切的版本是：别急着造一个完美的“咨询大模型 Agent”，不如先问问：你们真正独特的行业方法论和项目套路，有多少已经变成了可执行的 Skills？如果答案还接近于零，那恰恰说明，现在是一个非常好的起跑时间点。