GPT-6 Astra 进入 Codex 后，我更关心一个实际问题：日常开发是否有必要全部切到 GPT-6？
我的建议是，把 GPT-5.6 留在日常工作流里，根据任务中的不确定性和失败代价，把关键阶段交给 Astra。这里的 5.6 还要分清 Sol、Terra 和 Luna：复杂分析与细节打磨、日常实现、规则明确的批处理，适合不同的能力与成本档位。
OpenAI 在 2026 年 8 月 31 日至 9 月 4 日的官方更新中介绍了 Astra 在 Codex 和 ChatGPT Work 中的应用。新的模型定位、实验性上下文管理和计费差异，已经足以影响团队怎样分配任务。下面的任务分工是基于这些官方边界给出的工程建议，并非同一仓库上的实测排名。
5.6 继续做日常工作，6 接手高不确定性的部分
官方将 Astra 定位于需要持续推理和判断、跨多个步骤与工具的复杂工作；Sol 仍面向复杂开放任务，Terra 面向日常工作，Luna 面向明确、可重复的任务。这些定位有重叠，不能简单理解成“5.6 只会简单题”。
实际选模型时，可以先看任务的验收条件是否明确、改动是否局部，以及一旦做错是否容易发现。
| 开发任务 | 建议起点 | 什么时候值得交给 Astra |
|---|---|---|
| 按已有模式补 API、单元测试、类型定义 | 5.6 Terra | 现有模式本身存在问题，需要重新判断行为约定 |
| 提取日志字段、整理已确认的问题清单、固定格式转换 | 5.6 Luna，先抽样验证 | 信息互相矛盾，必须结合代码推断根因 |
| 有稳定复现步骤的单模块 Bug | 5.6 Terra 或 Sol | 排查跨越缓存、队列、数据库、客户端时序，多个假设都合理 |
| 模块边界调整、权限模型改造、兼容旧数据的重构 | 5.6 Sol 或直接用 Astra | 需要同时权衡多个约束，错误难以靠现有测试暴露 |
| 从需求澄清到实现、浏览器验证的长任务 | 根据复杂度用 Sol 或 Astra | 多阶段之间依赖强，过程中新证据会改变整体方案 |
比如“给文章列表补一个发布按钮”，如果后端已有状态更新接口，先交给 Terra 或 Sol 很合理。任务边界可以写得很具体：只对草稿显示发布入口、提交前确认、成功后刷新状态、失败时保留原状态。
但如果问题变成“发布、撤回、缓存、搜索索引和权限审计怎样保持一致”，就值得让 Astra 参与设计。难点已经从写一个按钮变成了跨系统约束，以及失败后如何恢复。
这些分工不需要以“5.6 失败一次”为前提。权限迁移、支付幂等、生产数据变更等失败代价高的任务，可以直接用 Astra 做方案分析，再由人审核关键决策。
升级的信号是卡在判断上
模型报错后立刻升级，往往只会换一个更贵的模型重新撞墙。依赖缺失、网络不可达、没有权限、测试数据库没启动，都应该先修复环境。Astra 的访问资格也不能扩大沙箱权限。
值得升级的信号更具体：
- 多次修复围绕同一个症状打转，始终没有排除根因。
- 代码改动涉及多个模块，局部正确但整体约定互相冲突。
- 必须在兼容性、性能、数据一致性和回滚成本之间作取舍。
- 任务进行到一半出现新约束，需要重新评估此前方案。
例如，5.6 已经定位到重复请求会导致重复扣款，但修补方式只是增加一个前端按钮锁。此时升级后的问题应该是：“后端幂等键、事务边界和消息重投怎样配合，哪些失败窗口还会重复扣款？”如果继续只说“再修一下”，新增的推理预算很容易浪费在同一条错误路径上。
升级前带上复现步骤、已排除的假设、关键日志和真实 diff。更强的模型也需要证据来判断。
分工合作要围绕可交接的结果
一种实用的工作方式是：5.6 收集事实，Astra 处理跨模块判断，5.6 按明确方案实施，最后用测试与人工审阅验收。但小任务没有必要经历全部阶段，交接本身也有成本。
以“登录后偶发掉线”为例，可以这样拆：
- Terra 收集证据。 找到登录、刷新令牌和退出登录的实现，列出 Cookie 属性、过期时间、并发请求路径和现有测试。先提交带文件位置的事实清单。
- Astra 判断根因。 结合复现和请求顺序，判断是否存在刷新令牌竞争、旧响应覆盖新状态等问题。输出需要改动的边界、备选方案和验证条件。
- Terra 或 Sol 完成实现。 在审核后的方案内修改代码，增加覆盖失败时序的测试；遇到新的结构性问题再交回分析阶段。
- 人工核验结果。 检查变更 diff、运行测试、复现原故障。需要时让 Sol 或 Astra 做第二轮代码审阅，但模型的认可不能代替运行证据。
交接记录可以直接使用下面的模板：
任务：修复登录后偶发掉线
代码基线：分支、提交号，以及当前未提交 diff
必须保持：已有登录协议、Cookie 安全属性、服务端权限判断
可观察故障：复现步骤、请求顺序、实际与预期结果
已确认事实：文件路径、关键函数、脱敏日志
尚未确认：待验证假设及缺少的证据
已经执行：修改过的文件、运行命令、测试结果
下一步范围：只分析 / 允许修改哪些文件
完成标准：原故障不再复现，相关回归用例通过
模型自称“已跑测试”不够，交接时要带命令和退出结果。也不要让两条会话同时修改同一文件；并行实现需要独立工作区和明确的合并责任。
这套方法可以由人手动切换模型或开启新任务完成。它并不意味着所有客户端都支持自动安排不同模型的子 Agent。切换或新建会话时，还要检查实际模型选择和上下文是否保留，不能假定旧会话状态已经完整传递。
Astra 的长任务能力有明确的产品边界
官方模型文档列出一项值得关注的实验：在受支持的 Codex 客户端中，Astra 可以跨上下文窗口保留笔记，并搜索同一任务此前的消息和工具结果。
这会改变长任务的恢复方式。过去单靠压缩摘要继续任务，某个早期约束可能不再处于当前上下文；历史检索为重新找到原始证据提供了另一种方式。但文档描述不能证明每次检索都完整，也不能代替仓库里的测试结果和任务记录。
这项实验默认关闭，首发仅面向符合条件的 ChatGPT Plus / Pro 登录用户，不支持 Business、Enterprise 或 API Key 登录。个人账户上验证过的工作流，迁到企业账户时需要重新验收。这里的历史检索范围是同一任务，不能推导为任意跨任务记忆。
模型可用入口也要分开看：官方模型表列出 Astra 支持桌面端、ChatGPT Work 网页、Codex CLI 和 IDE 扩展，Codex cloud 则标记为不支持。ChatGPT 工作区启用模型，不会自动授予 API 组织和项目的访问权。
企业首发还有额外条件：官方说明初期组织需要具备 Daybreak 访问资格，管理员才能启用 Astra；Enterprise 在发布后的前两周默认关闭。这些是有时间范围的上线条件，实际使用前应核对当前工作区设置。
另一个影响长跑的边界是安全监控。Astra 在 Codex 和 Work 中使用异步监控，任务可能在触发行为之后才暂停。官方说明 CLI、移动端以及某些数据控制条件下无法使用完整的查看与恢复流程，任务会结束。因此，长任务执行到重要节点时仍应保留 diff、工具结果和可恢复的业务状态。
成本要算到任务完成，而不是只比单次费率
按照官方 Codex token 信用点计费表，标准模式下的对照如下。单位是每百万 token 的 credits，不是 OpenAI API 美元价格，也不是固定的每任务费用。
| 模型 | 输入 | 缓存输入 | 输出 |
|---|---|---|---|
| GPT-5.6 Sol | 100 | 10 | 500 |
| GPT-6 Astra | 250 | 25 | 1,250 |
在输入、缓存输入和输出用量完全相同的前提下，Astra 标准费率是 Sol 的 2.5 倍。Astra Fast 模式又对 Astra 标准费率乘以 2.5；部分 Enterprise 客户仍适用旧费率表，需要以自己的计费安排为准。
举一个纯计算示例：假设一次任务消耗 10 万未缓存输入 token 和 2 万输出 token，没有其他费用，Sol 为 20 credits，Astra 标准模式为 50 credits，Astra Fast 为 125 credits。这个例子不代表真实任务的典型消耗；推理、重试、工具结果和交接历史都可能改变最终用量。
所以，5.6 与 6 分工的收益不能只看模型费率。Astra 如果减少了几轮无效修补或人工排查，整项任务可能更划算；如果只是处理一个字段改名，多一次模型交接反而可能增加成本。这两种结果都需要从自己的工作流里测出来。
可选三类已经有明确验收条件的历史任务做比较：局部修复、跨模块 Bug、完整功能交付。在相同代码基线、工具权限和测试条件下，分别尝试 5.6 单独完成、Astra 单独完成，以及两者分工。记录实际模型与推理档位、总用量、总耗时、人工介入次数和最终缺陷，而不是只记录第一次回答速度。
不要提前假定高推理档一定更省返工。先用能完成任务的较低档位，只有明确卡在分析和判断上时再增加预算。
把模型选择落到任务边界上
日常可以从一个简单规则开始：验收清楚、改动局部的工作交给 5.6 Terra；需要更多分析和细节打磨的任务使用 Sol；规则明确的批量工作试用 Luna。遇到跨模块决策、高失败代价或多阶段强依赖时，把 Astra 放到关键位置。
完成复杂决策后，也不必为了“已经用了 6”而让它继续处理所有重复细节。方案边界稳定、交接成本可控时，可以把实现交回 5.6；如果任务还在不断发现新约束，继续保留 Astra 的完整上下文可能更合适。
最终决定分工是否有效的，是功能有没有正确交付、原故障有没有被复现并修复、人工返工有没有减少。模型升级应当服务这些结果。