为什么真正强大的 AI Agent，不再靠 Prompt，而靠 Skills？

Anthropic Agent Skills

Anthropic（Claude的技能体系）：Anthropic是当前Agent Skills理念最积极的倡导者和实践者。2025年10月，Anthropic在其产品Claude中正式引入了技能框架，并公开了相关规范。可以说，Anthropic是将“技能作为智能体一等公民”明确提出并实现的先驱。从理念上，Anthropic团队认为随着AI走入复杂真实场景，需要一种模块化方式来扩充和定制AI能力，于是提出用技能包封装专业任务流程。工程上，Claude的Agent Skills由Anthropic率先实现：Claude能够加载多个技能目录，根据需要触发其中的指令和代码，使一个通用对话模型变身为具备专业能力的智能代理。Anthropic不仅实现了技能功能，还积极推动成为行业标准。他们在2025年末宣布开源技能规范（agentskills.io）并提供参考SDK，希望其它平台采用这一标准。Anthropic还联合Linux基金会和其他公司成立Agentic AI联盟来共建技能标准。

Agent Skills 的本质拆解（What）

Skill 的技术本质

从工程角度来看，一个“技能（Skill）”到底是什么？简言之，Skill是一个封装了特定能力的可执行模组。Anthropic对技能的定义是：“一个技能就是一个包含SKILL.md文件的文件夹，里面组织了指导说明、脚本和资源，赋予代理特定的新能力”。也就是说，技能既不是纯粹的一段Prompt，也不是简单的API函数，而是包含多种要素的能力包。其本质特征可以归纳如下：
• 结构化的指令集合：每个Skill核心是一个或多个指导说明（通常写在Markdown文件中）。这些说明可以看作小型的操作手册或剧本，教会AI如何执行某类任务。例如Claude的PDF处理技能中，SKILL.md详细列出了处理PDF的步骤、应使用的工具命令以及质量要求。相比普通Prompt里的散文式要求，技能中的指令是模块内部的，不直接暴露给终端用户，而是在触发技能时作为系统信息提供给模型。这样技能起到了SOP脚本的作用。
• 元数据（Metadata）：技能通常带有元数据描述，如名称、描述、权限需求等。例如Anthropic规定SKILL.md开头有YAML元信息，包括name和description。这些元数据被加载到代理的系统提示中，起到索引和触发判据的作用。模型会根据技能的描述判断当前任务是否相关，需要调用哪个技能。因此元数据让技能成为Agent体系中的一等公民：代理启动时就“知道”自己有哪些技能可用，每项技能的大致用途是什么。
• 代码和资源：与简单文本提示不同，技能还可以包含可执行代码脚本以及其它资源文件。这些代码通常用于执行技能相关的子任务，例如一个技能可能附带Python脚本用于数据处理、API调用等。当技能触发时，模型可以选择运行这些脚本来完成任务的一部分，而不是用自身的推理能力去“模拟”那个过程。例如，在Claude的PDF技能中就打包了一个Python脚本用于提取PDF表单字段，Claude可以直接运行它以高效获得结果。除了代码，技能目录还可包含参考资料文件（如规范文本、示例数据等），模型可在需要时加载阅读 。由此可见，技能实际上是一个迷你文件系统模块：既有人可读的指导，也有机器可执行的脚本和数据。一套技能就像插件一样赋予Agent额外能力。

归根结底，一个Skill的本质可以理解为“可动态加载的能力单元”。它既不同于传统prompt（技能可以不用每次都塞在对话里，而是按需加载），也不同于普通API函数（技能内部可能调用多个工具、包含复杂逻辑，而不仅是一行调用）。Skill更像是一个微型的软件模块，但其接口和实现对接的是LLM。对于模型而言，加载一个技能就如同人翻开一本特定工作手册，里面不仅写着该做什么，还可能附带工具（脚本）去完成部分工作。

Skill与Tool/Function的区别在此也变得清晰：Tool/Function通常是原子操作，比如调用计算器、检索数据库、发送HTTP请求等。它们提供的接口往往是单步的，由模型决定何时调用。而Skill是复合动作或策略，相当于封装了一系列操作步骤和知识。模型使用Skill通常不是一步完成，而是先根据技能指导执行多步操作甚至调用多个工具，然后合成最终输出。举例来说，“翻译一篇文章”这个任务，可以有一个Translation工具API，但Skill的话可能包含如何选择翻译风格、如何逐段检查一致性等指导，再调用翻译API和校对函数等一系列步骤。Tool偏向能力接口，Skill偏向能力实现。此外，在当前实现中，Tool是通过函数schema告诉模型“你可以调用X函数完成Y功能”，而Skill则是模型通过阅读说明自主掌握用何种策略达成目标。这使得Skill比Tool更灵活和丰富，但也要求模型具备理解长文档和遵循复杂指令的能力。

Skill与Memory/State/Policy的关系则比较微妙。技能本身通常是静态文件，不会像Memory那样随对话演变更新。因此技能不是对话记忆，而更接近长期知识。如果说Memory（如长时记忆向量库）解决的是“AI知道了什么内容”，Skill解决的就是“AI知道怎么做某件事”。两者有点类似于大脑中的语义记忆和程序记忆之分：Memory存储事实和上下文，Skill存储程序化步骤和技巧。当然，两者也有交叉——技能执行过程中，模型可能需要查询记忆（比如技能指示模型去检索知识库）；反过来，Agent长时间运行过程中也可能学习新技能（将新方法固化下来），那就相当于把临时经验升华为新的“程序记忆”。

至于Policy（策略），可以将其视为Agent更高层的决策逻辑。现在常见的大模型Agent，大部分策略（即何时用哪个工具/技能、接下来该做什么）都是隐含在模型推理里的。而引入Skill后，模型在决策时相当于有了更多“选项”。技能的元数据（描述）提供了策略选择的依据，模型通过检索匹配当前任务，决定要不要“走”某个技能流程。这有点像强化学习里的宏动作：高层策略可以选择执行某个技能（类似一个Option）来简化决策序列。因此可以说，技能为Agent策略提供了抽象动作空间。未来若引入显式的Policy模块（比如一个独立控制器来调度技能），那么技能就是策略可调用的基础单元。目前Claude的实现中，仍由模型自身在chain-of-thought中决定技能触发，相当于把策略学习内隐在LLM中进行。而无论是内隐还是外部policy，技能都起到了扩展动作集的作用，让代理的策略不再只是“思考词串或调用底层API”，而是可以“执行一套预定义的复杂流程”。

Claude Agent Skills 的技术机制

Anthropic的Claude技能体系是目前公开资料最丰富的实现，下面对其技术机制作详细拆解：

技能结构与组成：Claude的每个技能以一个独立目录表示，其中核心是SKILL.md文件。SKILL.md采用Markdown格式，顶部是YAML元数据，包括name（技能名称）和description（技能描述），这些是必填项。元数据下面是技能的正文内容，可以包含多级标题、步骤说明、注意事项等具体指导。技能目录内还可以有其他文件：如果SKILL.md太长或需要按情境划分内容，作者可以将部分内容放入额外的.md文件中，并在SKILL.md正文用链接引用 。此外，目录中可以包括脚本代码（如.py脚本）以及所需的静态资源（配置文件、模板等）。例如Anthropic官方的PDF技能中，除了SKILL.md外有forms.md（关于表单填写的指令）、reference.md（引用说明）和extract_fields.py（用于提取PDF表单字段的脚本） 。通过这种方式，一个技能可以容纳分层次的信息：核心流程在主文件，细节或扩展规则放次级文件，代码工具放脚本文件，形成完善的能力封装。

Claude Agent技能架构示意：左侧是Agent的系统提示包含已安装技能的名称和描述；右侧是Agent运行环境的文件系统，其中各技能以文件夹形式存在，内部含SKILL.md和相关子文件/脚本 。技能可以调用MCP服务器（外部工具接口）或执行本地脚本，实现功能扩展。

渐进式加载（Progressive Disclosure）：Claude技能的设计核心原则是“渐进披露”。具体而言，代理不会在一开始就把每个技能的完整内容都塞入上下文，那样会爆掉上下文窗口。取而代之，它采用三级逐步加载：第一级，启动时Claude只将每个技能的name和description加载进系统提示。这每个技能仅占用几十个Token，却提供了该技能的“目录索引”。第二级，当Claude经过思考认为某个技能可能和当前用户任务相关，它会通过一个工具（如文件读取命令）去加载该技能完整的SKILL.md正文，将其中详细指令纳入上下文。此时模型获得了技能的操作指南。第三级，如果SKILL.md里引用了额外文件（如前述forms.md），Claude会视需要再进一步读取这些文件的内容 。只有在执行特定子情景时才加载更详细的附录信息。通过这种渐进机制，Claude能够在需要时逐步获取技能知识，而在不需要时保持上下文精简。这意味着技能可包容的总信息量实际上不受单次上下文限制 ——代理可以按需一点点把技能内容读进来，哪怕技能文件总体很大也无妨。这为企业将海量流程知识编码成技能提供了可行性，不必担心上下文窗口大小 。

举个实例：Claude开始处理用户请求时，系统提示里可能有“已安装技能：PDF处理（用于阅读和编辑PDF）、Excel处理、NDA审查…”等描述作为指引。如果用户问的是PDF相关任务，Claude的推理链会注意到有“PDF处理”技能描述吻合，于是执行一个“读文件pdf/SKILL.md”的动作。这相当于触发技能加载。Claude读入SKILL.md发现其中指示需要在填写PDF表单时参考forms.md，于是当用户任务涉及表单时，再触发读取forms.md 。否则如果任务仅是阅读PDF内容，那可能无需读forms.md。整个过程由模型自己决定调用何种“读文件”操作，没有硬编码流程。渐进披露保证了效率与灵活性的平衡：技能写作者可以在技能中附带尽可能详尽的指导，但模型不会不加分辨一次性吞下，而是像阅读指南一样按需索引章节。

3. 技能触发判断机制：“模型如何判断要不要使用Skill”是技能体系的关键一环。在Claude实现中，这主要基于两个方面：系统提示中技能的描述，以及模型的自主Chain-of-Thought推理。Claude启动时其系统提示已经包含了每个技能的name和简短description。当用户提出一个任务，模型在内部推理时会将这些描述与用户请求进行匹配。如果某个描述明显相关，模型就会倾向于使用那个技能。Anthropic官方也强调技能的name和description写得清晰准确非常重要，因为Claude据此决定是否触发技能。触发过程在技术上是通过工具调用实现的：Claude被赋予一个类似“文件系统读取”的工具（比如一个特殊的read_file函数或bash命令），技能内容存在于虚拟磁盘上。当Claude决策使用技能时，就调用如read_file(‘pdf/SKILL.md’)，工具执行后将文件内容注入模型上下文。这个调用在对话中有时是可见的（如Claude Code模式下，用户能看到Claude的“想法”里说正在读取技能）。OpenAI的ChatGPT则将其藏在“思考中”，但同样做了类似调用。简而言之，技能触发=模型识别相关→调用文件读取工具→加载技能指令。模型的识别靠提示和大模型自身理解，不需要开发者手工指定。如果出现模型没有及时用该用的技能或者用错技能，那需要改进技能的描述或内容，这属于技能工程调优范畴。

技能的上下文与作用范围：技能加载后，其内容被视为系统层或工具返回信息融入对话上下文。Claude官方示例显示，技能指令往往以系统消息形式加入，使模型将其视作必须遵循的指导。一旦加载，技能内容对当前会话后续几步都是可见有效的，直到任务完成或对话结束。Claude不会每一句都重复加载，除非对话任务改变需要别的技能或重置上下文。由于技能可能包含详细步骤和要求，它相当于临时接管了模型的行为模式，让模型在这个上下文中扮演技能作者设定的专业“工人”。比如PDF技能要求逐步渲染PDF检查格式，Claude加载后就严格执行这些步骤，宁可花上十分钟生成结果 。这说明技能一旦触发，对Agent行为影响是显著的，它提高了任务的一致性和可靠性，但也可能带来较长的执行时间（模型按照技能一步步来）。因此技能主要用于需要高质量严格流程的场景，而对时效要求超高的简单任务，Agent可能反而不触发繁重技能流程。

技能与代码执行：Claude技能框架的亮点之一是在技能中嵌入可执行代码。Claude具备一个安全受限的虚拟机环境，可以运行Python、JavaScript等代码。这使得技能可以将一部分工作交给代码完成。例如前述PDF技能包含extract_fields.py脚本用于PDF表单读取。Claude的做法是，在需要时通过内部的“运行Python脚本”工具来执行该文件，获取结果后再继续对话。这带来了两个好处：【1】效率：许多计算、格式转换等操作，代码执行比让LLM用纯文本推理快得多、准确得多。LLM生成token进行排序、分析图片等既慢又易错，不如用专门算法。通过脚本，Agent把这类工作外包出去，大幅提高执行效率和正确性。【2】确定性：LLM生成内容有随机性和不稳定，而代码执行是确定性的。同样输入下脚本产出的结果一致可靠。对关键任务（如财务计算、数据库查询）而言，这点尤为重要。Claude技能因此实现了大模型+传统编程的融合：模型负责理解任务和做高层决策，遇到明确可编程部分，就运行预置代码完成。这种模式让AI既具备学习能力又具有传统软件的可靠性。在技能作者层面，编写技能时需要考虑哪些部分交给代码、哪些由模型处理，并在SKILL.md中清楚指示模型何时“运行脚本”或“先读脚本内容再行动”。比如代码既可以作为一个工具直接执行，也可以当作静态知识让模型阅读（比如给出算法伪代码供模型参考）。Anthropic建议在技能中将代码既视作可执行工具，也视作文档，并在提示里明确模型该运行还是该阅读。这种双重属性很有趣：代码既提供了实际能力，又对模型起到提示规范作用（模型知道代码里实现的是哪个函数，就不会用错）。

Claude技能的优势与边界：相较传统仅靠Tool的代理，Claude的技能机制优势明显。首先是上下文扩展：借助渐进加载，技能突破了上下文长度限制，可随时访问几乎无限量的指令和知识 。工具调用只能返回即时结果，技能却相当于动态加入一整套知识库，让模型临时“学习”一门手艺。其次，复用性大增：技能写好后可应用于无限次任务，用户不必每次都提供复杂提示，减少人为提示工程成本。尤其对专业场景，封装技能后一致性和质量都有保障，避免模型在不同对话中前后不一致或漏掉步骤。再次，技能体系方便团队协作和分享：技能文件本质上是代码/文档，可以在开发者间共享、版本控制，甚至构建技能市场。这比隐含在模型权重或私有提示中的知识更易传播。最后，结合代码执行，Claude技能还能显著提升效率和可靠性，发挥符号算法与神经网络各自所长。

当然，Claude技能也有一些边界和挑战。其一，技能作用的发挥仍然高度依赖模型的正确“召回”和执行。如果技能描述不够清晰，模型可能不触发该技能，或者触发了却未严格遵循流程。这需要不断调优技能内容和模型习惯。其二，引入技能虽然提高结果质量，但也会增大响应时延。模型执行技能步骤繁琐时，会占用较多对话轮次甚至计算资源（如前述生成PDF耗时11分钟 ）。在追求实时性的场景，需要折中。其三，技能管理成为新问题：当技能库里的技能很多时，如何避免冲突（比如两个技能描述类似）？如何优先选择最合适的技能？如何避免模型“过度依赖”技能而丧失灵活性？这些都需要在实践中探索策略，比如给技能分类、引入技能选择策略网络等。其四，安全问题不可忽视：Anthropic指出不可信的技能可能含有恶意指令或代码，带来漏洞风险。因此部署时必须只安装可信来源的技能，并对技能内容进行审计。这类似于安装软件插件要防病毒一样，需要建立技能签名验证、沙箱限制等机制。Anthropic通过把Claude技能运行限制在沙盒VM、强调技能审核等方式来降低风险。总的来说，Claude的Agent Skills机制充分展示了技能体系的技术可行性和优越性，同时也提醒我们在使用中要注意良好治理和持续优化，以发挥技能的最大价值。

与 LangChain 的关系

LangChain是早期流行的LLM应用框架，它提供了链式调用、工具集成和Agent执行等功能。LangChain的经典Agent范式利用提示让LLM根据观测-思考-行动循环调用工具，实现任务。例如Zero-shot和ReAct Agent都是LangChain支持的模式。然而LangChain并没有原生的“技能”概念。它的Tool是由开发者预定义的API函数，Agent在运行时基于提示选择调用，并不具备动态加载复杂指令的机制。如果要在LangChain里实现类似技能的效果，需要手工将技能内容嵌入Prompt或作为文档存在然后通过工具检索，这相当麻烦。可以这样理解：LangChain偏重调用流程（Orchestration），Agent Skills偏重能力封装（Capability）。LangChain的核心是让开发者串联各模块，让模型按序完成任务；而技能的核心是提供模块本身的实现细节给模型使用。二者并不冲突，反而互补：LangChain可以作为技能触发和调度的上层框架。例如，我们可以用LangChain构建一个多步任务，其中某一步是调用“技能工具”让模型加载相应技能，然后继续流程。实际上，随着Anthropic开源技能规范，未来LangChain有可能内置支持技能标准，把技能当作特殊类型的Tool。目前已有开发者将Claude技能与LangChain集成实验，发现模型可以通过LangChain工具接口来读取技能文件，从而在LangChain环境下使用技能。这意味着LangChain已经能在一定程度上运用技能，只是没叫这个名字。不过LangChain自身的设计（以Chain和Agent为核心）决定了它在非常复杂流程时不够灵活，高度依赖预设逻辑。而技能提供的是细粒度知识，如何选择和组合多个技能完成任务，这可能超出LangChain原本的范畴，需要引入更多推理。综合而言，Agent Skills提供了LangChain未涉及的知识抽象层；两者结合可让Agent既有LangChain的流程控制又有技能的知识支撑，相辅相成。

OpenAI 视角：Skill 理念是如何被“隐式吸收”的？

OpenAI作为业界领军的AI公司，早期并未公开倡导“Agent Skills”概念，但从其产品演进来看，技能理念实际上被“隐性地”吸收融合了。我们可以从以下几方面分析：

OpenAI未直接提出Agent Skills的原因：OpenAI在2022-2023年的侧重点是快速将ChatGPT普及和丰富其功能。他们采用的是工具插件和模型升级两条路径：通过插件和函数调用扩展ChatGPT的外部能力，通过训练更强的GPT-4、GPT-5提高模型内部推理能力。在这样的路线下，引入一个显式“技能层”似乎并非当务之急。可能的考虑有：一方面，OpenAI倾向于端到端解决问题，崇尚“大模型足够聪明可以直接完成任务”，因此对增加中间层持谨慎态度（避免复杂度和不可控因素）。另一方面，OpenAI在2023年推出了ChatGPT Plugins平台，已让外界开发插件扩展ChatGPT能力，在他们视角，这类似于Alexa的技能生态，只不过插件更偏工具API，不涉及复杂流程文档。当时OpenAI或许认为有了插件就能满足大部分扩展需求。再者，从战略上，OpenAI可能不想跟在Anthropic之后宣传对方提出的概念，而更愿意用自己的术语框架来描述（例如他们称之为定制GPT、助手、插件等），以保持话语权。因此直到2025年Anthropic把技能规范开放并广获关注，OpenAI都没有正式发表关于“技能”的声明。然而，这并不代表OpenAI无视这一思路，反而他们选择了技术跟进、低调吸收的策略。

GPTs、Assistants、Tools、Memory是否构成隐式技能系统：可以说，OpenAI原先推出的一系列功能组合，实际上在不同程度上解决了技能层想要解决的问题，只是分散在各组件中。比如：
• Tools/Plugins：提供了模型调用外部操作的能力，相当于技能中的“工具脚本”部分。缺少的是如何使用这些工具的详细策略。OpenAI最初让模型通过提示学习使用插件，但复杂用法依然依赖开发者硬编码或Few-shot示例。这部分现在可以由技能文档来承担。因此插件机制是技能系统的一块拼图，但缺乏流程知识。
• Function Calling：OpenAI的函数调用API允许开发者给模型定义结构化调用契约，模型会在需要时输出JSON来调用函数。这实际上提供了技能触发的接口——技能可以被包装成若干函数，让模型调用。早期没有技能概念时，开发者已经用函数调用实现一些复杂任务（比如一步调用search函数，然后调用analyse函数等），但这些函数的调用顺序和逻辑需要模型自己摸索或通过示例学习，没有显式的指导文档。可以认为函数调用机制是技能的“钩子”，但函数不是技能本身，技能需要挂载在函数调用之上变成可执行序列。
• Custom GPTs / Assistants：OpenAI在2023年开放的让用户创建自己的GPT，本质是允许用户设定一个系统提示（所谓“Persona”）并配置一些相关工具插件，进而生成一个专用助手。这相当于提供每个特定任务一个定制的Agent实例。例如你可以创建一个“旅行规划GPT”，内置了一些旅游插件和提示。这个Custom GPT其实就是针对单一技能的定制代理：它始终以预先写好的指令来对话。所以说，OpenAI一开始走的是多Agent专才路线，而Anthropic走的是单Agent多技能路线。OpenAI的想法是用户可以根据场景生成不同GPT，各司其职。这与Anthropic提出的“一般助手 + 技能库”理念有所区别。但二者目标相似，都是为了解决通用模型在特定任务上的不足。OpenAI没有叫它技能，而是称之为GPT应用或者Assistant，实际上达到的效果类似“包装了一套技能的Agent”。只是OpenAI的方式需要用户切换不同GPT来获得不同能力，没有一个中心的大脑调度。
• Memory（长期记忆）：OpenAI通过对话历史和后来插件的方式，让ChatGPT有一定上下文记忆，甚至支持用户上传文档（相当于临时记忆知识）。Memory的作用是补充模型的语义信息，它解决的是知道内容的问题，而非知道怎么做的问题。OpenAI没直接提供“程序性记忆”接口，但一些第三方用向量数据库+ChatGPT做到了知识库检索。可以认为Memory系统是对技能的知识部分的补充，但不足以取代技能，因为流程/策略类知识Memory无法有效表达（大模型拿到一堆文本知识，不代表会按正确顺序用它们）。

OpenAI路线与Anthropic差异：工程选择还是战略选择？ 回顾两家公司路径的差异，可以看到既有工程实现层面的取舍，也有产品战略上的考量：

工程上，Anthropic选择构建一个开放的、文件系统式的技能机制，这需要在模型中嵌入解释执行文档和代码的能力。Claude本身就是为长上下文和可控生成优化的模型，适合承载这种复杂链式推理。OpenAI的GPT-4/5也有强大的推理能力，但他们早期更强调通过预训练知识解决问题，工具使用也是靠提示形式。可以说，Anthropic更加“编程范”一些，把AI视为可编程agent去开发；OpenAI更“模型范”一些，相信大模型的泛化能力尽可能cover需求。这是工程哲学的差别。但随着实践证明在有限窗口内难以cover全部流程，OpenAI也转向引入可编程元素（函数、工具）。所以工程上双方正在趋同，都承认LLM+程序**的混合模式效果更好。

战略上，Anthropic采取了开放生态战略，把技能规范拿出来送给行业采纳，希望以标准制定者身份获得长远优势。这种战略类似以前的技术标准之争：开放标准一旦普及，制定者往往能左右生态。OpenAI起初则更封闭，所有功能都围绕自己的Closed API和付费服务，不强调与外部系统的标准衔接（早期插件也是自己定义接口）。OpenAI没主动提出技能概念，部分原因可能是不想削弱自家模型的中心地位——如果过分强调技能的重要性，用户可能会认为模型本身不够用，需要人类知识补充，这是OpenAI不太希望的认知。相比之下Anthropic更务实地指出大模型通用但欠专业，需要人类分享流程知识进来。这背后也反映出两家公司定位不同：OpenAI瞄准的是通用人工智能平台，Anthropic更侧重企业解决方案。企业用户天然希望自定义AI行为、保护和利用自己的知识，而Anthropic投其所好，通过技能满足这些需求；OpenAI则更多面向开发者和消费者市场，一开始着力打造统一的ChatGPT体验，对用户自定义细节控制兴趣不大。然而，OpenAI后来也看到企业市场的重要性（发布了ChatGPT Enterprise、Azure OpenAI等），开始在策略上向Anthropic方式靠拢，例如推出ChatGPT企业版的扩展能力和Assistant API（一种可以编排对话流的开发接口）等。这些都体现OpenAI在战略上调整，从“一款通用助手打天下”转向“给用户/企业更多定制能力”。因此，本质上OpenAI与Anthropic在Agent技能问题上的差异，最初是战略定位不同导致的工程选择有异，但随着市场驱动，现在两条路线正在收敛。

应用层：今天应该如何应用 Agent Skills？（How）

工程实践建议

Agent Skills概念虽新，但已经能够在多种应用场景中落地，为开发者提供提升Agent能力和可靠性的工具。下面分别针对几类典型场景，给出应用技能体系的实践建议：

（1）执行型 Agent（自动化任务代理，如本地电脑助理、电话机器人等）：这类Agent需要在现实世界或操作系统中执行具体操作、完成人类委派的任务。应用技能的核心思路是将各种常见操作流程编排成技能，使Agent具备模拟用户操作的“技能库”。实践建议：
• 操作宏技能：将用户在电脑/手机上的繁琐操作录制或编写成技能。例如“文件备份技能”（包含检查磁盘->压缩文件->上传云盘的步骤和shell脚本）、“软件安装技能”（包含搜索软件下载->执行安装命令->配置环境变量的流程）等。这种技能本质和传统RPA（机器人流程自动化）的宏很像，但由LLM执行意味着更灵活。通过预装这些技能，Phone Agent或电脑助手在接到“帮我安装XX软件”这样的请求时，就能触发相应技能，有条不紊地完成每一步，而不需要每次都即时推理如何操作电脑。
• 多步骤事务技能：对于电话机器人，典型任务如“预订餐厅”“客户身份验证”“电话调研”等都有固定话术和流程。可将这些流程写成技能：包含话术模板、分支逻辑（如客户不同回答走不同路径）等。机器人触发技能后，按照其中脚本与用户通话，大大提高一致性。技能还能附带调用外部API（通过MCP连接）执行查库存、下订单等操作。因此建议梳理目标领域常见电话业务，将其SOP全部转为技能，代理就能胜任不同话务任务而无需重新训练模型。
• 环境接口技能：执行型Agent往往需要跟底层系统交互，如操作文件系统、调用OS命令、调用应用API等。可为这些交互设计技能，让Agent知道如何安全正确地使用环境接口。例如“邮件发送技能”：包含调用邮件客户端API发送邮件的代码，和如何格式化邮件内容的指导；“系统信息查询技能”：包含用shell命令获取CPU、内存状态的脚本等。这样Agent不会直接在对话中胡乱尝试危险命令，而是通过技能里审核过的脚本来执行，既简化模型推理，也提高安全性。开发者应针对操作系统和常用应用，编写一系列低级操作技能，赋予Agent可靠的“手脚”。
• 监控与纠错技能：让执行Agent长期运行，还需考虑其健壮性。可以开发一些元技能，用于监控和自我纠错。例如“错误处理技能”：当Agent检测到执行命令出错时，触发该技能，指导它按错误类型采取措施（如权限错误时尝试提升权限，网络错误时重试连接等）。又如“状态保存技能”：设定Agent定时保存当前任务进度到文件，或崩溃重启时从文件恢复。这些技能提升Agent连续执行任务的可靠度。工程上，可以将其写成守护性技能，每隔一段时间主动触发或在异常时自动调用。

（2）企业内部 Agent（处理企业流程、合规审查、知识问答等）：企业场景需要Agent符合业务规则、对接内部系统和知识库。Agent Skills在这里大有用武之地：
• 流程性技能：企业内部有大量明确流程，例如“员工入职办理”“报销审批流程”“技术支持工单处理”等。将这些SOP写入技能，Agent便可按标准执行。例如“入职办理技能”指导Agent按顺序收集新员工信息、创建账户、发送欢迎邮件；“报销审批技能”指导Agent检查发票、核对政策、记录审批结果等。这些技能可以附带对接内部系统的代码（通过MCP接口访问HR系统、财务系统），实现端到端流程自动化。相较人工，Agent按照技能流程处理可减少疏漏，提高效率。
• 合规/政策技能：企业对AI输出的合规性很重视。可以开发政策检查技能，内含公司规范和监管要求清单。当Agent生成内容后，自动触发此技能比对其中有无违规要素，并根据规则决定是否需修改或警示。例如一个“GDPR合规技能”详细列出隐私信息处理要求，Agent在发送客户数据前使用该技能自检，发现违规则采取预定动作（如匿名化数据或请求人工复核）。这种技能使AI行为可控、可解释，符合企业治理需要。类似地，还有“品牌风格技能”“法律审阅技能”等，确保AI产出符合企业调性和法律要求。
• 知识类技能：企业内部知识丰富，但常常分散于文档、wiki等处。虽然RAG（检索增强）可以让Agent查询知识库，但如何运用这些知识依然需要指导。例如，“故障诊断技能”包含公司产品常见故障排查步骤和要点，Agent结合实时检索信息，就能系统地指导解决问题，而不会遗漏关键检查步骤。再如“财务分析报告技能”内含财报分析框架、指标解释方法，Agent拿到具体数据后，可按照技能模版逐章分析，保证报告结构专业全面。这种技能实质上把隐性经验显性化：资深员工总结的套路，固化为AI的行为规范。建议企业鼓励各部门专家参与编写技能，把重要领域的know-how移植给Agent，从而在新人/AI助手执行任务时也能达到专家水准。
• 中央管控与权限：在企业应用中，还应考虑通过技能实现权限管理和中央配置。例如，不同部门的Agent可能允许使用不同技能，对此可以用技能清单配置来控制Agent加载哪些技能。企业可有一套“技能目录服务”或配置文件，Agent启动时只加载被授权的技能。这样也避免了某些敏感技能（如能提取敏感数据的脚本）被无关Agent滥用。Anthropic企业版已支持集中部署技能库并分配给员工使用。在实践中，可将技能按部门/功能分类存储，Agent通过传入的身份标签决定加载对应技能子集，达到按需授权的效果。

（3）长期运行 Agent（具备长时状态、持续学习的自治代理）：这类Agent强调在一个连续环境或长期任务中持续工作，有记忆和状态的积累。应用Agent Skills可以帮助长期Agent更好地管理状态和改进自身：
• 状态管理技能：当Agent需要维护内在状态（如任务列表、知识库），可开发技能辅助。例如“记忆归纳技能”：指导Agent定期总结近期对话要点写入长期记忆（如日志文件或向量库），以免上下文窗口溢出；“状态检查技能”：包含一系列自检项目（有哪些任务未完成？是否遗漏用户要求？），Agent定期运行确保自己状态一致。这些技能相当于Agent的元认知工具，帮助其在长时间运行中保持有序和自省。开发者可以将这些技能设置为定时触发或在每轮对话开始前后自动触发，让Agent形成良性循环。例如Stanford的Generative Agents研究中，模拟角色定期反思总结，实际上就可视为一种自我技能。
• 持续学习技能：让Agent学会从经验中提炼新技能是令人期待的方向。虽然目前完全自动生成技能仍在研究中，但已有初步实践。例如Claude的指南建议与AI一起迭代技能：在任务完成后，询问Claude哪些部分可以提炼成技能、哪些错误要避免。开发者可以半自动地据此创建新技能或更新技能内容。对于长期运行Agent，可以引入“技能提炼技能”这种元技能：当Agent完成一个任务且判断这个任务模式会重现时，它触发该技能，总结刚才用到的知识和步骤，生成一个技能草案供开发者审核。这样Agent本身就参与了技能库的演进，渐渐变成终身学习型。工程上，这种持续学习技能需要较强的prompt设计，引导模型客观审视自己的过程，并以Skill.md格式输出建议。这属于前沿探索领域，但值得尝试在非关键场景下让Agent积累自己的技能仓库。
• 成本与效能平衡技能：长期运行Agent往往要考虑资源消耗和效率。可以设计一些技能帮助Agent权衡取舍。例如“算力开销评估技能”：列出各种行动（调用大型模型、搜索网络、运行本地算法）的时间和费用估算，Agent在决定策略时调用此技能对比选项成本，从而选择最优路线（比如简单算术就别调用大模型算了，自己写个公式计算）。再如“结果可信度评估技能”：让Agent根据执行结果进行信心评估，低于某阈值时重试或请求人类帮助。这些技能赋予Agent一定的理性元分析能力，避免其傻傻一直尝试错误路径或者浪费计算资源。虽然模型本身不擅长精确算计，但通过技能编码一些已知的成本数据和checklist，可以弥补模型在长期规划上的短视。开发者在构建长期Agent时，应加入此类技能，提升Agent在漫长自主运行中的理性与稳健。
• 安全停止技能：一个长期自治Agent需要明确何时终止或交还控制，以免失控。可以设置“停止条件检测技能”，列出任务完成标志或者环境触发的停止信号，Agent定期检查。一旦满足条件，就执行“安全关停技能”：保存状态、记录日志，然后正常结束进程。这防止了Agent陷入无限循环或资源耗尽导致崩溃。虽然这更像是系统层保护，但通过技能由AI自身监控更灵活，可应对复杂业务完成判定。例如爬虫Agent可能不停发现新页面，通过技能可以限定抓取深度或时间，到点就收尾。

设计建议

引入Agent Skills后，如何合理设计技能本身，也是开发者必须考虑的问题。以下提供一些技能设计层面的建议：
• 何时值得“技能化”：并不是所有问题都需要包装成技能。一般来说，当某项任务具有以下特征时，值得将其技能化：1）高复杂度或多步骤：任务需要严格按步骤完成且步骤较多，人类有明确方法论的，比如报税、合同审查等。2）高复用性：该任务会反复出现，或对多个Agent都适用，如格式转换、报告生成这样的需求。3）高专业性：任务涉及专业知识/规范，纯靠大模型常出错或不一致，例如医疗问诊流程、法律文书撰写。4）高可靠性要求：出错代价高的场景，如财务计算、医疗建议，需要确保操作万无一失，可以通过技能详述检查点降低出错概率。如果任务不复杂、一次性或模型已能很好完成，则无需额外技能，直接让模型自由发挥反而更简单。所以技能化前要进行成本效益评估：编写和维护技能有开销，只有预期能提升结果质量或节省长远成本时才去做。可以采用“小步试验”——发现模型某任务表现不佳后，先尝试一次对话内提供更详细指示；如果有效且任务常见，再抽取这些指示做成技能文件。这样按需逐步增加技能，避免过度工程。
• 技能粒度的控制：技能应该拆分到什么细粒度，是设计成关键。粒度太粗，技能内涵盖多个异质子任务，反而难以重用；粒度太细，又会导致技能数量膨胀、管理困难。经验上，可按照功能语义聚合来决定粒度：每个技能尽量围绕一个明确的用户任务或能力领域，并能在相对独立情境下执行完毕。例如，将“撰写会议纪要”作为一个完整技能，而不要把“听写对话内容”和“摘要提炼”拆成两个技能，让Agent中途切换（这中间信息衔接复杂，不如在一个技能内完成）。但对于完全不同的任务，即使步骤类似也建议做不同技能，以便描述精准，比如“生成财务报告”和“生成学术论文”就该分开技能，即使都涉及写长文，因为规范差异大。一个技能的长度方面，如果SKILL.md正文超过几千token，说明可能涵盖太多内容，可以考虑拆分子文件或拆技能。Anthropic的推荐是当SKILL.md变得“难以管理”时，就应拆分。可以用主题划分或场景划分。例如PDF技能把表单填写单独放forms.md就是一种粒度优化 。另外在技能描述中可引用已有技能，表示依赖关系。总之，遵循高内聚低耦合原则：技能内部内容高度相关，每个技能尽量自成一体解决一个问题，避免过多互相依赖。这样Agent选择技能才更准确，技能库也易维护。
• 技能的状态、情感与成本设计：传统软件模块可以有内部状态，Agent技能一般默认是无状态的静态指导。但是否要让技能具备状态或情感呢？这取决于应用需求。多数情况下，技能文件应写成泛化的模板，不存储对话中变化的信息，把状态交给Agent记忆或上下文。但是在某些长期流程中，可以让技能与外部文件配合，达到存状态目的。例如在技能里指导Agent“将中间结果记录到logs.txt”，Agent照做后再从logs.txt读取，这样状态就保存下来了。所以技能本身可以设计一些占位来和Agent交互状态。情感方面，如果某技能专门用于情感交互（如安慰用户的技能），那么技能内容可以是带情绪色彩的指令，例如语气上使用安抚词汇等。情感本质上还是通过语言内容来体现的，技能正好能提供一致的语言风格。因此不妨在技能编写时注重语气和风格要符合预期的人设或场景，这样Agent执行技能时就天然带上了该情感。至于成本模型，目前技能规范并没有硬性成本度量，但设计上可以人为加入提示，例如在技能描述里注明“此流程预期耗时较长”或者“调用某外部API会产生费用”，以提醒模型谨慎。真正让Agent量化比较成本还需要配合外部机制（比如前述成本评估技能或外部监控）。在技术负责人层面，可以建立技能分类标签，比如给每个技能标注其需要的资源（网络、GPU）、大致耗时、重要等级等，模型可能不直接理解数字成本，但可以根据标签“慢”“快”“危险”等作一定判断。未来技能标准或许会扩展这些元数据，但当下可以通过技能描述或配套文档传递这类信息给Agent。
• 技能的评估、升级与淘汰：技能库不是一劳永逸的，需持续治理。评估方面，建议建立一个技能效果评价体系。可对每个技能设计一组典型测试用例，让Agent调用技能完成，看成功率和质量如何。比如对“代码生成技能”，用几组任务考察代码正确率；对“审阅技能”，看是否发现预埋的合规违规点。这种离线评估可以每次修改技能或模型版本时跑一次，确保技能有效性。也可以收集线上使用日志，分析模型在什么情况下未触发技能或使用技能失败，从而改进技能描述或内容。升级方面，当业务流程改变或有更好方法时，要及时更新技能。技能应当版本化管理，可以用Git等对技能文件做版本控制。升级技能需注意向后兼容或同步更新依赖的其它技能。比如如果更新了公司政策，那么涉及此政策的多个技能都要同步修改。建立技能的维护人制度也是好做法，即每个技能指定责任人定期检查内容准确性。淘汰方面，如果某技能长期不再使用或已被更优技能覆盖，应考虑移除以免干扰模型决策。可以通过监控调用频次发现“僵尸技能”。淘汰技能时要确保模型系统提示不再包含它，以免模型把过期技能当选项。这也提示我们，不宜无节制添加技能，定期梳理很重要。如果担心日后需要，可将淘汰技能转存归档，不在生产环境加载。总而言之，把技能库当成类似代码库来治理——持续集成（测试）、持续部署（发布更新）、版本控制、文档和责任人。唯有这样才能保证Agent Skills系统随时间推移依然可靠，避免技能变成陈旧手册拖累AI表现。