Peter 的七月：别追模型排行榜，先把 Agent 做成系统

Peter Steinberger 在 7 月写了很多看似分散的东西：GPT 5.6、Fable、Codex 的并行 QA、Claude CLI、工作流图、OpenClaw 的产品细节。若逐条阅读，结论很容易滑向“他最近更喜欢哪个模型”。但把这些观察放在一起，真正清晰的主线恰好相反：模型越来越像可以替换的零件；决定 Agent 能不能稳定交付的，是把零件组织成系统的能力。

这不是一篇模型推荐榜。Peter 分享的是自己在真实项目、真实代码库和真实发布节奏中的经验，而非通用评测。它的价值不在于替团队做采购决策，而在于暴露了一种判断顺序：先问任务有没有被可靠完成，再问模型是否领先。速度、质量、成本、可恢复性与可验证性，应当同时进入答案。

可以用一个判断统领他 7 月的全部实践：不要把 Agent 当作一个更会聊天的人，而要把它当作一套会行动的生产系统。模型是其中的推理引擎；Harness 决定它在什么环境工作；Loop 决定它怎样从结果中纠错；Graph 决定多个任务怎样协作收敛；验证机制则决定系统何时值得相信。

一、别追“最强模型”，先定义任务角色。Peter 提到，ClawSweeper 的代码审查切换到 Terra High 后，速度提升、成本下降，而质量损失很小。具体数字只属于当时的工作负载与配置，不能抽象成排行榜。但它给出了更好的评估方式：把同一类真实任务放进同一套流程，记录完成时间、可接受率、返工量和单位成本；在交付结果上比较，而不是在总分上站队。

这也解释了他对 GPT 5.6、Fable 与 Codex 的不同使用。GPT 5.6 的进步，可能体现在复杂协作中的理解与表达；Fable 可以更适合作为设计方向的顾问；Codex 则可以承担高吞吐的执行。这里没有永远正确的模型分工，只有更贴合目标的角色分工。一个模型包办规划、写代码、跑工具和自证正确，往往既昂贵又难调；职责清楚，模型才真正可替换。

Peter 关于设计的一条建议尤其值得借鉴：用 GPT 做视觉探索时，先生成一张设计图，再围绕这张图继续迭代。关键不在“先出图”这个技巧，而在于把模糊的审美要求外化成可审视的中间结果。文字里的“做得更独特”无法被精确反馈；一张图可以被批评、修改、继承。对 Agent 而言，好的中间产物会比更长的提示词更重要。

同样，benchmark 只能帮你筛选候选，无法替你完成集成评估。Peter 指出，不同 API 实现对 reasoning token 的处理就可能让模型比较失真。模型、服务层、工具协议、上下文裁剪、系统提示词和采样设置，共同决定一次运行的结果。今天很多“模型 A 赢了模型 B”的讨论，本质上是在比较两套不同的系统。

二、Harness 才是 Agent 的工作世界。Peter 提到自己持续在做 dream harness，背后的意思很朴素：模型会更新，舆论会反转，真正会积累的资产是任务环境。Agent 能看到哪些文件、能调用什么工具、权限到哪里、如何读取项目规则、失败后得到哪些日志、完成后如何验收、状态如何保存与恢复——这些才是它能够工作的现实。

强模型不会减少这部分工程，反而会放大它的重要性。弱模型通常只能在局部犯错；强模型能跑得更远，如果边界含糊、权限过大或测试信号不可靠，它也能更快放大错误。强模型不是放松控制的理由，而是把控制从人工盯屏升级为系统约束的理由。

Loop 是这种约束在时间上的展开。它不是“失败了就再试一次”，而是每一步都必须读取新证据：测试失败后定位原因，修改后重新验证，工具超时后区分重试、换路径还是交给人。Peter 提到过让 Codex 重启进程这个小动作。它提醒我们：卡住时反复追加解释，未必能改变系统状态；重启、重建上下文或切换工具路径，往往才是真正的纠错。

所以，好 Loop 的标准不是能运行多久，而是知道何时停止。它要有检查点、失败分类、重试预算和升级门槛；它要分得清什么证据足以说明完成，什么情况应当重新开始，什么风险必须由人接管。自主性不是永远继续，而是在证据允许时继续、在风险升高时停下。

Graph 解决的是更大范围的组织问题。Peter 转发过一个实用建议：先把流程画成图，再让 Codex 把它实现成可接收输入的脚本。图的价值不在于画得漂亮，而在于逼迫团队把隐含规则说清楚：输入从哪里来，哪些步骤可并行，哪里等待人工批准，失败回到哪里，输出如何汇合。自动化前先画清流程，往往比再加一个 Agent 更有效。

Harness、Loop、Graph 不是三组时髦名词。Harness 说明 Agent 在哪里工作；Loop 说明它如何根据后果纠错；Graph 说明多个工作单元如何分支、协作与收敛。一个 Graph 节点可以是带完整 Harness 的 Agent，节点内部也可以跑多个 Loop。需要设计的从来不是术语，而是不确定性由谁承担、确定性由什么来保证。

三、实践的重点不是“多 Agent”，而是可替换执行与独立验证。Peter 提到 Agent 可以直接调用 Codex、Claude 等 CLI，也提到为解决实际问题给 OpenClaw 增加直接使用 Claude CLI 的路径。这两件事的共同点是：不要让系统被一个 SDK、一次工具调用或一家模型服务锁死。CLI 应被看作可组合的执行接口，而不是只能由人手动操作的聊天窗口。

一个成熟的协作方式可以很简单：主 Agent 保持目标与状态；专门任务负责检索、实现、测试或审查；独立验证环节负责找反例。Peter 用 Codex 做大规模并行 QA 时关注的并非“能否写出像样的修复”，而是能否理解意图、发现复杂行为问题，并在长流程中不投机。实现输出只是候选答案；测试、QA 与人工抽查提供的是不同类型的反证。把“写”和“证”交给同一个没有约束的角色，通常只会得到一个自洽但未经检验的故事。

他提到过 Agent 报 bug、另一侧 Agent 当晚修复的闭环。真正让这件事成立的，不是“Agent 替代了谁”，而是周围的工程合同：缺陷可描述，验证可运行，权限被限制，变更可审查，结果可回滚。缺少这些条件，Agent-to-Agent 只会让错误传得更快；具备这些条件，它才会缩短交付周期。

这也是产品体验为什么不能后置。任务跨越多分钟、多个工具和多个模型时，用户需要看见系统做了什么、用过哪些上下文、成本花在哪里、失败发生在哪一步，以及如何介入和恢复。聪明却不透明的 Agent，会把人变成焦虑的旁观者；能展示状态、证据和接管入口的 Agent，才像一个可以委派的同事。

如果把 Peter 的 7 月压缩成一组动作，就是：用真实任务而非单一榜单选模型；把规划、执行、验证拆成可替换角色；把文件、工具、权限、日志与验收条件做成 Harness；让每个 Loop 都消费新证据并有停止规则；先画出并行、审批、回退与汇合，再把流程交给 Agent；最后，把历史、来源、成本和恢复入口直接做进产品。

因此，Peter 的 7 月不该被概括成“GPT 5.6 更好”或“Fable 很强”。更准确的结论是：领先模型与 benchmark 会持续变化，能沉淀下来的只有系统能力——它能接入不同模型，能在失败后恢复，能把复杂协作显性化，也能让人随时理解、审查和接管。模型会成为更好的发动机；能否稳定抵达目的地，仍取决于整辆车的结构、仪表和刹车。