https://x.com/githubnext/status/2116220286928585103看看这个

回复 joye： GitHub Next 的 Agentic Workflows 在 10 月 28 日正式 GA，之前一直在实验室阶段。核心设计跟别的 agent 产品不太一样：你用 Markdown 自然语言写工作流，它编译成标准 Actions YAML，所以 runner groups、策略约束这些现有基建直接复用，不需要在仓库外再养一套调度系统。触发方式就是 Actions 那套事件，issue 一开、CI 一挂就跑。可配的引擎是 Copilot CLI（默认，需授权）、Claude、Codex、Antigravity，每个 workflow 能单独选，还能走模型路由按任务难度分派。 GA 相比预览新加的东西里，有两个比看着有用：一是 ARC 加 DinD 支持，能跑在自建 runner 上，意味着企业内网环境能用；二是 gh aw forecast 出了实验阶段，把威胁检测的额度也算进预算预测，这个细节说明他们知道 token 花费是拦路虎。另外隔离上提到可以跑在 Cloud Hypervisor 或 NVX 微虚拟机里，跨仓库再用 enclave 防泄漏。 安全设计是这套东西最值得看的部分：agent 默认只读权限，跑在防火墙后的沙箱容器里，产出走 safe outputs 校验流程，还有个独立威胁检测 job 在改动落地前全扫一遍。也就是说默认假设 agent 会干坏事，把写权限收在验证之后，而不是先给权限再事后审计。 几个数据我保留态度：Accenture 那边说一位负责人每周省 29 小时、团队速度翻倍、AI 占 91% 的 commit、生产错误从每天 降到 1000 以下。这种量级要么是某个特定迁移项目的峰值，要么口径有问题——AI 写 91% 的 commit 不等于 91% 的工作。看这类案例得注意分母是什么。 我的判断：它真正的卖点和前面聊过的 Warp 那篇是一路的，但走的是另一个方向。Warp 要做集中的 software factory，GitHub 则直接把 agent 塞进你已经有了的 CI 事件流里，用现成触发器省掉一层基础设施，并用它的杀手级优势来竞争——仓库和权限都在这儿。代价也很清楚：延迟高、你被钉在 Actions 生态里、而且每个 workflow 的 token 花费得自己盯。适合那些“逻辑清楚但每次都要人看一遍”的活，比如 issue 分诊、CI 失败归因、依赖升级、文档同步；不适合需要长时间交互、跨仓库乱逛的任务。 顺带一句，你发的图没取到，要看的话重发一下。