当一个 AI 不够用：我是怎么从"模型拼接"掉进 harness 这个坑的

摘要：一个模型写代码、一个模型审代码、一个模型读文档——听着很美，直到它们半夜三点一起炸了。这篇文章讲的是，我怎么从"把模型粘在一起"走到"给模型搭一个操作系统"的过程。如果你的 AI 系统也在多个模型之间反复打补丁，这篇可能省你两周时间。

---

一、一个模型干不了所有活，这不是你的错

2026 年 1 月，我在做一个内部工具。需求不复杂：读一堆 PDF 技术文档，提取关键参数，生成一份结构化的配置文件。

我选了当时手边最强的模型，信心满满地把任务一口气扔给它。

结果？

它把一份 40 页的规格书读完了，前三页提取得漂漂亮亮，从第四页开始，参数就开始对不上号。等到第十五页，它已经开始"自信地编造"——那些参数名看着像那么回事，值全是瞎填的。

我加了 chunk 分段、加了 few-shot 示例、加了 CoT 提示。好了一些。但到 30 页以上的文档，准确率还是会塌。

问题不是"这个模型不行"。

问题是这个任务本身就不是单个模型该干的活——长文档理解需要耐心和上下文，参数提取需要精确和刻板，配置生成需要领域知识。一个模型再强，它的注意力窗口、它的推理风格、它的可靠性边界，也不可能在三个维度上同时拉满。

这不是模型的错。这是任务分配的错。

一个模型要同时擅长"耐心读长文"、“精确抠参数”、"懂领域规则"三件事。现实中不存在这样的模型。就像你不能指望一个人同时是外科医生、麻醉师和护士。

---

二、"拼"出来的系统，长什么样？

想通了这一点，我决定搞多模型协作。

方案很简单：模型 A 负责读文档、模型 B 负责提取参数、模型 C 负责校验和生成配置。串起来，像流水线一样。

我花了两天时间，用 Python 把三个 API 调用串在一起。中间加了 prompt 模板、加了 JSON schema 约束、加了错误重试。

跑通了。

Demo 效果很好。我截了图发到群里，同事说"牛"。

然后我把它部署到生产环境。

2026-01-17 凌晨 3:12，告警响了。

模型 B 在处理一份包含大量表格的 PDF 时，输出了一个不符合 JSON schema 的东西。模型 C 收到这个畸形输入，没有报错——它"理解"了一下，用自然语言回复了一段话，大意是"这份文档似乎有些问题，以下是可能正确的参数"。

它编的。而且编得很自信。

更糟糕的是，错误重试逻辑被触发了。模型 B 再次输出畸形 JSON，模型 C 再次自信地编造。重试了 4 次之后，系统安静地把一坨错误数据写进了数据库。

我第二天早上看到告警，回滚了数据，修了半天。

那一刻我意识到一个问题：把模型串起来不难，难的是当链条断了的时候，谁来兜底？

---

三、“那如果模型互相打架呢？”

我跟一个做 AI 平台的朋友聊了这段经历。他问了一个问题：

“你有三个模型，没有一个人负责看全局。模型 B 出错了，谁来发现？模型 C 在编造，谁来拦截？”

我说：“我写了校验逻辑。”

他说：“校验逻辑能拦 JSON 格式错误，能拦’参数看着对但实际是编的’这种错误吗？”

沉默。

他接着说：“你那个系统，就像三个实习生坐一排，各自干各自的，中间没有任何人 review。出了问题只能靠最后验收，但验收的人也是个实习生。”

这个比喻扎了我一下。

我缺的不是更好的模型，不是更细的 prompt，不是更严的 schema。

我缺的是一个"组织者"——一个能看全局、能调度、能兜底的运行框架。

---

四、harness：给模型搭一个操作系统

这就是 harness 这个概念跳出来的地方。

harness 直译是"挽具"——套在马身上的那些皮带和扣环，让马可以拉车。在 AI 工程语境里，harness 是把多个 AI 模型组织在一起的运行框架。

打个比方：模型是应用，harness 是操作系统。

你手机上装了微信、支付宝、地图。但让它们能正常工作的，不是它们自己有多强，而是操作系统在背后管理内存、调度进程、处理权限。单个应用挂了，操作系统决定是重启还是换一个。

harness 干的事一模一样：

调度——决定哪个模型接哪个任务。不是固定分配，而是根据任务特征动态选择。文档里有大量表格？派擅长结构化提取的模型。文档里有长段论述？派擅长长上下文理解的模型。

监控——持续观察每个模型的输出。不是事后校验，是实时看着它干活。发现输出偏离预期，立刻介入。

兜底——一个模型犯了错，不是简单重试，而是换一个模型来接。或者把任务拆小，分别喂给不同的模型。

记忆——记住哪些模型在哪些任务上表现好，哪些容易出错。下次遇到类似任务，直接选对的模型。

听着是不是有点像 Kubernetes 管容器？

确实。核心思想一样：你不需要每个组件都完美，你需要一个框架让不完美的组件也能交出可靠的结果。

---

五、我实际搭出来的第一版 harness

不是什么高深的东西。

我用 Claude Code 的 sub-agent 机制做了一个最小版本：一个主 agent 负责看任务全局，下面挂三个 sub-agent 分别负责读文档、提取参数、校验生成。

关键的设计决策只有两个：

决策一：错误归主 Agent 管

sub-agent 出了任何问题——格式错误、内容存疑、超时——不自己重试，汇报给主 agent。主 agent 来决定是换个模型重新做，还是把任务拆小。

这一个改动，就解决了凌晨三点炸库的问题。因为主 agent 能看到"模型 C 在编造"这件事，而原来的串行流水线看不到。

决策二：给每个 Sub-Agent 配一个"能力画像"

不是问"你是什么角色"，而是问"你擅长什么、什么条件下容易出错"。比如模型 A 的画像写的是：

┌─ 能力画像：Sub-Agent 1（文档理解）─────────────┐
│                                               │
│  擅长：长文档的结构化理解，                      │
│       尤其是带层级标题的技术文档                  │
│                                               │
│  弱点：纯表格文档会漏行，                       │
│       密排数据会丢失中间行                      │
│                                               │
│  兜底：如果输入文档超过 60% 是表格，             │
│       交给 Sub-Agent 4（表格专项）              │
│                                               │
│  历史表现：50 份文档测试，准确率 87%             │
│  最近更新：2026-02-15                          │
└───────────────────────────────────────────────┘

这个画像不是模型自己填的，是我跑了 50 份文档之后总结出来的。手动写的。朴素，但管用。

跑了一个月，准确率从 71% 拉到了 93%。不是因为模型变强了，是因为出错的模型被及时拦住了。

---

六、“这不是套壳调 API 吗？”

拿到这里，你可能会说：这不就是加了一层 orchestration 逻辑吗？跟 LangChain 那套有什么区别？

区别在"弹性"。

LangChain 那种链式调用，本质是写死的流水线——模型 A 的输出永远喂给模型 B，模型 B 的输出永远喂给模型 C。链子断了就是断了，重试逻辑是预设的，不会根据情况变化。

harness 不一样。harness 的调度是动态的，决策是基于当前状态的。

举个例子：模型 B 拿到一份文档，读了前面几段之后说"这份文档有大量数学公式，我处理不了"。在链式调用里，这一步就失败了。在 harness 里，主 agent 会说"行，换模型 E 来，它处理数学公式好使"。

这种"根据实时状态做调度"的能力，才是 harness 和简单 orchestration 的分界线。

---

七、踩过的坑

说几个真话。

坑一：主 Agent 太聪明反而坏事

第一版的主 agent 我给它配了很强的推理能力，结果它开始"越权"——觉得 sub-agent 做得不够好，自己上手重做。然后它做的还不如 sub-agent。

后来我加了一条硬规则：主 agent 只做调度和决策，不做具体任务。就像项目经理不用自己写代码。

越权的主 Agent：

  主 Agent："这个提取不对，我自己来"
       │
       ▼
  主 Agent 动手提取参数...
       │
       ▼
  结果比 Sub-Agent 还差  😅

解法：主 Agent 的 system prompt 里写死——
  "你只做调度和决策。永远不要自己执行具体任务。"

坑二：能力画像会过期

模型在更新，能力在变。我 2 月写的能力画像，到 3 月模型更新之后，有些弱点已经不存在了，有些新的弱点冒出来了。

解法没别的：定期跑 benchmark，刷新画像。目前我每两周跑一次。

坑三：兜底策略比你想象的复杂

"换个模型重新做"听起来简单。但换哪个？拆多小？中间状态怎么存？任务优先级怎么定？

我的经验是，先写最笨的兜底——重试一次，失败就人工介入。跑了两周看看人工介入的 case 有哪些规律，再把这些规律自动化。别一上来就写复杂的 fallback 树。

坑四：别让 Sub-Agent 之间直接通信

我试过让 sub-agent 之间互相传递中间结果，想着"模型 B 觉得拿不准的参数，发给模型 C 帮忙看看"。

结果两个模型开始互相"说服"——模型 B 给了一个存疑的参数，模型 C 说"看起来合理"，模型 B 说"那应该没问题"。两个不确定加在一起，变成了虚假的确定。

解法：sub-agent 之间不通信。所有中间结果都经过主 agent。主 agent 看到"模型 B 存疑"，不会问模型 C 觉得怎么样，而是直接换一个模型重做。

---

八、你真的需要 harness 吗？

不是所有人都需要。

如果你的任务用一个模型就能搞定，而且准确率够用——别折腾。harness 引入的复杂度是有成本的，调试、维护、监控，每一样都要时间。

但如果你发现在下面这些场景里反复挣扎，可能值得试试：

场景一：补丁叠补丁。 你不停地给同一个模型打补丁——加 prompt、加 few-shot、加后处理——修了 A 坏了 B。

场景二：多维需求冲突。 你的任务既要快、又要准、又要能处理边界情况，而任何单个模型都没法同时满足。

场景三：多模型无协调。 你的系统已经用了多个模型，但它们之间没有协调，出了问题全靠人工兜底。

场景四：错误代价高。 模型输出直接写入生产数据库或面向用户，一次编造可能造成严重后果。

不需要一步到位搭个完整的 harness。从最小的开始：加一个"主控"，让错误有地方汇报，让调度有地方决策。就这两个能力，就已经是质的变化。

---

九、结尾：从"用模型"到"管模型"

回到最开始的那个问题——40 页的 PDF，前三页漂漂亮亮，后面开始编造。

现在的解法不是找一个"不会编造的模型"。那种模型不存在。

现在的解法是：承认每个模型都会犯错，然后搭一个框架，让错误在扩散之前就被拦住。

这就是 harness 的核心思想。不是让 AI 更强，而是让 AI 的弱点可控。

从"用模型"到"管模型"，这一步跨过去，很多之前无解的问题就通了。

---

推广语：你手上的 AI 系统，有没有一个"看不见的管理员"在看着各个模型干活？如果没有，那些凌晨三点的告警，迟早会来。

---

本文首发于 CSDN，作者持续分享 AI 工程实践。如果这篇文章帮你少踩了一个坑，点个收藏就是最好的反馈。