在尝鲜GPT5.6 sol后，我裂开了

你好我是司沐。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不是FableFable太贵了绝非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-65.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发二维码会失效可以私聊获取~