给 CI 里的 agent 做一道“加减乘除”：GitHub Agentic Workflows 转正了
GitHub Agentic Workflows 正式可用：用 Markdown 写 agent 工作流，编译成 Actions YAML，默认只读、沙箱、safe outputs 兜底；成本先用 gh aw forecast 估个区间。
很多人担心，coding agent 进了 CI，不够聪明。
我反而担心，它太能干。
为什么？
因为 CI 是一个特殊的地方。它手里有代码，有密钥，有发布权限，而且没人盯着。
一个不够聪明的 agent，最多是活干得差。
一个太能干、又没人管的 agent，可能把不该改的改了，把不该说的说了。
所以，真正的问题不是“agent 能不能在 CI 里干活”，而是“怎么让它在 CI 里干活，还能管得住”。
10 月 28 日，GitHub Changelog 宣布，GitHub Agentic Workflows 正式 GA。
据 GitHub 官方介绍，这是 GitHub Next 的开源项目，现在 github.com 上的 Free、Team、Enterprise 都可以用。
它想回答的，正是上面那个问题。
怎么理解它？我用一个老办法：加减乘除。
加法：多了一种写自动化的方式
以前写 GitHub Actions，你要写 YAML。
缩进、触发条件、权限、步骤，一个都不能错。
Agentic Workflows 加了一种新写法：用自然语言写一个 Markdown 文件，描述你想让 agent 做什么，然后编译成标准的 Actions YAML。
流程是这样的：
Markdown 描述 → 编译 → Actions YAML → 在现有 runner 上运行
注意最后一步。
它不是另起炉灶，而是复用你现有的 runner 组和策略。
这很重要。为什么？因为企业里最难改的，从来不是工具，而是规矩。新东西能装进旧规矩里，才走得进去。
官方举的典型任务有这些：issue 分诊、CI 失败分析、文档更新、写测试。
默认引擎是 Copilot CLI，需要 Copilot 许可。你也可以自带 coding agent。
不想从零写，也可以抄作业。GitHub Next 的 agentics 仓库里有预置模板，覆盖分诊、依赖管理、code review、报告。GA 版本的 gh aw add-wizard 也加了新模板。
做一个假设。
假设你维护一个开源项目，每天早上打开 issue 区，新问题一大堆，有的是 bug，有的是提问，有的是重复。
过去你要么自己一条条看，要么写一堆规则脚本。
现在你可以写一段话：“读新 issue，判断类型，打上标签，如果和已有 issue 重复，留言指过去。”
这就是加法。加的不是功能，而是表达方式。
减法：把权限减到刚好够用
加法让 agent 能干活。减法让 agent 不乱干活。
我一直觉得，安全可以写成一个公式：
风险 = 能力 × 权限 × 暴露面
能力，你不想减。那就只能减后两项。
据 GitHub 官方介绍，Agentic Workflows 做了这样几道减法：
- 读取 GitHub 内容时，遵守 integrity filter 规则。
- 默认只读权限。
- 在 Agent Workflow Firewall 后面的沙箱容器里运行。
- agent 想要产生的输出，要走 safe outputs 校验。
- 有一个专门的 threat detection job，在变更真正落地之前做扫描。
你会发现一个思路：agent 自己不直接动手，而是“提申请”。
agent 提出想做的事 → safe outputs 校验 → 威胁检测扫描 → 变更落地
这像什么？
像工厂里的“工作票”制度。电工要上岗，不是给他一把万能钥匙，而是开一张票，写清楚在哪儿干、干什么、谁批准。
当然，这些护栏是官方的设计说明。它们在你的仓库里拦得住多少，要你自己去验证。这里也不讨论怎么绕过它们。
乘法：一份写法，乘以很多仓库
加法和减法，解决的是一个仓库的事。
乘法，解决的是一家公司的事。
一家公司有很多仓库，不可能每个都重写一遍。所以要能复制。
GA 版本加了几样东西，都和“复制”有关：
支持自托管的 ARC runner，加上 Docker-in-Docker。你的机器，你的网络，也能跑。
可以按 workflow 选模型提供方。不同的活，用不同的模型。
模型路由会按任务类型和难度来优化。官方没有给出具体效果数字。
agent 可以跑在 Cloud Hypervisor 或 NVX micro-VM 里。隔离更彻底。
跨仓库的工作流，用 enclaves 来防数据泄漏。
为什么跨仓库要特别处理？
因为乘法有个副作用：一份写法乘以很多仓库，一个漏洞也会乘以很多仓库。
所以乘法的前提，是减法做好了。
除法：把账摊清楚
最后是除法。
除法就是摊账。agent 跑一次花多少，一个月花多少，要能算出来。
GA 版本里，gh aw forecast 转正了。据官方介绍，它会给出包含威胁检测额度在内的月度区间预估。
注意，是“区间”，是“预估”。它不是账单。
那么收益呢？
GitHub 在公告里引了一段客户的话。Accenture 的 Ben Alton 提到，一位负责人估计每周省下约 29 小时；团队里 AI 写了 91% 的提交；生产错误从约每天 11000 个降到 1000 以下。
这段话，我只能把它当作客户自述。
为什么？因为这是一家客户、一个团队、一位负责人的估计。它没有对照组，也没有说是怎么统计的。它说明有人用得很好，但不说明你也会用得这么好。
除法的本质，是用自己的分母，而不是别人的分子。
先别急着全上
工具转正了，不等于你要一口气全铺开。
如果是我，会按这个顺序来：
只读的活 → 会提建议的活 → 会产生变更的活
为什么？
因为分诊、出报告这类活，就算 agent 判断错了，损失也小。改文档、写测试，会真的产生变更，等 safe outputs 和威胁检测在你的仓库里跑顺了，再交给它。
还有一件小事：编译出来的 YAML，要看一眼。
为什么？因为 Markdown 是你的意图，YAML 才是真正跑起来的东西。意图和执行之间，隔着一次编译。
最后，铺多少仓库，先用 forecast 看区间，再决定。别人的节省，不是你的预算。
最后
回到开头那个问题。
agent 进 CI，最怕的不是它不够聪明，而是它太能干、又没人管。
GitHub Agentic Workflows 给的答案，用一句话说就是：
加法让你更容易写，减法让它更难乱来，乘法让好做法能复制，除法让你看得见成本。
但工具只是工具。
哪些活交给 agent，哪些权限绝对不给，出了问题谁来兜底，这些问题，Markdown 文件替你写不了。
给 agent 的，不应该是一把钥匙，而应该是一张工作票。
来源：GitHub Changelog（2026-10-28）。功能与护栏描述据官方 changelog；模型路由官方没有给效果数字；Accenture 的每周约 29 小时、91% 提交、生产错误从约 11000 降到 1000 以下均为公告引用的客户自述，没有对照组和统计口径；“加减乘除”框架与上线顺序为作者看法。利益关系说明：本站日常使用 GitHub。