我的第一次 GPT-6 Astra 评测始于一个无法正常加载的 CRM 仪表板。我希望这个 agent 找到原因、修复问题，并证明页面能够正常运行。和一个新模型共度夜晚，这似乎是个不错的方式。
这次工作带来了三个具体修复：缺失的安装默认值、无法保存所选用户的设置，以及因模型别名不一致而导致的数据加载故障。随后，仪表板在本地测试环境中成功打开。
这足以让我产生兴趣，但还不足以让我宣布其他所有 coding model 都已经过时。
这是一份早期的亲身体验记录，同时参考了独立基准测试结果和其他开发者的初步印象。研究反映的是 2026 年 9 月 3 日至 4 日的情况。本文描述的 CRM 更改在测试时仅存在于本地，尚未提交，也不是生产版本发布。
GPT-6 Astra 是为哪些工作打造的？
OpenAI 将 Astra 定位为一个适用于代码、浏览器、文档和其他软件中高要求工作的模型。API model 是 `gpt-6-astra`，拥有 1,050,000-token context window，并支持图像输入。它的新能力包括异步 tool calls，以及在任务运行期间发送 instructions。OpenAI model documentation、Astra guide。
对我来说，真正有趣的测试是：这些能力是否能帮助处理一个现有系统。一个正常运行的 CRM 包含权限、旧有假设、不完整的集成，以及希望昨天的功能今天仍能继续工作的用户。生成一个整洁的组件只是这项工作的一部分。
我的 GPT-6 Astra 评测：真实 CRM 中的三个修复
我使用了一次由 Astra 主导的 Codex 会话，调查 Perfex CRM 安装中的一个日常工作仪表板。这个模块原本就已经存在。Astra 没有构建整个 CRM，而项目此前的工作也使用过其他模型。
第一个问题出现在安装过程中。该模块使用了错误的返回值来检查缺失的设置。因此，它可能会跳过所需的默认值。修复方案使用了平台现有且可重复的选项创建函数。
第二个问题出现在设置页面。页面的 script 在 jQuery 可用之前运行，因此所选的试点用户没有传递到表单提交的字段中。等待页面准备就绪后，这条路径便恢复正常。
第三个问题涉及 database-model aliases。模块的部分代码以一个名称加载 model，却尝试用另一个名称访问它。明确指定 aliases 后，错配得到修正。这些是 application models，而不是 AI models。
围绕这三种故障模式，我们添加了 regression tests。该会话还在一个隔离的本地数据库副本中检查了已认证的仪表板、历史记录和即将到来的日历。
有用之处在于，它把症状与修复连接了起来。安装、表单行为和 server-side loading 分别需要不同的检查。仅凭渲染页面的截图，无法解释它为什么会失败。
之后，一些已连接的数据源仍然报告警告，增长建议也依旧被阻塞。我将其视为尚未完成的集成工作，而不是一切都已准备好发布的证据。
我也无法把这次会话变成速度比较。我没有在相同的初始状态和时间预算下，用另一个模型执行相同任务。我的在真实工作中对 AI models 进行基准测试的指南介绍了在提出这一结论前，我希望采用的比较方式。
其他开发者如何评价 Astra
Claire Vo 的 early-access 记录描述了她在 coding projects 上取得的进展，这些项目此前曾在使用 Sol 和 Fable 时屡次失败。她的例子包括 product-intelligence 功能、基于浏览器的 QA，以及在 creative tools 中的工作。浏览器测试这一点与我的体验尤其相关：编写修复并检查其行为，应当属于同一个 workflow。这些是她报告的个人经历，而不是受控比较。Claire Vo's hands-on review。
Matt Shumer 的 early review 强调了 backend engineering、长对话中的连续性，以及更清晰的进度更新。他也指出了缺点：Astra 可能比他希望的更慢，而且他仍然更喜欢 Claude 的视觉品味和 asset creation。他表示，日常工作使用 Medium reasoning，而更大型的实验使用 Ultra。这是一个值得测试的起点，而不是适用于所有人的通用设置。Matt Shumer's review。
社区反应并不统一。一个 r/codex 讨论认为，automation 和 efficiency 比 GPT-6 这个标签更重要，同时质疑基准测试是否足以支撑发布宣传。我会把它视为这场争论的一个样本，而不是开发者调查。Community discussion。
Astra 基准测试：也要看成本一栏
Artificial Analysis 报告了以下发布结果：
| 指标 | GPT-6 Astra | GPT-5.6 Sol | Claude Fable 5.1 |
|---|---|---|---|
| --- | --- | --- | --- |
| Coding Agent Index | 67 | 65 | 70 |
| Intelligence Index | 61 | 61 | 66 |
这些是 index points，而不是任务成功率。Coding comparison 在 Codex 中评估 Astra 和 Sol，在 Claude Code 中评估 Fable，因此比较的是 model-and-tool setups，而不是单独隔离模型本身。
在 max effort 下，Astra 在 coding evaluation 中使用的 tokens 大约是 Sol 的三分之一，而每项任务的成本大致相同。更广泛的 Intelligence Index 则呈现出不同结果：整体表现与 Sol 相近，但每项任务的成本高出约 75%。效率取决于 workload。Artificial Analysis methodology and results。
对于需要决定预算投入方向的团队，我会衡量 agent 停止工作后还剩多少 review 和 rework。更短的响应只有在工作正确时才有价值。如果一次更长的运行能够解决困难问题，它可能值得付出，但仅凭持续时间本身无法证明任何事情。
从 Astra 获得有效工作的五个技巧
1. 明确定义什么叫完成
描述故障以及可观察的 acceptance test。要求复现问题、进行范围明确的修复，并检查受影响的用户流程。
2. 清楚说明它拥有的权限
Astra 可能会暂停以请求澄清。明确指定它可以执行哪些本地操作。将部署和外部消息置于单独的审批流程之后。
3. 保持项目 instructions 一致
检查 `AGENTS.md` 和相关 skills。OpenAI 警告称，冲突的 instructions 可能会中断进度。删除过时或相互矛盾的规则。
4. 让测试匹配更改内容
要求能够捕获实际故障的检查。Astra 可能会在小任务上过度扩展测试；额外检查应当针对尚未解决的问题。
5. 为 reviewers 分配具体任务
对于高风险更改，为 reviewer 分配权限、故障处理或 regression 方面的任务。说明何时进行 delegation；Astra 进行 delegation 的频率可能低于预期。Official prompting guidance。
我的多 agent code review workflow将独立 review 与最终 writer 分开。对于重大更改，我会采用这种结构，而不是让多个 agent 同时编辑相同文件。
接下来我会在哪里使用 Astra
接下来的测试将涉及跨多个层的 backend bugs、症状具有误导性的 integration problems，以及代码更改后的 browser checks。这些都是对早期 reviewers 所描述优势的有用测试。
对于 visual design，我会进行单独比较。在将日常工作交给成本更高的模型之前，我也会比较完成任务的成本。
这次 CRM 会话给了我继续测试 Astra 的具体理由：三个故障得到了理解和修复，而剩余的集成问题仍然清晰可见。我希望 agent 能够区分这两者。本地仪表板成功打开是一种进展。经过 review、完成部署且集成健康的功能，则是另一个里程碑。
*披露：本文是在审阅我的 Git 更改、会话记录和所链接来源的基础上，在 AI 协助下完成的。主视觉是一幅编辑插图，并非 CRM 截图。*