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

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

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

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

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

自托管也把另一类成本交还给使用方。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)，管理员可以为新会话指定默认模型。

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

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、确定性 orchestration、可观测性和带明确边界的 multi-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 trajectory。作者提出 Spread、Novelty、Centrality 三个维度，分别描述修改分布范围、新增代码比例和被修改位置的架构重要性。

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

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

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

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

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

Reddit 和 Claude Code 社区这周继续出现围绕长任务的工具：有人用 hooks 防止 Agent 根据过期测试结果声称“tests pass”，有人给 build/test 命令做低噪音 wrapper，失败时才保留完整日志，也有人专门处理跨 session 的 context handoff。

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

社区现在补的很多东西，在传统任务系统里都有对应概念：freshness、checkpoint、acknowledgement、bounded input、retry、provenance。Coding Agent 的实现形式不同，可靠性问题却没有消失。这里更值得观察的是哪些机制会逐渐被 Codex、Claude Code、Cursor 等 Runtime 原生吸收，哪些仍然适合留在项目自己的 hooks 和脚本里。

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

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

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