Agent Skills 捐给 AAIF 之后：公司的工作方法，能不能跟着团队走？

概念插图：工作方法可以整理与传递，环境和访问钥匙需要分别准备。

假如你们已经把客户上线资料的检查交给了 AI：先看清单，再查附件，缺什么就列出来，有矛盾就保留两边的记录。一开始调了好几轮，现在终于用得顺手。

过一阵，团队想换个 Agent 环境。你把原来的要求复制过去，它却找不到脚本，打不开附件，连“检查通过”的含义都和之前不太一样。那些花时间磨出来的方法，还得重新讲。

Anthropic 在 2026 年 10 月 22 日宣布将 Agent Skills 标准捐给 AAIF。这件事让一个问题变得更值得讨论：团队教会 AI 的工作方法，怎样才能在换工具、换同事之后继续用？

开放格式让这些方法有了更容易保存和分享的形式。至于换个环境能不能照常工作，还得看看方法里究竟依赖了什么。

先翻开一份已经在用的方法

还是拿客户上线资料检查举例。它可能包含这样的约定：合同和开票信息都要齐；合同日期和客户清单不一致时，先列出差异；少了内部负责人，就放进待确认项。

这些规则换个地方依然有用。但“到这个文件夹找附件”“调用那个脚本”就未必。新环境里的文件路径可能不同，工具名称也可能变了。原来的客户账号，更不会因为复制了一份说明就自动连上。

整理时，可以分开看：

Skill 文件夹可以装 SKILL.md、脚本和参考材料。密码、原始 Token 和真实客户附件就另当别论，不要为了省事一起塞进去。下一位同事需要知道怎样取得合适的访问权限，而不需要拿到你打包的账号密钥。

把“我们一直这么做”再多解释一句

一份方法最难带走的，往往是大家已经习惯、所以懒得再写的部分。

比如“核对合同日期”，到底是核对签署日期，还是服务开始日期？发现不一致，是直接判失败，还是交给负责人确认？如果这些只存在于某一段旧对话里，接手的人和新的 Agent 都很难猜对。

你可以从上次返工的地方往回找。为什么那次报告退回来了？是少了附件名称，还是把客户希望的日期当成了合同日期？把这条判断写进方法，再留一个对应例子，通常比多加一句“请仔细检查”更有帮助。

Leina 支持把跑通的方法保存为 Skill，并通过已授权 Apps 做事。在 Skills 目录中选现成方法时，也可以带着这些问题去读：它检查的是什么，依赖哪些 Apps，遇到缺项会怎样处理，是否符合你们的实际做法。

flowchart TB
  accTitle: 迁移方法，不复制账号权限
  accDescr: 方法包和脱敏样本进入目标环境，重新准备工具与授权，验证输出后才用于真实任务。
  A("方法与脱敏样本"):::resource --> B("目标 Agent 环境"):::agent
  B --> C("重配工具与依赖"):::gateway
  B --> D("单独配置账号授权"):::restricted
  C --> E("对照样本验证"):::gateway
  D --> E
  E --> F("检查通过后运行真实任务"):::resource

一起带走几份用来试手的材料

除了说明，最好再留几份脱敏样本。不必多：一份材料齐全，一份少了必需附件，一份日期冲突，再来一份编号重复的。

每份旁边记下你期望看到什么。少附件的那份，应该点名缺了哪一件；日期冲突的那份，两处记录都得留下；编号重复时，不能悄悄用后一条盖掉前一条。

换了模型，报告的措辞和排版有点不同很正常。你真正想确认的是，这些会影响后续工作的判断有没有保住。

也别只挑工具运行顺利的情况。给它一条读不到的链接，或者用没有写入权限的账号试一次，看看它能否说清卡在哪里。这样第一次处理真实客户材料时，大家不会对“完成了”三个字有不同理解。样本经过脱敏即可，不用把客户资料公开出去。

到 Leina 里，先跑一次小范围检查

可以先把现有 Skill 和样本交给 Leina，让它帮你看看哪些部分还能直接用：

看看这份客户上线资料 Skill。先列一下要用的 Apps、操作、脚本和本地路径，暂时别读真实客户资料，也别改业务记录。用我提供的脱敏样本试一遍，对照旁边写的预期结果。告诉我哪些方法可以接着用，哪些工具步骤需要改，哪些账号还没授权。再一起确定第一次正式处理的范围。

安装和配置要按目标环境的说明来。特别是用到了 CLI、专用插件、外部 Python 包的 Skill，可能需要先准备依赖，或者换一种工具完成同一个步骤，不能指望复制文件之后每个环境都原样运行。

账号接好后，可以先读取一小批真实资料，看看样本里没碰到的问题会不会出现。等这一步顺了，再安排写回表格或发送消息，并说清目标位置和需要确认的内容。

下次有人改它时，留一点来龙去脉

一份 Skill 用久了，总会改。客户清单新增一列，某个 App 换了操作，原来的脚本也可能升级。过几个月再回头看，最好能知道：当时为什么这样改，谁确认过，哪些样本重新试过。

这些记录放在团队文档或版本库里就行。给方法留个维护者，写上版本说明和最近一次验证日期，出了问题至少找得到人，也找得到上一次还能正常工作的状态。

你们已经跑顺的那套客户资料检查，就很适合先整理一份。等另一位同事在新环境里拿到说明、接好自己的账号，用那几份样本跑出了预期结果，再回来处理真实客户时，之前花过的功夫才算真正留了下来。