Anthropic 于 2026 年 10 月 22 日宣布，将 Agent Skills 捐赠给 Linux 基金会旗下的智能体人工智能基金会 AAIF。此次移交包括项目名称、标识、GitHub 组织和官方域名，后续维护将由来自多家企业的工程师共同参与。
Agent Skills 的目标，是把一类工作的操作方法保存成 AI 执行任务时能够读取的文件。团队可以把步骤、模板、参考资料和必要脚本整理成技能包，运行工具再按任务加载相关内容。原本需要用户反复解释的要求，也因此有了可保存、可修改、可重复调用的形式。
把工作方法整理成技能包
文章以编辑团队为例说明这一机制：如果团队每周都要完成资料检索、文章写作、配图和审稿，且已经形成固定的标题习惯、图表字号、资料核验办法和交付目录，那么每次在对话里重复输入这些要求，不仅耗时，也容易遗漏。
在 Agent Skills 规范下，团队可以把这些要求整理成一个技能包。包内包含一份核心说明，告诉 AI 何时使用这套流程、先读哪些材料、按什么顺序完成工作；同时还可以附上版式模板、检查清单和处理文件的小程序。之后遇到同类任务，AI 就可以沿着既有方法推进。
这份核心说明在规范中被命名为 SKILL.md。文件首先写明技能名称和用途描述，后面再用普通文字记录操作方法。若需要更多材料，还可以另外保存参考文件、脚本和素材，并在说明中指向它们。这样一来，编辑能读懂流程内容，开发人员也可以继续补充自动处理部分。
这种组织方式的价值，在于把原本隐性的经验写清楚。比如「图表要适合手机阅读」这样的要求较为笼统，若进一步细化为最小字号、每张图的信息量、预览尺寸和检查方法，执行时更容易得到一致结果。技能包是否真正好用，很大程度上取决于这些经验能否被整理成可操作的要求。
文章还提到，技能包中应保留任务的结束条件。以编辑流程为例，正文达到约定长度、来源能够追溯、图片已经插入并完成预览后，才进入审稿。这样一来，AI 可以检查自己的交付是否完整，用户也能按同一标准验收，减少「看起来已经做完」与实际可用之间的差距。
如果团队在使用过程中发现新的错误，也可以回到同一份技能包中修改。下周继续执行时，改进后的方法仍然保留。对于反复发生的业务，这种持续修订比每次临时提醒更容易积累效果。
技能还可以附带一个已经通过验收的示例，例如一份排版完整的报告，并注明正文、图片和来源文件分别对应什么位置。AI 执行时有具体参照，人工审查时也更容易发现输出偏离发生在哪一步。文章同时提醒，示例中的客户信息和过期事实需要提前处理，只保留值得复用的方法与结构。
AI 如何找到合适的技能
随着技能数量增加，新的问题也会出现：如果每次任务都把全部说明交给模型，会占用大量上下文，也会让无关要求干扰当前工作。Agent Skills 采用分层读取的思路，先让 AI 看到技能名称和用途，在匹配任务后再加载完整说明，必要时继续读取相关文件。
例如，用户只要求「整理合同中尚未解决的修改意见」，AI 可以先识别合同审阅技能，而不必同时读取做封面、统计流量或整理票据的全部规则。等到实际处理合同，再按说明打开对应模板和条款清单。
这里的关键，在于用途描述是否足够清楚。文章举例称，「处理文件」覆盖范围太大，而「整理已有合同的修订意见并生成待确认清单」则更容易确定使用场景。对于大型团队，技能库维护还包括合并重复技能、清理失效步骤，以及说明相邻流程如何分工。
参考资料也需要拆分。常用要求放在主说明中，篇幅较长的法条、客户模板或技术文档则按需读取。这样既能减少模型在大量材料之间来回寻找的时间，也便于更新某一部分内容，而不必把整套流程重新复制一遍。
如果流程需要执行脚本，还要确认运行环境是否具备相应工具。比如，一个技能要求把表格转换为图表，实际执行仍需要可用的数据处理程序、字体和输出位置。技能包描述的是方法，平台负责提供执行条件，二者需要在使用前接好。
文章认为，跨平台迁移更适合从一小组真实任务开始测试。同一份技能换到另一套 AI 工具后，文件路径、可用接口、审批方式和输出格式都可能变化。只有把这些差异记录下来，团队才能逐步形成真正可复用的技能库。
项目移交后，规则由谁维护
Agent Skills 最初来自 Anthropic 的产品实践，2025 年 10 月推出，并于同年 12 月发布为开放标准。Anthropic 在此次公告中称，已有超过 70 个智能体平台支持这一格式。文章同时指出，这一数字反映的是厂商公布的生态接入情况，实际使用效果仍需结合具体任务观察。
随着参与者增多，格式修改会影响更多团队。一个字段如何解释，新版本是否兼容旧技能，平台能否增加自己的扩展，都可能影响企业已经积累的工作流程。项目移交 AAIF 后，这些问题有了共同讨论和维护的组织基础。
Anthropic 公布的安排显示，后续将由多家公司的工程师以个人身份参与维护，David Soria Parra 和 Mahesh Murag 担任首席维护者。使用标准或提交贡献，无需先成为基金会会员。项目后续方向还包括版本发布、正式提案流程和安全指引。
对于企业用户，文章特别提到版本管理的重要性。一个经过团队确认的技能，应当能够说明自己依赖哪一版规范、哪一版模板和哪些工具。更新后如果出现问题，也应有办法回到此前正常工作的版本，而不是依靠聊天记录拼凑旧要求。
对于平台开发者，共同维护有助于减少重复设计。不同平台可以围绕同一种文件结构提供加载、验证和管理工具，再在各自产品体验上继续改进。企业已有的流程资料也更容易被保留下来，迁移成本则主要集中在环境适配和结果验证上。
文章还提到，标准治理的效果最终会体现在日常维护中，包括问题由谁受理、变更如何讨论、安全缺陷如何通报、旧版本保留多久等。随着路线图落地，企业也可以据此调整内部技能的更新频率和审批方式。
Agent Skills 与 MCP 的分工
在智能体基础设施中，另一个经常被提到的名称是 MCP，即模型上下文协议。文章指出，MCP 主要帮助 AI 应用连接外部工具和资料来源；Agent Skills 更适合保存完成某类工作的步骤与经验，两者可以在同一项任务中配合使用。
仍以编辑工作为例，AI 可以通过连接工具读取资料库中的文章，再通过技能了解哪些来源优先、怎样记录核验结果、什么时候进入写作。前者提供可访问的内容和操作，后者组织任务的执行方法。
这种分工也适用于客户服务场景。工具负责查询订单、读取物流状态、创建工单；技能则说明遇到不同问题时先查什么、如何判断处理路径、哪些请求需要人工接手。企业可以分别更新系统接口和服务规则，而不必让每次流程调整都变成一次软件开发。
在法律工作中，技能可以保存合同审查顺序、条款分类和意见输出格式。执行时仍需读取当前合同、适用法律与客户需求。文章强调，团队需要把稳定的方法与每次变化的事实分开管理，避免把上一个项目的具体结论带入新的事项。
这一点也关系到知识更新。适用日期、地区和文件版本，应当随参考资料一起保存。政策改变后，维护者可以替换对应文件，并检查哪些技能引用了它。对于监管研究和法律服务团队，这比单纯堆积大量文档更容易控制错误传播。
技能库还有一个组织层面的用途：让新人看到熟练员工如何完成工作。很多流程过去只存在于个人经验中，交接时只能口头说明。整理技能的过程，会促使团队把容易出错的环节、例外情况和验收方法写下来，供人和 AI 共同使用。
引入外部技能时的权限与安全问题
文章指出，技能包中既可能有普通说明，也可能包含脚本、外部链接和调用工具的要求。一旦被 AI 选中，就可能影响文件读取、数据传输和实际操作。因此，企业引入外部技能时，需要同时检查内容来源与运行权限。
例如，一个看似用于整理发票的技能，可能要求访问整个文档目录；一个用于生成报告的脚本，可能连接外部服务器。审核人员需要知道这些访问与任务之间的关系，是否可以缩小范围，以及执行记录保存在哪里。把权限限制在实际需要的文件和工具上，可以降低错误操作带来的影响。
文章援引 OWASP 在提示词注入风险指引中的讨论称，AI 在读取网页、文档或其他材料时，可能遇到夹带的操作指令。如果这些内容被当成可信要求执行，模型就可能偏离用户原本交代的任务。
技能使用同样会接触这类问题。团队既要检查技能本身，也要让运行环境区分工作要求与外部资料。付款、发邮件、修改生产系统等操作，应设置适当的人工审核；文件和网络权限则应由实际运行系统控制，而不是只靠一段文字维持边界。
文章还提到，当前规范中的 allowed-tools 字段仍被标为实验性内容，其支持方式取决于具体平台。因此，企业可以在技能说明中列出所需工具，同时到平台权限设置里核对真实可用范围，再通过测试观察工具调用记录，确认执行过程与设计一致。
引入外部技能时，使用许可也需要单独查看。规范允许作者填写 license 字段或指向许可文件，但这一字段并非必填。团队应确认代码、模板和随包资料分别允许怎样使用，并保存许可证及对应版本；缺少许可说明的部分，则应先联系作者确认，再纳入内部流程。
外部技能更新也应留有记录。团队可以先固定使用已经检查的版本，再定期评估更新内容。若某个技能突然新增联网动作、依赖新的程序或要求更大权限，维护者就有机会在上线前理解变化，而不必等到出现异常后追查。
对于客户资料较多的机构，还需要检查技能中的模板和示例是否包含保密内容。将内部经验整理为公开技能时，具体客户名称、合同片段和身份信息应当经过处理。公开流程与内部资料可以分别保存，减少误传整份项目文件的机会。
企业如何开始建立技能库
文章建议，企业可以先从频繁、边界清楚、交付容易检查的任务开始建立技能库，例如整理周报、归档合同意见、生成会议待办，或按固定格式准备文章审稿包。团队先把现有做法写清楚，再让 AI 执行几轮，通常比一开始追求完整覆盖全部业务更容易发现问题。
准备材料时，可以从最近一次成功交付倒推：输入是什么，工作人员查过哪些资料，完成了哪些步骤，最后怎样判断结果可以交付。把真实流程整理出来后，再补上出错时的处理办法，技能就有了较可靠的起点。
测试材料也应包含常见例外情况，例如合同缺页、来源链接失效、表格字段不一致、图片没有授权记录。这些情况会直接影响交付。团队需要观察 AI 能否发现缺口、保留已有成果并说明下一步，而不是在条件不足时继续生成一份看似完整的文件。
评估可以围绕实际工作量展开：完成同一任务需要多少人工补充，哪些错误重复出现，交付文件是否齐全，修改后能否稳定改善。保存少量有代表性的任务与结果后，就可以在技能或模型更新时重新执行，判断新的组合是否仍适合业务。
维护责任也需要明确。谁可以修改步骤，谁核对法律或业务依据，谁决定新版本何时投入使用，都应有固定安排。涉及多个部门的技能，可以保留共同审阅记录；只用于个人整理的技能，则可以采用更轻便的管理方式。
团队还可以约定一个简单的修改记录格式：本轮出现了什么问题，修改了哪一步，用什么任务验证。这样，新增要求背后的原因可以被后来接手的人理解。长期没有使用、与其他技能重复或依赖已经停用工具的内容，也能在定期检查时清理，避免技能库越积越大，执行反而越来越慢。
当同一技能服务多个客户时，文章建议将通用步骤与客户偏好分别保存。通用部分规定怎样核验和交付，客户部分记录名称、格式和特定审批要求。新项目开始时只加载相应客户资料，更新公共流程时再检查它对现有项目的影响。这种安排有助于保持方法一致，也能降低误用其他客户资料的机会。
一轮测试通过后，维护者可以把技能版本、模板版本、验收样例和已知限制一并保存。下次更新模型或工具时，先重跑这组样例，检查文件是否齐全、权限是否合适、关键核验步骤是否执行。若出现差异，也更容易定位需要调整的环节，并保留一个可回退的稳定版本。
文章附带说明
原文最后注明，全文仅用于法律、政策及行业研究交流，旨在对数字金融、稳定币、数字资产及相关监管动态进行客观分析，不构成投资建议、法律意见、税务意见或其他专业建议，也不构成任何金融产品、数字资产或商业项目的推荐、宣传或招揽。
原文同时提示，文中涉及的监管规则、市场数据及机构信息主要来源于公开资料，可能因法律法规、监管政策、市场环境及项目进展变化而发生调整，读者应结合最新公开信息独立判断，并遵守所在国家或地区适用的法律法规。作者及发布平台不对任何因依赖本文内容所产生的投资、交易或其他商业决策承担责任。
文末免责声明写道：「市场有风险，投资需谨慎。本文不构成投资建议，用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资，责任自负。」
