别造 Agents 了，去造 Skills 吧

在 2026 年初的时候，Anthropic 做了一次分享，Barry Zhang 和 Mahesh Murag 上来第一句话就很直白，上次他们来讲的时候，大家还在吵一个问题，agent 到底算个啥。结果才过了一阵子，很多人已经开始天天用 agent 了，写代码的，做运营的，搞分析的，甚至财务法务这种以前离编程很远的岗位，也开始把 agent 当半个搭子在用

但你真用上了就会发现，槽点也很明显

agent 很聪明，很能干，跑起来像 300 智商的数学天才，推理能力拉满，工具也能接一堆

可一到真干活，你会突然卡住

不是它不会做，而是它不懂你所在的那个行业到底怎么做才算对

你想想看，谁来帮你报税更靠谱，一个是天才但没干过税务，一个是税务老会计

我反正会选老会计

我不想让天才从零推导 2025 的税法，听着就头皮发麻

他们说现在的 agent，很多时候就像那个天才

能做出惊人的东西，但缺的不是智商，缺的是稳定的领域经验，缺的是你一家公司一团队一岗位每天重复执行的那套做事方法

然后他们抛了一个很硬的观点，code 就够了

这个点我当时有点愣住

他们解释也很朴素，他们原来以为不同领域的 agent 会长得完全不一样，每个领域都得配一套独有的工具和脚手架，结果就变成一个用例一个 agent，一个团队一堆 agent

结果他们做了 Cloud Code 之后才发现，底层那个 agent 其实更通用

code 不是某个领域的用例，code 反而更像数字世界的通用接口

做财务报表也好，做研究也好，你只要能用代码去拉数据，去查资料，去把东西组织进文件系统，去用 Python 做分析，再把结果生成成你要的文件格式

这整套链路，说穿了就是 bash 加文件系统，再加一点脚本能力

脚手架突然就变得很薄，很可扩展

可问题又回来了，通用归通用，专业归专业

于是他们就不继续纠结怎么造更聪明的 agent 了，转头去造了一个东西，agent skills

这个词听着挺玄，结果定义出来特别接地气

skills 是一组组织好的文件

对，你没看错，就是文件夹

他们说这个简单是刻意设计出来的，因为他们想要一种任何人都能创建和复用的知识载体，不管你是人还是 agent，只要你有台电脑就能搞

你可以把 skills 放进 Git 里版本管理，也可以丢进 Google Drive，甚至打个 zip 发给同事就能用

我们过去几十年一直在用文件当原语，现在为啥要改

不改也行，那就继续用文件

但在这个文件夹里，你不只是放一堆提示词

你还可以把脚本当成工具塞进去

他们举了个例子，我觉得特别有代表性

他们反复看到 Claude 在处理幻灯片的时候，一遍一遍写同样的 Python 脚本去做样式处理

那你说这是不是有点离谱

既然它总要写，那干脆让它把脚本保存进 skill 里，变成未来的它自己随手就能调用的工具

下次再遇到同样的需求，直接跑脚本就完事了

一致性上来了，效率也上来了，更关键的是，你不需要每次都在对话里把怎么做讲一遍

但 skills 一多，又会遇到另一个问题，context window 这玩意本来就紧张

你总不能把几百个 skills 的全部内容都塞进上下文里，那纯纯浪费 token

所以他们搞了一个设计，progressive disclosure

运行时只把 metadata 展示给模型，让模型知道自己有这么个 skill

等真的要用的时候，它再去读 skill.md，里面有核心指令，还有目录结构，告诉它该去读哪些文件

其他东西都在文件系统里躺着，没用到就不进上下文

这个思路我觉得很对味

你把它当成给 agent 配了一套技能库，平时放包里，真打架的时候才掏出来

他们说 skills 发布五周，生态就长得很快，已经有几千个 skills 了

而且很自然分成了几类

有些是基础能力类的，给 agent 增加新的通用能力，或者补足某个领域的能力缺口

他们自己做了 document skills，让 Claude 能做出专业质量的办公文档

也有人做科研类 skills，比如更好地分析 EHR 数据，更熟练地用常见的 Python 生物信息库

还有一类是第三方伙伴做的，比如 Browserbase 给他们的开源浏览器自动化工具做了 skill

这样 Claude 装上 skill 之后，就能更有效地用浏览器去完成任务

Notion 也做了一堆 skills，让 Claude 更懂你的 workspace，能在你的资料库里做更深的研究

但他们说最让他们兴奋的，是企业内部的那一类 skills

大公司开始用 skills 去教 agent 公司的最佳实践，去教它内部那堆奇奇怪怪的定制软件怎么用

还有那种开发者效率团队，服务几千甚至几万开发者的，他们用 skills 去把代码风格规范，内部开发流程，统一写进去

这个画面你想想就很爽

以前你要推广一套规范，得写 wiki，得做培训，得做 code review

现在你可能直接把规范做成 skill，配给所有人的 agent

大家天天用着用着就把习惯养成了

而且 skills 的另一个趋势也很明显

它们在变复杂

最简单的 skill 可能就是一个 markdown 文件加一点提示词

但越来越多的 skill 会打包软件，可执行文件，二进制，脚本，资产文件，甚至完整的工作流

他们的判断是，未来很多 skills 会像软件一样，需要花几周几个月去开发和维护

然后他们把 skills 和 MCP 放在一起讲，我觉得这个搭配特别关键

MCP 更像连接外部世界的管道，提供工具和数据的接入

skills 更像你做事的方法论和经验，提供专业度和可预期的执行方式

一个给你手脚，一个给你套路

更骚的是，他们还观察到，很多 skill 的作者并不是技术人

财务，招聘，会计，法务，这些人也能用 skills 去扩展通用 agent，让 agent 变得更贴近他们日常工作

这件事一旦跑起来，AI 的可用性会被拉到一个新的层级

聊到这里，他们给了一个更完整的架构图式的说法

一个通用 agent 栈，会慢慢收敛到几个组件

一个 agent loop，负责管理模型的内部上下文，决定哪些 token 进出

一个 runtime environment，给它文件系统，让它能读写代码

再接上 MCP servers，连外部工具和数据

再给它一整套 skills 库，可能上百上千个，让它只在需要的时候加载

这样你要让一个 agent 进入一个新垂类，可能就变成一件很工程化的事

配对合适的 MCP servers

配对合适的 skills

然后就能上岗

他们还提到，Anthropic 自己在推出 skills 五周后，就快速上线了金融服务和生命科学的产品包，每个包里都带着对应的 MCP 和 skills，让 Claude 对专业人士更好用

当然，他们也很清醒，skills 变复杂之后，工程问题会一堆

他们想把 skills 当软件来对待

要做测试和评估

要有更好的工具，去验证 agent 在什么时机触发 skill，触发得对不对

要能衡量装了 skill 之后的输出质量是不是达标

还要做版本管理，技能升级了，行为变了，得有清晰的谱系

甚至他们还想让 skills 能显式声明依赖

依赖别的 skills

依赖某个 MCP server

依赖 runtime 里的某些包和依赖

这样 agent 在不同环境里会更可预测，多 skill 组合在一起也更稳

然后他们讲了一个我特别喜欢的愿景

未来企业里会出现一种集体的知识库

它不是那种写在 wiki 里的静态文档

而是一套可执行的能力集合，随着人和 agent 的互动不断演进

你给 agent 反馈，你把机构知识塞进去，它就会变得更懂你们的做事方式

然后整个团队里所有 agent 都会一起变强

新人加入团队的第一天，用 Claude 的时候，它已经知道你们在乎什么，知道你们每天怎么干活，知道怎样才算高效

这玩意一旦形成复利，想想就挺离谱

更离谱的是，他们希望 Claude 也能自己写 skills

skills 的格式标准化之后，有一个很重要的保证

Claude 写下来的东西，未来的它也能高效复用

学习才变得可迁移

他们把它叫 continuous learning 的一个具体落点

skills 不是记忆所有东西，它更像把程序性知识存下来，让它在特定任务上能稳定复现

你跟 Claude 合作到第 30 天，它应该比第 1 天更好用

不是靠神秘的自我进化，而是靠你们一起把能复用的东西写进文件夹

收尾的时候他们用了一个类比

模型像处理器，投入巨大，潜力巨大，但单独放那儿也就那样

runtime 像操作系统，把处理器的价值放大，负责编排资源和数据

可真正的价值来自应用

处理器和操作系统是少数公司做的

应用层是无数开发者写出来的，写进了领域经验，写进了独特视角

他们希望 skills 能把这一层打开，让更多人能参与

用他们的话讲，你只要把东西丢进文件夹里，就能开始解决具体问题

所以他们收尾那句口号也就顺理成章了

别再一遍遍重造 agent 了

去造 skills 吧