你好，我是司沐。

7月9日，OpenAI正式发布了GPT-5.6系列。

这次一共来了三个型号：旗舰Sol、均衡款Terra，以及便宜快速的Luna。

其中，Sol被摆在了整个系列的最顶端，面向复杂编码、科研、网络安全和长程Agent任务，还专门准备了能够调用子代理并行工作的Ultra模式。官方展示出来的几项Agent编程成绩也相当漂亮，价格则是每百万Token输入5美元、输出30美元，比它对标的Fable便宜很多。

发布前后的第一波评价也不差。有人说它写代码快，有人说它终于解决了OpenAI模型不擅长长程任务的问题，还有人对Ultra模式下的多代理协作寄予厚望。当然，很多早期评价都来自OpenAI员工和提前拿到权限的人，真正大规模的独立测试还没有完全铺开，但当时的舆论氛围，总体是兴奋多于怀疑。

我看到这些消息以后，自然也坐不住了。

作为一个重度使用AI Coding工具的Agent工程师，比起发布会上的Demo，我还是更好奇在真是的代码场景里它表现如何。于是我打开Cursor，点进了手头正在开发的项目。

这个需求并不复杂：开放平台的基本骨架已经搭好了，我需要在现有结构上增加几个MCP工具。相关服务层已经存在，数据模型也基本存在，工具注册方式、错误封装方式、测试目录和开发文档都可以参考。

我本来以为，这会是一次轻松愉快的新模型体验。

在之后的两个小时里，我为这个决定后悔了无数次。

一、我只是让它加几个工具，它给我成立了一个软件公司

最开始给Sol的要求写得其实相当详细。文档已经写好，明确指出了过程中开发哪些，更新哪些，复用哪些，不动哪些。对于以往和我朝夕相伴的Opus4.8（不是Fable，Fable太贵了）（绝非Claude软广，所有开发者可鉴，要能接到他们的商单我就真练成了）来说，这个粒度的文档已经非常够用了。

我原本以为这种提示词已经足够严谨了。

Sol看完以后，先没有急着写代码，而是检查分支、检查工作区、阅读开发记录、比较现有实现和设计文档，然后启动了一个只读子代理，对整个开放平台进行“全面缺口审计”。这个子代理读完项目以后，给出了一份相当正式的施工报告，把工作重新划分成N1到N5五个阶段，并列出了每个阶段涉及的文件、方法签名和推荐开发顺序。

单看这一步，其实还挺专业。

问题是，Sol看了这份报告后，开始了任务增殖。

N1阶段，它先处理API Key与分片键的绑定，然后启动一个子代理审查N1是否符合规格，再启动一个子代理审查代码质量。审查结束以后，它根据意见修改代码，随后又安排一次复审，确认刚才的修复是否真的完成。

进入N2以后，它开始实现Redis结果存储、窗口化响应、detail_id、预览截断、内容序列化、所有者隔离和缓存失败语义。写完以后，它再次进行规格审查、代码审查、安全加固、审查意见修复、加固复审和最终质量复核。

进入N3以后，它开始实现文档中的三个MCP工具，随后继续进行字段约束审查、所有权审查、懒加载依赖审查、工具注册范围审查、Schema完整性审查。每一次审查都可能发现几个问题，每发现几个问题，就再启动一个子代理修改；修改以后，再启动另一个子代理复审。

到了N4，它又开始处理上下文持久化和响应长度限制。然后是字段读取缺口检查、序列化上限检查、缓存持久化检查、代码质量检查，以及检查完以后的检查。

最后，它还做了一次所谓的“holistic review”，也就是整体性复查。这个复查又发现了一些事务提交顺序、展示持久化、生产密钥校验和部署文档方面的问题，于是再修改、再测试、再复核，最终向我宣布：257个测试通过，1个跳过，编译、Lint和diff检查全部干净。

整个过程看起来非常严谨。

严谨得像我不是让它增加几个MCP工具，而是让它独立完成载人登月系统的适航认证。

作为对比，我的好伙伴 Opus4.8 常见的工作流大概是：读文档、写代码、补测试、跑测试、Review一下、结束。

Sol的工作流则是：成立项目组、召开需求评审会、制定五阶段作战计划、每个阶段分别安排开发、规格审查、代码审查、整改、整改复核、阶段总结，五个阶段完成以后，再邀请一个不知道从哪里来的专家组进行终期验收。

在传统公司里，这种流程至少能养活二十个人。

在Cursor里，它只用我的Token账单养活了自己。

Sol 写完代码很高兴，那不高兴的人在哪呢？原来是我。大的还在后面。

二、问题一：它不是在执行设计，而是在一边开发，一边重新发明设计

Sol最严重的问题，并不是流程长，而是它在流程里逐渐忘记了自己的位置。

原本的设计中，我写的另一个平台会显式注入Agent会话相关的信息，请求本身也已经通过API Key进行身份认证。Sol在开发过程中却自行增加了一套名为OPEN_PLATFORM_CORVIA_CONTEXT_SECRET的HMAC签名机制，要求调用方额外携带签名请求头，用来证明会话信息确实由可信的服务注入。

乍一看，这似乎是一项很有安全意识的改进。

但当我追问它：“原先的设计里有这个吗？如果没有，你为什么要加上？”它承认，原设计里根本没有这套东西。这是它为了实现所谓的纵深防御，自己补进去的一层安全机制。

问题在于，当前API Key已经绑定用户，未来外部平台本身也会通过Token完成服务身份认证。这个额外的HMAC既没有引入新的身份主体，也没有形成新的权限边界，更没有解决API Key泄露以后无法解决的问题。相反，它增加了一份密钥、一套签名逻辑、一种请求头格式、一组配置项、一批测试，以及未来部署时的一整套运维负担。

最荒诞的是，当我把这些问题一条条指出来以后，Sol 也意识到了单独维护这个HMAC密钥没有必要，正确方式应该是依赖正式Token鉴权和会话归属校验。

也就是说，它先自作主张设计了一套不存在的协议，花Token实现它，花Token测试它，花Token审查它，花Token为它写配置，最后又花Token和我讨论为什么应该删掉它。

这是整个体验里最让我裂开的地方。

大模型当然可以提出架构建议，但“提出建议”和“未经批准直接改变协议”是两回事。如果一个改动会影响调用方、请求头、数据库结构、部署配置或安全边界，那么模型首先应该停下来问一句。

Sol没有问。

它从“我想到了一种更周全的做法”，直接跳到了“我有权替用户修改系统”。

这一点在官方发布的《GPT‑5.6 System Card》里也有提到（但这篇现在似乎打不开了：https://deploymentsafety.openai.com/gpt-5-6），5.6系列似乎比前代更容易代替用户做决定。或许这就是Agentic和MultiAgent训练数据的代价吧。但Claude可不这样啊

类似的事情还发生在数据库上。原本设计希望结果先进入缓存，其中一小部分选择性进入数据库——一个现有的会话表，但Sol左看看右看看，大手一挥加了一张新表，专门负责这部分数据落库。它宁愿自己写个新表出来，都不愿意调查如何接入旧系统。

当然，这个问题肯定可以通过更精细的文档与提示词解决，但关键在于，本场景里关于这里的提示词和上下文已经够精细了，如果换用Opus4.8，一定不会有理解偏差。

三、问题二：它把软件工程变成了一场自我证明的仪式

Sol特别喜欢Review。

听起来有点像表扬？毕竟过去大家经常批评编程，怎么写完代码就跑，不检查也不测试。现在模型终于知道审查代码了，难道不是进步吗？

理论上当然是。

但Review并不是越多越好。有效的Review应该引入新的视角，捕捉开发者没有意识到的问题；无效的Review只是让另一个上下文副本重新阅读同一份文档、同一批代码和同一组测试，然后用更正式的语言复述一遍。

这次任务中，Sol安排了规格审查、代码质量审查、安全审查、范围审查、Schema审查、最终质量审查和整体性审查。很多审查并没有发现架构问题，而是去在讨论某个字段描述够不够完整、某个错误映射是否足够统一、某段文档里的“持久化”应该改成“缓存”，或者某个Schema是否应该再多写一句格式说明。

这些事情也不是没有价值，但优先级远低于“你是不是正在实现用户真正要求的东西”。

结果就是，Sol在细节上越来越自信，在整体方向上却越走越远。十几个子代理共同确认某个字段的描述非常准确，却没有一个子代理站出来问：“等一下，用户原本允许我们增加这个字段吗？”

整个过程像极了一辆正在开向悬崖的车，乘客与司机紧张地认真讨论后视镜应该倾斜多少度。

后视镜调好了。

车也掉下去了。

四、问题三：测试全绿，不等于做对了

Sol最终给出了一组很漂亮的数字。

N2阶段，新增测试7个通过；开放平台原有测试45个通过；N3阶段逐步增加到112个、132个、161个；最终整体测试257个通过，只有1个跳过。同时Lint没有发现问题，git diff --check也顺利通过。

如果只看最终报告，这大概是一次堪称教科书的交付。

但问题在于，我们系统中原先设计出的测试点，也就只有三百多个。Sol仅仅为了开发我们系统中开放平台部分的三个新工具，就几乎写了等同于旧系统整体规模的测试。

它就像一个学生自己出题、自己答题、自己批卷，最后郑重宣布自己考了满分。你不能说这个满分是假的，因为每一道题确实都答对了；你只能说，这张卷子更像是为了自我满足。

当然，更精细的测试不是坏事，精细测试可以拦截不少潜在系统风险，但是3个工具200多个测试点，还是太有表演性质了。过多的测试点不仅影响CI速度，也会影响人工维护测试case时的难度与压力

所以这次体验给我留下了一个非常强烈的印象：现代Agent越来越擅长制造“完成感”。

测试数量在上涨，审查状态全部变成Completed，终端里不断出现绿色，最终总结写得像一份刚刚通过验收的国家级工程报告。整个界面都在告诉你，一切正在稳步前进。

只有真正理解项目的人知道，它正在稳定地越飘越远。

五、问题四：它完全没有成本意识

上面的聊天记录中，我告诉Sol，他已经花了40刀。后来我看了后台，精确数字是46.9刀。

3个MCP工具，40多刀，近2个小时。它做的并不出彩，费用却比我的时薪还高。

这里最烧钱的部分，甚至不一定是代码生成。

真正昂贵的是上下文被不断复制。每启动一个新的子代理，它都需要重新阅读设计文档、当前diff、相关服务、测试文件，以及前一个代理留下的结论。一个实现代理读一遍，一个规格审查代理再读一遍，一个代码质量代理再读一遍，修复代理再读一遍，复核代理还要再读一遍。

模型看起来只是在界面里多列出了几个Completed，用户看到的却是一张逐渐燃烧起来的账单。

subAgent并没有错，但问题是，Sol似乎没有一种稳定的“任务价值密度”判断。

它不会主动估算：这个问题值不值得启动一个新的高阶模型？这个审查能带来多少额外收益？发现的问题是阻塞级错误，还是一句文档措辞？看文档、写代码、review，是否值得新开一个Agent换取更不偏颇的结果？

它只知道多一轮Review，理论上更保险。

至于这轮Review花的是谁的钱，它并不关心。

六、问题五：子代理越多，不等于能力越强

过去两年，几乎所有大模型厂商都在强调Agent能力。工具调用、长期规划、任务拆解、并行子代理、自我审查，已经成了新模型发布时的标准节目。

这种方向当然有价值。对于真正复杂的研究任务、大型代码迁移、跨模块排障和需要大量检索的工作，一个模型很难同时把所有细节放在工作记忆中，适当拆分任务确实能提高完成率。

但子代理不是一种无条件增益。

当任务本身结构清晰、骨架完整、修改范围有限时，最需要的是一个拥有全局上下文的开发者持续工作。它读懂现有架构，在脑子里维持住约束，然后沿着已有路径完成修改。 此时强行拆成十几个代理，反而会破坏上下文连续性。

每个子代理只看到自己那一小块任务，于是它会局部最优地解决问题。安全审查代理想增加更多验证，持久化代理想补齐数据落库，Schema代理想让每个参数都更加严格，代码质量代理想进一步抽象公共逻辑。每个代理单独看都很勤奋，合起来却可能把一个简单功能膨胀成一套基础设施。

这就是多代理系统最容易出现的问题：没有人偷懒，但项目失控了。

如果主Agent缺乏足够强的范围约束能力，子代理越勤奋，最终偏离用户目标的速度反而越快。它们不是在并行接近终点，而是在朝十几个“看起来也挺合理”的方向同时狂奔。

七、和Opus相比，Sol像一个管理欲过剩的技术总监

同样的任务，如果交给我平时使用的Opus，通常会是另一种节奏。

它先阅读相关文档和代码，确认已有模式，然后直接开始实现。写完一部分就补测试，跑完测试以后检查diff，发现问题再修一次。整个过程中当然也可能犯错，也可能需要我纠正，但大多数时候，它的注意力集中在任务本身。

它更像一个能力很强、偶尔需要指方向的工程师。

Sol给我的感觉则像一个刚刚读完所有软件工程管理书籍，又第一次被任命为技术总监的人。它不满足于写代码，它要建立流程；不满足于建立流程，它还要建立流程的审计流程；不满足于完成需求，它还要证明自己完成需求的方法符合一套由它自己制定的质量体系。

最终结果是，Opus可能二三十分钟就能完成的任务，Sol花了两个小时，还需要我花掉半个下午去理解它究竟改了什么、为什么改，以及哪些部分应该被回退。

只凭这一次测试，不能断言Sol的代码能力一定弱于Opus。模型表现和任务类型、提示词、项目结构、上下文长度都有关系，而且Cursor如何调用模型、如何组织子代理、如何裁剪上下文，也会显著影响最终结果。

但至少在这次真实开发里，Opus更像是在替我干活，Sol更像是在邀请我旁听它举办的软件工程峰会。

前者交付代码。

后者交付流程、报告、审查记录、测试数字，以及一份需要我亲自收拾的代码。

八、我开始怀疑，新模型正在被训练成不在乎用户成本的样子

这次经历让我产生了一种并不严谨，但越来越强烈的感觉：最近的新模型，正在集体朝着“通过消耗更多Token换取更高任务成功率”的方向演化。

甚至是故意使用能消耗更多Token的训练集与策略。从Opus4.8到Sonnet5就是这样，降价，但对同一任务，Token消耗翻三倍。

以前模型能力不够，厂商只能努力让单次回答更准确。现在上下文更长了，工具更多了，推理预算更高了，子代理也能并行启动，于是另一条路线出现了：一次不够就多想几次，一个模型不够就叫十个模型，一个Review不够就Review三轮。

从评测角度看，这很合理。

如果一个任务只统计最终有没有做对，而不统计花了多少时间、调用了多少模型、生成了多少Token，那么最优策略当然是不断增加计算预算。多读几遍代码，多叫几个审查者，多跑几组测试，成功率总会提高一点。

但用户不是生活在评测表格里的。

用户需要支付Token，需要等待结果，需要阅读模型留下的修改，也需要承担它擅自改变架构以后的维护成本。

对评测来说，只要最终答案正确，过程再冗长都没有关系；对用户来说，花50美元做完一个原本5美元能完成的任务，本身就是失败。

当然，也不能全怪模型。Sol最终表现成什么样，显然还取决于Harness。Cursor决定什么时候启动子代理，如何给代理提供上下文，使用什么模型进行Review，以及怎样把代理结果重新汇总给主模型。换到Codex、Claude Code或者其他Agent框架中，同一个模型完全可能表现出不同的行为。

但是，现在的模型更喜欢当领导安排活这件事，确实已经成为现实了。

九、我甚至开始怀念Sonnet 3.5的时代

从Agent工程师的角度来讲，我非常激进的认同，2026年后半年，一定是MiltiAgent的天下。 大多模型厂早已经在25年开始了正式布局，并且更重要的一点是，在我自己的开发中，我能感受到，通用场景下的单Agent上下文/Harness已经快要摸到工程极限了。很多时候，业务侧的精调才是提升Agent效果的杀手锏——但这部分很难跨领域迁移。

如果想提高通用场景的效果，做通用框架，那当前最划算的方案就是研究MultiAgent。

所以，批评归批评，但我其实非常理解且赞同各大模型厂商的训练路线。这与痛斥Sol浪费掉我40多刀并不冲突。

不过，如果切换到码农视角，我竟然有点怀念Sonnet 3.5。

Sonnet 3.5并不完美。它上下文没有现在这么长，复杂任务容易做到一半迷路，工具调用也远没有今天成熟。放到现在，它在许多评测上可能已经显得落后。

但那个时代的模型有一种现在越来越少见的干净感。

你让它改一个函数，它就去找那个函数；你让它补一个接口，它就沿着现有代码补上；遇到不确定的地方，它可能会问你一句，而不是立即召集五个子代理成立联合调查组。

当时的模型像一把刀，皮实，便宜，有小惊喜。

能力有边界，但刀刃很清楚。你知道它能切什么，不能切什么，也知道这一刀大概会落在哪里。

结语

虽然前面说了那么多Sol的坏话，但是需要说明的是，这篇文章只是我对GPT-5.6 Sol一次测试的记录。

任务里使用的是Cursor，任务发生在一个拥有现有骨架、历史代码和明确设计约束的真实项目中。最终体验既反映了模型本身的规划与委派倾向，也受到Cursor当前Harness策略、子代理配置和上下文管理方式的影响。它不能证明Sol在其他任务中一定表现糟糕，也不能证明它在Codex或其他Harness里会重复完全相同的行为。

对于真正需要广泛检索、长程推理和多角色协作的复杂任务，Sol这种强烈的流程意识可能反而会成为优势。 它愿意测试、愿意审查、愿意主动补边界，这些能力本身都不是坏事。

但至少在我的这一次尝鲜中，它没有让我看到一个更强的编程模型。

我看到的是一个拥有庞大组织能力，却缺少成本意识和权限边界的Agent。它有能力把一个简单任务拆成一套完整工程，也有能力让这套工程中的每一步都通过审查。

只是从头到尾，它似乎忘了最重要的一件事：

我需要的不是一场工程奇观。

我只需要它把那几个MCP工具写好。

---

ps：骂归骂，用还是要用的，sol在对话场景比前代提升不少，比如本篇就使用了sol来润色（

如果你也对新模型体验感兴趣，或者是希望与更多人一起沟通交流Agent开发/AI工具使用技巧，可以加入下方交流群，一起聊天~

*csdn发二维码会失效，可以私聊获取~