Peter 的七月：模型正在退居二线，Agent 系统正在成为主角

如果把 Peter Steinberger 在 7 月的讨论逐条看，很容易得到一个热闹但不太有用的印象：这里夸一下 GPT 5.6，那里谈一次 Fable；一会儿说 Codex 做并行 QA 很强，一会儿又提 Claude CLI、图编排和 OpenClaw 的产品细节。它们像是一个高频实践者的随手笔记。把这些笔记放到同一个坐标系里，反而能看到一条非常稳定的主线：模型仍然重要，但它已经不再是产品或工程的唯一中心；真正的差异，正在转移到模型被放进了怎样的系统。

这不是一份“Peter 推荐模型排行榜”。他自己也明确说过，分享的是在自己工作里有效的实用建议，而不是一套通用评测框架。因此，下面的文章不会把他某次体验外推成产品事实，更不会把一条帖文当作行业定论。更有价值的读法，是把这些评论当成工程判断的样本：一个长期把 Agent 放进真实产品、真实代码库和真实发布节奏的人，究竟在反复关心什么。

我会把 7 月的观点分成三层。第一层是模型：GPT 5.6、Fable、开源与 benchmark，到底应当怎样看。第二层是 Agent 系统：harness、loop、graph 为什么开始比“选到哪个最强模型”更重要。第三层是实践：Codex、Claude Code 与多 Agent 工作流，怎样从好看的演示变成可复用的交付能力。三层连起来，结论很简单：模型能力正在成为组件；能够持续产出结果的系统，才开始成为产品。

一、模型不是结论，而是要被放进具体任务里的变量。7 月中旬，Peter 提到把 ClawSweeper 的代码审查切到 Terra High 后，整体速度提升约四成，质量损失很小；另一条帖文里，他又说在某个配置中把成本降了大约八成。这里最值得注意的并不是某个具体数字——它们来自特定工作负载、特定 harness 和当时的部署配置——而是评价模型的顺序：先看完成任务的速度、质量和成本，再谈“谁更强”。

这比盯着总榜更接近实际。代码审查、代码生成、研究、设计、客服、批处理，各自对延迟、推理深度、工具调用和错误类型的容忍度不同。一个模型在综合 benchmark 上领先，不等于它在你的代码审查队列、你的 UI 修改或你的高并发任务里最划算。Peter 说 5.6 在他的一些工作流中有明显进步，甚至认为它的“人格”表现更好；这仍然是对特定协作体验的反馈，而不是替所有团队做选择。

Fable 的讨论把这一点说得更清楚。Peter 在 7 月谈到 Fable 与 GPT 5.6 都适合做设计探索，但使用 GPT 时，先让模型生成视觉设计，再从视觉结果继续推进，往往更容易得到有辨识度的界面。这里的技巧看似在讲提示词，实则在讲任务表征：不要只用抽象文字要求“做得独特”，而要给模型一个可以被审视、被修改、被继承的中间产物。图像不是装饰，它是把模糊审美外化成可反馈状态的一种方式。

更有意思的是他对角色分工的建议：让 Fable 做高层顾问或规划者，让 Codex 做 workhorse。它并不意味着“前者永远更聪明、后者永远更适合执行”。真正的含义是，模型选择应当被拆成角色选择：谁负责提出方向、谁负责跑工具、谁负责成本敏感的大量执行、谁负责最终验证。把一个模型当作全能员工，往往既昂贵又难调；把模型放进清晰职责里，才会出现可替换性。

这也是理解 benchmark 的关键。Peter 在月底讨论某个兼容接口时，指出不同 API 实现会保留或处理不同的 reasoning token，因而直接比较很容易失真。模型本身、服务层、接口语义、采样参数、工具协议、上下文裁剪和系统提示词，都会共同决定一次 Agent 运行的结果。今天很多“模型 A 赢了模型 B”的争论，实际比较的是两套不同的系统配置。Benchmark 可以帮助筛选候选，但不能替你完成集成评估。

对开源的态度同样不应二元化。Peter 一方面强调竞争与选择对生态有益，另一方面也承认服务大模型本身很难。这个判断很成熟：开放权重、可控部署与供应链选择很重要，但它们并不能自动解决推理成本、稳定性、工具调用、运维和产品体验。闭源模型也不是天然更适合一切任务。真正稳妥的策略不是选边，而是建立路由能力：保留多种可用模型，让高价值任务走更强或更可靠的路径，让规模化任务在质量阈值内追求效率。

二、从模型到系统：harness 才是 Agent 的工作世界。Peter 在 7 月一句很有代表性的话是：面对外界关于 Agent 的夸张赞美与夸张反弹，他大多选择忽略，然后继续构建自己的 dream harness。这句话的重点不是“不要听批评”，而是把注意力从情绪化叙事转回工程：模型会变，舆论会摆动，能留下来的资产是任务环境、工具边界、反馈机制和运行记录。

所谓 harness，不该被理解成一个套在模型外面的 prompt 模板。它更像 Agent 的工作台：能看到哪些文件，能使用什么工具，拥有哪些权限，怎样获得项目规则，失败后能读到什么日志，完成后由谁验收，状态如何保存，出了问题能否恢复。模型的能力决定它能在这个世界里走多远；harness 决定它有没有一条正确、可解释、可回头的路。

这解释了为什么“模型变强”并不会自动减少工程工作，反而可能放大环境质量的重要性。一个弱模型只能在局部犯错；一个强模型能跑得更远，如果任务边界含糊、工具权限过大、测试信号不可靠，它也能更快把错误扩散到更多地方。高能力不是放松控制的理由，恰好是把控制从人工盯屏升级成系统约束的理由。

loop 是 harness 里的时间维度。它不只是让 Agent 多试几次，而是要求每一轮行动都读取新的证据：跑完测试，分析失败；改完代码，再验证行为；工具超时，区分重试、切换路径还是交还给人。Peter 的一条小建议——“让 Codex 重启进程”——听起来朴素，却说明可靠执行必须把恢复动作当成正式能力。卡住时继续追加解释，未必能改变系统状态；重启、重建上下文、换一条工具路径，有时才是最短的纠错回路。

可恢复性也决定了 loop 不能等同于无限运行。没有新的观测，没有明确的停止条件，没有预算与权限边界的循环，只会把不确定性自动化。好的 loop 需要检查点、失败分类、重试预算和升级门槛。它必须知道：什么时候测试结果已经足够支持完成；什么时候需要重新开始；什么时候应该停止并让人做决定。自主性不是“永远继续”，而是“在证据允许时继续，在风险变大时停下”。

graph 则是在更大尺度组织这件事。Peter 转发过一个很实用的建议：把工作流程画成图，哪怕画在纸上；再把它交给 Codex，让它生成一个 Agent-mode 脚本来实现这个流程、接收输入并运行。图的价值不是可视化本身，而是逼迫人把隐含的步骤说出来：输入从哪里来，哪些任务可以并行，哪一步要等待，失败回到哪里，结果如何汇合，谁拥有最终批准权。

从这个角度看，harness、loop、graph 不是三套互相竞争的“新范式”。Harness 解决 Agent 在哪里工作；loop 解决它如何从后果中纠错；graph 解决多个工作单元如何分支、协作和收敛。一个 graph 里的节点可以是带完整 harness 的 Agent，一个节点内部也可以运行多个 loop。团队真正需要设计的不是术语归属，而是把不确定性放在哪里，把确定性放在哪里。

第三层才是最容易被复制、也最容易被误解的实践。Peter 说，可以直接提示 Agent 调用 Codex、Claude 或其他 CLI，自主完成任务；也可以按 harness 的能力使用 subagent。随后他又提到，为了应对某些工具调用路径的实际问题，OpenClaw 增加了直接使用 Claude CLI 的代码路径。两条评论放在一起，不是在鼓吹“所有事情都多 Agent”，而是在强调执行路径应当可替换。Agent 系统不应被某一个 SDK、某一次工具调用或某家模型服务锁死。

这对 Claude Code 和 Codex 的使用有一个很实际的启示：先把 CLI 当成可组合的执行接口，而不是只能由人亲手操作的聊天窗口。一个主 Agent 可以负责理解目标、拆分任务和保留状态；专门的 CLI 子任务可以负责检索、实现、测试、审查或生成资产；最后再由独立的验证环节检查结果。这样的分工不是为了显得“多智能体”，而是让每个步骤都有清楚的输入、输出和失败信号。

Peter 用 Codex 做大规模并行 QA 的分享，给出了更具体的标准：他关心的不是 Agent 能否写出一段像样的修复，而是它能否理解意图、发现复杂的行为问题，并在长流程里不因上下文压缩而开始投机。这个标准很值得借鉴。实现 Agent 的产出只能算候选答案；QA Agent、测试和人工抽查提供的是不同类型的反证。把“写”和“证”交给同一个没有约束的角色，常常会得到看似自洽、实则未被检验的结果。

更进一步，他提到过一个近乎科幻、但已经很日常的闭环：一侧的 Agent 报告 bug，另一侧的 Agent 当晚完成修复。真正值得关注的不是“Agent 替代了谁”，而是这个闭环具备了哪些条件：缺陷可被准确描述，代码库有可运行的验证，执行者有受限权限，修复能被审查，变更能被回滚。没有这些条件，Agent-to-Agent 只会让错误传递更快；具备这些条件，它才会让工程节奏加速。

产品体验在这套系统里也不是后置的美化。Peter 同期持续迭代 OpenClaw 的 UI，也提到网页端的 session summaries 等能力。原因很简单：当任务开始跨分钟、跨工具、跨模型运行时，用户需要知道系统正在做什么、已经用过什么上下文、花了多少成本、失败在哪里、下一步能否介入。一个足够聪明但过程不可见的 Agent，会把用户变成焦虑的旁观者；一个能解释状态、展示证据和提供恢复入口的 Agent，才更像值得委派的同事。

把这三层压缩成可执行的工作法，我会给出六个动作。第一，用真实任务而非单一榜单挑选模型，并记录质量、耗时、成本和失败类型。第二，把规划、执行和验证拆成可替换角色，不让一个模型承担所有责任。第三，把文件、工具、权限、规则、日志和验收条件做成 harness，而不是藏在操作者记忆里。第四，让每个循环消费新证据，并写清重试、重启、升级和停止条件。第五，把并行、审批、汇合和回退画成 graph，先对齐流程再自动化。第六，把任务历史、来源、成本与恢复入口做成体验的一部分。

所以，Peter 的 7 月不该被总结成“GPT 5.6 更好”或“Fable 很强”这样的短句。更准确的总结是：领先模型的差距会不断变化，benchmark 也会不断更新；真正能沉淀的，是一套能接入多个模型、能在失败后恢复、能把复杂协作显性化、还能让人随时看懂和接管的 Agent 系统。模型会继续变成更好的发动机，但决定你能否稳定抵达目的地的，始终是整辆车的结构、仪表和刹车。