欢迎光临
我们一直在努力

Vibe Coding - 从 “聪明的 Mahesh” 到 “靠谱的 Barry”:Anthropic Skills 如何重塑 AI Agent 的专业能力

文章目录

  • 一、问题背景:为什么聪明的 Agent 仍然“不专业”
  • 二、核心理念:为什么是“代码 + 文件夹”
    • 1. 认知一:代码即一切
    • 2. 认知二:文件是最佳协作单元
    • 3. 认知三:代码胜过传统“工具定义”
  • 三、Skills 是什么:一个“可执行的专业经验包”
    • 1. Skill 的组成结构
    • 2. 逐步披露:如何在成千上万个 Skills 中高效检索
  • 四、统一架构:Agent Loop + Runtime + MCP + Skills
  • 五、Skills 生态图谱:从基础能力到企业知识库
    • 1. 基础 Skills:增强大模型“底盘能力”
    • 2. 第三方 Skills:为外部产品定制“AI 使用手册”
    • 3. 企业私有 Skills:组织级“数字老员工”
  • 六、趋势:从工程师玩具到全员可用“技能层”
    • 1. 趋势一:非技术人员也在写 Skills
    • 2. 趋势二:Skills 与 MCP 的分工越来越清晰
    • 3. 趋势三:Skills 正在变得越来越复杂
  • 七、企业实践:从 6–12 个月到数周的垂直 AI 落地
  • 八、工程视角:如何把 Skills 当“软件”来管理
    • 1. 像软件一样工程化管理 Skills
    • 2. 管理 Skills 间依赖关系
  • 九、知识库与持续学习:从“堆信息”到“堆经验”
    • 1. 企业内部的能力知识库
    • 2. Skills 是“记忆具象化”的载体
  • 十、给开发者的实践启发
  • 十一、结语:一起从“造 Agent”转向“造 Skills”

在这里插入图片描述


一、问题背景:为什么聪明的 Agent 仍然“不专业”

过去两年,很多团队已经把 AI Agent 深度融入日常工作:写代码、做报表、查资料、起草合同,几乎无所不包。 但真实体验往往是——能用,却远谈不上“放心托付”。

一个非常形象的类比来说明这个痛点:

  • Mahesh:智商 300 的数学天才,推理能力超强,但对现实税法完全陌生。
  • Barry:经验丰富的税务专家,不一定会证明定理,却能在真实业务中游刃有余。

如果把 AI Agent 类比成 Mahesh,它有三大致命短板:

  • 无法高效吸收你的专业经验(行业 know-how 很难被沉淀和复用)。
  • 无法随时间自我进化(今天教的东西,明天还要从头说一遍)。
  • 起步阶段缺乏关键背景信息(不懂你公司流程、不懂你项目上下文)。

Skills 的使命,就是把一个“聪明但缺经验的 Mahesh”,进化成“懂你业务、可持续进步的 Barry”。

https://www.youtube.com/watch?v=CEvIs9y1uog


二、核心理念:为什么是“代码 + 文件夹”

Anthropic 在打造 Claude Code 和 Skills 的过程中,总结出三个关键认知转变,这是理解整个体系设计的基础。

1. 认知一:代码即一切

传统做 Agent 的思路是:

不同领域 = 不同 Agent 架构 + 不同工具链 + 不同脚手架。

但在 Claude Code 的实践中,Anthropic 发现了一个更“极简”的事实:

  • 绝大多数数字任务的共性是:操作文件系统 + 调用程序/脚本 + 调用 API。
  • 底层只要提供:一个 Bash 环境 + 一个可读写的文件系统,就足以支撑大量复杂任务的编排。

例如“生成财务报告”这个看上去很业务化的任务,本质可以拆成四步:

  • 调用 API 抓取数据
  • 在文件系统里整理原始资料
  • 用 Python 分析数据
  • 合成特定格式的报告(比如 PPT/Excel)
  • 不再需要为“财务 Agent”“运营 Agent”“法务 Agent”设计截然不同的底层架构,只需要一个通用的代码执行环境,再把领域经验封装在可复用的“技能包”中即可。

    2. 认知二:文件是最佳协作单元

    Anthropic 对 Skills 的本质给出的定义非常朴素:

    Skills = 文件的有序集合 = 一个个结构化的文件夹。

    看上去“原始”,但这背后是三条非常现实的设计原则。

    • 普适性:任何会用电脑的人都能理解“文件夹”的概念,开发者可以用,AI 也能用,不引入额外认知负担。
    • 兼容性:天然融入现有工具链——用 Git 做版本管理,放在 Google Drive 共享,压缩后发给其他团队,都不需要新基础设施。
    • 永恒性:几十年软件工程的实践已经证明文件是稳定的协作单位,这种抽象不会轻易过时。

    对开发者来说,一个 Skill 更像是: “一个可以被模型理解和调用的 repo / 目录”,里边装的是过程性知识而不是静态文档。

    3. 认知三:代码胜过传统“工具定义”

    传统工具调用设计(例如 JSON 的工具 schema)有四个典型问题:

    • 指令容易含糊,边界定义不清。
    • 无法自我修改,一旦不适配场景就会“卡住”。
    • 持续占用上下文,工具描述越多,token 压力越大。
    • 难以表达复杂流程和业务逻辑。

    而采用代码 + 文件的方式,有几大优势:

    • 代码天然“自文档化”,函数名、注释、文件结构就是最好的说明书。
    • 可以由 AI 或人类随时修改优化,而不是一次性写死在 prompt 里。
    • 平时只是“躺在文件系统里”,需要的时候按需加载,避免挤占上下文窗口。

    一个典型例子:Claude 反复写同一个 Python 脚本来调整 PPT 样式,每次都在重新构造脚本,既浪费 tokens,质量也不稳定。 现在改成:第一次写好后保存为一个 Skill,之后只需要“调用脚本”即可,大幅提升稳定性与效率。


    三、Skills 是什么:一个“可执行的专业经验包”

    1. Skill 的组成结构

    从实现视角看,一个 Skill 本质上是一个目录,它可以包含:

    • Markdown 文件(例如 SKILL.md,负责说明与指令)。
    • 软件包(依赖库、环境说明)。
    • 各类脚本(Python、Shell 等)。
    • 可执行文件与二进制文件。
    • 相关资产(模板、配置、示例数据等)。

    在演进路径上,大多数 Skill 会经历两个阶段:

    • 早期:只是一个简单的 Markdown 文件,几分钟即可写完,负责说明“如何完成某个流程”。
    • 成熟期:逐渐演化为综合体,包含完整的脚本、配置、测试、资产等,可能需要数周甚至数月精心打磨。

    这很像软件工程从“脚本小工具”逐步演变为“企业级应用”的过程。

    2. 逐步披露:如何在成千上万个 Skills 中高效检索

    如果给 Agent 装上了 500 个甚至几千个 Skills,一个核心挑战是:上下文窗口不够用。

    Anthropic 的解决方案是“逐步披露(progressive disclosure)”策略:

  • 初始状态:模型只看到所有 Skills 的“元数据”(名称、简介、标签等),大约占用 5–10K tokens。
  • 当模型决定使用某个 Skill 时,再加载该 Skill 的 SKILL.md,读入核心指令和目录结构,额外占用约 1–2K tokens。
  • 在执行过程中,按需加载具体脚本、模板或配置文件,用完后可从上下文中“清理”。
  • 例如用户说:“帮我生成一份销售报告”,大致流程会是:

    • Agent 浏览元数据,找到 sales_reporting Skill。
    • 加载 sales_reporting/SKILL.md,理解它能做什么、需要什么输入。
    • 再按需调用 generate_report.py、format_template.json 等资源,完成任务后释放上下文。

    这样一来,即使有成千上万个 Skills,系统依然可以保持上下文轻量、能力丰富、组合灵活。


    四、统一架构:Agent Loop + Runtime + MCP + Skills

    经历一年多实践,Anthropic 观察到通用 AI Agent 的架构正在收敛为四个核心组件:

  • Agent Loop(大脑)

    • 负责理解用户意图、拆解任务、规划步骤。
    • 决定何时调用哪些 Skills 或 MCP 工具,并管理上下文窗口。
  • 运行时环境(Runtime)

    • 提供代码执行能力(例如 Bash、Python)。
    • 管理文件系统、进程隔离和安全策略。
  • MCP:Model Context Protocol

    • 负责连接外部世界,例如 API、数据库、第三方 SaaS。
    • 关注“能不能连上”“能不能调用成功”的层面。
  • Skills(知识与经验层)

    • 承载领域专业知识、流程和最佳实践。
    • 关注“该不该这样做”“在这个场景下怎么做更合理”。
  • 可以把这套结构类比为:“操作系统 + 驱动 + 应用”的关系,其中:

    • MCP 像“驱动层”和“连接器”,让模型看见更多外部资源。
    • Skills 像“应用+脚本库”,封装了可执行的业务经验。

    对于开发者而言,这种统一架构的好处是:心智模型更简单,可以在一个一致的框架内思考 Agent 能力扩展,而不是为每个垂直场景重新发明轮子。


    五、Skills 生态图谱:从基础能力到企业知识库

    自 Skills 发布以来,生态中已经涌现出数千个 Skills,大体可以分为三类。

    1. 基础 Skills:增强大模型“底盘能力”

    这类 Skills 给 Claude 增加了“系统级”能力,例如文档、表格、演示文稿处理等。

    代表案例:

    • Document Skills:让 Claude 能以专业水准处理 Word、PPT、Excel 等文件,理解文档结构与业务逻辑,真正像一个“高配办公助理”。

    对开发者来说,这一类 Skills 更像给操作系统增加新的系统调用—— 它们不局限于某一无关紧要的小功能,而是显著扩展模型的通用能力边界。

    2. 第三方 Skills:为外部产品定制“AI 使用手册”

    第二类是围绕特定产品/平台打造的 Skills,用来让 Claude 更“像熟练用户那样”操作这些工具。

    典型示例:

    • Cadence – 科研与生物信息 Skills

      • 使 Claude 能在电子病历(EHR)数据分析场景中表现远超原生模型。
      • 熟练使用 Python 生物信息学库,理解科研数据处理流程。
    • Browserbase – 自动化浏览器操作 Skills

      • 针对开源浏览器自动化工具 Stagehand 定制 Skills。
      • 让 Claude 可以更稳健地操控浏览器进行表单填报、数据抓取、流程回放。
    • Notion – 工作空间 Skills

      • 帮助 Claude 深度理解用户的 Notion 空间结构。
      • 支持跨文档研究、信息整合和项目管理辅助。

    这类 Skills 的价值在于:替你写“如何正确使用这些复杂工具”的说明书,并且能自动执行说明书里的步骤。

    3. 企业私有 Skills:组织级“数字老员工”

    第三类,也是最具想象力的,是企业为自身场景打造的私有 Skills。

    常见用法包括:

    • 把公司内部的最佳实践编码成 Skills,新来的 AI 也能按公司习惯办事。
    • 把内部系统使用方法沉淀为流程,让 AI 像老员工一样熟悉各类后台工具。
    • 在代码层面强制执行内部代码规范、Review 流程和工作流,提升工程一致性。

    这样的 Skills 不只是“一个工具”,它更像是“组织记忆的一部分”, 新员工、人类或 AI,只要接入这些 Skills,就能快速共享经验红利。


    六、趋势:从工程师玩具到全员可用“技能层”

    Anthropic 工程师在实践中观察到了三个明显趋势。

    1. 趋势一:非技术人员也在写 Skills

    Skills 采用文件夹 + Markdown 的形式,门槛相对较低,因此正在吸引大量业务专家参与构建:

    • 财务团队、招聘团队、会计师事务所。
    • 法律顾问等专业人士。

    这些人可能不擅长写复杂代码,但非常清楚“正确的业务流程是什么”。 通过 Skills,他们可以把自己的专业经验转译成 AI 可执行的流程,从而让 Agent 真正进入日常工作主战场。

    2. 趋势二:Skills 与 MCP 的分工越来越清晰

    很多开发者正在使用 Skills 作为“编排层”,来调度多个 MCP 工具,形成端到端工作流。

    在这套范式里,职责大致分为:

    • MCP:专注“能不能”,负责连上外部系统、保证调用正确执行。
    • Skills:专注“该不该、怎么做”,负责业务策略和流程逻辑。

    当你有 N 个 MCP 服务器和 M 个 Skills 时,可以组合出远超传统“单工具调用”的能力空间。 这使得 Agent 能在高度复杂的企业环境中保持灵活而不失可控性。

    3. 趋势三:Skills 正在变得越来越复杂

    从一开始几分钟写完的 Markdown,到后面包含多种资产、复杂依赖和精细测试的“能力包”, Skills 的复杂度在迅速提升,这恰恰说明它开始承载真实业务逻辑而不仅是 demo。

    复杂化带来的好处包括:

    • 能够覆盖更高价值、更高风险的业务场景(例如金融、医疗)。
    • 可以被组织当成“软件资产”长期维护和进化,而不是一次性脚本。

    七、企业实践:从 6–12 个月到数周的垂直 AI 落地

    在内部实践中,Anthropic 基于 Skills 推出了至少两个专业方案:

    • 金融服务专业方案
    • 生命科学专业方案

    实现方式是:预装对应的 MCP 服务器和 Skills 包,让 Claude 直接以“行业专家助手”的姿态上线。

    与传统“从零打造垂直 AI 产品”的路线相比,优势非常明显:

    • 开发周期从 6–12 个月缩短到数周。
    • 易于快速试错和迭代,业务团队可以频繁更新 Skills。
    • 同一套 Skills 可以跨项目、跨子场景复用,复利效应显著。

    对正在考虑“如何把大模型真正落地到本行业”的团队来说, 这提供了一条成本更低、可控性更强的路径:

    先构建和积累 Skills,而不是一上来就重造一个“全新的垂直 Agent”。


    八、工程视角:如何把 Skills 当“软件”来管理

    想要在更大规模上使用 Skills,必须引入软件工程思维。

    1. 像软件一样工程化管理 Skills

    关键措施包括:

    • 为 Skills 引入测试与评估机制,确保在关键场景下表现稳定。
    • 提供更智能的触发逻辑,确保在正确时间激活正确 Skills。
    • 建立输出质量指标体系,用量化方式持续优化。
    • 强化版本控制、回滚与变更审计能力。

    这意味着:Skills 不再只是“个人脚本收藏夹”, 而是作为一类正式的软件资产进入企业开发治理体系。

    2. 管理 Skills 间依赖关系

    随着 Skills 数量增长,一个明显课题是:依赖管理。

    未来的目标是让一个 Skill 能显式依赖于:

    • 其他 Skills(复用已有流程)。
    • MCP 服务器(需要外部数据或操作)。
    • 特定的环境包(例如特定版本的 Python 库)。

    有了清晰的依赖图,Agent 在复杂环境中的行为会更可控、更精准,也更容易组合多个 Skills 来完成高级任务。


    九、知识库与持续学习:从“堆信息”到“堆经验”

    更长期的愿景: Skills 不只是工具,而是迈向“持续学习”与“组织知识库”的重要台阶。

    1. 企业内部的能力知识库

    理想状态下,企业可以构建一个由“员工 + AI”共同维护的能力知识库:

    • 业务流程、操作规范、复盘经验都会沉淀为 Skills。
    • 新项目可以复用旧项目的 Skills,并在此基础上增量改进。
    • 每次迭代都是对知识库的小幅增强,形成长期复利。

    与传统静态知识库相比,Skills 的区别在于:它不仅能被阅读,还能被直接执行。

    2. Skills 是“记忆具象化”的载体

    在这一框架下,“记忆”不再是模糊的 embedding,而是具体可见的文件和脚本:

    • 过去:只是信息堆积(FAQ、文档、wiki)。
    • 现在:针对特定任务的过程性知识(步骤、脚本、模板)。

    标准化的 Skill 格式保证了一个重要性质:

    “今天 Claude 为某个任务创造的经验,明天的 Claude 能够无损继承这些经验。”

    这为真正意义上的“持续学习”打下了基础: 与其试图让模型在权重层面不断重训,不如让它通过持续积累 Skills 来扩展能力边界。


    十、给开发者的实践启发

    如果你正在搭建或改造自己的 Agent 系统,可以从以下几个方向思考如何借鉴Skills 思路

  • 以“文件夹 + 代码”的形式组织流程经验

    • 把常复用的脚本、模板、流程说明集中放进一个目录,并用一个 Markdown 说明其用途与调用方式。
  • 设计自己的“逐步披露”机制

    • 不要一股脑把所有工具说明塞进上下文;
    • 先只暴露工具列表与简要说明,真正使用时再加载详细文档和脚本。
  • 从基础 Skills 做起,再上升到组织知识

    • 先实现一批稳固的基础能力(文档、报表、数据处理),
    • 再在此之上为本组织打造“私有 Skills”(流程、规范、内网系统)。
  • 尽早给 Skills 引入测试与版本管理

    • 把 Skills 当作软件来维护,而不是临时脚本;
    • 对重要的 Skill 增加单元测试或集成测试,配合 CI/CD 工具自动回归。
  • 让业务人员参与 Skill 设计

    • 技术人员负责 MCP 和 Runtime,
    • 业务人员负责写清楚“正确的做事方式”,共同完成 Skills。

  • 十一、结语:一起从“造 Agent”转向“造 Skills”

    “与你共事 30 天后的 Claude,表现应当远优于第 1 天。”

    要实现这一点,关键不在于无限堆大模型参数,而在于: 让 AI 拥有可复用、可积累、可共享的专业经验,并以 Skills 为载体持续进化。

    从工程实践的角度看,这意味着一个范式切换:

    • 少花精力在一次性、场景定制的“超级 Agent”上。
    • 多把精力投入到可组合、可管理、可共享的 Skills 生态。

    对于开发者、研究者和技术管理者而言, 如果你希望自己的 AI 系统真正走向“专业”“可靠”“可持续”, 那么从今天开始,把“构建 Skills”当作一等公民来设计,可能是一个更长期正确的方向。

    在这里插入图片描述

    赞(0)
    未经允许不得转载:171主机测评 » Vibe Coding - 从 “聪明的 Mahesh” 到 “靠谱的 Barry”:Anthropic Skills 如何重塑 AI Agent 的专业能力
    分享到: 更多 (0)

    评论 抢沙发

    • 昵称 (必填)
    • 邮箱 (必填)
    • 网址