很多团队现在已经接受一件事：Agent 能写代码，也能跑测试，还能顺手帮你补文档。
真正的问题早就不是“它能不能做”，而是“它为什么每次都像第一次进这个仓库”。昨天会的事，今天又要重新解释；上周踩过的坑，这周还会再踩一遍；一套明明每次都要跑的验证流程，还是得靠人一句一句提醒。人很累，Agent 也不轻松。
OpenAI 这篇文章有意思，就因为它不再讨论抽象的 Agent 愿景，而是直接拿 OpenAI Agents SDK 两个活跃仓库的维护经验说话：怎么把日常的开源维护动作，整理成可以反复触发、自动遵守、还能进入 CI 的工作流。
这就是这篇文章最值钱的地方：它讲的不是“Agent 很聪明”，而是“怎么让 Agent 在同一个仓库里越来越靠谱”。
文章给了一个很硬的信号。2025 年 12 月 1 日到 2026 年 2 月 28 日，OpenAI Agents SDK 的 Python 和 TypeScript 两个仓库一共合并了 457 个 PR，而前一个三个月是 316 个 PR。这当然不等于“全靠 Agent”，但它至少说明，当验证、审查、发布准备和 PR 交接这些重复劳动被流程化以后，团队吞吐量确实会变快。
技能不是提示词仓库，它是可复用的操作知识包
文章开头先把一个常被说轻的话题说清了。所谓 skill，不是随手存几个 prompt，也不是给 Agent 加一段“你要认真一点”的叮嘱。它是一个带结构的知识包：至少有一个 SKILL.md，需要时还可以带上 scripts/、references/ 和 assets/。
这层结构很关键。因为很多团队做所谓 Agent 定制，最后都堆成一团文本说明。信息确实写下来了，可一旦工作流开始复杂，模型很难稳定判断“什么时候该用它”“用了以后该输出什么”“哪些步骤必须执行”。技能把这些事拆开了。元数据负责被发现，正文负责说明流程，脚本负责处理确定性动作，附加资料只在需要时再加载。这种 progressive disclosure（渐进式加载）不是术语游戏，它直接决定上下文会不会被无意义信息撑爆。
文章里提到的几个仓库内技能都很典型。比如 code-change-verification 负责代码变更后的验证栈，docs-sync 负责文档和代码同步，pr-draft-summary 负责在交接时生成 PR 草稿，JavaScript 仓库还有 changeset-validation、integration-tests、pnpm-upgrade 这种明显带有仓库个性的技能。你看这些名字就能发现一个规律：每个技能都很窄，但都很具体。
这比“大而全的超级 Agent”靠谱得多。边界越清楚，触发越稳定，结果也越容易检查。
真正让流程稳定的，不是能力，而是触发条件
很多人做 Agent 工作流，注意力都放在“它能干什么”。OpenAI 这篇文章提醒你，更重要的是它什么时候必须干。
这也是 AGENTS.md 出场的地方。文章给出的做法很直接：把仓库级别每次都该遵守的规则写进 AGENTS.md，然后用短小但明确的 if/then 规则把技能触发条件钉死。比如，改了运行时代码、测试、示例或构建行为，就必须跑 $code-change-verification；碰到 OpenAI API 或平台接入，就必须用 $openai-knowledge；工作做完准备交接，就触发 $pr-draft-summary。
这看起来像流程管理，实际上是在解决 Agent 最容易飘的地方：它常常知道“这些事也许应该做”，却不知道“这里必须做，而且做完之前不能宣告完成”。
从官方 AGENTS.md 指南来看，这种设计也合理。AGENTS.md 的定位，本来就是在会话开始前加载的长期项目规则，而且它支持从全局到项目再到子目录的分层覆盖。换句话说，技能负责具体动作，AGENTS.md 负责强制时机。这两个东西不是二选一，而是配套关系。
这四层东西，别再混着用了
文章其实在反复强调一个工程分层。我把它整理成一张表，会更清楚：
| 组件 | 它负责什么 | 不该拿它做什么 |
|---|---|---|
AGENTS.md | 定义长期规则、仓库约束、必须触发的流程 | 承担长篇操作说明或复杂机械步骤 |
SKILL.md | 描述一个可复用流程的适用条件、步骤和输出 | 代替 CI 执行强约束校验 |
scripts/ | 执行固定顺序、可重复、确定性的命令 | 做上下文判断、权衡和解释 |
| GitHub Actions | 把稳定工作流搬到 CI，形成自动化门禁 | 代替本地先打磨流程本身 |
这张表背后的判断很稳。Agent 擅长解释、比较、归纳和做有上下文的判断；脚本擅长机械、重复、不会变的动作；CI 擅长强制执行；仓库指令擅长建立长期规则。如果把这些角色搅在一起，最后就会出现一种很熟悉的场景：提示词越来越长，Shell 命令越来越散，结果谁都不稳定。
一个技能写得能不能被路由到，description 比正文还重要
这部分我很喜欢，因为它说中了很多团队忽略的细节。
文章专门拿 description 开刀，不是为了文案，而是为了路由。按照技能规范，启动时先被读取的是 name 和 description 这类元数据，不是整个 SKILL.md。也就是说，如果描述写得很空，比如“运行验证流程”，模型在真正读到技能正文之前，压根不知道它该什么时候选这个技能。
OpenAI 给出的好例子很实在。真正有效的描述不是“运行 OpenAI Agents JS monorepo 的验证”，而是“当变更影响运行时代码、测试或构建/测试行为时，运行必需的验证栈”。一口气把做什么、什么时候做、是不是必需的都写进去了。
这件事在 AI 时代特别重要。因为 Agent 现在最常见的问题，已经不是不会执行，而是选错流程。如果元数据模糊，Agent 就只能凭模糊语义猜；一旦猜错，后面的高质量脚本和详尽文档全都白搭。
这就是今天做 Agent 工作流最现实的一课：不要只优化提示词，先把触发信号写对。
脚本做机械活，模型做人该做的判断
文章对“模型和脚本怎么分工”给出的边界，也很值得抄作业。
一句话概括：解释、比较、判断、报告，交给模型；固定命令、重复步骤、证据采集，交给脚本。
这不是抽象原则，文中给了不少具体例子。像验证命令按固定顺序执行、示例自动跑起来、日志归档、失败后生成 rerun 文件，这些事显然应该沉到脚本层。可脚本跑完以后，日志是不是符合示例设计意图、某个 diff 是否真带来兼容性风险、发布是否应该被挡住，这就不该继续硬写成脚本规则了，应该让模型结合上下文去读、去比、去解释。
这条线画得非常对。
很多人现在做 Agent 自动化，会陷进两个极端。一个极端是凡事都让模型现场想，结果同一套命令每次都要重组一遍；另一个极端是凡事都想脚本化，最后复杂判断被压成几个脆弱的布尔条件。OpenAI 这篇文章的价值，就在于它把中间那条更稳的路讲明白了。
验证、发布、交接，这三类维护动作最适合先被技能化
文章展示的技能清单很多，但真正高价值的，大概集中在三块。
第一块是 代码验证。Python 仓库要求依次执行 make format、make lint、make typecheck、make tests；JavaScript 仓库则要求按顺序跑 pnpm i、pnpm build、pnpm -r build-check、pnpm -r -F "@openai/*" dist:check、pnpm lint、pnpm test。重点不只是“有命令”，而是仓库明确规定：当某类变更发生时，不跑完这套验证，工作就不算完成。
第二块是 发布准备。比如 changeset-validation 会根据实际 diff 判断 bump 级别对不对，final-release-review 会把上一个 release tag 和当前候选版本做对比，检查兼容性风险、行为变化和漏掉的迁移说明。这些事以往都容易堆到资深维护者头上，现在被拆成一个个可以让 Agent 先完成第一轮判断的流程。
第三块是 PR 交接。pr-draft-summary 这个技能很接地气。工作做完时，自动收集分支名建议、工作树状态、变更文件、diff 统计和最近提交，再输出固定格式的 PR 草稿。很多团队低估了这类动作的价值，可现实是，它们天天发生，而且非常消耗上下文切换。
如果你也在维护仓库，我会建议先从这三块下手。因为它们同时满足三个条件：重复率高、边界清楚、输出容易验证。这样的流程最容易先跑通。
放到今天看，AI 已经改写的不是“写代码”，而是维护节奏
这篇文章最值得放到 2026 年语境里重新看的一点，是它反映出的变化已经不是“AI 能帮你写点代码”了。
变的是维护节奏。
以前仓库维护里的很多动作，默认都要靠人显式发起：记得跑哪些命令、记得检查 release metadata、记得补变更说明、记得整理 PR 描述。现在这些事开始被压缩成随任务自动触发的流程。门槛下降了，速度上来了，很多原本靠经验口口相传的做法，被正式写进仓库结构本身。
但也有些东西完全没变。
API 兼容性边界依然要有人拍板。发布是不是该卡住，仍然需要证据和责任归属。技能的命名、触发条件、权限范围、输出格式，仍然要由真正理解仓库的人设计。Agent 能执行得越来越好，不代表流程可以凭空长出来。
这也是我觉得文章最清醒的地方。它没有把维护效率提升归功于“更强的模型”，而是归功于更明确的工程组织。模型当然重要，可如果没有触发规则、没有脚本、没有 CI、没有安全边界，模型再强也会在仓库里四处碰壁。
现在最该关注的，不是再写十个新技能
看到这里，很多人第一反应可能是：那我也去建一堆技能目录。
我反而建议先慢一点。
今天更值得关注的，不是技能数量，而是四个更硬的问题。
第一，你的仓库里到底有哪些流程是真正重复发生、而且值得长期保留的。第二，这些流程的触发条件能不能一句话说清。第三，哪些部分必须脚本化，哪些部分必须保留给模型判断。第四，它们进入 CI 以后，权限和安全边界有没有被认真设计。
文章里关于 GitHub Action 的延伸资料也补了一刀。把本地流程搬进 CI 很有价值，但前提是触发源受信任、输入做过清洗、OPENAI_API_KEY 保护到位、权限尽量收紧，而且最好把 Agent 放在作业的最后一步运行。流程自动化以后，真正危险的往往不是模型本身，而是触发器、输入源和运行权限。
很多团队接下来会遇到的新问题，也会集中在这里：不是 Agent 不会做事，而是 Agent 现在可以做太多事，结果你必须更认真地设计边界。这个阶段，工程判断比新鲜感重要得多。
这篇文章适合谁认真读
如果你只想让 Agent 帮你写几个函数，这篇文章未必会让你兴奋。它没有炫技味，也不卖万能幻觉。
可如果你在维护开源仓库，或者你正在把 Agent 往团队真实开发流程里接，它就很值得读。因为它讲的都是那些真正会决定长期效率的事：规则怎么常驻、流程怎么触发、命令怎么固化、判断怎么保留给模型、CI 怎么接手、交接怎么标准化。
这不是“让 AI 参与研发”的宣传稿。
这是在回答另一个更难的问题：当 Agent 已经足够能干以后，仓库应该怎样重新组织，才能真的把速度变成稳定收益。
这个问题，接下来会比“模型又升级了什么”更重要。
参考
- 原文: Using skills to accelerate OSS maintenance — Kazuhiro Sera / OpenAI
- Customization：Skills 与 AGENTS.md — OpenAI Codex 文档
- Custom instructions with AGENTS.md — AGENTS.md 分层与发现机制
- Codex GitHub Action — 在 CI 中运行 Codex 的官方说明
- Agent Skills Specification —
SKILL.md元数据与目录结构规范 - OpenAI Agents SDK for Python — 技能目录与维护流程示例
- OpenAI Agents SDK for JS — JavaScript 仓库中的技能化工作流示例