需要自进化的不是 Agent，而是 Harness
作者: Arvin Xu (@arvin17x) — LobeHub 创始人、Ant Design 核心成员 日期: 2026-05-27 来源: Twitter Article 互动: 226 likes, 39 retweets, 402 bookmarks, 53K views
单独的模型已经不再是产品。模型 + harness 才是产品。
因为 Harness 负责把模型、工具、上下文、权限、环境和用户任务组织在一起。它不直接等同于 Agent，却决定了 Agent 能不能稳定地做完一件事。一个好的 Harness 不只是负责调用模型，它更像一套运行时：什么时候该给模型什么信息，什么时候该调用工具，失败后如何恢复，哪些错误应该展示给用户，哪些错误应该被系统自己吸收。
Lobehub 多样的模型支持让我们不得不深入思考这个问题。单独厂商可以根据自家模型定制，但是当我们不清楚模型的性格，又要一套框架适配所有模型时，就是一个巨大的挑战。
本文将聊聊如何设计一个健壮、自进化的的 Harness。
一个正在发生的范式转移
2026 年整个上半年，AI 行业正在经历一场轰轰烈烈的范式转移。
早期的 AI 产品竞争，很大程度上是模型能力竞争。更高的 benchmark、更快的推理、更长的上下文窗口，都会直接带来可见的体验差异。但是到 2026 年，边际效应逐渐递减。在很多用户的日常任务里，模型本身的水平已经不相上下，任务效果迁移到了对环境的感知和控制。
这是 Phil Schmid （我所知道的，最早提出 Harness 概念 的人）所说的「持久性（Durability）」 的体现 —— 模型在执行数百次工具调用后，还能多好地遵循指令？一个模型在 benchmark 上领先 1%，并不能说明它在第 50 步不会误删文件、忘记约束，或者在工具失败后开始编造结果。
但这里有一个悖论：模型越来越强，构建在其上的产品体验却未必同步提升。为什么？
因为缺失了一环：产品本身能否随模型迭代、用户使用而自动进化。
什么是 Harness？为什么它必须是活的？
在进入正题之前，我们需要先理解一个概念：Agent Harness。
如果把模型看作 CPU，上下文窗口像 RAM，Agent Harness 就接近操作系统。它管理启动过程、上下文、工具、错误和生命周期。Agent 则是跑在这套运行时之上的应用逻辑。CPU 再快，如果操作系统不会调度进程、不会处理 I/O、不会隔离权限，用户仍然会觉得电脑不好用。Agent 产品也是一样。模型能力是基础，Harness 决定这些能力能不能在真实任务中稳定释放出来。
在 LobeHub，我们的 Harness 主要围绕几层系统构建：Model Runtime 适配不同模型供应商，Agent Runtime 实现云原生的步级 Agent 循环，Context Engine 管理上下文策略，Environment 提供 Page、Task、Group、IM 等不同使用环境。这里的重点不是模块名字，而是它们共同承担的职责：让 Agent 在复杂、不稳定、长链路的真实环境里继续工作。
但这带来了另一个问题：Harness 本身也会过时。模型接口会变，工具 schema 会变，用户任务会变，错误模式也会变。一个今天看起来合理的上下文策略，可能在下个月的新模型上变成负担。一个原本只在小流量下偶发的 provider 错误，可能随着用户增长变成主要故障来源。
如果每一次变化都需要工程师手动发现、分类、修复，是非常低效的。所以我们自然会抛出一个问题：Harness 能不能也像模型一样，自己进化？
当然，这里所说的进化，并不是那种现在很多人提到的「产品开发者用自己的产品开发自己」的现象。这种自举形式的主体仍然是人，很大程度上会被人类的处理带宽所局限。我们想说的进化，是更高一层的自我演进。
让 Harness 学会自己进化：Tracing 是核心构件
我们认为 Harness 的下一步，不是再仅仅是被动的执行环境，而是主动的自我进化系统。这里的「进化」指的不是模型变强——那是模型厂商的事。进化的对象是 Harness 自身。 一个 Harness 需要在四个核心维度上持续优化：
- 上下文策略：Context Window 是有限资源。系统需要知道哪些信息该进入上下文，哪些可以延后，哪些应该压缩，哪些应该从任务历史里恢复
- 工具编排：工具 schema 怎么设计、什么时候调用、失败后是否重试、重试时改什么参数，这些很难靠设计会议一次想清楚，只能在真实任务里慢慢暴露
- 错误认知：系统必须知道什么会出错。每出现一种新的错误模式，都是 Harness 对自己边界的一次更新
- 模型适配：我们接入了 70 多个模型 provider。它们的 API、限流、错误格式、reasoning 字段和边界行为都不一样。适配层如果不能持续学习，维护成本会越来越高
这些问题的共同点是：它们需要可以像日志一样被记录。
要让 Harness 改进自己，首先要让系统知道自己刚才发生了什么、是好事还是坏事。实现这个前提，需要一个最基础的能力：可追溯。
每一次 Agent 执行——调用了什么模型、每个 LLM 调用花了多少钱、哪一步出错了——都需要被完整记录下来。没有这些记录，Self-Evolution 就是空中楼阁。
行业的集体困境：为什么 Tracing 这么难？
大家可以观察到整个 Agent 行业都在喊 Tracing 难做，而且这些不是偶然的抱怨，但是为什么？我们分析了 LangChain、CrewAI、OpenAI Agents SDK、AG2 等这些主流的 agent Framework 的源码，发现了一个共同的模式 —— tracing 都是在执行模型之上「后加」的：
- LangChain：callback 是可选的，忘了注册就丢 trace
- CrewAI：事件监听器挂在事件总线上，事件丢失 = trace 断裂
- OpenAI Agents：需要显式创建 trace，不自动传播
- AG2：middleware 是可选安装的，不装就零 tracing
它们的架构可以概括为一句话：
执行 → [需要手动加 callback/listener/middleware] → 产生 trace
这就是为什么行业都在说难—— 不是因为大家不会用 OTel，是因为大家所使用所有 runtime 架构，都没把 observability 当作一等公民。
而在 LobeHub，我们的 agent runtime 采用的状态机模型从根本上不同，按照「单步执行」原则做了细粒度拆分，每个 step 天然就是一个 trace event。Tracing 是执行的副产品，不是后装功能。
单步执行 → 自然产生 trace（run step = event boundary）
同时，在这套运行时之上，我们完整自研了一套 Agent Operation Tracing 基础设施，为每一次 Agent 执行生成一个完整的 Execution Snapshot（执行快照）——它记录下所有关键数据：调用了哪个模型、每个 LLM 请求花了多少 Token、每一步是什么类型（调模型还是调工具）、耗时多久、最终走了几步、在哪一步出错、错误是什么。这些快照被持久化存储，可以随时回溯、分析和对比。
举个例子，一条 Agent Operation Tracing 在在我们的 CLI 中看起来大概是这样的：
Agent Operation op_123456 claude-sonnet-4-6 6 steps 45.2s
├─ Step 0 [call_llm] 3.1s
│ ├─ LLM in:4.2k out:156 tokens cache:87%
│ └─ Output I need to search the user's document library first...
├─ Step 1 [call_tool] 2.4s
│ └─ Tool search_documents ✓
├─ Step 2 [call_llm] 8.7s
│ ├─ LLM in:8.1k out:342 tokens cache:92%
│ ├─ → 2 tool_calls: [edit_file, read_file]
│ └─ Output Found relevant docs, now I need to modify the config...
├─ Step 3 [call_tool] 1.2s
│ ├─ Tool read_file ✓
│ └─ Tool edit_file ✓
├─ Step 4 [call_llm] 25.3s
│ ├─ LLM in:12.5k out:1.2k tokens cache:76%
│ └─ Output File modified. Here's a summary of the changes...
└─ Step 5 [call_tool] 4.5s
└─ Tool create_pr ✓
└─ done tokens=8.4k cost=$0.0423 cache:84% hit:7.2k miss:1.2k
这类记录在开发调试时有用，但它更大的价值在于生产环境。每一次失败都留下了足够多的上下文 —— 每一步的类型、耗时、Token 消耗、cache 缓存率、调用链、以及最重要的：单步执行时候的 Context Engine、出错时的上下文 ——都被完整保留了。
这意味着 Harness 的所有后续优化，无论是要分析错误模式、优化上下文策略、还是适配新模型，都建立在真实运行数据之上，而不是靠猜。
Trace 就像是 Harness 的黑匣子。黑匣子本身不解决问题，但它让问题第一次变得可以回放、归因和比较。
一个已经在生产上跑的案例：Error Pattern 自动巡检
我们在4月初左右完成了整个 Tracing 系统构建，这些 “黑匣子” 里的数据，很快就验证了它的价值 —— 这个案例就是我们的 Error Pattern 自动巡检系统，也是在我们的 Harness Engineering 实践中 Self-Evolving Harness 理念的一个缩影。
众所周知，LobeHub 的 Model Runtime 接入了 70+ 个 AI Providers（OpenAI、Anthropic、DeepSeek、Gemini、MiniMax、Kimi、GitHub Copilot 、Coding Plan …），每天承接处理大量的 Agent 运行。而每次模型调用失败，都会在我们的系统中留下一条错误记录，错误来源大致可以分成几类：用户的 API Key 过期、余额不足、触发速率限制；上游服务临时不可用或网络超时；Harness 自身存在 schema 不兼容、context window 溢出、thinking mode 元数据丢失等问题。
要知道 Error handling 本质上是后置的 —— 开发者永远无法在不知道有什么错误的情况下，设计出完备健壮的错误处理体系。 你只能在错误真实发生后，才知道需要处理什么。但用户一旦遇到未处理、未归类的错误，体验就会立即恶化。这意味着：错误认知能力的增长速度，直接决定了产品体验的下限。
传统做法是定期看后台数据，人工分类，再手动修复。这种方式在低频系统里可以接受，在高频 Agent 运行环境里很快会失效。错误产生的速度高于人工分类的速度，未归类错误就会不断堆积。用户看到的是一条陌生的报错，系统看到的是一个还没被理解的模式。
于是我们把失败 trace 的查询权限开放给 Agent，让它批量解析 tracing，按 provider、errorType、status code 和 message 分桶，对照已有 pattern 找出未覆盖的错误，再生成修复建议。对于明确的用户侧错误，Agent 可以直接更新匹配规则；对于 Harness 自身缺陷，它会继续做根因分析，生成需要工程确认的修复任务。
这套系统已经运行了九轮，数字会说话：
- 累计 Pattern 从 31 增长到 104 后趋于平稳，新增 Pattern 从 31 持续下降至 0——即使 error 日志量在 334~1158 之间大幅波动，收敛趋势始终不变：Pattern 库趋于饱和，新错误几乎全部命中已有 pattern。
- Agent 在巡检过程中自主发现了 20+ Harness 自身缺陷，从 Tool schema 不兼容、负数 max_tokens、DeepSeek reasoning_content 丢失、Context Window 过载等。这些都是在真实运行中暴露的问题，有些 bug 甚至人都很难发现，而这些 bug 都已经在巡检后第一时间修复。
这正是 trace 驱动改进的价值：它不仅减少错误噪音，还能把 Harness 的薄弱点从运行数据里挖出来。
随着迭代的次数的深入，我们将整个流程变成了一个标准化的巡检 skills：
- 数据采集：从后台中拉取最近的 error records，按 provider、errorType、message 进行多维度分桶
- 模式识别：对比已有的用户维度的 ERROR_PATTERNS，识别新的错误模式
- 自动分类：将用户侧错误（余额不足、速率限制等）与 Harness 自身 bug（Schema 不兼容、Context 溢出等）分开
- 自动修复：对于用户侧错误，直接更新匹配 Pattern
- 自动提交：commit → push → 开 PR
- 自动清理：删除 Dashboard 中匹配新 pattern 的历史噪音
- 根因分析：对于 Harness 自身的 bug，深入分析根因，创建相应的修复 Task
在这套巡检运行后，我们的 Agent 成功率从早期的约 75% 提升到 95% 以上。虽然不能说明所有问题都解决了，但它说明一件事：Harness 的错误认知可以随着使用增长而增长。
这就是 Self-Evolving 的本质：Harness 在持续使用的过程中，自己在变好。
Harness 自进化的四个层次
从 Error Pattern 巡检这个例子看，Harness 自进化并不是一步到位的。它更像一个连续谱。
- L0 — 纯人工：人发现问题，人分析，人修复。
- L1 — Agent 辅助：Agent 找出可疑问题，人确认，再让 Agent 执行部分修复。
- L2 — Agent 主导：Agent 可以主导大部分流程：采集数据、识别模式、修改代码、提交 PR、跑验证。人仍然保留关键判断，比如根因归属、修复方向、是否影响用户体验。
- L3 — 人监督：Harness 能持续观察自己的运行状态，发现可改进点，提出修复，经过人确认后执行并验证。人不需要盯着每一条日志，而是设定目标、审查边界和处理少数高风险决策。
LobeHub 的 Error Pattern 巡检大致处在 L3。Agent 已经能完成数据采集、模式识别、代码修改、PR 提交和噪音清理，但在一些关键判断上仍然需要人。对于生产系统来说，“完全自动”并不是天然更好。真正重要的是把人从重复分类、重复排查、重复修复里解放出来，让人的注意力放在判断和设计上。
而下一步 L4 的预期形态是：Agent 还能主动优化 Context Engine 的策略、调整 Tool schema 的兼容层、预测和预防错误——Harness 自己进化自己，人只需要设定一个目标，而我们正在实现的路上。
为什么 Consumer-Aimed Product 本质上是 Self-Evolving 的 Harness？
这个实践让我们看到了一个更大的图景。
传统 SaaS 产品的逻辑是：产品 = 功能代码 + 用户数据。功能是固定的，用户数据是副产品。产品变好靠的是版本更新——人写代码、人测试、人发布。
AI-Native 产品的逻辑则完全不同：产品 = Harness（运行时）+ 用户交互数据 + 进化能力。每一次用户交互都在为 Harness 提供进化信号——不是训练模型，而是优化运行时。
这意味着：
- 真正的护城河不是模型，而是 Harness 中沉淀的上下文、pattern、trajectory —— 模型是通用的、外部的、可替换的，Harness 是专属的、内部的、持续积累的。当你的 Harness 积累了数百个 error pattern、上万条 trajectory 数据、针对你的用户场景优化的 context strategy —— 这是竞争对手无法复制的
- 产品体验随使用自动变好，而非等待版本更新 —— 传统产品：用户遇到 bug → 反馈 → 等排期 → 等发布 → 更新；Self-Evolving 产品：Harness 自动发现 → Agent 自动分析 → Agent 自动修复 → 用户无感升级
- 用户在使用产品的过程中，也在”训练”产品 —— 每一次模型报错，都在丰富 error pattern 的执行回路；每一次 Context 溢出，都在优化 context compaction 策略；每一次 Tool call 失败，都在完善 schema 兼容层
这就是为什么我想说：新一代 Consumer Product 本质上是一个 Self-Evolving Harness。
OpenClaw、Hermes 这些自部署方案技术上非常出色（当然 LobeHub 也支持），但它们有一个根本瓶颈：每个用户每天的 Agent 执行可能只有几条到几十条，由于本地部署，应用开发方无法得到这些错误信号。这种密度下，反馈信号太稀疏，且无法获得原始执行数据——你可能几天才遇到一个新错误，一两周才能验证一个 pattern 是否真的修复了。稀疏信号无法支撑高效的自我迭代，进化天花板一眼望得到头。
而 Consumer-Aimed Product 天然拥有信号密度优势。以 LobeHub 为例，每天有上万次 Agent 执行，这意味着 Error 样本是按分钟级积累的，而不是按天。一个 Harness bug 上午触发、中午被巡检发现、下午就能修复上线——反馈闭环的速度，直接决定了 Self-Evolving 能进化到什么程度。
The Bitter Lesson Revisited
Rich Sutton 在 2019 年写下了著名的《The Bitter Lesson》：通用方法 + 算力，最终会战胜手工编码的领域知识。
在 Agent 时代，这条定律有了新的含义。
LangChain 在回顾他们的 Open Deep Research Agent 时说过：他们在一年内重构了三次架构——不是因为最初的设计不好，而是因为模型进步太快，昨天的”最佳实践”今天就成了负担。Manus 的 Harness 在六个月内重构了五次。Anthropic 也在不断从 Claude Code 的 Harness 中剥离过时的逻辑。
模型在快速迭代，你手工编写的 Harness 逻辑随时可能过时。
唯一的解法是什么？让 Harness 自己能进化，而不是等人来重构。
这就是 Self-Evolving Harness 的终极意义：它不是一个更聪明的静态系统，而是一个能够随环境变化而自动适应的生命体。
我们正在构建的未来
Error Pattern 巡检只是第一步。它证明了 trace 可以驱动 Harness 改进，也证明了 Agent 可以承担一部分原本靠人工维护的运行时工作。
接下来，我们会把同样的机制扩展到更多层面。
- Agent Level 的自动进化：每个 Agent 在夜间自动回放当天所有 Operation Tracing，分析执行轨迹中的失败模式和优化机会，自我调整 Prompt 和执行策略。优化结果以 Brief 的形式推送给用户——第二天醒来，用户看到的是「你的 Agent 已经变得更聪明了」。
- 用户 Level 的自动进化：每天晚上自动识别用户今日的生成使用与交互反馈，分析可行的优化迭代方向，自动更新生成提示词与 Persona 记忆。随着不断使用，产品体验在润物细无声中持续变好。
- 全局自动化的 Eval Harness：每个 Failed Task 自动进入评估 → 归因 → 修复闭环——不等人来调试，不让同一个坑踩两次。Agent 自己在失败中学习，自己证明自己确实变好了。
当然，这些能力都需要边界。生产系统不能因为”自进化”就绕开权限、审查和回滚。更合理的方向是让 Agent 做高频、可验证、低风险的工作，让人保留目标设定、风险判断和最终决策。
Build a Harness That Builds Itself
回到开头的问题：为什么模型越来越强，产品体验却未必同步提升？
因为大多数产品仍然把 Harness 当作一个静态的执行环境——它不会学习，不会进化，不会自己变好。
而我们认为，新一代 Consumer Product 的本质，是一个活的、会自我进化的运行时。
它观察每一次交互。它从错误中学习。它自动修复自己。它在用户不知不觉中变得更好。
这就是 Self-Evolving Harness，正在 LobeHub 中发生的工程实践。这是我们在构建的未来。
相关链接: