GitHub开发者倡导者Andrea Griffiths：构建跨客户端可移植Agent技能的三层分离法

你本周有多少次向同一个Agent重新解释同一件事？又有多少次不得不去问一位掌握深厚机构知识的同事，才能解决某个具体问题？GitHub开发者倡导者Andrea Griffiths在2026年11月12日发布的这篇实践指南中，把这种重复劳动视为Agent技能要解决的核心痛点：上下文不该消失在聊天记录里，也不该锁在一个人的脑子里。

一个Agent技能是一个以SKILL.md文件为中心的版本化目录，描述何时以及如何完成一项可重复的任务。Griffiths强调一个关键边界：技能描述的是做事的指令，不是做事的权限。一个技能可以描述如何查询数据库，但它不会授予对该数据库的访问权。工具、凭证和权限仍然由运行技能的那个宿主环境提供。这意味着技能本身是可移植的，但移植不等于即插即用——目标环境必须已经具备技能所假设的工具和访问条件。

有了这个边界，Griffiths给出了让技能真正跨项目、跨团队复用的核心方法：把项目配置从技能指令中分离出来。在Data Forge的support-desk管道示例中，forge-init技能首先探查源表和命名约定，把发现的项目细节写入一个resolved manifest；后续技能读取这个manifest获取它们所需的项目上下文，而不是各自重新猜测或把具体名称硬编码进指令。manifest描述项目名、指标存储和平台引擎，技能描述做事的规则和标准。一个在仓库中发现的模式不自动等于应当保留的规则，所以发现的细节必须可审查，由人确认或修改需要业务判断的部分。

多个技能如何协调是第二个关键问题。forge-builder技能从issue到pull request协调整个工作流，调用forge-dbx查询数据平台，调用forge-lint应用团队标准。forge-dbx为所有Data Forge技能提供一条统一的数据平台访问路径：它读取manifest并选择Databricks或DuckDB适配器，每个技能不必各自定义连接和查询逻辑。Griffiths用一句话概括这个设计原则：当步骤变化时，你改一个技能，其余的不动。

跨客户端移植是这套方法的最后一环。Data Forge示例保留skills//SKILL.md作为唯一源文件，用一个打包脚本生成各客户端的适配文件：.claude-plugin/plugin.json给Claude Code，.cursor-plugin/plugin.json给Cursor，.github/agents/.agent.md给GitHub Copilot。脚本还包含一个CI检查模式，确保各客户端文件与源保持同步。安装技能后，Griffiths建议逐项验证：客户端是否识别该技能用于预期任务、是否加载了引用文件、能否使用所需工具、是否返回技能要求的证据。

Griffiths也划出了技能方法的适用边界。技能适合有界、可重复、受益于可复用判断的工作——检查清单、发布流程、迁移、指标管道。如果工作流需要稳定接口、共享状态、审计追踪、长时间控制或模型外部强制的权限，那更适合构建一个应用。这个区分提醒读者：技能是捕获判断的载体，不是替代基础设施的万能方案。

她的三条实践建议归结为：把业务上下文放进一个文件让所有技能读取；给相关技能一条一致的平台访问路径；用指令引导工作，用检查和人工审批点验证工作。如果某个检查必须阻止合并或部署，那应该在仓库规则中配置，而不是在技能指令中声明。

最后Griffiths给出了一个务实的起点：从你厌倦了反复解释的那个任务开始。写下它需要什么、在哪里结束、审查者看到什么。然后用另一个Agent试一次，在学到什么有效时改进它。