11Harness 概念边界
四个术语,按"所有权"维度区分:
| 类别 | Own 什么 | 交付给谁 | 典型产品 |
|---|---|---|---|
| Framework | 组件(chain、agent、tool 类) | 库 → 开发者 | LangChain, AutoGen |
| Runtime | 执行图、状态机、持久化 | 平台 → 开发者 | LangGraph, Temporal |
| Harness | 主循环、permission、UI、context | 产品 → 终端用户 | Claude Code, Cursor |
| Platform | 模型托管 + infra | 云 → 开发者 | Bedrock, Vertex AI |
Framework = 工具箱。LangChain 给你 LLMChain、AgentExecutor、Tool 这些类,你写 Python 拼装。Framework 本身没有"运行"的概念,它是个 lib。
Runtime = 执行容器。LangGraph 让 agent 写成有向图自动管 checkpoint;Temporal 把每个 agent 步骤变成 durable workflow,挂了能恢复。Runtime 解决"agent 怎么稳定跑",但 agent 是什么样、loop 怎么转,还是开发者写代码定义。
Harness = 跑着 agent 的产品本体。Claude Code 不是一个 lib,是 CLI 工具,装上就有完整 agent 跑着。Harness 工程师 own 的是 loop 控制(死循环检测、最大步数)、permission 决策(哪些 tool 自动跑、哪些要确认)、context 管理(满了 reset 还是 compact)、tool registry(哪些 tool 暴露给模型)、UI bridge(streaming 怎么渲染、用户怎么中断)——这些都是产品决策,不是用户能配置的。
Platform = 模型基础设施。AWS Bedrock 给你 API endpoint 调用各种模型,处理认证、计费、合规。不关心 agent 怎么写。
为什么这个区分关键:做 harness 工程,要的是"造产品本身"的能力。如果你说"我用 X framework 搭了 agent",在懂行的人听来等于"我是 framework user,不是造 harness 的人"。差一个抽象层级,工程深度天差地别——这直接决定你能解决的问题边界。
案例:Cursor 的分层
Cursor 的产品架构(基于 VS Code fork)分层如下:
┌─────────────────────────────────────────┐
│ VS Code 内核(UI runtime,不是 harness) │
├─────────────────────────────────────────┤
│ Cursor Composer / Agent 模式 │ ← Harness 本体
│ · own agent loop │ (Cursor 团队的差异化资产)
│ · own permission(Apply / Reject UX) │
│ · own diff UI、streaming 渲染 │
│ · own tool registry │
├─────────────────────────────────────────┤
│ OpenAI / Anthropic API(Platform) │
└─────────────────────────────────────────┘
Cursor 对接 LangChain 吗?没有——他们自己实现 agent loop,因为要 own loop 控制 + UI 集成。Framework 给不了这种 vertical integration。
这个例子里,harness 层就是 Cursor 的核心差异化资产。如果他们用 LangChain,产品体验会变成"AI 集成插件",而不是"AI-native 编辑器"。
什么场景要造 harness(而不是用 framework)
- 终端用户直接交互的产品(coding agent、客服 agent、操作 agent)
- 需要 own 用户体验细节(streaming、permission UX、撤销 / 重试 UI)
- 要 vertical integration——loop 控制要配合 UI 和 permission 一起设计