GPT-6 Astra 使用指北：怎么把这个模型用顺

摘要：一些简单的使用 Tips 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