GitHub 直接雇 Agent：脚本管确定性，判断归它

github.com/github/gh-aw 有条官方发布值得拆：GitHub 推出 gh-aw（Agentic Workflows），Actions 正从"跑脚本"变成"直接雇 Agent 干活"。 分工写得很清楚：build、test、lint、deploy 这些确定性工作继续归 Actions；Issue 分类、PR Review、CI 失败分析、文档维护、依赖分析这些需要判断的交给 Agent。 Workflow 用 Markdown 加 YAML 写，最后编译成标准 Actions，模型可以直接选 Copilot、Claude Code、Codex、Gemini 或 Pi。 两层一，接 62287"能修则修、查不了要报"与 62137 数据库权限三档 ＝ 工具层信任的第三角闭环：那条讲怎么汇报，那条讲做到哪一步，这条讲最硬的一环——写权限单独管。 Agent 默认只读、跑在沙箱里，真正要写 GitHub 的操作再过一道 safe-outputs job 校验执行。 脚本管确定性、Agent 管判断、写权限单独管，三权分立比让 Agent 拿着仓库权限乱跑靠谱得多。 二，"编译成标准 Actions"这步是接入旧世界的巧劲：不另起炉灶造新平台，而是把 agent 工作流降维成现有 CI 能执行的形态——存量流程一行不用改就多了个会判断的工位。 这跟 62287 把规范编译成 skill 是同一个思路的官方级示范。 口径：①功能、分工与权限设计其原帖及仓库表述（我没实际部署跑一遍）；②L1 为官方 GitHub 仓库链接可查；③"三权分立/降维"是我的引申；④各模型接入方式以其文档为准。 要用的两条：一，工程团队——先开默认只读加沙箱，把 PR Review 和 CI 失败分析当第一批判断类试点，风险最小收益最先见到；二，做 CI/CD 产品的——安全边界现在是卖点本身，"Agent 拿不到写权限"要写在首页而不是文档第 8 页。 CI 的工位开始换人了——脚本留下，判断上岗，你的流水线先换哪一把椅子？