别再争 Big Model vs Big Harness：用工程视角拆开 Agent 的“上限”和“兑现率”

很多人聊 Agent 工程时，会把问题简化成两派对立：要么押注更强的模型（Big Model），要么押注更厚的工程系统（Big Harness）。但真实世界里，这更像是在争“发动机 vs 方向盘”：它们决定的是不同指标，缺一不可。

本文面向 CSDN 读者，用工程视角把 Agent 能力拆成可落地的层次，并给一个可复用的最小落地示例（以本地工具链/IDE 型工作流为例，亦可迁移到你自己的平台）。

你是否遇到过这些问题

• 同一个模型：在 A 工具里像“高级工程师”，在 B 平台里像“实习生”。
• 模型看起来会写代码，但一到真实仓库就卡住：找不到文件、改不对位置、也没法验证。
• 你加了很多工具、很多路由、很多校验，结果系统更脆，维护成本更高。
• 你做了“知识库摘要”，短期 token 省了，长期 bug 变多：因为关键细节被摘要吃掉了。
• 团队每次用 Agent 的产出波动极大：看起来像“随机”，其实是“起点上下文”不稳定。

快速导航（按问题定位）

你看到的现象	优先读哪一节
“同模型不同环境表现差很多”	第 1 节、第 2.2 节
“工具越多越脆，越难维护”	第 2.3 节、第 7 节
“先摘要再喂看似省 token，实际更不稳”	第 3.1 节、第 4 节
“要把已知任务做快、做稳”	第 5 节、第 6 节
“想做一个最小可落地的工程闭环”	第 6 节、第 7 节

摘要（先看结论）

• Big Model 更影响能力上限；Big Harness 更影响能力兑现率。工程上更实用的表述是：Harness 决定下限，模型决定上限。
• 会被模型逐步“压缩”的主要是认知型编排（复杂提示链、强制规划器、反思循环、能力补丁钩子）；不会消失的是系统型基础设施（工具接入、权限、状态、反馈回路、可观测性）。
• 长期更靠谱的上下文策略是“索引 + 预览 + 按需读原文”，而不是“先摘要再喂模型”。
• 把“高质量启动上下文”做成可复用的 Checkpoint，比反复手工组装上下文更省 token、更稳定。

1. 先统一语言：Big Model / Big Harness / Agent 分别是什么

• Big Model：主要变量押在模型本身（推理、对齐、上下文能力）。直觉是“模型强到一定程度，很多编排都不需要了”。
• Big Harness：主要变量押在运行环境与工程系统（工具、权限、状态、反馈、评测与回放）。直觉是“同一个模型在不同环境里表现天差地别”。
• Agent：不是“一个模型”，而是“模型 + 可执行环境 + 闭环”共同组成的工作系统。

把它们放在一个类比里更直观：

Model ≈ CPU（算力/推理能力）
Context window ≈ RAM（一次能装下多少材料）
Harness ≈ OS（工具、权限、状态、反馈、隔离、可观测）
Agent ≈ App（把任务跑通的应用：感知→推理→行动→观察）

一个更“工程化”的补充：当你说一个 Agent “更强/更稳”，至少要拆成三个指标分别讨论：

指标	解释	常见误区
上限（capability ceiling）	能解决多复杂的问题	把上限当作稳定性
兑现率（delivery rate）	在真实环境里一次做对的概率	只看 demo，不看复现与验证
成本（latency/token/$）	每次尝试的时间与 token 消耗	只追求正确率，把成本打爆

三个指标的关系（直觉版）

          上限（capability）
                ▲
                │
                │  模型更强：更高天花板
                │
兑现率（delivery） ◀──────────────▶ 成本（latency/token/$）
    Harness 更好：更稳                Harness 更好：更省（更快、更少试错）

工程落地里最常见的坑：只追“上限”，却忽略了兑现率与成本。

2. Agent 工程的四个层次：哪些长期存在，哪些会被压缩

把“Agent 能力”拆成四层，工程策略会清晰很多：

四层结构（从“模型能力”到“系统可达性”）

┌──────────────────────────────────────────────┐
│  4）模型选型（决定上限）                      │
├──────────────────────────────────────────────┤
│  3）认知型编排（会被压缩）                    │
│     提示链 / 规划器 / 反思循环 / 各类补丁      │
├──────────────────────────────────────────────┤
│  2）试错闭环（效率看反馈回路）                │
│     测试 / 报错 / 日志 / 观测 / 回放           │
├──────────────────────────────────────────────┤
│  1）工具可达（无工具不可达）                  │
│     文件系统 / 命令执行 / 搜索 / 数据访问等    │
└──────────────────────────────────────────────┘

2.1 无工具不可达：模型再强也做不到

没有工具接入，就没有可达性。比如：

• 不能读写文件 → 不能真正改代码
• 不能跑命令/测试 → 不能验证改动
• 不能访问数据库/接口 → 不能拿到真实数据

这一层是 Harness 最不可替代的部分，属于系统基础设施。

2.2 需要试错才能做对：效率由“反馈回路”决定

很多工作模型能做，但需要多轮尝试与纠错，比如调 bug、在陌生仓库里找修改点。这里最关键的不是“模型能不能想出来”，而是：

• 每次试错的信息增益有多大（模型推理质量）
• 每次试错的成本有多低（Harness 反馈回路：日志/报错/测试/环境状态是否完整）

这也是为什么“只有模型，不给环境”的 Agent 经常表现像这样：

用户描述问题
   │
   ▼
模型输出一堆猜测
   │
   ▼
无法验证（没测试/没日志/没权限）
   │
   ▼
反复试错（低信息增益，高成本）

而一个好的 Harness 会把“每轮试错”变成可控的工程循环：

提出假设 → 定位证据 → 最小改动 → 运行验证 → 收集反馈 → 继续/收敛

2.3 会被模型压缩的部分：认知型编排

随着模型变强，越来越多“替模型思考”的脚手架会变成负担，例如：

• Prompt Chaining（提示链）：拆成很多步扶着模型走
• 复杂 Planner（复杂规划器）：强制路由/强制步骤顺序
• 反思 Loop（反思循环）：多轮自检、反复改写
• 能力补丁 Hooks：为模型短板加的拦截/纠偏规则

它们不是永远没用，而是更适合被当作“临时补丁/过渡方案”，而不是长期资产。

一个简单判断标准：如果你写的逻辑本质是在替模型做“认知决策”（选什么信息、走什么路径、怎么推理），那它很可能会被更强的模型压缩；如果你写的是“系统能力”（工具/权限/状态/反馈/审计），它长期更难被替代。

“会被压缩” vs “长期资产”（把争论落到工程分层）

        ┌──────────────────────────────┐
        │  Loop：感知→推理→行动→观察   │
        └──────────────┬───────────────┘
                       │
                       ▼
┌──────────────────────────────────────────────┐
│ 会被压缩的认知编排（越写越像“替模型思考”）    │
│ Prompt Chaining / Planner / Reflection / Hooks│
└──────────────────────────────────────────────┘
                       │
                       ▼
┌──────────────────────────────────────────────┐
│ 长期资产：系统基础设施（越写越像“给模型双手”）│
│ Tools / Permissions / Sandbox / State / Feedback│
└──────────────────────────────────────────────┘

2.4 模型选型：横向比较中最大的影响因子

同一时刻横向对比系统时，换模型往往比换编排更影响上限；但纵向长期趋势又会让编排简化。这并不矛盾：

横向截面（同一时间）：模型差异更显著 → 上限差异大
纵向趋势（跨版本演进）：模型变强 → 认知型编排被压缩

2.5 Harness 里到底应该“加厚”什么

为了避免“Big Harness 变成大杂烩”，可以把 Harness 的长期资产拆成下面几类：

组件	你到底在解决什么	最小落地形态
工具接入	让模型可达（能读写/能执行/能检索）	文件系统 + 命令执行 + 搜索
权限与审计	让行为可控（可回溯、可限制）	白名单、只读模式、审计日志
沙箱隔离	让副作用可隔离（不污染环境）	临时目录、容器/虚拟环境、mock
状态与记忆	让多轮任务不丢上下文	任务状态、checkpoints、历史记录
反馈回路	让试错更便宜（高信息增益）	测试输出、错误栈、可观测指标
索引与预览	让“找资料”变快（可导航）	llms.txt + 目录 README + 入口清单

3. 两种常见但容易“误判价值”的建设方向

3.1 错误方向：先摘要再喂（压缩必失真）

很多团队会先对仓库/文档跑一遍总结，再把摘要塞进上下文。短期看起来省 token，长期问题是：

• 摘要不可逆丢信息
• 模型还以为自己看全了（不知道自己不知道）
• 真正关键的细节往往是任务相关的，而不是“摘要时看起来重要的”

更靠谱的策略是“索引/预览 + 按需读原文”。

✗ 先摘要再喂（信息不可逆丢失）          ✓ 索引 + 按需读取（可回溯到原文）

┌──────────┐      ┌──────────┐          ┌──────────┐      ┌──────────┐
│ 原始文档  │  →   │  LLM 摘要 │   →      │  llms.txt │  →   │  Agent   │
└──────────┘      └──────────┘          └──────────┘      └────┬─────┘
                                                     按需打开原文 │
                                                                 ▼
                                                           ┌──────────┐
                                                           │ 原始文档  │
                                                           └──────────┘

3.2 正确方向：索引 + 预览 + 按需获取原文

可以把知识环境分三层：

• 索引层：目录结构、模块边界、关键入口（天然结构化，不需要模型“理解”）
• 预览层：每个模块/文件提供简短可导航的提示（标题、接口、入口函数）
• 原文层：需要时直接读原始内容（不经过摘要中间层）

如果你要把它落到一个真实仓库，建议按“先索引后预览”的顺序做：

1. 先补一个 llms.txt（目录入口，告诉 Agent 从哪开始）
2. 再补每个一级目录的 README（提供“预览”与“入口”）
3. 最后才考虑把长文拆页、加标签、补示例

索引 + 预览 + 原文 的三层（把“找资料”做成导航，而不是摘要）

┌──────────────┐
│   索引层      │  llms.txt / 目录 README / 入口清单
└──────┬───────┘
       │（定位）
       ▼
┌──────────────┐
│   预览层      │  章节标题 / 接口列表 / 示例入口
└──────┬───────┘
       │（确认相关）
       ▼
┌──────────────┐
│   原文层      │  直接读 Markdown / 源码 / 真实配置
└──────────────┘

4. llms.txt：给 Agent 用的“目录入口”，不是摘要

llms.txt 可以把它理解成“给大语言模型看的索引入口文件”：

• llms 是 LLMs（Large Language Models，大语言模型）的缩写
• llms.txt 更像目录/站点地图，而不是摘要
• 常见放在站点根路径 /llms.txt（纯文本），让 Agent 先读索引，再按需打开原文

llms.txt 在体系里的位置（站点/仓库“导航入口”）

            ┌──────────────────┐
            │      llms.txt     │
            │  Start here + TOC │
            └────────┬─────────┘
                     │
        ┌────────────┼─────────────┐
        ▼            ▼             ▼
   README.md    docs/overview   blog/ai/...
   （入口）      （机制）        （专题）

一个最小模板如下（按你自己的站点/仓库改路径即可）：

# Docs Index for LLMs
这是一份面向 Agent/LLM 的文档索引入口，优先“看目录→按需读原文”，不要依赖摘要。

## Start here
- /README.md
- /blog/README.md

## Key topics
- /blog/ai/README.md
- /blog/ai/agents/
- /blog/ai/tools-protocols/

## Notes
- 优先读 Markdown 原文；长文件按需分段读取。
- 遇到概念名词不确定，先在索引里定位到定义页。

一个更适合工程团队的习惯是：让 llms.txt 只承载“导航信息”，不要承载“解释性长文”。解释应该留在具体页面里（避免索引文件膨胀、也避免重复维护）。

5. 把“已知任务”做快：沉淀三件套（说明书、模式库、Checkpoint）

已知任务之所以能做快，不靠“更聪明”，靠“更少重复劳动”。最实用的三类沉淀如下：

沉淀形态	载体	解决的问题	典型例子
静态指令/模板	文本规范与 runbook	让 Agent “知道怎么做”	CLAUDE.md / AGENTS.md / 任务模板
过程性沉淀	经验条目与模式库	让 Agent “少走弯路”	源发现策略、已验证无效路径、工具序列
启动上下文 Checkpoint	可复用的就绪状态	让 Agent “从正确起点出发”	目标/入口/约束/观测点/关键路径

其中最容易被忽视、但收益极高的是：启动上下文 Checkpoint。

沉淀三件套怎么配合（从“知道”到“能稳定做到”）

┌──────────────────────┐
│  说明书 / Runbook     │  AGENTS.md / CLAUDE.md / 模板
│  解决：怎么做         │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│  模式库 / 剪枝清单     │  patterns.md / pitfalls.md
│  解决：别走哪些弯路     │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│  Checkpoint（就绪状态）│  bugfix-ready.md / content-edit-ready.md
│  解决：从正确起点出发   │
└──────────────────────┘

5.1 启动上下文 Checkpoint：为什么能让结果更稳定

“同一个任务”之所以每次结果波动大，常见原因不是模型随机，而是起点不同：

每次重新组装上下文（方差大）                 从 Checkpoint Fork 出发（方差小）

[Agent Start]                                  ┌──────────────────────┐
   ├─ 收集工具清单                              │      Checkpoint      │
   ├─ 检索背景文档                              │  (Ready-to-run 状态)  │
   ├─ 推理约束条件                              └─────────┬────────────┘
   └─ 正式执行                                            │
        ├─（顺序/取舍不同）                                ├──────────▶ [正式执行] A
        └─（信息遗漏/噪声不同）                            └──────────▶ [正式执行] B

把“高质量起点”固化下来，往往比“多写几条提示词”更直接有效。

再补一个可操作的视角：已知任务的“快”和“稳”，通常来自于你把下面三件事提前做完了：

• 入口明确：从哪个文件/哪个目录开始看
• 观测明确：跑什么命令、看什么输出，如何判定“改对了”
• 剪枝明确：哪些路是死胡同，哪些操作是禁区

5.2 一个极简的 Agent Loop（伪代码）

下面用伪代码表达“闭环 + 工具 + 反馈”的最小结构（重点是结构，不是语言细节）：

state := { goal, constraints, notes, evidence }

while not done(state):
  plan := think(state)
  action := choose_tool(plan)
  result := run(action)
  state := update(state, result)

把 checkpoint 加进去，本质就是把 state 的初始值做成可复用资产：

state := load_checkpoint("bugfix-ready")
state.goal := user_goal

6. 一个可复制的最小落地示例：用 Trae 思路把沉淀落到仓库

你不需要先做一个“宏大平台”。先把最小闭环跑起来：把索引、说明书、checkpoint 都放进仓库，任何人/任何 Agent 来了都能按目录走。

推荐的最小结构如下：

repo/
  AGENTS.md
  CLAUDE.md
  llms.txt
  .trae/checkpoints/
    bugfix-ready.md
    content-edit-ready.md

其中 .trae/checkpoints/bugfix-ready.md 可以这样写（模板，直接复制改字段）：

# Checkpoint: bugfix-ready

目标（验收口径）
- 修复：<现象>
- 验证：<怎么证明修好了：测试/截图/日志>

入口（先从这里开始）
- 代码：<关键目录/文件>
- 文档：<索引入口，如 llms.txt>

观测点（每轮迭代都要看）
- 运行：<测试/构建命令>
- 关注：<错误栈/日志关键词/性能指标>

已知坑（剪枝清单）
- 不要做：<不可逆操作/会污染数据的操作>
- 已验证无效：<走过的死胡同>

源发现策略（检索套路）
- 先看：llms.txt / README / docs index
- 再看：入口函数/路由/handler 的调用链
- 最后：带着关键词做全局搜索

这类 checkpoint 的目标不是写“文学”，而是把你最想反复提醒自己的那几件事，固化成可复用起点。

如果你想再向前一步，把“已知任务做快”真正做成工程资产，可以加一个“模式库”文件，例如：

docs/patterns.md
- 如何快速定位入口（路由/handler/Controller）
- 如何从报错反推调用链（关键关键字策略）
- 如何最小化改动（先加观测，再修逻辑）

6.1 实战演示：同一个“修 bug”任务，怎么从混乱变得可复现

下面用一个非常典型的“修 bug”任务来演示：如何把任务从“凭感觉改”变成“可复现、可回放、可验收”。

假设现象是：

• 有一个接口在某些输入下会返回错误数据
• 你需要修复它，并补一个最小测试证明修复有效

如果没有 Harness/Checkpoint，常见的失败路径是：

读错入口 → 猜测性修改 → 没验证手段 → 继续猜 → 最后靠运气跑通

把 checkpoint 落地后，任务会变成标准化流程：

1. 从 bugfix-ready.md fork 一份任务状态（或者复制一份到本次任务里）。
2. 填写验收口径（要修什么、怎么证明修好了）。
3. 按“入口”先定位到正确文件/调用链，再动手。
4. 每次修改都跑一次“观测点”里的命令拿到反馈（测试/日志/报错）。
5. 把关键证据（错误栈、关键日志、测试输出）追加到 evidence，保证可复盘。

你会发现：这套流程最关键的不是“模型能不能写出正确代码”，而是把“定位—验证—回放”做成低成本重复动作。

6.2 实战演示：内容类任务怎么做成 Checkpoint（更贴近 CSDN 写作场景）

不只是写代码，写文档/写博客同样适合 checkpoint。一个“内容编辑”checkpoint 的核心是：

• 风格：读者是谁，语气是什么，哪些词尽量不用
• 结构：文章骨架固定（摘要→导航→正文→清单→总结）
• 产出：必须有 ASCII 图、必须有 checklist、必须可复制
• 禁区：不写公司内部敏感信息、不贴不可公开链接、不做洗稿改写

你可以按下面模板做一个 content-edit-ready.md：

# Checkpoint: content-edit-ready

目标（验收口径）
- 产出：一篇可发布的 Markdown（含摘要、导航、ASCII 图、清单）

读者与语气
- 读者：CSDN 工程师
- 语气：工程化、少口号、多 checklist

结构骨架（不要跳级）
- 摘要（先看结论）
- 快速导航（按问题定位）
- 正文（按“问题→原理→落地”）
- 工程化清单
- 结语

禁区
- 不引用公司内部内容，不做洗稿改写
- 不贴敏感链接与私有数据

把它放进仓库后，任何一次写作任务都从这个“就绪状态”出发，质量会稳定很多。

7. 工程化落地清单（你可以直接照抄到团队规范里）

• 工具与权限：先把“可达性”补齐（读写文件、跑测试、检索、预览、隔离）
• 反馈回路：每次尝试都要能看到全量报错/日志/测试结果
• 文档策略：索引优先、按需读原文；摘要只是最后手段
• 沉淀体系：说明书（规范）+ 模式库（剪枝）+ checkpoint（高质量起点）
• 复杂编排：默认当作临时补丁；每次模型升级都要敢于做减法

把环境做成“agent-friendly”（你真正要加厚的是这几层）

┌──────────────────────────────────────────────┐
│ 索引与预览：llms.txt / README / 入口清单      │
├──────────────────────────────────────────────┤
│ 反馈回路：测试/日志/报错/指标（全量可见）     │
├──────────────────────────────────────────────┤
│ 状态与回放：任务状态 / checkpoints / history  │
├──────────────────────────────────────────────┤
│ 权限与隔离：白名单 / 只读 / 沙箱 / 审计       │
├──────────────────────────────────────────────┤
│ 工具接入：读写文件 / 执行命令 / 搜索 / 预览   │
└──────────────────────────────────────────────┘

把它再落到“可验收”的层面，你可以用一组非常朴素的验收题来检查 Harness 是否到位：

验收题	能答出来说明什么
Agent 能否在 2 分钟内定位到入口文件？	索引/预览有效
Agent 能否跑一次验证并拿到全量输出？	工具/反馈回路有效
Agent 失败后能否给出可复现的证据链？	可观测性与状态有效
同类任务重复 3 次，行为方差是否显著下降？	checkpoint 真的在起作用

把“验收题”当成闸门（过不去就别急着堆更多编排）

[定位入口] → [跑通验证] → [拿到证据链] → [重复任务更稳定]
     │            │             │              │
     ▼            ▼             ▼              ▼
   索引好       工具好         可观测好        checkpoint 好

8. 结语：真正可持续的 Harness，是“为删除而设计的”

模型会持续变强，认知型编排会持续被压缩；但工具、权限、状态、反馈、索引这些系统基础设施会长期存在，并变得更重要。

与其追求“写一个很聪明的编排系统”，不如追求“让环境变得可导航、可验证、可回放”，让 Agent 像一个刚入职但很聪明的工程师一样：翻一下目录，就知道从哪里开始做事。