Google 最近公开了他们怎么批量生产 Agent Skills 文章不长，但把 Skill 从“写一份 SKILL.md”推进到了工程化维护。自己在做 Skill 库，可以直接抄这 7 个做法： 1、目录先统一 每个 Skill 都按同一套结构来：SKILL.md 放主指令，OWNERS 标负责人，EVAL.yaml 放测试题和评分标准；复杂资料、脚本、素材和内部数据再各自归档。人多以后，统一结构能省掉大量沟通和排查 2、工具调用有优先级 能接远程 MCP 就优先接远程 MCP，需要时再退回 CLI 或 API。原因很实际：MCP 既能给 Agent 提供工具，也方便统一处理认证和权限 3、内部开发，自动导出 Google 先在内部编写和评测 Skill，通过后再用自动规则发布到 GitHub。导出时会剥离负责人信息、内部素材和评测集，公开仓库保持干净，内部治理信息也不会混进去 4、合并前先过机器检查 CI 会检查 frontmatter、行数、目录结构和命名规范，还会逐条测试链接，拦住 404 和编造出来的网址。文章推荐用 lychee 查链接，也给了一份用 skills-ref 验证 Skill 的 GitHub Actions 配置 5、持续跑评测 新 Skill 提交时要附多组测试题和评分标准，发布前先跑一次；整个 Skill 库每周还会定时复测。评测会比较 Agent 使用 Skill 前后的准确率、任务完成率、Token 消耗和完成时间，并在不同 Agent 框架里重复运行 6、每个 Skill 都要有人长期负责 仓库维护者管 CI、架构规范和整体健康，Skill Owner 负责后续更新。API 变了、评测退化了，都能直接找到应该修的人 7、用 Agent 帮作者写 Skill Google 还做了内部 Skill 和基于 ADK 的多 Agent 工具，辅助作者写指令、补评测、做自我批评，再导出到主仓库。Skill 数量一多，作者工具本身也得产品化 如果你正在维护自己的 Skill 库，可以先试试：统一目录、每个 Skill 配评测、明确长期负责人。做到这一步，Skill 才能跟着模型、API 和工具变化持续更新