GPT-6 Astra 发布之后，OpenAI 同步更新了一份模型使用指南。在这份指南中，官方给出了一些使用指南：任务怎么交代、上下文怎么组织、长任务怎么中途调整，以及怎样控制模型的自主程度。
本文将结合这份指南，整理一套适合日常使用 GPT-6 Astra 的方法和注意事项。
执行权限要清楚
GPT-6 Astra 在遇到可能影响最终结果的信息缺失时，会倾向停下来询问用户。这个特性适合需要确认需求的场景，但放进 Agent 后，会遇到明明可以继续但模型却停下来等确认的情况。
所以，在 Prompt 里明确模型能够自主推进到什么程度很重要。比如，你可以告诉它：
根据当前任务和已有上下文判断用户意图。
对于可逆、只读或者当前任务明确授权的操作，自行继续执行，直到完成目标。
只有缺失的信息会明显改变最终结果时，再询问用户。
如果 Agent 有部署、发布、合并 PR 之类需要人工确认的步骤，也可以进一步约定：先完成分析、修改和验证，把可检查的结果准备好，再请求最终确认。
这样，可以减少任务执行过程中频繁停顿。
检查旧规则
GPT-6 Astra 对上下文中的指令会更敏感。除了当前的 Prompt，Skill、AGENTS.md 和其他规则文件里的内容，都会影响它的任务执行。因此，可以检查这些文件中是否存在模糊或冲突的要求。
比如一个 Skill 写着：
修改代码前先请求确认
另一个项目规则又写着：
修复问题时自行修改并运行测试
如果这类规则同时进入上下文，Astra 可能会停下来判断应该遵循哪一个规则。因此，如果项目里使用了多套 Skill 或规则文件，最好把优先级也写清楚，例如：
当前用户明确提出的要求优先于 Skill 中的一般性建议。
遇到模型突然停止、请求额外确认或偏离预期时，也可以让它说明是哪一条规则影响了当前决策，方便排查隐藏在上下文里的指令。
输出风格写进 Prompt
GPT-6 Astra 比较喜欢用 Markdown、列表和表格组织内容，回答也容易写得比较完整。如果应用对输出形式有自己的要求，最好提前规定。比如：
使用简洁的连续段落。
只有并列信息适合比较时才使用列表。
技术解释保留必要细节，避免重复总结。
如果是面向开发者的产品，还可以规定：
是否保留代码块
是否输出 Markdown
回答长度
是否先给结论
是否使用表格
面向什么技术背景的用户
Astra 的指南文档专门增加了写作风格的相关建议，是在提醒我们：输出格式也应该成为模型配置的一部分。
中途修改要求
GPT-6 Astra 新增了 Mid-turn Steering 功能。以前一个长任务开始运行后，如果用户突然想到：
数据库部分先别动。
或者：
前端改成 TypeScript。
一般需要等当前请求结束后，再把新的要求作为下一轮输入。现在通过 WebSocket 使用 Responses API 时，可以在模型工作过程中发送新的用户指令。系统会保留前面完成的工作，再根据新的要求继续执行。
长时间运行的 Agent 会经历多个执行阶段，任务过程中也可能需要临时调整方向或补充约束。比如：
分析仓库
→ 找到问题
→ 修改代码
→ 运行测试
→ 修复失败
执行到中间阶段时，用户仍然可以纠正方向、补充条件或者修改任务范围，不需要重新开始整个任务。
异步执行
另一个需要了解的新能力是 Async Tool Calling。将 function 或 custom tool 设置：async: true 之后，在工具执行期间，GPT-6 Astra 可以继续处理不依赖该工具结果的工作，也可以发起其他工具调用。工具完成后，再通过原来的 call_id 返回结果。
比如一个 Agent 同时需要：
查询远程数据
读取本地文件
分析代码
生成修改方案
其中远程查询可能需要几秒甚至更久。这时可以让远程工具异步运行，同时继续读取文件和分析代码，减少等待工具结果造成的空档。而具体的工具执行和 pending 状态管理仍由应用负责。
弹性的推理强度
GPT-6 Astra 还支持在对话过程中调整 reasoning effort。比如：
简单信息提取 → low
复杂代码定位 → high
修改后的说明 → low
可以通过 configuration_update 修改后续请求的推理强度。
这样有个好处是不需要重新修改前面的 Prompt prefix，因此可以继续利用 Prompt Cache。新的 reasoning effort 会一直生效，直到再次更新。
对于一个包含很多阶段的 Agent，其实没必要让整条任务链都保持相同推理强度。
提前规定工作范围
GPT-6 Astra 支持 Subagent，但是如果你希望它积极拆分任务并行执行，需要在 Prompt 里说明什么时候使用 Subagent。
比如可以规定：
存在相互独立的研究、代码分析或验证任务时，允许拆给多个 Subagent 并行完成。
代码任务还有一个类似的问题。Astra 在修改代码后比较重视测试和验证，小改动也可能扩大测试范围。因此，可以提前告诉它：
运行与本次修改相关的测试。
相关检查通过后，如果没有新的失败或风险，继续完成任务，不重复扩大测试范围。
对于代码 Agent，这类约束可以减少很多额外执行。
检查配置
如果原来使用 GPT-5.x，迁移到 GPT-6 Astra 时还有几个配置需要处理。
首先，Astra 不支持 none reasoning effort。如果原来使用 none 或 minimal，建议先从 low 开始测试。工具调用需要使用 Responses API。
下面几个参数也不再支持：
temperature
top_p
top_logprobs
Chat Completions 还需要移除：
logprobs
从 GPT-5.5 或更早模型迁移 Prompt Cache 时，也要把旧的 prompt_cache_retention 配置换成：
prompt_cache_options.ttl = "30m"
如果应用需要在任务过程中切换 reasoning effort，可以优先考虑 configuration_update。
一个简单的使用思路
如果准备开始用 GPT-6 Astra，可以先检查下面几件事：
给模型明确的自主执行范围
清理 Skill、
AGENTS.md等上下文里的冲突规则明确回答长度、结构和格式
长任务考虑接入 Mid-turn Steering
耗时工具考虑 Async Tool Calling
根据任务阶段调整 reasoning effort
多 Agent 场景明确 Subagent 的使用条件
代码任务限定合理的测试范围
很多时候，换到一个新的模型之后，真正需要一起调整的还有围绕模型的 Prompt、工具和任务流程。
GPT-6 Astra 的这份官方指南，基本把这些容易影响实际使用体验的地方列了出来。
参考资料：OpenAI《Using GPT-6 Astra》developers.openai.com/api/docs/guides/latest-model?model=gpt-6-astra
