GPT-6 Astra 的能力强，很多人的第一反应也很一致：任务稍微复杂一点，就把推理强度开到最高；上下文尽可能全塞进去；工具能挂的全挂上；写完代码再多跑几轮检查。
结果往往是：任务还没完成，额度先没了。
省 Token 的关键并不是把所有提示词删短，更不是让模型少做必要的思考。真正应该减少的，是无关上下文、重复工具定义、无效输出、已经通过后的重复验证，以及每一轮从零开始建立任务理解。
OpenAI 目前为 GPT-6 Astra 提供 low、medium、high、xhigh 和 max 五档 reasoning.effort，同时支持提示词缓存、上下文压缩、持久化推理和工具搜索。官方模型页、官方模型指南
下面这套方法，适合用来搭建更稳、更省的日常工作流。
先把推理强度当成“任务预算”，不是能力开关
reasoning.effort 调整的是模型在当前任务里愿意投入多少思考、搜索和验证预算，并不是在切换一套完全不同的模型。
因此，不能简单理解成“越高越聪明，越高越值得开”。真正应该问的是：这件事做错后，要花多少时间和成本返工？
| 任务类型 | 推荐起点 | 什么时候升级 |
|---|---|---|
| 信息抽取、分类、短改写、格式整理、小型修改 | low |
发现遗漏，或需要跨材料核对 |
| 常规编码、文档整理、多步工具调用 | medium |
出现跨模块依赖、需求缺口或测试失败 |
| 仓库级改动、复杂排错、执行既定计划 | high |
路线仍不清晰，或失败代价显著上升 |
| 架构取舍、迁移前审查、疑难根因分析 | xhigh / max |
额外研究确实可能改变最终决策 |
一个短任务用 low 通过验收，已经是好结果。用更高档位写出更长的解释，不会让它更正确。
反过来，涉及数据迁移、认证逻辑、架构路线或大范围重构的任务，前期多花一点思考预算有价值，因为它可能避免一次昂贵的返工。
复杂任务分两段：先想清楚，再执行
许多 Token 浪费，来自让模型从头到尾一直保持高强度。更稳的方式是把复杂任务拆成两段。
第一段是规划：让模型阅读相关材料、列出假设与风险、比较路线、给出可以验收的执行计划。这里可以使用较高推理强度，因为目标是减少方向错误。
第二段是执行：把确认过的计划拆成小改动，使用 medium 或 high 完成，并限定本次需要的测试范围。OpenAI 文档建议，在标准单 Agent 对话中使用 configuration_update 调整后续推理强度，从而不必为了换档重写整段稳定提示词前缀。官方模型指南
这样做的好处是：方案有问题，就回到规划阶段；执行有问题，就直接看当前改动与测试结果。每一段都能独立复盘。
一个容易执行的规则是：同一路径连续两次没有得到可验收结果，就不要在原档位里无限重试。先判断是信息不足、工具失败，还是路线本身错误；只有额外推理能解决问题时才升级强度。
提示词不要盲目变短，要让稳定部分稳定
缓存最喜欢的是可复用的前缀。系统规则、输出格式、长期资料、固定工具说明和数据边界，应该保持内容与顺序稳定；用户本轮需求、时间、变量和临时材料则放在后面。
很多人为了“省 Token”，每一轮都重写系统提示词，或者把固定规则压缩成不同版本。这可能破坏缓存匹配，让看似更短的请求变得更贵。
GPT-6 Astra 的公开价格区分普通输入、缓存输入、缓存写入和输出。具体费用要以账户、调用模式和账单为准，但这个定价结构说明了一件事：可复用的稳定前缀有实际价值。官方模型页
稳定不代表堆满内容。过期、相互矛盾、与当前产品无关的长指令，仍然应该删掉。目标是留下真正影响交付质量的“产品契约”。
工具只在需要时出现
浏览器、搜索、数据库、设计、邮件、日历、代码、图片、PDF……每个工具的说明和参数都会占据上下文。一个 Agent 有二十个工具，不等于每次请求都该把二十个工具塞给模型。
更合适的设计是按阶段加载：
- 研究阶段只提供检索与文件读取；
- 实现阶段再增加代码、终端和测试工具；
- 发布阶段才加入部署或外部写入能力。
OpenAI 的模型指南建议，在适合的场景使用 Tool Search 和按需加载，让模型只在任务需要时获取工具定义。官方模型指南
这不仅节省输入 Token，也降低了模型误选无关工具的概率。工具集应该服务于当前阶段的明确目标，而不是展示系统拥有多少能力。
两个常见误区
误区一：把所有资料都塞进上下文。 材料越多并不一定越可靠。先让检索或人工筛出本轮真正要用的文件，再传入原文片段和明确的引用任务。这样更容易发现证据不足，也减少模型在无关信息里绕路。
误区二：为了省钱，完全取消验证。 省下的一次测试，可能在后续引入更大的返工。正确做法是缩小验证范围：小改动跑相关检查，高风险改动扩大验证，并把停止条件写清楚。
长任务延续状态，但不要无限积累历史
在多轮任务中，工具输出、关键决定和中间结论本来就属于任务状态。每一轮都重新发送完整项目背景，不仅贵，也更容易让模型在不同版本的上下文里反复横跳。
Responses API 支持通过 previous_response_id 延续前一轮响应；接口还提供 prompt_cache_key、缓存选项与缓存诊断字段，帮助应用维护和观察可复用上下文。Responses API 参考
但“延续”不等于把所有历史永久留在活动窗口里。长任务更需要三类可检索记录：
- 已确认的目标、约束与决策；
- 当前文件版本、测试结果和待办；
- 可以丢弃的旧讨论与失败尝试。
把前两类压缩成任务笔记或状态摘要，把第三类移出当前上下文。这样模型能带着正确的历史继续工作，而不是反复阅读已经失效的过程噪声。
限制输出，不等于限制思考
很多日常任务只需要结论、差异和下一步。若不说明，模型可能写出长背景、重复复述需求，再附上一段没有执行价值的总结。
可以把输出要求写得具体：
只输出问题列表、修改建议和验证结果；每项最多三条；不复述任务；没有发现则明确写“未发现”。
这会减少无用输出 Token，也让验收更快。对于评审、技术方案和风险分析等任务，再明确要求它给出完整依据。关键是由交付物决定篇幅，而不是把“简短”设成绝对原则。
验证要与改动风险匹配
GPT-6 Astra 在编码任务中可能会主动做更多检查。对高风险改动，这是优点；对小而可逆的改动，在必要检查已经通过后继续跑完整测试、反复扫描边缘场景，可能只是增加成本。
在任务中明确三件事：
- 本次哪些检查必须执行；
- 什么结果算通过；
- 必要检查通过后何时停止。
OpenAI 的模型指南也提示，应避免在没有新修改、失败或未解决疑点时重复扩大验证范围。官方模型指南
这不是降低质量，而是把验证预算用在真正存在风险的地方。
最后看“合格交付成本”，不要只看单次 Token
优化是否有效，不能只看一次调用少了多少 Token。至少应记录以下指标：
| 指标 | 它回答的问题 |
|---|---|
| 输入、输出与推理 Token | 成本主要出在理解、生成还是思考 |
| 缓存命中与可复用 Token | 稳定前缀是否真的发挥作用 |
| 工具调用与失败次数 | 工具集是否太宽，或工具定义不清楚 |
| 重试与人工修复次数 | 低成本首轮是否制造了返工 |
| 合格交付耗时 | 优化是否真正改善最终效率 |
每次只改一个变量：推理档位、输出长度、工具集、提示词顺序或状态传递方式。用同一批代表性任务比较，才能知道哪一项真的有效。
今天就能执行的 20 分钟检查
如果你还没有完整的可观测系统，先做以下五件事：
- 找出过去一周最常见的三类任务，各选两条真实样本；
- 为每类任务写一条验收标准，避免只凭“回答看起来不错”判断；
- 把系统规则与工具说明整理为稳定前缀，把本轮变量移到末尾；
- 为研究、实现、发布三个阶段分别列出最小工具集；
- 记录每个样本的总 Token、工具调用、重试次数、人工修正时间和最终是否通过。
完成这一步后，再去比较 low、medium 与 high，调整才会有依据。没有基线的“优化”，通常只是在把成本从一个环节挪到另一个环节。
最省 Token 的工作流，不是永远用最低档位，也不是永远压缩 Prompt。它是让简单任务不过度思考，让稳定上下文被复用，让工具只在需要时出现，让高强度集中在关键节点，并用清晰验收标准阻止无效返工。
