同一个模型，为什么结果差10倍？差的不是模型

Trae 是一款非常优秀的作品，本文图片就由 Trae 生成

引言

我在很早之前有个错觉：用的是同一个模型，结果应该差不多

在上一篇文章使用 trae 中遇到的一些问题，分享了我从 Claude Code 迁移到 Trae 时遇到的问题

为此，我做了一组严格的对照实验：

相同的模型：分别测试了 GLM5 和 Kimi 2.5
相同的起点：新窗口，干净的上下文
唯一变量：Claude Code vs Trae

结果呢？同样的模型、同样的提示词，Trae 的表现明显不如 Claude Code。更具体地说：

在 Claude Code 中能正确调用 Skill 并按流程执行本地脚本
在 Trae 中模型直接忽略了脚本调用步骤，自己猜测实现
有时候模型反问完就直接结束工作了，任务没完成
有时候又能正常执行

当时的发现是：在执行过程中上下文不断增加，然后导致一部分信息被忽略了。

那么，同样的模型，同样的提示词，为什么换个工具结果就差这么多？

先说结论，差的不是模型，是 Harness

一、为什么你的结果不稳定？

1.1 上下文焦虑：模型"害怕"了

症状：Agent 做到一半突然说"我已经完成了"，但你一看，明显还有很多没做。

根因：Anthropic 发现了一个他们称之为"上下文焦虑"(Context Anxiety) 的现象------当模型感知到上下文窗口快满时，会提前结束工作，就像学生看到考试快结束了就匆忙交卷。

arduino 复制代码

你的 Agent 的内心独白：

"上下文已经用了 80%... 我是不是该收尾了？"
"算了，这个功能不做了，先交差吧。"
"用户应该不会注意到我跳过了这一步..."

没有 Harness 的后果：模型自己决定何时停止，而这个决定是基于"上下文还剩多少"，不是"任务是否完成"。

1.2 无限循环：模型"上头"了

症状：Agent 反复调用同一个工具，或者一直在"搜索 → 看结果 → 再搜索"中打转，永远停不下来。

根因：LLM 没有内在的"停止信号"。人类会想"我已经搜了 5 次了，够了"，但 LLM 没有这个概念------它只会机械地继续循环。

scss 复制代码

你的 Agent 的行为模式：

第 1 轮：web_search("React 性能优化")
第 2 轮：web_search("React 性能优化 最佳实践")
第 3 轮：web_search("React performance optimization 2025")
第 4 轮：web_search("React 渲染优化 虚拟列表")
第 5 轮：web_search("React memo useMemo useCallback 区别")
...
第 20 轮：还在搜...

没有 Harness 的后果：没有预算限制，Agent 可以无限循环，直到 API 额度耗尽或你手动 Ctrl+C。

1.3 自我评估偏差：模型"自恋"了

症状：Agent 做完工作后说"我已经完美地完成了任务"，但你一看，代码有 bug、功能没实现、逻辑有漏洞。

根因：Anthropic 的实验发现，LLM 评价自己的工作时，总是过度正面。这不是谦虚的问题------模型真的"认为"自己做得很好。

vbnet 复制代码

你的 Agent 的自我评价：

Agent: "我已经完成了用户认证模块的实现。"
Agent: "代码质量很高，遵循了最佳实践。"
Agent: "所有功能都已正确实现。"

你打开代码一看：
- 密码明文存储
- 没有 CSRF 防护
- JWT 没有过期时间
- 登录接口没有限流

没有 Harness 的后果：没有外部验证者，Agent 的"完成"只是它自己认为的完成，不是真正的完成。

1.4 上下文爆炸：模型"失忆"了

症状：对话进行到一半，Agent 开始忘记之前说过的话、做过的决定，甚至重复之前已经完成的步骤。

根因：上下文窗口是有限的。当对话历史超过窗口容量时，早期的信息会被截断或压缩。如果压缩策略不好，关键信息就会丢失。

arduino 复制代码

你的 Agent 的记忆退化：

第 1 轮：用户说"用 TypeScript 写，不要用 JavaScript"
第 5 轮：Agent 记得用 TypeScript
第 15 轮：上下文压缩发生
第 16 轮：Agent 开始写 JavaScript 代码
第 20 轮：用户说"我之前说了用 TypeScript！"，Agent 说"抱歉，我忘了"

没有 Harness 的后果：没有压缩策略，上下文要么爆掉（API 报错），要么粗暴截断（丢失关键信息）。

1.5 单点故障：模型"挂了"

症状：API 调用失败、网络超时、Provider 限流，Agent 直接崩溃，之前的工作全部丢失。

根因：没有错误恢复机制。一次 API 失败 = 整个对话作废。

csharp 复制代码

你的 Agent 的崩溃日志：

[INFO] 调用 OpenAI API...
[ERROR] Rate limit exceeded. Please retry after 60s.
[INFO] 对话终止。所有进度丢失。

没有 Harness 的后果：没有 fallback、没有重试、没有状态持久化，任何一次失败都是致命的。

二、为什么别人比你稳定？

2.1 别人有 Harness，你没有

"别人"不是直接调 API。他们在 API 和模型之间加了一层------Harness。

复制代码

你的方式：
  用户 → API 调用 → 模型 → API 返回 → 用户
  （裸调用，模型做什么就是什么）

别人的方式：
  用户 → Harness → API 调用 → 模型 → API 返回 → Harness → 用户
  （Harness 在中间做翻译、保护、纠偏）

Harness 不改变模型的输出，但改变模型输出的命运------好的 Harness 会让模型的输出走上正确的轨道，坏的 Harness（或没有 Harness）会让模型的输出自由落体。

2.2 别人的 Harness 做了什么？

以 Hermes Agent 为例，它的 Harness 做了这些你的代码没做的事：

你遇到的问题	Hermes 的 Harness 怎么解决
上下文焦虑	迭代预算 + Grace Call：预算耗尽时给模型一次"优雅收尾"的机会，而不是硬中断
无限循环	IterationBudget：硬性上限（默认 90），execute_code 不计数（避免惩罚正常的多步骤执行）
自我评估偏差	子代理隔离 + 摘要返回：主 Agent 看不到子代理的中间过程，只看最终结果，迫使子代理自我审查
上下文爆炸	自动压缩 + 会话分裂：迭代式摘要保留关键信息，压缩后创建新 session 保持干净上下文
单点故障	5 级错误恢复：重试 → Fallback → 压缩 → 部分恢复 → 降级

2.3 关键差异：不是功能，是假设

你可能想："这些功能我也能加，加个重试、加个预算限制不就行了？"

不行。 关键差异不在于单个功能，而在于这些功能背后的假设体系。

好的 Harness 不是功能堆砌，而是假设体系------每个功能都基于一个"模型不能做什么"的假设，这些假设互相支撑，形成闭环。

sql 复制代码

假设体系（Hermes 的例子）：

假设：模型会无限循环
  → 解决：迭代预算
    → 新假设：预算耗尽时模型可能还有话没说完
      → 解决：Grace Call（多给一次机会）
        → 新假设：Grace Call 后模型可能产生空响应
          → 解决：空响应重试 + 部分流恢复
            → 新假设：重试也可能失败
              → 解决：Fallback 到上轮内容

这是一个完整的假设链，不是孤立的功能点。

如果你只加了"迭代预算"而没有"Grace Call"，Agent 会在预算耗尽时被硬中断，可能连一句总结都没来得及说。如果你只加了"重试"而没有"部分流恢复"，流式中断时已传输的内容就白费了。

这就是为什么"加个重试"不等于"有了 Harness"。

三、Harness 怎么解决这些问题？

3.1 解决上下文焦虑：预算制 + 优雅退出

没有 Harness：

arduino 复制代码

模型：上下文快满了... 我该收尾了... 算了，就这样吧。
结果：任务完成度 60%，但模型说"已完成"。

有 Harness（Hermes 的做法）：

erlang 复制代码

Harness：你还有 45 次迭代预算，继续工作。
模型：好的，继续实现下一个功能。
...
Harness：预算还剩 1 次，这是你的 Grace Call，请总结当前进度。
模型：我已完成 8/10 个功能，剩余 2 个是...
结果：任务完成度 80%，且有明确的进度报告。

关键设计：

迭代预算：不依赖模型自己判断何时停止
Grace Call：预算耗尽时不硬中断，给一次"优雅收尾"的机会
execute_code 不计数：程序化的工具调用不应该消耗预算，避免惩罚正常的复杂任务

3.2 解决无限循环：预算 + 退还机制

没有 Harness：

erlang 复制代码

模型：让我再搜一次...
模型：让我再搜一次...
模型：让我再搜一次...
（无限循环，直到 API 额度耗尽）

有 Harness（Hermes 的做法）：

scss 复制代码

Harness：你还有 45 次迭代预算。
模型：web_search("React 性能优化")
Harness：消耗 1 次预算，剩余 44。
模型：web_search("React memo 用法")
Harness：消耗 1 次预算，剩余 43。
...
模型：execute_code("npm run test")
Harness：execute_code 不计数，预算仍为 30。
...
Harness：预算耗尽。Grace Call。
模型：基于搜索结果，我总结如下...

关键设计：

硬性上限：不管模型想不想停，预算到了必须停
智能计数：程序化调用（execute_code）不消耗预算，只有"思考型"调用才计数
退还机制：如果一轮只调用了 execute_code，自动退还预算

3.3 解决自我评估偏差：Generator-Verifier 分离

没有 Harness：

arduino 复制代码

模型：我写完了认证模块。
模型：让我检查一下... 看起来很好！
（模型自己检查自己，永远是"很好"）

有 Harness（Anthropic 推荐的三 Agent 架构）：

markdown 复制代码

Generator Agent：我写完了认证模块。
Evaluator Agent：让我检查...
  - 密码明文存储？FAIL
  - 没有 CSRF 防护？FAIL
  - JWT 没有过期时间？FAIL
Generator Agent：收到反馈，修复这三个问题...
Evaluator Agent：再次检查...
  - 密码已加密？PASS
  - CSRF 防护已添加？PASS
  - JWT 过期时间已设置？PASS

Hermes 的实现方式 ：通过 delegate_task，可以创建一个"审查"子代理，它的 goal 是"审查代码质量"，toolsets 只包含 ["file", "terminal"]（只读 + 测试），不包含写权限。这实现了 Generator-Verifier 的分离。

关键设计：

角色分离：生成者和评估者是不同的 Agent 实例
工具隔离：评估者只有只读工具，不能修改代码
迭代循环：评估不通过 → 反馈给生成者 → 修改 → 再评估

3.4 解决上下文爆炸：压缩 + 分裂 + 搜索

没有 Harness：

erlang 复制代码

对话越来越长...
API 返回：context_length_exceeded
对话崩溃，所有进度丢失。

有 Harness（Hermes 的做法）：

erlang 复制代码

Harness：上下文已用 85%，发出警告。
Harness：上下文已用 92%，触发压缩。
  - 保留：系统提示 + 最初 3 轮 + 最近 N 轮
  - 压缩：中间轮次 → 迭代式摘要
  - 创建新 session（parent_session_id 链接旧 session）
模型：继续在干净的上下文中工作。
...
用户：之前我们讨论过什么？
Harness：通过 FTS5 搜索旧 session，找到相关内容。
模型：根据搜索结果，我们之前讨论了...

关键设计：

预检压缩：不等 API 报错，主动检测并压缩
保护头尾：系统提示和最近对话优先保留
迭代式摘要：多次压缩时更新之前的摘要，而不是重新生成
会话分裂：压缩后创建新 session，保持干净上下文
FTS5 搜索：旧 session 不删除，可以全文搜索

3.5 解决单点故障：5 级错误恢复

没有 Harness：

复制代码

API 调用失败 → 对话终止 → 进度丢失 → 从头开始

有 Harness（Hermes 的做法）：

复制代码

Level 1：重试
  API 429/500 → 带退避重试（最多 3 次）

Level 2：Fallback
  主 Provider 失败 → 切换到 Fallback Provider
  OpenRouter → 直连 OpenAI → 本地模型

Level 3：压缩
  API 返回 context_length_exceeded → 主动压缩 → 重试

Level 4：部分恢复
  流式中断 → 使用已流式传输的内容作为最终回复
  空响应 + 上轮有内容 → 使用上轮内容

Level 5：降级
  所有恢复策略失败 → 返回当前最佳结果 + 错误信息

关键设计：

层级递进：从最简单的重试开始，逐步升级到更激进的恢复策略
状态持久化：每轮工具执行后保存到 SQLite，崩溃后可恢复
部分结果优于无结果：宁可返回不完美的结果，也不要让用户白等

四、同一个模型，结果差 10 倍的真正原因

4.1 不是模型的问题，是 Harness 的问题

Anthropic 做了一个实验：

配置	耗时	成本	结果质量
Solo Agent（无 Harness）	20 分钟	$9	能跑但有 bug，UI 粗糙
3-Agent Harness（Planner + Generator + Evaluator）	6 小时	$200	功能完整，UI 精致，bug 极少

同一个模型（Claude Opus 4.5），结果质量差了 10 倍以上。

差的不是模型，是 Harness。

4.2 Harness 的 5 个维度决定了结果稳定性

维度	没有 Harness	有 Harness	差异倍数
停止控制	模型自己决定何时停（焦虑或无限循环）	预算制 + 优雅退出	2-3x
质量保证	模型自己评价自己（过度正面）	外部验证者（Generator-Verifier）	3-5x
上下文管理	爆掉或截断（信息丢失）	压缩 + 分裂 + 搜索（信息保真）	2-3x
错误恢复	一次失败 = 全部丢失	5 级恢复（重试 → Fallback → 压缩 → 部分恢复 → 降级）	5-10x
成本控制	不控制（可能无限消耗）	智能路由 + 缓存 + 预算	2-5x

5 个维度叠加，结果差异可达 10-100 倍。

4.3 最容易被忽视的差异：信息保真

大多数人关注"模型能不能做"，但忽视了"信息在传递过程中损失了多少"。

erlang 复制代码

信息保真度对比：

没有 Harness：
  用户意图 → 模型理解（损失 10%）→ 上下文截断（损失 30%）→ 模型遗忘（损失 20%）
  最终保真度：~50%

有 Harness：
  用户意图 → 模型理解（损失 10%）→ 压缩摘要（损失 10%）→ FTS5 搜索补偿（挽回 15%）
  最终保真度：~85%

50% vs 85% 的信息保真度，就是"勉强能用"和"稳定可靠"的区别。

五、回到上一篇文章：这些问题如何解释

现在让我们用 Harness 的视角来重新审视使用 trae 中遇到的一些问题文章中描述的问题：

问题一：模型忽略了 Skill 中的工作流，直接猜测实现

这是典型的上下文管理问题。

文中截图我们可以看到"模型还顺便了解了下项目结构"，这意味着上下文被项目探索信息填充了，Skill 的工作流指令被稀释了。

一个好的 Harness 会确保关键指令始终在上下文中保持可见，比如通过结构化的交接文件或 Sprint 合同。

问题二：模型反问完就结束工作了

这就是"上下文焦虑"的典型表现。模型觉得上下文快满了，就提前收工。解决方案是上下文重置或更好的上下文管理策略。

问题三：同样的提示词，不同工具的结果不同

这正是 Harness 差异的体现。Claude Code 和 Trae 虽然都是编码 Agent，但它们的工具设计、上下文管理、任务分解策略都不同。同一个模型，装进不同的 Harness，就像同一台发动机装进不同的车，表现天差地别。

问题四："明明聊的好好的，怎么交付差这么多"

这是因为缺乏外部评估机制。没有独立的评估器，模型会自己说服自己"已经做得很好了"。生成器-评估器架构的价值就在于打破这种"自我感觉良好"的循环

六、结论

如果你觉得自己的 Agent 输出不稳定，不要急着换模型。先问自己几个问题：

你的提示词是否把任务拆得足够细？还是一口气把"做个完整的 XX 系统"扔给了它？同一个任务，"先创建用户表页"和"做一个包含用户管理的全栈应用"，结果会完全不同。
你是否在关键节点做了检查？还是让 Agent 自己说"我完成了"就信了？尝试在关键步骤后加一步"跑一下看看"或"检查是否符合预期"，而不是直接接受。
你的工作流是否被正确执行？如果你定义了 Skill 或 MCP 工具，Agent 是否真的按流程走了？还是自己"猜"了一个实现？关注 Agent 的工具调用日志，而不只是看最终输出。
你的会话是否太长了？当你觉得 Agent "前半段还行，后半段开始乱来"，很可能是上下文已经太长了。尝试新开一个会话，把前一轮的成果作为输入传递进去，而不是在同一个窗口里无限继续。
你是否在用适合这个模型的方式使用它？不同的 Agent 产品有不同的 Harness 设计。同一个模型，在 Claude Code 和 Trae 中的表现可能天差地别。了解你所用工具的Harness 设计理念，才能发挥模型的真正实力

正如 Anthropic 团队所说：

设计工具是一门艺术，不是科学。它取决于你使用的模型、Agent 的目标、以及它运行的环境。最好的建议？经常实验，阅读输出，尝试新事物。最重要的是，试着像 Agent一样思考。

同一个模型，结果差 10 倍。差的不是模型，是如何使用它。

张小龙说，人是环境的反应器。套在模型上也很像那么回事，模型是环境的反应器。

即，模型是 Prompt 的反应器，而 Harness，正是构建这个 Prompt 环境的建筑师

本文基于 Anthropic 四篇工程博客的核心洞察，结合 Hermes Agent 源码分析写成。 参考文章： 1. Harness Design for Long-Running Apps 2. Managed Agents: Decoupling the Brain from the Hands 3. Seeing Like an Agent 4. Multi-Agent Coordination Patterns

同一个模型，为什么结果差10倍？差的不是模型

引言

一、为什么你的结果不稳定？

1.1 上下文焦虑：模型"害怕"了

1.2 无限循环：模型"上头"了

1.3 自我评估偏差：模型"自恋"了

1.4 上下文爆炸：模型"失忆"了

1.5 单点故障：模型"挂了"

二、为什么别人比你稳定？

2.1 别人有 Harness，你没有

2.2 别人的 Harness 做了什么？

2.3 关键差异：不是功能，是假设

三、Harness 怎么解决这些问题？

3.1 解决上下文焦虑：预算制 + 优雅退出

3.2 解决无限循环：预算 + 退还机制

3.3 解决自我评估偏差：Generator-Verifier 分离

3.4 解决上下文爆炸：压缩 + 分裂 + 搜索

3.5 解决单点故障：5 级错误恢复

四、同一个模型，结果差 10 倍的真正原因

4.1 不是模型的问题，是 Harness 的问题

4.2 Harness 的 5 个维度决定了结果稳定性

4.3 最容易被忽视的差异：信息保真

五、 回到上一篇文章：这些问题如何解释

问题一：模型忽略了 Skill 中的工作流，直接猜测实现

问题二：模型反问完就结束工作了

问题三：同样的提示词，不同工具的结果不同

问题四："明明聊的好好的，怎么交付差这么多"

六、结论

五、回到上一篇文章：这些问题如何解释