代码代理的讨论很容易停在模型能力：能不能修 bug，能不能写测试，能不能读懂仓库。GitHub 和 Vercel 最近几条更新更值得看，因为它们没有继续讲一个更聪明的聊天框，而是把代理塞进 CI、移动端、工具扩展和审批规则里。
这类变化不夸张，但实际影响更大。代理一旦能从失败检查发起修复，能通过扩展包拿到外部系统工具，还能带着审批规则去执行写操作，它就不再是开发者旁边的建议框，而是工程系统里的一个参与者。
CI 失败不再等人回到桌面
GitHub Mobile 的新流程很直接：当 PR 上的 GitHub Actions 检查失败时，用户可以从失败检查里选择 Fix with Copilot，让 Copilot coding agent 调查并尝试修复。GitHub 说代理会在原有 PR 之上打开一个新 PR，分析失败检查，准备变更后再标记用户审阅。用户仍然要检查方案、补跑需要的检查，并决定是否合并。
这里的重点不是移动端终于能点一个按钮，而是 CI 失败的响应路径被缩短了。过去这类问题常常要等人回到桌面，打开日志，切分支，再决定是否值得修。现在入口出现在 iOS 和 Android 的生产版 GitHub Mobile 里，意味着工程平台正在把代理放进更碎片化的工作时间。
扩展包把工具、连接和审批放在一起
Vercel 的 eve 更新则从另一个角度推进。GitHub tools extension 可以让 eve agent 获得 42 个 GitHub 工具，配置里带 Vercel Connect 认证、预设范围和审批规则。示例里，写工具默认需要批准，也可以用输入条件控制，例如只在评论外部组织时要求审批。
更底层的 eve extension 机制允许把工具、连接、技能、指令和 hooks 打包成扩展，发布到 npm 这类包注册表，再像普通项目依赖一样安装、版本化和升级。扩展可以声明配置 schema，导入时验证设置；也可以替换、移除工具，或者在 hooks 里收窄工具结果类型。
代理平台需要像依赖一样治理
这套设计把代理工程从提示词管理推向依赖治理。一个代理接了哪些工具，拿到哪些连接，令牌在什么时候铸造，写操作是否要人工批准，包版本如何升级，这些问题会变得和后端服务依赖一样具体。
Vercel 强调 Connect 会在运行时铸造短期、限定范围的 GitHub token，预设会把工具范围映射到 Connect scopes。这个方向是对的：如果代理要进入 issue triage、code review、ci-ops 这样的真实流程，长期宽权限 token 和模糊审批都站不住。
难点转到变更审查
GitHub 的移动端修复流程保留了一个重要边界：代理创建新 PR，最终仍由人检查、跑检查、决定是否合并。Vercel 的扩展也把写工具审批列为默认约束。两边合起来看，成熟形态不是代理悄悄替人合并代码，而是让代理更早介入问题定位和初稿修复，同时让审查权留在清楚的位置。
这会改变团队的评估方式。以前试用代码代理，常问的是能不能写对。现在还要问：它从哪里启动，能调用哪些工具，失败时留下什么记录，审批规则是否和组织边界一致。模型会继续变强，但代理能不能进生产工作流，越来越取决于这些看似普通的工程接口。