2026 年 9 月 29 日，OpenAI 发布 GPT-6.1 Sol，并将它定位为以较低成本处理复杂工作的模型。对经常用 AI 写代码、改界面、查资料、做报告的人来说，这次更新值得关注的地方，是能否把一项有来回修改的工作持续做到交付，而不仅是第一次回答是否漂亮。官方提供了 发布介绍，开发者也可以直接查看 模型规格。
先看定位：把同一项工作做完，再比较价格
“接近 Astra”是官方对模型能力的描述，而不是每个任务都会得到同样结果的承诺。看模型选型时，我更关心两件事：一个真实任务能不能在有限的修改次数内完成，以及每次修改是否仍然遵守之前的约束。比如，做一个登录后可用的后台页面，模型可能很快画出首屏，但接下来的筛选、分页、错误提示、手机端布局和现有权限结构才决定成果是否可用。
因此，第一次尝试 Sol 不妨直接拿你最近做过、知道哪里困难的任务。把同一份输入交给 Sol 和 Astra，要求相同的文件、相同的质量检查和相同的工作范围。不要让一个模型只写方案，另一个模型真的改代码，然后比较费用。公平的比较应落在相同的完成状态上，例如页面能打开、数据口径正确、测试通过、你能继续编辑得到的文档。
官方评测，应该怎样读
发布页中的软件工程、专业工作、自动化与电脑操作等评测，可以帮你决定先从哪类任务试用。读曲线和柱状图时，需要一并看推理档位、运行条件和成本轴：单个输入或输出 token 的价格，只是费用的一部分；一个任务读了多少资料、思考了多久、调用了多少工具、是否返工，同样影响最终成本。图表告诉我们一组测试中的表现，真正选型仍要把你的输入和交付标准放进去。
把任务写成可交付的工作说明
很多时候，效果差不是因为一句话不够“高级”，而是要求里缺了可以执行的内容。给一个现有项目改功能时，建议把四项信息写清楚：现在是什么情况、希望用户看到什么、哪些文件或资料可以作为依据，以及如何知道工作已经完成。举个实际的任务：“在现有产品目录页加厂商筛选，沿用现有 URL 和中英文结构；搜索参数可以分享；桌面显示筛选栏，手机收起；验收时用三个真实筛选组合演示结果。”
这里面的技能点，是把模糊的愿望改成可观察的行为。你无需提前写出每一行代码，但需要说明产品行为和验收方式。模型完成一版后，反馈也要具体：不是“看着不舒服”，而是“手机上按钮挤在一行，360 像素宽时无法点击；把主要操作保留在第一行，次要操作放到下方”。这样下一轮能围绕一个真实问题修复，避免全页重画而丢掉已经满意的部分。
如果你做的是报告或演示文稿，可以采用相同方法。先要求整理事实表和引用，再形成结构，最后制作可编辑文件。让每一张图表对应一个明确的问题：趋势是不是变了，增长来自哪一类，哪项支出需要解释。模型写出一段顺畅的话之后，再检查它是否真的与原始表格一致。把“缺失值不要猜”“所有金额沿用源表单位”“观点必须注明依据”写进任务，比反复强调“专业一点”更有用。
Codex、Work 和 API，入口要分开看
官方首发说明列出的账户范围是 Plus、Pro、Business、Enterprise 和 Edu；Enterprise、Edu 默认关闭，需要管理员开启。Free 与 Go 不在 Sol 的首发范围。模型在 Codex 桌面端、CLI 和 ChatGPT Work 中逐步提供，实际按钮还取决于客户端和工作区设置。在 ChatGPT 中，Work、Codex 的模型可用性不能当成普通 Chat 的模型列表。查看官方可用性说明。
使用桌面端时，先从账户默认的 Power 设置开始；需要更深的分析时再向 Smarter 调整，需要控制等待与成本时向 Faster 调整。Advanced 中的具体模型、速度和推理选项是否出现，以账户实际界面为准。这里的 Light、Ultra 等标签属于产品控制；开发者写 API 请求时，reasoning.effort 的合法值是 low、medium、high、xhigh、max，其中 medium 为默认值，none 和 minimal 不支持。把客户端名称直接写进 API 会混淆两套控制方式。
API 使用 gpt-6.1-sol 这个标识。需要模型搜索网页、查文件或调用自定义函数时，使用 Responses API；Chat Completions 可以用于不带工具调用的请求。Sol 接受文本和图片并输出文本，图片生成则通过独立工具完成。对读者而言，这意味着一张截图可以作为分析材料，但要生成或编辑真正的图像，还需要工作环境启用相应工具。模型名称与一个包含工具、文件和权限的完整工作环境，是不同层面的选择。
codex -m gpt-6.1-sol这条命令适用于已经安装并登录的 Codex CLI。开始后可以这样下达第一项任务：“先查看现有项目说明，定位产品列表的筛选逻辑，再实现厂商筛选。复用现有样式；给出修改文件、三个筛选实例和验证结果。”命令只是选择模型，项目是否能访问、可用的工具和账户是否有权限，需要按实际环境判断。
百万上下文，怎样放资料才有用
模型的上下文窗口为 1,050,000 tokens，最大输入 922,000、最大输出 128,000。这个容量给长代码库和成组文档带来空间，但不应该变成“能放就全放”的习惯。上传之前，先把资料分成当前版本、历史背景和待核对信息。在任务开头告诉模型哪个文件是最终口径，遇到冲突要指出而不是自行合并。内容较多时，可以先让它列一份目录和关键约束，再开始修改或分析。
一个容易检验的做法，是让它在每个关键结论后写出文件名或小节位置。比如，合同条款整理应能回到具体条款；代码建议应能回到具体接口；数据结论应能回到列和筛选范围。只把文件放进上下文，却不检查引用，你很难知道模型是依据资料得出结论，还是用熟悉的说法补出了一个看似合理的答案。读长材料时，这一层可追溯性比文章字数更关键。
Multi-agent：适合拆开的工作可以并行
Sol 在 Responses API 中支持 Multi-agent beta。根智能体可以把独立的任务交给子智能体，再综合它们的结果。一个网站修改可以分别检查后端流程、页面结构和已有测试；一组资料可以分配不同来源，再汇总观点分歧。官方建议从默认的三个并行子智能体设置开始。这个功能并不意味着每项任务都值得拆分，子智能体也会增加 token 消耗。查看官方 Multi-agent 指南。
HTTP：工具结果需要接续请求
图中，某个子智能体提出函数调用后会暂停。应用执行函数，收集结果，再发起接续请求，让暂停的工作继续。这适合工具调用不多、流程简单的情况。实现时真正要保证的是：不要漏掉不同智能体产生的函数调用，每个结果都要对应它自己的调用标识。不能因为主任务已经有一段回答，就误认为所有分支都完成了。
WebSocket：结果准备好就继续对应分支
这张图展示了长连接的差别：一个工具完成后，结果可以注入仍在运行的响应，对应子智能体继续，不必等待其他分支走到同一个停顿点。适合工具较多、时间较长的流程。对产品团队来说，需要观察的是端到端等待时间是否下降，而不是看启动了多少个智能体。多个分支不断修改同一个文件，或者每一步都依赖上一条结果，反而可能增加协调负担。
价格怎么计算：用一个可以复核的例子
| Standard 计费项 | 输入 ≤272K tokens | 输入 >272K tokens |
|---|---|---|
| 输入 / 百万 tokens | $2 | $4 |
| 缓存读取 / 百万 tokens | $0.10 | $0.20 |
| 缓存写入 / 百万 tokens | $2.50 | $5 |
| 输出 / 百万 tokens | $10 | $15 |
长上下文门槛影响整次请求。Fast 为 Standard 的两倍，Batch 和 Flex 为标准价的一半；区域处理在适用情况下增加 10%，工具费用另外核对。以上是 API 美元价格，客户端订阅与 credits 采用产品自己的规则。查看价格与处理档位。
假设一次请求有 10 万未缓存输入 tokens 和 1 万计费输出 tokens，仅按短上下文标准文本费估算，是 0.20 美元加 0.10 美元，共 0.30 美元。这个例子只是计算方法，尚未计入其他计费项，也不是某个真实任务的报价。尤其在多轮任务里，模型可能反复读取材料、调用工具、运行检查；比较 Astra 和 Sol 时，应统计整个任务的使用量，不能只根据“$2 输入”就宣布总费用固定降低多少。
我会怎样决定是否把 Sol 设为常用模型
我会准备一组有代表性的任务：一个跨文件的功能修改、一份基于真实数字的报告、一个需要看截图的界面修复，再加一个长资料的整理。每项都记录是否第一次达到标准、后续改了几次、是否出现遗漏事实、总耗时和总费用。对于重复执行的工作，这些记录比一次非常漂亮的演示更有参考价值。
如果 Sol 在大多数任务中已经稳定完成，就可以让它承担常规复杂工作，把 Astra 留给你确认更困难、错误成本更高的部分。简单格式修改和批量提取还可以试更轻量的模型。这是一种基于任务的分配建议，不是我们已经完成的跑分结果。官方 模型选择指南 同样建议用相同输入测试，并保留满足质量要求的较轻设置。把模型当成工作配置来调整，会比始终追逐最强名称更容易控制日常使用。