GPT-5.6 真正改变 Agent 工程的，不只是模型更强
GPT-5.6 最值得工程团队关注的变化，并不是又多了一个更高的 benchmark 分数，而是模型 API 开始显式承认：一个 Agent 任务内部存在几种完全不同的计算。
有些步骤需要模型重新判断；有些只是把几十个工具结果做过滤、连接和聚合；有些可以拆成互不依赖的工作流并行完成；还有些动作涉及审批、外部写入或不可逆副作用，不能因为模型更强就自动执行。
GPT-5.6 把 Sol、Terra、Luna 三档模型、reasoning.effort、Programmatic Tool Calling、Multi-agent、persisted reasoning 和显式 prompt cache 同时推到开发者面前。表面看是一组新功能，放在一起看，实际是一套新的 Agent 执行层。
模型不再是一个端点，而是一张调度表
GPT-5.6 的三档并不是简单的“大、中、小”：Sol 面向复杂专业工作，Terra 平衡能力与成本，Luna 面向高频、成本敏感的工作负载。三者都支持超过百万 token 的上下文，但上下文相同不代表任务角色相同。
一个生产 Agent 更合理的路由方式是：
| 任务形状 | 默认选择 | 升级条件 |
|---|---|---|
| 分类、抽取、格式转换、批量校验 | Luna | schema 连续失败，或存在语义歧义 |
| 常规代码修改、文档整合、数据分析 | Terra | 跨系统推理、长尾故障或高价值结果 |
| 架构设计、复杂调试、独立复核 | Sol | max 仍无法收敛时转人工或拆任务 |
| 高风险外部写入 | 与模型档位无关 | 必须经过权限、幂等和审批门 |
这里最容易犯的错，是把“高推理强度”当成“高可靠性”的同义词。更高的 reasoning.effort 允许模型投入更多计算，却不能自动修复错误数据、含糊目标、失效工具或缺失验收器。正确的升级顺序应该是先确认任务契约和证据，再提高推理强度。
Programmatic Tool Calling 把确定性计算移出对话循环
传统工具调用的节奏是：模型选择工具，应用执行工具，结果回到模型，模型再决定下一步。这个结构适合每一步都需要语义判断的工作，但不适合下面这种任务：
- 并行读取 30 个指标接口；
- 过滤掉时间窗外的数据；
- 按服务聚合错误率；
- 只把异常最大的 5 项交给模型解释。
如果 30 份原始结果都进入模型上下文，会增加 token、延迟和注意力噪声。Programmatic Tool Calling 允许模型生成 JavaScript，在隔离的 V8 runtime 中调用被授权的工具，用循环、条件和并发处理结果，最后只返回压缩后的结构化信息。
它的价值不是“让模型会写一段脚本”，而是减少不必要的模型回合和中间数据传输。控制流明确的部分交给程序，存在歧义的部分留给模型。
这个 runtime 的限制，恰好定义了安全边界
程序化调用运行在全新的隔离 V8 环境里，没有 Node.js、包安装、通用文件系统、子进程、直接网络和跨执行持久状态。程序只能通过本次请求明确授权的工具触达外部系统。
这组限制很重要。它意味着程序不能偷偷把工具调用退化成任意网络访问，也不能绕过应用定义的能力表。但“隔离 V8”仍不等于业务安全：如果应用把 delete_customer、send_payment 或生产数据库写入作为可调用工具暴露出去，runtime 再隔离也挡不住被授权的副作用。
因此工具授权至少要分三层：
- 纯读取、无敏感数据的工具，可以允许直接和程序化调用；
- 大结果处理工具可以允许程序化调用，但必须限制查询范围、并发、超时和返回尺寸；
- 写入、发送、购买、删除等动作默认只允许直接调用，并在应用侧保留审批与幂等检查。
官方文档还特别提醒：program_output 与最终 assistant message 是两种输出。程序可能聚合出正确的五条异常，而最终回答漏掉其中一条。评测不能只验证程序结果，也不能只读最后一段自然语言，两边都要检查。
Multi-agent 解决墙钟时间，不自动解决正确性
GPT-5.6 的 Multi-agent beta 允许一个实例协调多个 subagent 并行工作，再综合结果。它适合天然可分解的问题，例如四个地区的法规检索、互不依赖的四个模块审查，或同一方案的性能、安全和可运维性检查。
它不适合强依赖链：第二步必须基于第一步的未知结果，或者多个 Agent 会同时修改同一个状态。强行并行只会制造重复工作、合并冲突和更高 token 消耗。
判断是否值得并行，可以用一个简单条件：
并行收益 = 串行关键路径时间 - 并行协调与合并成本
当子任务足够独立、单个子任务足够长，而且合并标准清晰时，收益为正。否则，一个有检查点的单 Agent 往往更快。
生产实现还需要给每个分支定义：输入快照、允许的工具、输出 schema、最大预算、停止条件和失败回传。最终综合器只应做跨分支判断，不应悄悄重做所有研究。
Persisted reasoning 和 prompt cache 改变了长任务成本模型
GPT-5.6 可以在后续调用中复用可用的 reasoning items，也允许开发者对可重复前缀设置显式缓存断点。这对长任务很有价值，但两者解决的问题不同：
- persisted reasoning 保留的是前序推理对后续任务的帮助；
- prompt cache 复用的是完全相同的输入前缀计算；
- 外部任务状态保存的是事实、进度、副作用和证据。
不能用前两者替代第三者。一个持续一小时的 Agent，即使模型能复用推理，也必须把已创建的工单、已提交的 SHA、审批结果和验证证据写入外部 durable state。否则会话中断后，系统仍不知道现实世界发生了什么。
显式缓存也不是“开了就省钱”。GPT-5.6 的 cache write 按未缓存输入价格的 1.25 倍计费，cache read 才有大幅折扣。如果前缀变化频繁，持续写入可能比不缓存更贵。至少应记录：
cache_write_tokens与cached_tokens；- 前缀生命周期和命中次数；
- 缓存后 TTFT 的变化；
- 因错误缓存边界导致的上下文污染。
新的 Agent 运行时应该有四条路径
把这些能力组合起来，一套清晰的运行时应区分四条路径：
| 路径 | 负责什么 | 不能负责什么 |
|---|---|---|
| 模型推理 | 理解目标、处理歧义、做语义判断 | 代替权限系统和事实验证 |
| 程序化工具调用 | 确定性的批处理、连接、排序、验证 | 审批敏感写入与动态研究 |
| 多 Agent 并行 | 缩短独立工作流的墙钟时间 | 消除同源偏差和自动保证正确 |
| 应用控制面 | 身份、预算、幂等、审批、日志、恢复 | 把业务目标凭空补完整 |
这四条路径之间的路由规则，比“默认用 Sol 还是 Terra”更重要。模型档位只能改变能力、延迟和价格，控制面才决定系统是否可治理。
评测单位要从回答转向已验证任务
迁移时不要只用聊天问题做 A/B test。至少准备 30 个真实任务，覆盖短查询、工具密集型任务、长任务、并行任务和审批任务，然后比较：
- 一次完成率和最终完成率；
- 最终答案、引用、原生工件是否完整；
- 总 token、模型回合、工具调用和墙钟时间；
- cache write/read 的实际净收益；
- subagent 重复工作率和合并失败率；
- 写操作是否经过授权，重试是否产生重复副作用。
最关键的指标是“每个通过验收任务的总成本”，而不是一次请求的单价。Programmatic Tool Calling 少了五个模型回合，但若压缩掉关键证据，就不是优化；Multi-agent 快了两分钟，却把总 token 提高四倍，也未必值得。
趋势判断：Agent 基础设施开始从对话编排走向计算编排
早期 Agent 框架围绕 message、tool call 和 memory 组织。GPT-5.6 这一组能力透露出下一阶段的形状：模型只是计算图中的一种节点，程序、并行 worker、缓存、推理状态和确定性门控都成为一等公民。
这不会让 prompt engineering 消失，但会降低“大提示词包办一切”的价值。真正有复利的资产将是任务分类、工具契约、验证器、状态模型、成本遥测和权限边界。模型还会继续变强，运行时的工作是把这种能力导向可复现、可恢复、可审计的结果。