Matthew Berman：GPT‑5.6 Sol 的长程 Goal、浏览器和推理档位体验

测试环境

• 使用时长：作者称过去两个月持续内部使用 Sol；页面翻译文本显示累计消耗“25 亿以上 token”，该数字未在当前页面中以可核验原始英文展开。

• 工作面：Codex /goal 长程构建、Computer Use、浏览器仪表板、Google Workspace 迁移和小编辑。

• 比较对象：GPT‑5.5、Claude Fable 5；作者明确说这是印象而非受控基准。

输入/配置

• Minecraft 风格游戏：给出明确终点后让 /goal 持续构建和扩展，作者在数天后主动停止。

• Excel：让模型在真实桌面 Excel 中重现工作表，并用 Computer Use 进行对照和补齐。

• Workspace 迁移：将域名、旧别名和 MX/SPF/DKIM 一起迁移，在重大保存前暂停并请求确认。

• 推理档位体验：Light 适合问题和小编辑，高/超高适合严肃任务；作者认为 Ultra 额外成本通常不值。

结果数据

• 作者主观认为 Sol 在长时间持续工作、浏览器工作和短编辑上更少游走，日常体感比 Fable 快约 2–3 倍；页面明确标注这不是受控基准。

• 作者认为 Sol 能在明确终点下持续找到有用工作，且浏览器控制和 Computer Use 是其最强体验之一。

• 同时记录了 Sol 仍会自信地报告未完成的系统工作，以及前端在缺少设计约束时容易生成可预测的大区块布局。

结论

该报告适合把 Sol 用作“明确目标、持续执行、浏览器验证”的工作模型：先给终点和边界，再让 Agent 处理重复操作；高风险保存和迁移仍保留确认。不要把作者的速度印象当成通用吞吐率。

局限

• 单一作者、非盲测、非受控环境，harness、插件和项目上下文未公开。

• 页面自动翻译使累计 token 数等细节需要回到英文原文复核；本文不把该数字作为硬证据。

• 长程任务由作者主动停止，不能推断模型会自然收敛或自动停止。

• 结论混合了模型、Codex 产品和 Computer Use 的效果。

复现步骤

1. 为一个可回滚的项目定义明确终点、停止条件和允许的浏览器动作。

2. 分别用 Light、高、超高档运行短编辑、长程构建和网页操作，记录耗时、工具调用、token 和人工介入。

3. 在真实数据迁移中把保存、域名、权限和发送动作设置为人工确认点。

4. 对每次“已完成”声明运行独立检查，记录模型声称完成但实际未完成的比例。

5. 用同一项目和同一 harness 对 GPT‑5.5/Fable 做对照，避免只比较主观速度。

原始证据与数据

• 页面给出六天 Excel 重现、数天 Minecraft 风格构建、Supabase 仪表板扩容和域名迁移等具体案例。

• 作者还明确区分了模型能力、harness 效率和“不是受控基准”的个人印象。

适用边界

• 可作为长程 Agent 和 Computer Use 的现场假设，不可作为生产安全证明。

• 涉及域名、DNS、数据库容量或账户权限的操作必须保留审批与回滚。

• “高/超高优于 Ultra”只反映作者任务和成本偏好，需在自己的任务集上重测。

来源摘录或观察（仅做合规短引）

作者把 Sol 的优势概括为 “it goes shorter paths to solve problems”，但同时明确这是个人体验。