三层分清：Harness、框架和 MCP 到底谁管循环与恢复？

9 月这几周，行业里又在搞混三个词：Harness、Agent Framework、MCP。排障时最常见的误诊是：工具失败就疑 MCP，权限弹窗就疑协议，会话丢了就疑模型。三层混过一遍仍然不清楚。

更好用的问法是：这个能力换模型之后还必须留下来吗？它负责的是调用长相还是任务成败？回答不同，就该落在不同层。

一、MCP 管的是接口，不管运行时

MCP 是线协议，把 host、client、server 之间的工具、资源、prompt 发现统一成 JSON-RPC。它不负责 Agent 从哪一步继续，也不负责会话能不能恢复。

近几个月 MCP 在往外扩：Elicitation、长任务 Tasks、Skills over MCP。这些都是交互模式，不是把 MCP 变成 Agent。维护方已经画过线：核心回到请求响应。协议越强越应该更像插头，而不是变速箱。

排障启发式：工具调用失败，先看 host 有没有重试、降级和错误语义；不要一开始责备协议。MCP 只定调用长相，重试与否仍由客户端或 Harness 决定。

二、框架管的是编排抽象，不管业务不变量

LangGraph 一类框架的价值是把节点、边、checkpointer、持久化模式给出来。你可以用它拼出一条可重放的图。但是「任务算不算完成」「写操作要不要审批」「中断后从哪个检查点为人接」，仍要业务组自己定。

框架常被当成 Harness 的替代品，是因为它也有 loop。区别在于：框架提供可编程的控制流；Harness 要证明控制流在真实副作用下仍可信。换一套图执行引擎，业务不变量应该还在：完成定义、权限闸门、审计留痕、会话恢复。

三、Harness 管的是循环、状态与恢复

Harness 是把模型包起来、让任务能跑完的那一层。它至少要管四件事：

• 循环：下一步谁决定、何时退出、何时交给人
• 状态：会话能恢复、文件能回滚、进度能外置
• 权限：工具调用前谁批准、默认拒绝还是默认放行
• 恢复：中断、压缩、检查点、fork。这里是 Harness 挣饭的地方

Anthropic 把生成者和评估者拆开，是因为自我打分会偏乐观。更直白的一点是：同一个模型，换一套 Harness，评测分数和 token 消耗都能出现量级差异。这说明恢复与约束不是装饰，是能力的一部分。

四、一条可执行的划界

换模型、换工具实现仍要保留的，算 Harness。

换编排引擎仍能重用的图结构与中间件，算框架。

只定义调用长相、不负责任务成败的，算 MCP 或工具协议。

三个常见串层：

• 把 MCP 当成权限系统。权限弹窗是 host / Harness 的策略，协议不管「永远不问」。
• 把框架当成完成定义。checkpointer 只保证能重放，不保证业务上算做对。
• 把 Harness 当成另一个 SDK。Harness 该管不变量，不该替代业务工具本身。

五、排障时先问哪一层

工具调用失败：先看 Harness 的重试与熔断，再看 MCP 连接。

权限弹窗：去改 Harness 权限模式或审批中间件，不要改协议。

会话丢了：先看 Harness 的 session、transcript、checkpoint，再看框架的持久化模式。

模型能力波动：先不换模型。先看压缩、检查点、独立验收是否在起作用。

结语

三层混在一起，最终会做出一个什么都能插、什么都守不住的大一统平台。分开之后，MCP 负责工具怎么被发现，框架负责图怎么被编排，Harness 负责任务怎么被证明做对。模型会换，协议会迭代，唯一应该长期投资的，是那套能恢复、能审计、能验收的运行时。