夜雨聆风这一周没有一款新模型把所有注意力吸走，真正值得开发者关注的变化，反而集中在代理工程的“最后一公里”：代码代理进入 GitLab，模型平台补齐浏览器、技能与文件能力，代理工具开始有专门的评测框架，云平台把搜索、MCP 和结构化输出做成托管能力，数据库也开始把可审查的操作接口交给代理。
我的判断是，代理竞争正在从“能不能完成任务”，转向“能否进入现有系统、接受评测、控制权限，并留下可复核的结果”。
本周技术判断
本周五项变化可以连成一条工程链路：代码仓库负责触发任务，代理平台负责执行，Skill 或工具目录提供领域知识，评测框架检验它是否真的改善结果，数据库工具则让代理在明确授权下接触真实数据。
这比单纯刷新模型排行榜更重要。开发团队真正难解决的，往往不是再提高几个点的生成能力，而是如何把代理接入 MR、浏览器和数据层，同时守住凭据、成本与人工审批边界。
AI 热点 1
Codex cloud 正式进入 GitLab 工作流
OpenAI 8 月 19 日宣布，Codex cloud 的 GitLab 支持以 Beta 形式向所有 ChatGPT 计划开放。开发者可以连接 GitLab 项目、创建云端环境，从 issue 或 merge request 中用 @codex 启动任务，并请求单次或自动 MR 审查。OpenAI 发布说明与GitLab MCP 文档提供了两条互补路径：前者是云端原生集成，后者是通过 MCP 把 GitLab 能力接入 Codex。
对 GitLab 团队，最直接的改变是代理不再要求把协作主场迁到 GitHub。一个可落地的流程是：issue 描述验收条件，@codex 生成修改，MR 中由自动审查先给出问题清单，再由人决定合并。若团队暂时不想接入云端，还可以用 codex mcp add GitLab --url "https:///api/v4/mcp" 建立直接连接。
限制也很明确：GitLab 触发需要配置 webhook 的权限；Self-Managed 或 Dedicated 需要管理员配置，相关 webhook 能力要求 GitLab 19.0 或更高；折叠或超大 diff 被 GitLab 省略时，Codex 无法完成审查。它适合已经用 GitLab 管理 issue/MR、愿意设计最小权限环境的团队，不适合把代理当作无监督合并机器，或无法接受代码进入 Codex cloud 执行面的组织。
AI 热点 2
Claude 把 computer use、Skills 与 Files API 推到生产接口
Anthropic 8 月 20 日宣布 computer use、Skills API 和 Files API 在 Claude Platform 正式可用，并为网页操作加入 browser use。computer use 通过截图执行点击、输入和滚动；browser use 同时读取页面结构，减少只靠坐标定位的脆弱性；Skills 把团队流程和知识打包为可复用目录；Files API 则让输入与产物通过文件对象传递。官方公告与Skills 文档给出了能力与安全边界。
我更看重它们的组合，而不是单项功能。比如报表代理可以读取上传的数据文件，调用财务口径 Skill，在浏览器里进入没有开放 API 的后台，最后返回完成的工作簿。过去这通常需要分别维护 RPA、提示模板、对象存储和下载链路。
但“正式可用”不等于可以放弃隔离。官方文档提醒，仓库里的 Skill 可能被有提交权的人修改，而 bash、web_fetch 等工具会放大恶意指令的影响；挂载过多 Skills 也会增加沙箱启动时间。它适合流程稳定、权限可分级、产物可校验的文档和后台操作，不适合直接处理不可逆高风险动作，或把未经审查的外部仓库当作可信 Skill 源。
AI 热点 3
NVIDIA 用 SkillEvaluator 给代理技能建立三层质量门
NVIDIA 8 月 19 日发布开源 SkillEvaluator，把代理 Skill 的评测拆为确定性质量检查、语义重叠与上下文分析、隔离环境中的真实任务运行三层。NVIDIA 工程博客解释了设计思路，开源仓库则给出可执行命令和支持的模型提供方。
这项工具的重要性在于，它要求团队证明“加了 Skill 以后更好”，而不是只看文档写得是否漂亮。最小验证可以先不接模型：
uv tool install --python 3.13 ”skillevaluator[all] @ git+https://github.com/NVIDIA/SkillEvaluator.git”skillevaluator validate ./my-skill \--checks schema,pii,license,quality,unicode,lint \--no-dedup
再往下才是需要 embedding、模型调用和隔离执行的完整评测。官方仓库明确标记项目仍属 Experimental、社区尽力支持且没有 SLA；完整 Tier 1 还依赖 Semgrep、SkillSpector、Gitleaks，Tier 3 的模型与托管沙箱可能产生费用。它适合已经维护多个 Skills、需要 CI 质量门的代理平台团队；只有一两个内部提示文件的小团队，不必一开始就上完整三层体系。
AI 热点 4
Microsoft Foundry 上的 Claude 补齐五项代理构件
Microsoft 8 月 17 日为托管在 Azure 上的 Claude 加入 structured outputs、Web search、Web fetch、MCP connector 与 Tool search。Microsoft Foundry 工程博客给出了 Python、TypeScript 示例和部署差异，Foundry REST API则列出了 web_search、mcp、tool_search 等工具类型。
架构上最有价值的是减少重复脚手架：结构化输出约束 JSON Schema；搜索和抓取省掉自建爬虫；MCP 连接内部系统；Tool search 不必把几百个工具定义全部塞进上下文。对于已有 Azure 身份、网络和计费体系的企业，这让 Claude 代理更容易留在同一治理面内。
不过，托管位置不能被简化成“数据绝不外流”。微软说明，Hosted on Azure 下提示和补全留在 Azure，但使用元数据以及被 Anthropic 安全系统标记的内容可能传给 Anthropic；不同托管选项的模型目录也不完全相同。它适合 Azure 重度用户和工具数量快速增长的企业代理，不适合只需要一次模型调用的轻量应用，也不适合在未完成数据处理评审前直接接入敏感内部 MCP。
AI 热点 5
Cosmos DB 让代码代理在可见、可批准的边界内操作数据
Azure Cosmos DB 团队 8 月 18 日更新 VS Code 扩展：GitHub Copilot 可以识别当前 Query Editor、抽样容器 schema、生成并写入查询，在得到开发者许可后执行；同时提供数据库专用 Skills，以及通过 Cosmos DB Shell 暴露的可选 MCP 路径。官方工程文章说明了完整工作流，扩展仓库可核对查询编辑器和权限要求。
这类“先看 schema、再生成、最后审批执行”的交互，比在聊天框里猜字段可靠得多。比如开发者提出“查出该租户最近十次支付失败”，代理先确认活动容器并请求抽样，再生成按真实字段和分区键约束的查询，开发者检查后才执行，同时看到 RU 消耗和查询指标。
边界同样重要：schema 抽样会读取数据并消耗 RU；Shell 的 MCP 模式不是托管服务，需要自行决定运行位置和身份；vNext Emulator 只覆盖部分云能力，不能替代生产环境的性能、索引、安全与多区域验证。它适合使用 Cosmos DB、希望减少查询和诊断机械操作的团队，不适合让代理绕过 RBAC，或把本地模拟器结果当作容量结论。
我会怎么用
如果要把这五项能力落到同一条开发链路，我会从小而可审查的闭环开始：GitLab issue 只触发低风险代码任务；Skill 进入仓库前先跑静态和安全检查；代理访问 Foundry 或 Claude 工具时使用独立身份与最小权限；涉及 Cosmos DB 时只允许 schema 抽样和只读查询，并保留人工执行确认；最后用任务成功率、人工返工量、工具调用错误率和单任务成本判断是否扩大范围。
这里最容易犯的错，是同时开放仓库写入、浏览器操作和生产数据权限，然后用“模型更聪明了”解释风险。更稳妥的顺序是先让代理读、再让它建议、随后允许受控执行，最后才考虑自动化。
最后总结
本周的共同主题不是模型替代开发者，而是代理开始真正进入软件工程系统：能被仓库事件触发，能复用领域技能，能被质量门评测，能调用成百上千个工具，也能在权限与审批下接触数据。
接下来值得观察的，不只是任务成功率，还包括代理失败时是否可定位、Skill 更新是否可回归、工具权限是否可撤销，以及成本能否按一次真实交付来计算。
如果你的团队下周只能增加一个质量门，你会优先选择 Skill 回归评测、工具最小权限，还是数据库操作的人工审批？为什么？