AI Software Engineering Weekly：Agent 开始进入自托管环境，Benchmark 也在补真实任务差距

这周产品上最实在的变化是 Agent 跑在哪、模型怎么管。Cursor 把 Cloud Agent 带进企业自己的机器，GitHub 开始更集中地管理 Copilot 的默认模型和模型淘汰。研究这边连续出现几项工作，开始追问 Coding Agent 的 Benchmark 到底测到了什么，以及真实用户给出的任务为什么比 Benchmark 更难。

Cursor 9 月 2 日发布 Self-hosted machines (opens in a new window)，允许 Agent 在企业自己的网络和机器上执行工具调用，代码、构建产物和密钥留在内网。除了单机模式，还提供 team pool，多台 worker 组成动态资源池，按请求领任务，空闲机器也可以休眠后再恢复。

这次更新还支持把 Agent 跑在 AWS Lambda、Coder、Cloudflare、Daytona、Modal、Namespace、Vercel 和 E2B 等已有 sandbox 上。自托管 worker 在 Linux 和 macOS 上可以使用 computer use，Agent 能操作桌面和浏览器，用户也可以接管。

此前 Cloud Agent 的便利和企业自己的执行环境经常绑在一起，想后台运行就得接受厂商提供的运行环境。Cursor 现在把 Agent 的调度端和真正跑任务的机器拆开，企业可以继续用自己的网络、密钥管理、构建缓存和内部服务。这种模式对大型代码库尤其实际，因为“代码能不能出网”往往比模型选哪一个更早卡住采购。

自托管也把另一类成本交还给企业自己，worker 什么时候起停、容量够不够、镜像是否一致、网络权限和故障恢复都得自己维护。它解决的是任务跑在哪，不会自动解决 Agent 的权限管理和任务审计。

GitHub 这周连续调整 Copilot 模型。9 月 1 日，一批旧模型正式弃用 (opens in a new window)，涉及 Gemini 3.1 Pro、Claude Opus 4.5/4.6、Claude Sonnet 4.5/4.6 等。9 月 3 日又宣布 10 月 2 日将继续淘汰 Gemini 3.5/3.6 Flash、Kimi K2.7 Code 和 Claude Opus 4.7 (opens in a new window)。同一天，Gemini 3.8 Flash (opens in a new window) 已经进入 Copilot。

跟着一起来的是管理能力，GitHub 9 月 2 日增加了 enterprise-managed default model (opens in a new window)，管理员可以为新会话指定默认模型。

模型选择正在变成一项需要维护的配置：过去把某个模型名写进内部文档或工作流，几个月后通常还能继续用，现在 Copilot 一个月内就可能经历多轮上架和弃用。依赖固定模型行为的 Agent 工作流，至少要把“模型不可用”和“默认模型被替换”当成正常迁移场景，而不是异常故障。

OpenAI 9 月 3 日开始推出 GPT-6 Astra (opens in a new window)，官方把 coding、computer use、research 和复杂多步骤工作列为主要提升方向。当前仍是分批开放，并非所有用户都已经可用。

对软件工程更直接的变化在安全侧，OpenAI 在 9 月 1 日发布的 Path to Astra (opens in a new window) 中称，Astra 已达到其 Preparedness Framework 的 Critical cybersecurity capability threshold：在具备相应工具和访问权限时，模型能够在较少人工指导下寻找未知漏洞并发展利用方式。OpenAI 同时为安全场景提供 Codex Security 和 Daybreak 系列模型，并增加针对高风险操作的监控和访问控制。

这类能力会让 Coding Agent 的 sandbox、网络权限和审批策略更重要。模型变强之后，同一个“允许执行 shell 和访问网络”的配置所承载的风险并不会保持不变，权限策略如果几年不动，实际能做的事会随着模型能力一起变。

Google 9 月 3 日整理了 AI Agents Challenge 中表现较好的 四类工程模式 (opens in a new window)，包括双向 MCP、确定性编排、可观测性，以及职责划清的多 Agent 设计。

这篇文章的价值主要在案例，不在“四个模式”这个列表。很多多 Agent demo 把重点放在角色数量，真实工程里更难处理的是 Agent 之间如何交换结构化状态、失败后从哪里恢复，以及工具调用能不能追踪。Google 的案例也在往这些问题靠，而不是继续增加 planner、researcher、reviewer 之类的角色名称。

8 月 28 日提交、这周开始广泛传播的 RealSWE (opens in a new window) 专门研究 Benchmark 任务和真实用户请求之间的差异。作者比较 SWE-chat 中的真实 prompt 与 SWE-bench Verified / Pro，发现 88% 的真实请求只有问题描述或少量附加信息，而 Benchmark 中这种任务只有 7%，87% 的真实请求用语比较随意，Benchmark 则有 94% 是正式表述。

他们进一步构造了 381 组多版本任务，在底层任务和标准补丁（gold patch）不变的情况下，只改变需求信息和表达方式。换成更接近真实用户的输入后，七个被测模型的平均解决率下降 6.4 个百分点，模型排名也可能变化。

补上期望行为（Desired Behavior）和改动原因（Motivation）对成功率有明显帮助，环境信息（Environment Information）和复现步骤（Reproduction Steps）在这组实验里增加了 token，却没有测到显著收益。这不能直接推出“复现步骤没用”，因为结果受任务构造影响，但它说明需求信息不是越多越好。对 Coding Agent 来说，“最后希望变成什么样”和“为什么要改”可能比大段环境描述更有区分度。

9 月 1 日的新论文 What Does an Agentic Software Engineering Benchmark Measure? (opens in a new window) 分析了五个软件工程 Benchmark 和 14,922 条 Agent 执行轨迹。作者提出 Spread、Novelty、Centrality 三个维度，分别描述修改分布范围、新增代码比例，以及被改位置在架构里有多关键。

一个很基础、也最该留下的问题是，bug fix、feature 这类标签并不能充分说明任务实际要求。论文发现，每两个 Benchmark 至少在 SNC 的两个维度上存在统计差异，而这些差异与各自的数据筛选方式有关。Agent 的行为也会暴露标准补丁看不出来的任务特征，例如 Claude 的成功轨迹更接近标准补丁的修改范围，Qwen 的成功轨迹则经常超出这个范围。

所以看到两个 Agent 在“bug fix benchmark”上的分数差异时，先看数据集里的任务到底要求改多大、改到什么位置，比只看类别名更有用。内部评测也一样，如果任务集长期只有小范围局部修改，得到的结论未必能覆盖跨模块功能或架构调整。

本周 The Pragmatic Engineer (opens in a new window) 写到一个很实际的变化，一些公司开始把简单 AI 任务转向更便宜的开放模型，把高价前沿模型留给复杂任务。文章给出的案例和数字来自不同公司，不能直接套到 Coding Agent 成本上，但模型分流已经从“效果优化”变成预算问题。

Coding Agent 比普通聊天更容易放大这个差异，因为一次任务可能包含探索、读文件、跑测试、subagent 和多轮修复，同一个模型的 token 单价差一点点，跑得长就被放大。模型更新又越来越频繁，固定使用单一最强模型未必稳妥，比较成本时也不能只看单价，任务成功率、重试次数和总 token 才决定一次做完要花多少钱。

Latent Space 的 AINews (opens in a new window) 这周也把 GPT-6 Astra 的讨论放在“每个 token 更贵，单次任务成本可能更低”这个角度。后半句目前主要依赖发布期评测和早期数据，真实 Coding Agent 工作流还需要更长时间观察。

Reddit 和 Claude Code 社区这周继续出现围绕长任务的工具。有人用 hooks 防止 Agent 根据过期测试结果声称“tests pass”，有人给 build/test 命令包一层少刷屏的输出，失败时才保留完整日志，也有人专门处理跨 session 的上下文交接。

这些项目规模都不大，社区帖子也不能当成产品能力证明，但问题高度相似：测试证据会过期，CLI 输出会污染上下文，session 会中断，交接时可能把外部文本重新当成指令，Agent 跑得越久这些小故障越容易累积。

社区现在补的很多东西，在传统任务系统里都有对应概念，比如数据是否还新、检查点、对方确认、限制输入范围、重试、来源记录。Coding Agent 的实现形式不同，可靠性问题却没有消失，更值得观察的是哪些机制会逐渐被 Codex、Claude Code、Cursor 等 Runtime 原生吸收，哪些仍然适合留在项目自己的 hooks 和脚本里。

这周最值得跟进的是 Cursor 的自托管机器。Cloud Agent 能在企业自己的网络和机器上执行后，云端 Agent 与内部代码、构建环境之间少了一层硬冲突，代价是执行基础设施的维护重新回到企业手里。

评测这边的两篇研究也很实用，RealSWE 说明真实需求通常比 Benchmark prompt 更短、更缺信息，SNC 研究则说明同样叫一类任务，实际修改范围和架构难度可能差很多。做内部 Agent 评测时，任务来源、需求完整度和代码改动范围都应该记下来，否则一个总成功率很容易掩盖真正会什么、不会什么。

模型继续快速轮换，GitHub 已经把默认模型管理做成企业配置。现阶段更稳妥的做法是让工作流能够承受模型替换，并把权限、验证和任务状态放在模型之外管理。