我和 Codex / Claude Code 的聊天记录里，有个词出现得特别多：
“继续工作”
读完代码了，继续工作。方案列完了，继续工作。改完一个文件，它说剩下的也可以帮我做。。。
那你倒是做啊。
另一头也挺烦。你只让它修一个小问题，它顺手重构三个模块，补一套暂时用不上的抽象，再认真告诉你：架构现在更完整了。
代码能力越来越强，我这个监工倒是一点没闲下来。
所以这次 GPT-6 Astra 出来，我翻官方文档时，最在意的是它怎么处理工作进行到一半之后的事：工具还没返回怎么办，我突然改要求怎么办，项目里那些给旧模型写的规矩怎么办。
以前写 CoreCoder 的时候，最薄的 Agent 循环，几行就能讲清楚。真把它放进日常开发，时间会花在这些地方。
先聊官方公开的接口和行为，完整的工程任务横评我还没跑。至于这些改动能不能让我少当一会儿监工，我有期待，也有几个具体的疑问。
你说”等等”以后，它到底停了什么？
先说一个很容易被当成聊天体验的小功能：mid-turn steering。
假设你让 Agent 改一套接口。它正在干活，你发现下游还有老客户端，于是补一句：
「等下，旧接口先保留。只改内部实现，别动返回格式。」
Astra 的 Responses API 可以通过 WebSocket 接收这类执行中的更新，再把新要求带进后续响应。开发者对应的事件叫 response.steer。
有些 Agent 产品早就能让用户中途插话了。所以不能把这件事说成 OpenAI 发明了「打断 AI」。这里值得看的，是 API 给这次改需求定义了什么行为。
我特意留意了文档里一句限制：steering 不会撤销已经执行的动作，也不会取消已经开始的工具。
这句话比功能名重要。
它已经写进文件的东西，不会因为你说了「等等」就自己恢复；已经发出去的请求，也不会倒着飞回来。API 回一个 accepted，只说明新要求排进去了，还不能说明模型已经按新要求行动。官方说明
「收到，我不做了」和「那个操作确实没有发生」，中间隔着你得亲自处理的状态。
拿代码任务来说，用户改了要求，刚才启动的测试却还在跑。等测试结果回来，它验证的是旧代码，还是新代码？旧方案的结果，会不会被拿来给新方案盖章？
如果只是聊天，搞错了可以再解释一句。接上发邮件、改数据库、部署服务，这种含糊就很贵。
所以我看这个能力，会连着看工具取消、执行记录和权限检查。中途改需求有了更直接的通道，之前发生过什么，仍然得记清楚。
等测试的时候，别把整个 Agent 一起挂起
另一个变化是 async tool calling。
以前最直接的写法是：模型要求跑测试，程序去跑，等结果回来，再让模型继续。测试要等两分钟，这两分钟就一起等着。
这次可以把自己执行的 function 或 custom tool 标成 async: true。模型发出调用以后，可以先处理不依赖结果的工作；工具完成后，应用再用原来的 call_id 把结果送回来。官方说明
比如测试在跑，它先去看依赖升级的变更说明。这很合理。测试没跑完，它先写下「所有测试通过」，就不合理。
差别在于，它知不知道自己正在等什么。
这也不是给 Python 函数加个 async def 就能等价实现的。后台开线程，本来就可以做；这里变化的是模型调用工具之后，能否继续往下工作，以及晚到的结果怎样接回当前对话。
工程上有个小细节挺好：结果得回到原来的调用上。不能因为 A 比 B 先结束，就把两份结果按完成顺序随便塞回去。
还有，工具仍然是你的程序执行，后台任务也归你管。这个开关没有顺便送你一套可靠的任务调度系统。
我喜欢这个方向。但评测它时，我会故意让一个工具慢一点、一个工具报错，再把结果顺序打乱。看它还能不能分清哪些工作做完了，哪些只是启动了。
这一点，比正常网络下一次跑通更能说明问题。
模型更听话，你的旧规矩反而可能出问题
官方迁移文档还有一段，我觉得老用户应该认真看。
OpenAI 提醒：Astra 对 skills、AGENTS.md 这类文件里的指令可能更敏感；含糊或相互冲突的规则，可能让它提早停下来。它也更倾向于在一些地方向用户澄清。官方说明
我看到这里，想到了项目里很容易同时出现的两句话。
「任何修改前都要先确认。」
「任务没有完成就不要停。」
单独看都没什么问题。一起放进项目里，再碰上几个各有规矩的 skill，模型到底该听哪一句？
我们给旧模型打过很多补丁。它有一次乱改，就加一条「不要擅自修改」。它有一次停太早，再加一条「必须完成全部工作」。半年下来，项目说明成了模型犯错记录的合集。
换一个更认真遵守指令的模型，这笔旧账就不一定能继续糊过去了。
我会把边界写具体。比如，这个任务可以修改本地代码、补必要测试；不要推远端、不要部署。这样它知道哪些事情已经允许做，哪些事情确实需要停下来问。
保留清楚的边界，清掉互相矛盾的补丁，通常比再追加一句「你必须自主完成」有意义。
但也别把所有问题都甩给用户不会写 prompt。正常人就是会说得不完整、临时改主意。模型和产品得逐渐适应这种工作方式，总不能要求用户先写出一份滴水不漏的规格书，才配用 Agent。
贵了以后，得拿什么说服我？
看完功能，我还是会回去看价格。
按目前官方短上下文 Standard API 价格，每百万输入／输出 token，Astra 是 10／50 美元，GPT-5.6 Sol 是 4／20 美元。相同计费条件下，这两项单价都是 2.5 倍；Sol 当前是促销价。官方价格
这不便宜。
只做一笔简化账：不算缓存、工具费和其他附加项，假设两个模型都用 10 万输入、2 万输出计费 token。Sol 是 0.8 美元，Astra 是 2 美元。这是假设用量下的算术，不是我测出来的账单。
更强的模型当然可能少走弯路，少重试，最后反而更划算。但「可能」不能直接记进我的余额。它能省多少，得在同一批任务上，把成功和失败的消耗都算进去。
我还会记另一个数：我被叫回来几次。
一次把补丁做对，给出能复核的验证结果，我愿意为这个付钱。如果它只是花更多 token 写出一份更漂亮的计划，最后还要我接着敲「继续工作」，那对我的价值就有限。
100 多万的上下文窗口也是一样。能装下很多东西很有用，但我更想知道，它最后会不会拿三小时前已经作废的要求，否掉我刚刚说的新要求。容量数字回答不了这个问题。模型规格
把这些变化放在一起，我觉得 Astra 这次挺值得认真用一用。
它开始把工作中那些不整齐的部分放进接口里：会等人，会被打断，会同时有几件事没做完。对重度用户来说，这些事情每天都在发生。
如果让我选一个测试场景，我会给它一个不那么干净的旧项目：里面有我的未提交改动，有过期说明，有一条原本就失败的测试。改到一半，再补一个合理的新要求。
然后看它能不能在不覆盖我原来改动的前提下，把这件事做完，讲清楚哪些地方验证过、哪些地方还没把握。中间需要我判断的，再来问我。
这样的任务，不像一张跑分图那么好转发。但我每天用的就是这样的项目。
真能把它们处理顺了，我应该能少说几句「继续工作」，放心去吃顿饭。
