GitHub 和 Vercel 在 7 月 27 日分别更新了 agent 相关能力。表面看，一个是 Copilot app 的企业策略，一个是 Claude Managed Agents 和 Slack agent 的 SDK 能力；放在一起看，它们处理的是同一类生产问题：agent 不再只待在一个聊天窗口里。

当 agent 可以出现在桌面 app、CLI、VS Code、cloud agent、Slack 线程和 Web 聊天界面里，企业治理的重点就会从“这个模型强不强”转向“每个入口是否在同一套控制下”。插件能不能用，marketplace 从哪里装，命令执行前能不能绕过审批，正在运行的会话能不能取消或重置，这些问题比模型参数更接近上线后的真实风险。

GitHub 先把 Copilot app 拆成独立策略

GitHub 给 Copilot app 增加了自己的访问策略。此前 Copilot app 的访问依赖 Copilot CLI 策略开启；现在企业和组织可以分别管理 app 与 CLI。新的策略默认是 Enabled everywhere，管理员也可以 Disabled everywhere，或者交给组织管理员决定。

这个改动很小，但边界清楚。Copilot app 是一个新的 agent 入口，如果它继续挂在 CLI 策略下面，企业只能用粗粒度开关管理两个不同客户端。GitHub 同时强调，Copilot app 的工作发生在隔离 workspace 中，变更通过 pull request 落地，因此仍会经过代码审查、检查和审计历史。这里的重点不是给 app 放权，而是把放权纳入既有软件交付流程。

托管设置要覆盖每个 Copilot 表面

第二个更新更接近企业控制面。GitHub 的 enterprise managed settings 现在覆盖 Copilot app 和 Copilot cloud agent，沿用企业已经为 Copilot CLI 与 VS Code 使用的 managed-settings.json。企业 owner 可以在同一份配置中指定可用插件、允许安装插件的 marketplace、开发者能否绕过命令执行/文件访问/URL 获取前的审批提示，以及新会话是否默认启用自动模型选择。

细节也值得看。Copilot cloud agent 会读取插件和 marketplace 控制，但“能否绕过审批提示”只适用于 app、CLI、VS Code 这类交互式客户端。设置值会优先于开发者本地配置；已有 managed-settings.json 的企业不需要重新建一套策略，app 在开发者重新登录或重启后会读取配置，cloud agent 会在下一次任务分配时观察变化，GitHub 给出的常规生效窗口约为一小时。

这说明 agent 治理开始进入“最薄入口”阶段。只要有一个客户端不读企业策略，开发者就可能在未审核插件、未批准 marketplace 或未受控命令执行上绕出一条路。GitHub 自己的说法是治理强度取决于覆盖最少的表面，这一点比功能发布本身更重要。

Vercel 把会话生命周期暴露给 SDK

Vercel 的两条更新从另一个方向补齐了 runtime 层。Chat SDK 现在可以运行 Claude Managed Agents：模型、工具、agent loop、会话状态和 sandboxed web research 由托管 agent 处理，Chat SDK 通过一个类型安全 handler 把它接到 Web 聊天界面，也可以迁移到 Slack、WhatsApp 等三十多个平台。开发者能拿到 token 流式输出、工具调用和模型请求的活动流，并复用托管会话里的 transcript 与 replay，不必自己维护一套服务端数据库。

同一天，Vercel eve 的 Slack channel 也加了更细的会话控制。onMessage 可以接收 Slack 消息，ctx.isBotMentioned 判断显式提及，ctx.isSubscribed 判断一个线程是否已有活跃会话。ctx.cancel 可以停止当前 turn 并用新消息替换输入，ctx.reset 则终止当前线程会话，让下一条消息从新历史和新 sandbox 开始。onEvent 还能处理 Slack Events API 的原始事件，把 reaction_added、team_join 这类事件转成 agent turn。

这不是 GitHub 那种企业 policy，但它解决了同一个落地难题的另一半：agent 一旦进入协作工具，就必须有会话边界、事件入口和中途停止机制。没有这些控制，Slack 里的 agent 很容易从“帮忙回复”变成“在错误上下文里继续行动”。

治理能力会成为 agent 产品差异

今天这组更新给企业的判断标准很直接。第一，agent 入口必须可枚举，桌面端、CLI、IDE、云任务、聊天渠道都要在策略清单里。第二，策略要能下沉到实际执行点：插件、marketplace、命令审批、URL 访问、会话状态，而不是停在账号权限。第三，运行中的会话要能观察、取消、重置，并留下能审计的轨迹。

这也限制了炒作空间。GitHub 的能力主要服务 Copilot 生态，Vercel 的能力更偏开发者把 agent 接入渠道和应用时的 runtime 控制。两者都不是通用答案。但方向已经清楚：企业 AI agent 的关键控制点正在从模型选择前移到客户端覆盖和会话生命周期。下一轮真正有价值的比较，不是谁接了更多模型，而是谁让最危险的入口也受控。