GPT-6 Astra 实测：速度、编程、上下文管理与 Computer Use 有哪些技术升级？

我是安徽最忧郁程序员无隅

GPT-6 Astra 上线后，最容易得到的结论是"模型更强了"。但对于真正使用 Coding Agent 的开发者来说，这句话的信息量并不够。我们更关心的是：它在哪些任务环节变强了，能否减少返工，又能否把一个复杂任务稳定地做完。

这次我重点体验并学习了 GPT-6 Astra 在速度、编程、前端生成、上下文管理和电脑操作方面的变化。下面不会只罗列"效果更好"，而是从 Coding Agent 的执行链路出发，分析这些变化为什么会影响真实开发效率。具体耗时会受到项目规模、网络环境和任务类型影响，不能当作固定性能指标。

一、GPT-6 Astra 的核心变化：不仅是能力更强

OpenAI 将 GPT-6 Astra 定位为面向复杂端到端工作的旗舰模型，官方列出的重点能力包括软件工程、浏览、Computer Use、研究和专业工作。模型支持最高 1,050,000 Token 的上下文窗口、128,000 Token 的最大输出，并可在 Responses API 中使用函数调用、网页搜索、文件搜索、Computer Use、MCP、Skills 和 Hosted Shell 等工具能力。具体规格可查看 GPT-6 Astra 模型页。

不过，规格参数只能说明模型能够接收多少上下文、调用哪些工具，不能直接回答实际使用体验为什么发生变化。结合这次体验，我把升级归纳为六个方向：

• 完成复杂任务所需的整体时间缩短；
• 代码分析从局部修补走向系统级审查；
• 前端和 3D 场景的视觉完成度提高；
• 长任务中的状态保持和上下文连续性增强；
• 浏览器及普通 GUI 操作更快、更准确；
• 写作措辞和节奏有所改善，但提升幅度没有编码和视觉任务明显。

这里最值得注意的是，Coding Agent 的能力不能只看一次回答写出了多少代码，而要看它能否完成"理解---执行---验证---收尾"的完整链路。 Astra 的变化，更多体现在端到端任务完成质量上。

二、任务为什么变快了：重点不只是推理速度

在真实工程任务中，我最直观的感受是等待时间缩短了。过去一些 Bug 修复或策略开发可能持续一到三个小时，而 Astra 执行大型系统审查时明显更快。这个体验不能直接推导出固定的性能倍数，却揭示了 Agent 任务中一个经常被忽视的问题：总耗时并不等于模型生成文字的耗时。

一次 Coding Agent 任务的时间，可以近似拆成：

总耗时 = 理解需求 + 搜索代码 + 推理决策 + 工具执行 + 验证 + 返工

模型只要能够更早找到正确入口、减少无效搜索、少做几轮不必要的测试，最终完成时间就可能大幅下降。我在任务中观察到的"思考更聚焦、无效推理减少、电脑操作增强"，对应的正是这些环节。

官方模型指南也给出了相近的解释方向：Astra 面向跨代码、浏览器和专业软件的多步工作流，并在官方评测中以更少的输出 Token 完成更强的结果。它还新增异步工具调用和任务执行中的中途引导能力，使应用可以在工具运行期间继续处理独立工作，也允许用户在模型工作过程中补充或修正要求。参见 GPT-6 Astra 使用指南。

因此，判断模型是否"更快"，可以观察三个更有价值的指标：

1. 完成目标一共调用了多少次工具；
2. 中途是否反复回到已经检查过的位置；
3. 首次修改后还需要多少轮返工。

这些指标比单纯观察流式输出速度，更接近 Agent 的真实生产效率。

三、编程能力的变化：从表面修复走向系统级优化

在编程测试中，我让两个模型使用相同要求审查同一套系统。GPT-5.6 Sol 没有发现太多问题，而 GPT-6 Astra 找出了更多性能和工程层面的优化点，并在一个持续任务中推进修复。

这类差异并不只是"发现的问题数量不同"。如果模型只列出几十条建议，却无法判断优先级、完成修改并验证结果，那仍然只是代码分析工具。真正有价值的 Coding Agent 需要完成下面这条链路：

首先，它要从用户目标中识别真正的完成标准，而不是看到报错就修改最靠近报错的位置。随后，它需要找到项目入口、主调用链和问题根因，再决定修改范围。完成修改以后，还要运行与风险相称的验证，并区分哪些决策可以自主完成，哪些改变会影响产品行为、需要用户确认。

Astra 在完成一批优化后，保留了三个需要确认的问题。这些问题确实会显著影响线上产品体验，所以我先理解影响，再让它继续开发。这个过程让我看到了一条较成熟的 Agent 决策边界：

• 可逆、范围清晰的工程修改可以持续推进；
• 会改变产品行为或用户体验的方案，需要暴露影响；
• 提问之前，先把能够检查的事实和候选方案准备好；
• 用户完成关键决策后，Agent 继续执行，而不是停在建议阶段。

官方指南对 Astra 的描述也与此相符：模型更擅长在多步任务中保持连贯，并能根据上下文补全日常细节；当缺失信息会改变结果时，再提出聚焦的问题。但如果指令把"谨慎"写得过重，模型仍可能频繁停下来询问。

前端与 3D 场景生成

我还使用多组视觉任务测试了前端能力，包括月面探测车、可自由探索的家居建筑、根据图片还原 3D 场景，以及高精度 V8 发动机模型。这些任务的难点远不止生成一个网页。

以家居建筑案例为例，模型同时要处理房间的空间关系、家具结构、真实材质、白模与线框模式、昼夜灯光、对象显隐、房间漫游和平面图切换。任何一个状态没有进入统一的数据模型，都可能出现"按钮存在但场景没有正确变化"的问题。

这类任务可以拆成四层能力：

需求理解
  ↓
场景与对象建模
  ↓
材质、灯光和动画表达
  ↓
交互状态与运行时逻辑

从结果看，Astra 的提升主要体现在细节、材质、物理感和整体形式感上。进一步分析，它展现的是更强的多约束协同能力：模型不只生成某个局部组件，而是让场景结构、视觉表现和交互逻辑同时达到较高完成度。

不过，展示案例依然不能代替工程验证。面对真实前端项目，还需要检查帧率、资源体积、移动端兼容性、可访问性和状态边界。视觉上"第一眼惊艳"，只是完成产品开发的一个环节。

四、长任务上下文管理：从反复压缩到历史检索

Coding Agent 执行长任务时，会不断积累用户消息、代码片段、命令输出、报错信息和阶段性结论。即使模型拥有很大的上下文窗口，这些内容也不适合永久留在当前工作区：它们会增加成本，还可能让已经失效的旧信息干扰新决策。

一种常见方案是压缩上下文。OpenAI 的 Responses API 提供 Compaction：系统对之前的会话状态进行压缩，返回用于继续任务的加密、不透明条目，以更小的 Token 占用延续后续推理。官方建议在工具密集型阶段或重要里程碑之后压缩，而不是每轮都执行。参见 Compact a response。

从工程角度看，长任务最好把信息分成三个层次：

• 当前工作状态：正在解决的问题、下一步操作和仍未通过的验证；
• 阶段性任务笔记：已经确认的决策、完成的修改和不可重复踩的坑；
• 历史原始记录：旧消息、完整命令输出、失败日志和已经尝试过的方案。

在 Codex 长任务中，我体验到了更连贯的跨窗口状态恢复：开启新上下文后，系统可以根据任务笔记恢复状态，并在需要时重新找回旧窗口中的消息或工具结果。不过，公开 API 文档目前明确说明的是 Astra 支持 Compaction、持久化推理和长任务连贯性；因此，我不会把界面中观察到的行为直接解释成某个未经公开确认的内部数据结构。

无论底层如何实现，这种分层思路能够解决四个实际问题：减少反复摘要造成的细节损失，避免旧内容长期占用当前窗口，降低重复搜索和重复命令的概率，并让任务能够在多个阶段之间持续推进。

实验性上下文管理可能涉及 config.toml 配置。由于实验功能的配置键和可用范围可能变化，我没有把某段配置直接当作通用答案。实际开启前，应先确认当前 Codex 版本支持的字段和生效目录，再创建备份、局部更新并重新读取验证。

五、Computer Use 的进步、规则变化与能力边界

在浏览器操作、UI 走查和普通电脑任务中，我感受到 Astra 的速度与准确性都有提升。OpenAI 官方也把 Computer Use 列为 Astra 的重点能力，并明确说明它适合跨代码、浏览器和专业软件执行多步工作流。

但 Computer Use 并不是一个统一难度的问题。网页通常具有相对明确的页面结构、按钮语义和交互反馈；Blender、After Effects 这类专业软件则大量依赖画布坐标、快捷键、模式切换、三维空间关系和连续视觉反馈。模型能准确点击网页按钮，并不意味着它已经掌握了复杂建模工作流。

Blender 测试也暴露了这条边界：普通 GUI 操作变强了，但在复杂专业软件中仍会出现控制不够稳定的问题。要让 Computer Use 真正进入生产流程，还需要关注：

• 操作之后能否识别软件进入了什么状态；
• 误操作后能否恢复，而不是继续在错误状态上执行；
• 长流程中能否保持对象、图层和坐标系的一致理解；
• 最终结果能否通过截图、文件结构或自动化检查验证。

更强的模型，为什么反而要清理 AGENTS.md

这次学习后，我重新检查了 AGENTS.md 和 Skills。过去为了弥补模型容易跑偏、过度设计或停在表层问题上的不足，我们可能加入大量限制；模型升级后，这些旧规则可能互相冲突，反而导致重复确认、提前停止和不必要的测试。

这一点得到了官方指南的直接支持。OpenAI 提醒，Astra 的指令遵循能力更强，也更容易受到 AGENTS.md、Skills 和其他上下文信息影响，因此建议审查其中含糊或冲突的指令。官方还特别列出了自主推进、指令优先级、子 Agent 委派、写作风格和测试范围等调校方向。

规则清理并不意味着完全放任 Agent。更合适的做法是保留四类信息：

1. 用户真正稳定的沟通和技术偏好；
2. 系统、用户、项目规则之间的优先级；
3. 高风险操作和产品决策的批准边界；
4. 与改动风险相称的验证和完成标准。

对于小而可逆的修改，不必强制 Agent 创建庞大的方案和测试矩阵；对于会影响生产数据、产品行为或外部系统的操作，则仍然要准备可审查结果并获得明确授权。模型越能严格遵循指令，规则是否清晰就越重要。

写作能力：有所进步，但不是最明显的升级

我还测试了白描故事和技术科普续写。Astra 的用词、悬念和节奏比 GPT-5.6 Sol 更稳定，人机感有所减弱，但中文写作仍容易把一个观点解释得太满，缺少自然留白。

这说明写作任务和编码任务的评价标准并不相同。代码可以通过测试、类型检查和运行结果验证，文章的节奏、分寸感和个人风格却很难用统一指标衡量。对于风格要求高的中文写作，与其堆叠抽象规则，不如提供两到三篇真正匹配的范文，让模型从具体文本中学习句长、叙述距离和表达密度。

最后的判断

综合这次体验、机制分析与官方资料，我把 GPT-6 Astra 最重要的变化归纳为三点。

第一，它提升的不只是单次代码生成质量，而是复杂多步任务的整体完成能力。第二，Compaction、持久化推理和更强的长任务连贯性，让 Coding Agent 有机会减少上下文丢失和重复探索。第三，更强的指令遵循能力会放大规则质量：清晰的目标和边界能够释放模型能力，冲突的规则也会被执行得更加彻底。

这些结论仍会受到工作负载、网络环境、提示词和项目类型影响。前端展示效果需要工程指标验证，Computer Use 在专业软件中仍有明显挑战，写作能力的提升也没有编码和视觉任务那么突出。

对开发者而言，真正值得做的不是记住"新模型更强"这句话，而是重新检查自己的 Agent 工作流：任务入口是否清楚，工具链是否可验证，上下文是否分层，以及 AGENTS.md 是否仍在解决今天的问题。