AI测试日报7.28|带你了解最新的AI测试方向

日期：2026-07-28
范围：GitHub Copilot app 独立策略、enterprise managed settings、Copilot cloud agent、插件与 marketplace 管控、审批绕过、AI agent 分级治理、GitHub Models 退役迁移

摘要

今天的核心判断是：AI Agent 的企业治理正在从“有没有开关”进入“策略一致性验证”阶段。GitHub 7 月 27 日发布的 Copilot app dedicated policy 让企业和组织管理员可以独立控制 Copilot app 访问，不再把 app 访问绑定到 Copilot CLI policy。GitHub 同时发布 enterprise managed settings 覆盖 Copilot app 与 Copilot cloud agent，明确企业可以通过 managed-settings.json 统一控制开发者可用插件、可安装 marketplace、是否允许绕过命令/文件/URL 访问审批、是否默认启用自动模型选择等设置。

这两项更新非常适合测试团队关注，因为它们把 AI 助手治理从“单客户端设置”推进到“跨客户端一致性”。GitHub 公告强调，Copilot app、Copilot CLI、VS Code 和 Copilot cloud agent 都进入同一套 guardrails。Copilot cloud agent 会读取适用的 managed settings，并只使用企业批准的插件和 marketplace；不过审批绕过控制只适用于交互式客户端，也就是 Copilot app、Copilot CLI 和 VS Code。这个差异本身就需要测试：同一条策略在交互式客户端和后台 cloud agent 上生效语义并不完全一样。

对企业来说，今天最容易漏掉的风险不是“完全没有策略”，而是“策略覆盖面不完整”。比如：管理员禁用了某个插件 marketplace，但 cloud agent 任务是否马上观察到变化？开发者本地设置和企业 managed value 冲突时，是否一定由企业设置优先？组织选择 Let organizations decide 后，不同 org 下的 repo 是否出现策略分叉？Copilot app 默认 Enabled everywhere 后，是否有团队在未完成风险评估前就开始使用？GitHub Models 将在 2026-07-30 全面退役，是否还有评测脚本、demo、BYOK endpoint 或模型 catalog 依赖残留？

这类问题不会被普通功能测试自然覆盖。它们需要专门的“策略漂移回归”：把用户、组织、客户端、插件、审批、模型、网络、仓库和时间窗口组合起来测。策略治理这件事有点像空调：控制面板看上去设成 24 度，但你还得去每个房间摸一下，别有的房间在开暖风。

今日重点

1. Copilot app 独立策略：入口拆分后，访问控制要重测

GitHub 7 月 27 日公告称，GitHub Copilot app 现在拥有自己的访问策略，企业和组织层面可以单独控制谁能使用 Copilot app。此前 Copilot app 访问依赖 Copilot CLI policy 是否启用，现在 app 和 CLI 分别有独立策略。GitHub 提供三种策略选项：Enabled everywhere、Disabled everywhere、Let organizations decide，并说明该策略默认 Enabled everywhere。

从测试角度看，独立策略带来的不是“多了一个开关”这么简单，而是访问控制模型发生了拆分：

过去：CLI policy 可能隐式影响 app；

现在：app policy 与 CLI policy 可分别启停；

企业层：可以统一启用、统一禁用或下放组织决策；

组织层：在下放模式下可能形成差异化入口策略；

用户层：不同许可证、组织成员身份、仓库归属会影响可见性；

客户端层：app、CLI、VS Code、cloud agent 的策略生效方式不同。

建议测试团队补一组访问控制矩阵：

| --- | --- | --- | --- | --- |

这里最重要的是最后两行。因为策略拆分后，企业需要证明 app 与 CLI 互不误伤、互不绕过。别让“为了关闭 CLI”顺手把 app 也关了，也别让“为了开放 app”把 CLI 的旧风险入口一起带回来。

2. Enterprise managed settings：统一配置不是一次性写文件，而是持续一致性验证

GitHub 另一条 7 月 27 日公告说明，Copilot app 和 Copilot cloud agent 现在支持 enterprise managed settings。企业 owner 可以通过 managed-settings.json 定义统一 guardrails，例如：

开发者可以使用哪些插件；

可以从哪些 plugin marketplace 安装；

是否允许绕过 Copilot 运行命令、访问文件、抓取 URL 前的审批提示；

是否将 auto model selection 设为新对话默认值。

公告还说明，企业 managed value 会优先于开发者本地设置。若企业已为 Copilot CLI 和 VS Code 部署 managed-settings.json，Copilot app 会在开发者下次登录或重启 app 后读取配置，cloud agent 会在下一次任务分配时观察到变化；支持客户端通常在约一小时内应用更新。

这带来三个测试重点。

第一，优先级测试。开发者本地设置与企业设置冲突时，必须始终以企业设置为准。例如本地允许 bypass approval，但企业设置禁止；本地允许某 marketplace，但企业白名单不包含。测试不能只看 UI 灰掉，还要实际触发命令、文件读取、URL fetch、插件安装和 cloud agent 任务。

第二，传播延迟测试。约一小时、重启、重新登录、下一次任务分配，这些都是容易产生灰区的时间窗口。策略更新后，旧 app session、旧 CLI session、正在排队的 cloud agent task、已运行中的 cloud agent task、失败重试 task 是否继承新策略？这要明确产品语义，并写进验收标准。

第三，客户端差异测试。公告明确 bypass-prompt controls 只适用于交互式客户端，也就是 app、Copilot CLI 和 VS Code；cloud agent 使用插件和 marketplace 管控，但审批绕过控制语义不同。测试报告里要把“策略不适用”和“策略未生效”分开，免得误报或漏报。

3. 插件与 marketplace 管控：Agent 风险越来越像供应链风险

插件、MCP server、marketplace 和外部工具，让 Agent 的能力边界从“模型会说什么”扩展为“系统能做什么”。企业 managed settings 能统一限制可用插件和 marketplace，这本质上是在治理 Agent 的供应链入口。

测试团队应该把插件管控当作供应链安全的一部分，而不是普通功能开关。建议覆盖：

未批准插件是否在 app、CLI、VS Code、cloud agent 中都不可见或不可用；

已批准插件是否只在授权用户、授权组织、授权仓库范围内可用；

插件被撤销后，既有会话、缓存、cloud agent 队列、重试任务是否停止使用；

插件 marketplace 白名单变更后，客户端是否正确刷新；

插件描述、tool schema、权限说明是否可审计；

插件调用是否出现在统一日志里；

插件调用失败时，Agent 是否会尝试替代工具绕过限制。

这里最容易被忽视的是“撤销测试”。很多团队会测 enable，不测 revoke。但治理能力的含金量往往在 revoke：今天允许的插件，明天发现风险，能不能在合理时间内全域撤掉？旧 session 会不会继续拿着缓存工具跑？cloud agent 会不会在下一次任务才生效？这些都需要实测。

4. 审批绕过不是用户体验设置，而是风险控制边界

GitHub managed settings 与 VS Code 企业 AI 设置都把 tool approval 放在关键位置。VS Code 企业文档提醒，Agent 工具可以修改文件、运行命令或访问外部服务，组织可以禁用全局 auto-approval、要求特定工具必须人工批准、控制 terminal auto-approval，并建议在 auto-approval 或 autopilot 场景下启用 agent sandboxing。文档也明确指出，global auto-approval 会绕过所有 tool invocation 安全提示，在企业环境中不推荐。

这对测试团队有两个启发。

第一，审批提示不是弹窗测试，而是权限测试。需要真实触发：

终端命令；

URL fetch；

文件读取；

文件写入；

task run；

MCP 工具调用；

插件访问外部服务；

高风险配置变更。

然后验证：是否弹出审批、是否能被用户绕过、企业策略是否禁止绕过、日志是否记录批准人和上下文、拒绝后 Agent 是否停止或改走安全路径。

第二，审批疲劳也要测。Agent 长任务可能连续触发大量提示，用户为了省事开启 bypass 或 autopilot。企业策略应把危险工具从 auto-approval eligibility 中移除，尤其是 terminal、URL fetch、外部写操作、生产系统变更、凭据读取和权限变更。测试可以设计一个“审批压力场景”：让 Agent 在一次任务中尝试多种工具，看策略是否保持稳定，而不是在第十次弹窗后悄悄被用户一键放开。

5. Cloud agent 的策略语义要单独验收

Copilot cloud agent 是后台执行，不是开发者坐在 UI 前逐条确认。GitHub 公告说明 cloud agent 会读取适用 managed settings，包括插件和 marketplace 控制；它只使用企业批准的插件和 marketplace。与此同时，bypass-prompt controls 只适用于交互式客户端。

这意味着 cloud agent 的测试不能照搬 IDE/CLI 的审批流程。它更像受控 CI runner，需要关注：

任务分配时读取的是哪一版 managed settings；

策略变更后，排队任务、运行中任务、重试任务如何处理；

cloud agent 能用哪些插件；

能不能访问 URL、仓库、issue、PR、Linear、MCP server；

产物是否必须通过 pull request 落地；

PR 是否保留 review、checks、audit history；

cloud agent 失败或被策略拒绝时，是否有清晰错误原因；

禁用 app 或插件策略后，已有 cloud agent 任务是否被取消、拒绝新任务或继续到安全终点。

最建议加一条“策略快照”字段：每个 cloud agent task 记录任务启动时生效的 policy version / managed-settings commit / evaluated keys。这样出现争议时可以追溯：任务为什么用了某插件？当时策略是否允许？如果不能追溯，策略治理就会变成考古。

工具与平台动态

GitHub Copilot app：默认 Enabled everywhere，要做上线前风险确认

GitHub 的 dedicated policy 公告提到，Copilot app policy 默认 Enabled everywhere。这个默认值对采用很友好，但对企业安全、测试、合规团队意味着：如果组织还没完成 app 风险评估，就要主动检查是否需要切到 Disabled everywhere 或 Let organizations decide。

日报建议把 Copilot app 上线分成三步：

1. 先盘点：哪些 enterprise / org 已默认开启；

2. 再分级：哪些团队可直接使用，哪些团队要先试点；

3. 最后回归：app、CLI、VS Code、cloud agent 的策略矩阵全部跑通。

默认开启不是坏事，但默认开启不等于默认适合每个团队。尤其是涉及客户代码、金融数据、医疗数据、涉密仓库或生产变更权限的团队，必须先过治理用例。

GitHub Models：7 月 30 日全面退役，迁移测试只剩最后窗口

GitHub 7 月 1 日公告称，GitHub Models 将在 2026-07-30 全面退役。退役后，playground、model catalog、inference API、BYOK endpoint 都不再可用，并且相关 UI 会移除。此前 7 月 16 日和 7 月 23 日已安排 brownout，让请求临时返回错误，帮助用户提前发现依赖。

今天是 2026-07-28，距离 7 月 30 日只剩两天。测试团队应立即做最后一轮迁移扫描：

代码中是否仍调用 GitHub Models inference API；

CI、demo、文档、notebook、评测脚本是否仍引用 model catalog；

BYOK 配置是否残留；

内部培训材料是否还引导用户进入 GitHub Models playground；

失败 fallback 是否指向 Microsoft Foundry、GitHub Copilot 或内部模型网关；

7 月 30 日后错误信息是否可理解，不会误导用户以为是权限或网络故障。

这个迁移和今天的主题也有关：模型访问入口一旦退役，企业必须确认所有客户端、脚本和 Agent 工具都切到受管控的新入口。否则就会出现“人已经迁了，Agent 还在调用旧 endpoint”的诡异小妖怪。

VS Code 企业 AI 设置：审批、终端、沙箱要组合测试

VS Code 企业文档提供了很实用的控制项：禁用全局 auto-approval、配置哪些工具可自动批准、单独控制 terminal auto-approval、启用 agent sandboxing、限制沙箱命令网络访问、禁止用户确认后运行 unsandboxed commands。

这些控制项适合作为企业 AI 客户端的基准测试包：

ChatToolsAutoApprove=false：用户不能开启全局自动批准；

ChatToolsEligibleForAutoApproval：高风险工具必须人工批准；

ChatToolsTerminalEnableAutoApprove=false：终端命令不自动批准；

ChatAgentSandboxEnabled=on：Agent 命令进入沙箱；

ChatAgentSandboxAllowNetwork=false：沙箱网络遵循域名规则；

ChatAgentSandboxAllowUnsandboxedCommands=false：不能确认后跳出沙箱。

真正要测的是组合，而不是单项。比如禁用了终端 auto-approval，但如果 URL fetch、task run 或插件执行还能达到同样效果，就仍然存在绕路风险。Agent 不会像传统软件一样乖乖走你命名的“危险路径”，它会找可用路径。

Google Semantic Governance：从“工具审批”走向“意图门禁”

Google Cloud 的 Gemini Enterprise Agent Platform 文档提出 semantic governance policy，也就是在工具调用执行前做 intent gate。这个策略引擎检查两件事：拟执行动作是否与可信用户意图一致，以及是否符合组织用自然语言表达的约束。例如用户只是要求总结日程，Agent 却准备调用发邮件工具外发数据，策略引擎应识别意图不一致并拒绝。

这代表一种很值得测试团队借鉴的方向：仅靠“工具是否在白名单”还不够，还要判断“此时此刻调用这个工具是否符合原始意图”。同一个 send_email 工具，在“帮我发周报”场景是合理的，在“总结我的日程”场景就是高风险。测试用例要从工具级扩展到意图级。

建议为每个高风险工具建立 intent-policy 用例：

trusted intent；

untrusted context；

proposed tool call；

expected decision；

rejection explanation；

audit event；

fallback behavior。

如果只测工具白名单，你会知道门有没有装；如果测意图门禁，你才知道门卫有没有醒着。

Microsoft 365 Agent Requests：Agent 发布也需要版本审批

Microsoft 365 admin center 的 agent requests 文档强调，组织成员发布 agent 到 tenant 时，需要管理员审批；管理员可以查看 agent 描述、owner、data、tools，然后 publish 或 reject，并可限定用户或群组范围。对于已发布 agent 的更新，pending update 需要再次审批，在更新被批准前旧版本保持可用。

这个设计对企业内部 Agent 平台很有参考价值。Agent 不只是一个静态应用，它会更新工具、数据源、提示词、权限、owner 和目标用户。每次更新都可能改变风险边界。测试团队要推动 Agent 发布流程具备：

初次发布审批；

更新审批；

旧版本保留；

版本差异展示；

权限变化高亮；

工具变化高亮；

数据源变化高亮；

目标受众变化高亮；

回滚能力；

审批人与原因记录。

如果一个 Agent 更新后多了“发送邮件”“修改工单”“访问客户合同”能力，但审批页面只显示“更新了描述”，那就是治理缺陷。

研究与工程观察

分级治理比一刀切更适合 Agent

Gartner 2026-05-26 的观点值得结合今天的 GitHub 更新一起看：企业若对所有 AI Agent 使用统一治理，无论自治级别和作用范围如何，都可能导致失败。Gartner 将 Agent 按自治程度分为 Observe、Advise、Act with Approval、Act Autonomously，并提醒企业要根据不同信任边界设置不同治理要求。

这并不矛盾：GitHub 的 enterprise managed settings 强调跨客户端一致 guardrails，Gartner 强调按自治级别比例治理。放在测试语言里，就是：

底线策略要统一；

风险强度要分级；

客户端行为要一致；

Agent 权限要按自治级别收紧。

例如，代码解释类 Copilot Chat 可属于 Observe/Advise；Copilot app 驱动 agent session 并通过 PR 落地，接近 Act with Approval；cloud agent 异步修改代码并创建 PR，则需要更强的审计、策略快照、回滚和检查门禁；如果某些内部 Agent 能直接改生产配置，就进入 Act Autonomously 或接近该级别，必须有 circuit breaker 和持续监控。

测试团队可以把自治级别作为用例标签。不是每条 Agent 用例都要同样重，但每条用例都要知道自己属于哪个风险级别。

策略漂移是多入口系统的常态，不是异常

只要一个能力跨越多个入口，策略漂移就几乎必然发生。原因包括：

客户端版本不同；

策略缓存时间不同；

登录态刷新不同；

企业层和组织层继承规则不同；

本地设置与远端设置冲突；

后台任务和交互任务生效时机不同；

插件 marketplace 可见性缓存；

文档、UI、API 行为更新不同步；

旧 endpoint 退役迁移不彻底。

所以不要把策略漂移当作“偶发 bug”，要当作“系统属性”设计测试。最小可行做法是每日或每次策略变更后跑一组 smoke：

app / CLI / VS Code / cloud agent 是否都读到同一 policy version；

高风险工具是否都需要审批；

禁用插件是否全入口不可用；

退役 endpoint 是否无残留；

审计日志是否能串起用户、客户端、策略和动作。

把策略看成代码，把 guardrails 看成可回归资产。这个思路很朴素，但耐用。

审计日志要能解释“为什么允许”

很多系统只记录“某工具被调用了”，但 Agent 治理需要记录“为什么允许调用”。尤其在 semantic governance 时代，审计日志最好包含：

trusted user intent；

触发工具调用的上下文；

policy version；

proposed action；

policy decision；

被命中的规则；

审批人；

输出摘要；

失败或拒绝原因。

没有这些信息，事故复盘时只能看到一串工具调用，像看没有字幕的监控录像：知道有人动了，但不知道为什么动、谁允许、规则是什么。测试团队要把日志可解释性也纳入验收。

理念与方法

方法一：建立“跨客户端策略矩阵”

把策略和入口横向展开：

| --- | --- | --- | --- | --- | --- |

| app access policy | 生效 | 不适用 | 不适用 | 可能影响入口 | app 可独立启停 |

| plugin allowlist | 生效 | 生效 | 生效 | 生效 | 未批准插件不可用 |

| marketplace allowlist | 生效 | 生效 | 生效 | 生效 | 未批准市场不可安装 |

| bypass approval | 生效 | 生效 | 生效 | 不同语义 | 交互客户端禁止绕过 |

| auto model selection default | 生效 | 生效 | 生效 | 按产品语义 | 企业默认优先 |

| local override | 不允许 | 不允许 | 不允许 | 不允许 | 企业 managed value 优先 |

这张表不是文档，是测试用例生成器。每个格子都应该至少有一个正向、反向和冲突用例。

方法二：用“策略版本”测试传播

给 managed-settings.json 每次变更加版本号，例如 policyVersion: 2026-07-28-001。然后设计测试：

1. 客户端 A 登录前读取旧版本；

2. 管理员提交新版本；

3. 客户端 A 不重启继续运行；

4. 客户端 B 重启；

5. cloud agent 接收新任务；

6. cloud agent 重试旧任务；

7. 查询审计日志。

预期不是所有入口都瞬时变化，而是每个入口的生效语义明确、可观测、可追踪。尤其是 cloud agent，应记录任务使用的 policy version，否则很难解释延迟窗口内的行为。

方法三：设计“绕路用例”

Agent 的特点是会尝试替代路径，所以策略测试不能只测直路。例如禁用 URL fetch 后，还要看：

是否能通过插件间接访问 URL；

是否能通过终端命令 curl；

是否能通过包管理器下载；

是否能通过 MCP server 读取远端资源；

是否能通过 issue/PR 评论诱导外部系统拉取；

是否能通过 CI workflow 在 runner 中访问网络。

禁用 terminal 后，也要看 task runner、npm scripts、Makefile、IDE task、pre/post install 是否成为替代执行路径。策略测试的灵魂就是：不要问“这个按钮关了吗”，要问“这件事还有没有别的路能做到”。

方法四：把 GitHub Models 退役做成断路演练

7 月 30 日 GitHub Models 全面退役可以当作一次真实断路演练。测试清单：

正常模型请求迁移到新 provider；

旧 endpoint 返回错误时，应用展示清晰；

Agent 不会自动寻找非批准模型 provider；

BYOK 配置不再出现在 UI 或脚本中；

评测基准不因模型替换导致统计口径混乱；

成本中心、AI credits、审计日志能识别新 provider；

文档和培训材料全部更新。

断路演练的价值在于暴露“隐形依赖”。人写的业务代码通常容易搜到，Agent 工具链、demo、notebook、实验脚本和 CI 环境变量反而更容易漏。

落地建议

今天可以立刻做的 7 件事

1. 打开企业或组织 AI Controls，确认 Copilot app policy 当前是 Enabled everywhere、Disabled everywhere 还是 Let organizations decide。

2. 检查是否已有 `copilot/managed-settings.json`，并确认它覆盖 app、CLI、VS Code、cloud agent 的目标策略。

3. 明确插件和 marketplace 白名单，删除未审批插件入口。

4. 禁用全局 auto-approval，至少让 terminal、URL fetch、外部写操作、生产变更工具始终需要人工确认。

5. 为 cloud agent task 增加 policy version、插件列表、工具调用和 PR 审计字段。

6. 扫描 GitHub Models 旧 endpoint、BYOK、playground、model catalog 依赖，准备 7 月 30 日断路验证。

7. 建立“策略漂移 smoke test”：每次策略变更后跨 app / CLI / VS Code / cloud agent 跑一遍。

本周建议补的专项测试

Copilot app 与 Copilot CLI 独立开关测试；

企业层 / 组织层 policy 继承测试；

本地设置与 managed settings 冲突测试；

插件撤销后的旧 session / cloud task 行为测试；

marketplace 白名单变更后的刷新测试；

bypass approval 禁用后的绕路测试；

cloud agent policy update 延迟测试；

GitHub Models 7 月 30 日退役 fallback 测试；

Agent 发布/更新审批版本差异测试；

intent gate 用例：工具合法但意图不合法时必须拒绝。

指标建议

可以把今天的主题落成一组工程指标：

policy coverage rate：被统一策略覆盖的客户端比例；

policy drift count：不同入口策略结果不一致的数量；

revoke latency：插件或权限撤销到全入口失效的时间；

approval bypass attempts：用户或 Agent 尝试绕过审批的次数；

unapproved plugin invocation：未批准插件调用次数；

cloud task policy traceability：cloud agent 任务可追溯到 policy version 的比例；

retired endpoint residuals：退役 endpoint 残留调用数量；

intent mismatch rejection rate：意图不一致工具调用被拒绝比例。

有了这些指标，治理就不再只是管理员页面截图，而是可以持续回归的质量资产。

今日结论

2026-07-28 的重点不是又来了一个新模型，而是企业 AI Agent 正在进入“多入口、多客户端、多策略”的治理阶段。GitHub Copilot app 独立访问策略和 enterprise managed settings 覆盖 Copilot app / cloud agent，是一个很明确的信号：AI 助手不再只是开发者本地工具，而是企业级受管控基础设施。

测试团队今天最该推动的一句话是：策略必须像代码一样被测试。

它要有版本、覆盖率、回归、审计、冲突用例、撤销用例、延迟窗口和断路演练。否则，管理员看到的是“统一 guardrails”，开发者实际使用的却可能是 app 一套、CLI 一套、IDE 一套、cloud agent 又一套。那种策略漂移不会立刻炸，但会在真正高风险任务里悄悄开门。

这也是 AI 测试越来越有意思的地方：我们不只是测模型会不会答，还要测组织写下的规则能不能抵达每一个入口。听起来琐碎，但这类琐碎，往往就是生产事故和安稳上线之间的分界线。

参考链接

- GitHub Changelog：https://github.blog/changelog/

- GitHub Changelog：Manage GitHub Copilot app access with a dedicated policy：https://github.blog/changelog/2026-07-27-manage-github-copilot-app-access-with-a-dedicated-policy/

- GitHub Changelog：Enterprise managed settings in the GitHub Copilot app and Copilot cloud agent：https://github.blog/changelog/2026-07-27-enterprise-managed-settings-now-apply-to-the-github-copilot-app/

- GitHub Changelog：GitHub Models is being fully retired on July 30, 2026：https://github.blog/changelog/2026-07-01-github-models-is-being-fully-retired-on-july-30-2026/

- VS Code Docs：Manage AI settings in enterprise environments：https://code.visualstudio.com/docs/enterprise/ai-settings

- Google Cloud Docs：Semantic governance policies overview：https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/policies/semantic-governance-overview

- Microsoft Learn：Agent requests in Microsoft 365 admin center：https://learn.microsoft.com/en-us/microsoft-365/admin/manage/agent-requests?view=o365-worldwide

- Gartner：Applying Uniform Governance Across AI Agents Will Lead to Enterprise AI Agent Failure：https://www.gartner.com/en/newsroom/press-releases/2026-05-26-gartner-says-applying-uniform-governance-across-ai-agents-will-lead-to-enterprise-ai-agent-failure