第 01 期｜从模型能力到真实工作流

过去一周最容易被忽略的变化，不是哪一个模型又多拿了几分，而是模型公司开始把能力拆成不同价格、不同延迟和不同执行深度的产品层；与此同时，独立研究仍在提醒我们：基准分数、主观体感和真实生产率并不是同一件事。本期不做发布会摘要，而是把这些信号放进一条可以落地的工作流里。

这一期的结论可以先说在前面：模型能力正在从一个排行榜上的单点数字，变成一组需要被调度的生产要素。真正决定结果的，不只是模型本身，还包括上下文从哪里来、工具能做什么、评测是否有效、权限怎样收紧、失败后能否回滚。团队如果只讨论“用哪一个最强模型”，通常会错过其中四项。

一、本周信号：模型能力开始被重新包装为工作方式

7 月 8 日到 9 日，OpenAI 连续发布了几类性质不同的更新。GPT‑5.6 模型家族把同一代能力分成 Luna、Terra 与 Sol 三个层级；ChatGPT 面向复杂工作的产品更新强调长时间、多材料、多步骤协作；GPT Live则把实时语音和视觉交互推向更低延迟的场景。这三件事放在一起看，比逐项复述参数更有意义：供应商正在把“智能”拆成速度、深度、交互形式和单位成本，让应用在不同步骤选择不同档位。

同一时间，评测本身也受到审视。OpenAI 在编程评测审计中称，SWE‑Bench Pro 约三成任务存在环境、测试或题目定义问题。这个数字来自厂商自己的审计，不应直接外推到所有榜单；但它指出一个很实际的风险：当模型之间只差几个百分点时，脏数据和失效测试可能比模型差异更大。早前发布的SWE‑Lancer把 1,400 余个真实自由职业软件任务和超过 100 万美元报酬联系起来，也体现了评测从“答题”向“交付”移动的方向。

1. 7 月 8 日
   评测审计先确认题目、环境和判分是否仍有效
2. 7 月 8 日
   GPT Live让语音与视觉进入低延迟交互环节
3. 7 月 9 日
   GPT‑5.6 三档按任务难度选择成本与推理深度
4. 7 月 9 日
   复杂工作产品化从一次回答转向材料、步骤与交付物

阅读方式：本周真正的变化是“选择模型”被改写为“为每一个步骤选择能力、延迟与控制”。

因此，第一个判断不是谁赢了，而是产品边界变了。过去，团队可能为整个客服、研究或编程流程绑定一个模型；现在更合理的设计是：廉价快速的模型做分类和格式化，中间档处理材料与常规推理，最强档只进入少数高价值难题。模型路由从优化技巧变成成本结构的一部分。

二、三档模型意味着什么：别把价目表当能力排名

GPT‑5.6 的公开 API 定价让这种分层最直观。Luna 的输入与输出价格为每百万 token 1 美元和 6 美元，Terra 为 2.5 美元和 15 美元，Sol 为 5 美元和 30 美元。Claude Sonnet 5 在 6 月 30 日发布时也给出限时 2/10 美元、之后 3/15 美元的输入/输出定价。价格能精确比较，质量却不能只靠厂商自报的不同基准拼成一个“总分”。

模型	输入	输出	更适合先验证的任务	不应由价格替代的证据
GPT‑5.6 Luna	$1	$6	分类、抽取、改写、低风险批处理	格式通过率、遗漏率、尾部失败
GPT‑5.6 Terra	$2.5	$15	多材料分析、常规工具调用	任务成功率、重试次数、人工修改量
GPT‑5.6 Sol	$5	$30	高价值复杂推理、困难编码	是否真的减少总工时与返工
Claude Sonnet 5	$2 限时 $3 标准	$10 限时 $15 标准	编码代理、长任务与工具编排	仓库级测试、权限与恢复能力

价格来自厂商公开页面，只能用于预算；任务质量必须在相同输入、工具、上下文和验收条件下自行测量。

一个常见误区是把最贵模型留给“最重要的部门”，而不是最难且可验证的步骤。重要但规则稳定的付款核对，可能更适合确定性程序；不重要却信息混乱的旧文档整理，反而需要更强的语义判断。任务价值决定可接受的错误成本，任务结构决定需要什么能力，两者不能混为一谈。

另一个误区是只算 token 单价。一个便宜模型如果需要三次重试、更多上下文和人工重写，单位成功任务成本可能更高。团队至少应记录一次通过率、平均重试、人工修正分钟数和失败后果。路由规则也不应由模型自己无约束决定：先用任务类型、材料长度、风险等级和历史表现设定边界，再让系统在边界内选择。

三、从回答到执行：真正稀缺的是可验证的闭环

聊天产品优化的是“这一轮回答是否有用”，代理工作流优化的是“任务是否在约束下完成”。两者之间多出了状态、工具、身份、外部副作用和恢复。OpenAI 的代理构建实践指南把模型、工具和指令列为代理的基本组成，也建议先从单代理和明确工具开始。这个建议看似保守，却能避免把协调复杂度误认为智能。

以研究报告为例，漂亮摘要只完成了很小一部分工作。可靠流程要保存检索范围、来源日期、引文对应关系、版本差异和无法核实的空白；生成初稿后，还要检查数字、链接与结论强度。若模型没有权限写数据库，错误通常停留在文字里；一旦它能发邮件、改工单或提交代码，错误就会变成外部状态。因此，同一模型在“建议”和“执行”两种模式下需要完全不同的上线门槛。

这也解释了为什么编程代理格外受关注：代码有测试、构建和版本控制，产物相对容易验证和回滚。但“容易验证”不等于自动安全。代理可能为了让测试通过而修改测试，可能忽略环境差异，也可能在没有理解业务约束时完成局部任务。编程是代理较好的试验场，不是无需治理的例外。

四、协议解决连接问题，但不替你解决信任问题

Model Context Protocol（MCP）规范把服务器提供的能力区分为 prompts、resources 与 tools。这个划分有助于减少每个应用重复对接数据源和工具的成本：资源用于提供上下文，工具用于执行动作，提示模板帮助组织交互。但协议只定义怎样交换能力；某个资源是否可信、某个工具能否被当前用户调用，仍由应用与组织负责。

A2A 1.0进一步处理代理之间发现能力、委派任务和传递状态的问题，并明确把自身定位为 MCP 的补充。两者组合后，一个代理可以通过 MCP 使用工具，也可以通过 A2A 把子任务交给另一个代理。连接更顺畅的同时，信任边界也会扩大：身份能否跨代理传递、子代理获得了哪些权限、失败由谁补偿，都必须在协议之外落到策略和日志。

值得警惕的是“接上协议就获得企业上下文”的说法。上下文不是文件数量，而是来源、适用范围、更新时间和访问主体的组合。过期政策即使被准确检索，仍会给出错误行动；超出当前用户权限的数据即使对模型有帮助，也不应暴露。每一个资源都需要负责人和保鲜期，每一个工具都需要最小权限、参数校验与可观察结果。

协议还会放大供应链问题。一个看似简单的“查订单”工具，背后可能依赖插件、第三方服务和共享凭据。团队需要维护允许列表、版本和调用范围；高风险写操作最好经过独立审批，而不是让发起计划的同一个模型同时批准计划。连接标准化以后，治理更应该标准化，而不是被省略。

五、生产率证据为什么冲突：21% 更快和 19% 更慢都可能成立

关于 AI 编程是否提升效率，两项随机对照研究给出了方向相反的结果。Google 的企业开发者随机实验纳入 96 名工程师，最佳估计是完成时间缩短约 21%，但区间较宽，且场景来自特定组织与任务。METR 的成熟开源项目随机实验研究 16 名对代码库平均有约五年经验的开发者、246 个真实任务，测得允许使用当时的 AI 工具后完成时间增加约 19%。

Google RCT
96 名工程师

METR RCT
16 人 / 246 任务

METR 事前预期

METR 事后感受

能支持：在各自实验条件下，AI 对完成时间产生了可测影响。

不能支持：“所有开发者都会快 21%”或“所有成熟团队都会慢 19%”。

冲突并不意味着其中一项必然错了。Google 的实验更接近企业内部工具与任务，METR 则刻意选择资深开发者熟悉的成熟代码库；对后者而言，理解建议、等待生成、审查改动和修复偏差可能抵消输入代码的速度。工具版本、上下文可得性、任务粒度和参与者经验都会改变结果。

METR 研究还有一个比 19% 更值得记住的细节：参与者事前预计 AI 会让自己快约 24%，实验结束后仍主观认为快约 20%。也就是说，体感与计时可以同时存在明显偏差。流畅建议、快速补全和少打字会制造“进展很快”的感觉，却不一定缩短从接任务到测试通过的总时间。

这也是为什么Stanford AI Index 2026 的经济章节应被谨慎阅读：调查显示组织采用 AI 的比例已经很高，但代理在全面规模化使用中的占比仍低，收益更多集中在结构清楚、可测量的工作。采用率说明工具进入了组织，不等于已经产生同等规模的净收益。

更好的内部实验并不复杂。随机选择同类任务，在“可用 AI”和“不使用 AI”之间分配；记录从开始到通过验收的总时间，而不是只记录生成阶段；同时保留任务难度、开发者经验、返工、审查时间与质量缺陷。样本量小时，不要只报平均数，还要展示分布和不确定性。最重要的是，实验对象应是你真正想改善的工作，而不是为了得到漂亮数字挑选的演示任务。

六、Claude Code 数据揭示的不是“替代”，而是角色重新分配

Anthropic 对约 40 万次 Claude Code 交互的研究发现，专家用户获得经验证成功的概率超过新手两倍。研究同时观察到一种不对称分工：规划阶段人承担更多工作，执行阶段 Claude 承担更多。这个结果是产品使用数据中的关联，不是随机实验；它不能证明“使用越熟练就必然越高效”，但对产品设计很有启发。

规划确定目标、拆解、约束与验收

人 70%Claude 30%

执行编辑、调用工具、运行与迭代

人 20%Claude 80%

观察：专家的验证成功率超过新手两倍。

推论：未来培训重点可能从“如何写代码”部分转向“如何定义、分解和验证任务”；这是编辑部推论，不是研究的因果结论。

这组数据反驳了两种过度简单的想象。第一种是“代理会把整个开发任务吃掉”；实际上，人类工作更可能前移到定义问题和设置边界。第二种是“让新手直接使用最强代理就能追平专家”；如果专家优势来自更好的任务分解、仓库理解和验证策略，增强执行能力反而可能放大输入质量的差距。

Anthropic 的另一份50 万次编码交互分析把使用方式分为自动化与增强：Claude Code 中约 79% 被归为自动化、21% 为增强，而 Claude.ai 的编码对话更接近对半。这同样是分类后的观察性数据。它说明工具界面会改变行为：当系统获得文件、终端和连续执行能力时，用户自然把更多步骤交出去；这也意味着权限、日志和恢复要随自动化程度同步升级。

对团队而言，最值得投资的不是“人人学会一句万能提示词”，而是一套共享的任务模板：目标是什么，哪些文件和系统可以访问，哪些测试必须通过，哪些更改禁止发生，何时停止并请求确认。优秀使用者的隐性经验需要变成组织资产，否则代理效率只会留在少数人手里。

七、五道生产门：模型、上下文、工具、评测与治理

把前面的信号收束起来，一条可上线的 AI 工作流至少要经过五道门。模型门回答能力、延迟和成本是否适合；上下文门回答输入是否可信、及时且有权访问；工具门回答动作是否最小权限、参数受控且幂等；评测门回答成功能否被测量；治理门回答谁批准、谁监控、谁在失败后接手。

Anthropic 的代理评测方法强调从任务、试验、评分器和成绩记录构成评测体系，并关注多轮轨迹，而不只看最终一句话。对于会使用工具的系统，这一点尤其重要：最终结果碰巧正确，不代表过程没有访问越权数据；最终结果错误，也可能是外部服务失败而非模型判断错误。结果、路径和环境需要分别记录。

治理也不等于在最后加一个审核按钮。NIST AI 风险管理框架及生成式 AI 配套资料用 Govern、Map、Measure、Manage 组织生命周期风险。落到具体系统，就是先定义责任与范围，再识别任务和受影响对象，持续测量质量与风险，最后设置响应、停用和改进机制。人工审批只是其中一个控制点。

1 模型能力·延迟·成本

2 上下文来源·时效·权限

3 工具范围·校验·幂等

4 评测任务·轨迹·失败

5 治理审批·回滚·监控

任务形态	模型角色	主要验证	自动化上限
稳定、规则明确	分类或生成结构化参数	schema、业务规则	通过测试后可自动执行
材料复杂、结果易核验	检索、归纳、生成候选	来源、测试、人工抽查	逐步放开低风险写操作
高风险、可逆性低	提供证据与方案	独立审批、双人确认	不直接批准或付款
目标含糊、无法低成本验收	澄清问题、拆解任务	先建立成功标准	保持建议模式

真正的“智能路由”不是只选模型，也包括选择上下文、工具、评分器、审批与恢复路径。

在这五道门里，评测往往最晚才被补上，却应该最早设计。没有验收方式，就无法知道是否应该升级模型；没有失败分类，就无法判断该补提示、补数据、改工具还是缩小任务。把所有错误归因于“模型不够强”，会让团队不断增加成本，却不一定改善系统。

回滚能力同样是上线条件，而不是事故后的补丁。写操作应尽可能带幂等键，任务应保存步骤状态，模型和提示版本应能追溯，发布前后应有固定回归集。对于不可逆操作，让模型生成待审批结构，而不是直接执行，是更诚实的产品边界。

八、接下来 30 天：用一个任务验证，而不是铺开十个助手

第一周只选一条流程。它应高频、人工耗时、输入以文本或代码为主、结果能够快速验收，并且失败可恢复。记录当前人工基线：总耗时、等待时间、返工率、质量缺陷和一次成功成本。不要从“我们已经买了哪个模型”倒推任务。

第二周建立一组冻结样本和失败类型。样本应包含普通任务，也包含缺字段、冲突规则、长材料、权限不足和外部服务失败。先让系统只读和草拟，测量来源覆盖、格式通过率、事实错误、人工修改量与停止行为。此时最强模型也不能跳过失败样本。

第三周接入一个低风险工具，使用最小权限和明确 schema，所有有副作用的调用带幂等标识。记录每一步输入摘要、工具结果、模型版本和人工确认。故意制造超时、重复响应和无权限状态，确认系统会停、会解释，并能从确定状态恢复。

第四周做小规模对照：同类任务随机进入原流程和 AI 流程，比较端到端时间、质量、返工与失败成本。结果若没有改善，不要急着换最贵模型；先看瓶颈是在检索、上下文、工具等待还是审核。如果只有某类任务受益，就把路由范围缩到那一类。

未来几周值得继续观察三件事。其一，分层模型的路由是否真正降低单位成功任务成本，而不只是 token 账单；其二，MCP 与 A2A 的实现能否把身份、授权和可观察性带进跨代理协作；其三，更多独立研究是否能解释经验、任务成熟度和工具设计对生产率的影响。发布更强模型会持续发生，稀缺的仍是可信测量。

这一期最终要留下的不是“选 GPT 还是 Claude”，而是一个更耐用的问题：当模型能力进入真实流程时，我们能否说明它拿到了什么信息、调用了什么工具、怎样证明成功，以及失败后由谁把系统带回来？