后端平台要开始托管代理运行时，而不是只托管 CI

后端

发布日期: 2026-05-10

导语：
2026 年 5 月前后的后端平台消息，放在一起看有一个很明确的趋势：平台治理对象正在从传统 CI/CD 扩展到代理运行时。4 月 23 日，GitHub 宣布 immutable subject claims for GitHub Actions OIDC tokens；4 月 24 日，又提前通知 GitHub App installation tokens 即将采用新格式；4 月 27 日，GitHub 还说明 Copilot code review 将从 6 月 1 日开始消耗 GitHub Actions 分钟数。再叠加 Copilot cloud agent 相关度量和会话管理能力，可以看出平台方已经把 AI agent 的执行行为视为一种正式的后端运行负载。

这件事对后端团队的影响很直接。过去平台工程师主要托管构建流水线、部署流水线和服务运行时；现在还要开始托管“代理如何获得身份、在哪运行、访问哪些网络、消耗哪些配额、如何留下审计记录”。如果你仍然把 AI agent 看作 IDE 附件，而不是平台上的执行主体，后面会在身份、网络和成本三个方向同时吃亏。

1. 这次变化真正意味着什么

首先，它意味着 agent 已经从“建议生成器”变成“会消耗平台资源、具备执行影响”的角色。既然 code review 会消耗 Actions 分钟，agent 会话能写回 PR、访问仓库和调用插件，那它就不再只是文本层工具，而是平台负载的一部分。

其次，身份治理开始前置。immutable subject claims 和 token 格式调整都在说明一件事：平台需要更稳定、更可解析、更不容易被误用的身份断言。后端团队以后不只是发 token，还要设计哪些运行单元能拿到什么身份、身份和任务之间如何绑定、任务结束后如何失效。

最后，后端平台的边界正在被重画。以前 CI runner 和生产服务是两个主要运行面，现在中间多出一层 agent runtime。它可能不直接承载用户流量，但会读取代码、触发检查、调用外部系统，甚至改动仓库内容。治理上不能再把它归入“开发者本地工具”。

2. 为什么团队现在应该关心

因为大多数后端平台的默认设计，并没有为 agent 运行时准备好。很多组织对 CI 资源、服务身份和网络出口已经有规则，但对代理会话、插件调用和临时执行环境却没有成熟边界。结果往往是：人类工程师被严格约束，agent 反而拿着过宽的仓库权限和网络通道做事。

这会带来三类现实风险。第一，身份漂移。没有稳定 subject 和会话绑定，出了问题很难追到是谁在何时通过哪个代理触发了动作。第二，成本失真。AI code review、自动排障、批量扫描都会消耗真实算力与分钟数，如果不单独核算，平台预算会越来越模糊。第三，网络与数据外发风险。agent 往往会通过插件、MCP 或外部 API 触达更多系统，若准入和出口控制不清，问题会比传统 CI 更复杂。

后端团队现在介入，正好能在平台层把这些边界先框起来，而不是等业务线各自野生生长后再补洞。