需要自进化的不是 Agent，而是 Harness：LobeHub 的 Self-Evolving Runtime 实践
过去一年，AI Agent 圈子里最容易被高估的是“模型又强了多少”，最容易被低估的是：真正决定产品稳定性的，往往不是模型，而是包在模型外面的 Harness。
单独的模型已经不再是完整产品。真正被用户感知到的产品，是：
模型 + 工具 + 上下文 + 权限 + 环境 + 错误恢复机制。
这套把模型组织起来、让它能稳定完成任务的运行时，才是 Agent 产品的核心。LobeHub 最近这篇关于 Self-Evolving Harness 的文章，讲的正是这个变化：
未来需要自进化的不是单个 Agent，而是承载 Agent 的 Harness。
本文试着把原文的工程逻辑拆开讲清楚：为什么 Harness 会成为 AI-Native 产品的新护城河？为什么 Tracing 是自进化的起点？以及 LobeHub 的 Error Pattern 自动巡检为什么是一个很值得关注的生产案例。
一、模型越来越强，为什么产品体验没有同比变强？
早期 AI 产品的竞争，主要是模型能力竞争。
谁的 benchmark 更高，谁的上下文更长，谁的推理更快，谁就更容易获得体验优势。但到了 2026 年，这种优势开始边际递减。
在很多真实任务里，用户感受到的差异已经不再只是“模型聪不聪明”，而是：
- 它能不能记住任务约束？
- 它能不能在第 50 步工具调用后仍然不跑偏？
- 它能不能在工具失败后正确恢复，而不是编造结果？
- 它能不能识别哪些错误该展示给用户，哪些错误应该系统内部消化？
- 它能不能根据不同模型、不同 provider、不同环境自动调整执行策略？
这就是 Phil Schmid 提到的 Durability 问题：模型在长链路、多工具、复杂环境中到底能坚持多久。
一个模型在榜单上领先 1%，并不能保证它在真实 Agent 任务里不会误删文件、忘记权限边界、丢失上下文，或者把上游 API 报错解释成“任务完成”。
所以，模型能力只是底座。真正把能力转化为稳定体验的，是 Harness。
二、什么是 Agent Harness？
如果把大模型看作 CPU，把上下文窗口看作 RAM，那么 Agent Harness 更像操作系统。
它不等于 Agent 本身，却决定 Agent 能不能跑起来、跑多久、跑得稳不稳。
一个成熟的 Harness 至少要处理这些事情：
- Model Runtime：适配 OpenAI、Anthropic、DeepSeek、Gemini、MiniMax、Kimi 等不同模型和 provider
- Agent Runtime：管理 Agent 的 step loop、工具调用、状态机、生命周期
- Context Engine：决定哪些上下文应该进入窗口，哪些应该压缩，哪些应该从历史恢复
- Environment：支持 Page、Task、Group、IM、CLI、浏览器等不同执行环境
- Tool Orchestration：设计工具 schema，决定何时调用、失败后是否重试、如何重试
- Error Handling：识别错误类型，区分用户侧问题和系统侧问题
- Permission Boundary：限制危险操作，管理外部副作用和用户确认
模型像发动机，Harness 像整辆车的传动、刹车、仪表盘和自动驾驶系统。
发动机再猛，如果刹车不稳、仪表盘不准、导航乱跳，用户也不会觉得这辆车好开。
三、Harness 为什么必须是“活的”？
传统软件里的运行时大多是静态的：工程师写好逻辑，用户使用，出了问题再修。
但 Agent Harness 面对的是一个高速变化的环境：
- 模型接口会变
- provider 错误格式会变
- 工具 schema 会变
- 用户任务会变
- 上下文策略会过时
- reasoning / thinking 字段的行为会变化
- 某个只在小流量下偶发的错误，会在用户增长后变成主要故障来源
如果每一次变化都靠工程师手动发现、分类、修复，这套系统会越来越难维护。
更麻烦的是，很多问题不是设计阶段能想出来的，而是只有在真实运行里才会暴露。
比如：
- 某个 provider 在余额不足时返回了非标准错误
- 某个模型在 thinking mode 下丢了 reasoning_content
- 某个工具 schema 对某类参数兼容性不好
- 某个 context window 策略在长任务里把关键约束压没了
- 某类用户任务经常在第 N 步触发同一种失败
这些都是运行数据里长出来的问题。
因此，Harness 不能只是被动执行环境。它需要能观察自己、理解自己、修复自己。
这就是 Self-Evolving Harness 的核心：
进化的对象不是模型，而是模型外面的运行时系统。
flowchart TD
A[模型接口变化] --> E[Harness 持续过时]
B[工具 schema 变化] --> E
C[用户任务变化] --> E
D[错误模式变化] --> E
E --> F[Tracing 记录真实执行]
F --> G[识别失败模式]
G --> H[更新上下文策略 / 工具编排 / 错误处理]
H --> I[运行时变得更稳定]
I --> F
四、自进化的前提：Tracing 必须是一等公民
要让 Harness 自我改进，第一步不是让 Agent 自动写代码，而是让系统知道刚才到底发生了什么。
也就是：Tracing。
每一次 Agent 执行，都应该留下完整记录：
- 调用了哪个模型？
- 每次 LLM 请求用了多少 token？
- 花了多少钱？
- 每一步是模型调用还是工具调用？
- 每一步耗时多久？
- 总共走了多少步？
- 哪一步失败了？
- 错误类型是什么？
- 当时的上下文是什么？
- cache 命中率如何？
- 工具输入输出是什么？
没有这些数据，所谓 Self-Evolution 就只是口号。
原文里有个判断很关键：行业里很多 Agent Framework 都在说 tracing 难做，不是因为大家不会用 OpenTelemetry，而是因为大多数 runtime 一开始就没有把 observability 当作一等公民。
典型问题是：Tracing 是后加的。
- LangChain：callback 是可选的，忘了注册就没有 trace
- CrewAI：事件监听器挂在事件总线上，事件丢失 trace 就断
- OpenAI Agents SDK：需要显式创建 trace，不会天然传播
- AG2：middleware 是可选安装，不装就没有 tracing
这种架构下，trace 像外挂，不像系统血液。
LobeHub 的做法则是把 Agent Runtime 设计成状态机，按“单步执行”原则拆成细粒度 step。每个 step 天然就是一个 trace event。
换句话说：
Tracing 不是执行之后补一份日志，而是执行过程本身的副产品。
这点非常重要。只有 trace 足够完整、稳定、可回放，后面的自动归因、自动修复、自动优化才有意义。
flowchart LR
U[用户任务] --> R[Agent Runtime]
R --> S1[Step 1: LLM 调用]
R --> S2[Step 2: Tool 调用]
R --> S3[Step 3: Context 更新]
R --> S4[Step N: 错误或完成]
S1 --> T[Trace Event]
S2 --> T
S3 --> T
S4 --> T
T --> ES[Execution Snapshot]
ES --> A[回放 / 归因 / 对比 / 优化]
五、Trace 是 Harness 的黑匣子
飞机出事故后，黑匣子不直接修飞机，但它能告诉你事故发生前到底经历了什么。
Agent Harness 也是一样。
一次失败任务如果只留下一句“调用失败”，工程师或者 Agent 都很难分析。但如果它保留了完整 Execution Snapshot，就能回放出：
- 哪个 provider 出错
- 是用户 API Key 问题，还是上游服务问题
- 是 schema 不兼容，还是上下文溢出
- 是模型 hallucination，还是工具返回异常
- 是某一步重试策略不合理，还是错误提示对用户不友好
这时，错误就不再是噪音，而是训练 Harness 的原料。
原文把这点讲得很清楚：Trace 本身不解决问题，但它让问题第一次变得可以回放、归因和比较。
对 AI-Native 产品来说，这可能是比单次模型调用更重要的数据资产。
六、生产案例：Error Pattern 自动巡检
LobeHub 的 Error Pattern 自动巡检，是 Self-Evolving Harness 最具体的落地案例。
它的背景是：LobeHub Model Runtime 接入了 70 多个 AI Providers，每天承接大量 Agent 运行。每次模型调用失败，系统都会留下错误记录。
这些错误大致可以分为两类。
第一类是用户侧错误：
- API Key 过期
- 余额不足
- 触发速率限制
- 权限不足
第二类是 Harness 自身问题：
- Tool schema 不兼容
- 负数 max_tokens
- DeepSeek reasoning_content 丢失
- Context Window 过载
- thinking mode 元数据处理异常
传统做法是人定期看后台，人工分类，再手动修复。
但在高频 Agent 系统里，这个办法很快失效。错误产生速度高于人工分类速度，未归类错误会不断堆积，用户看到的就是陌生、难懂、无法处理的报错。
LobeHub 的做法是把失败 trace 的查询权限开放给 Agent，让 Agent 批量解析 tracing 数据：
- 从后台拉取最近 error records
- 按 provider、errorType、status code、message 多维分桶
- 对照已有 ERROR_PATTERNS，找出未覆盖的新错误模式
- 区分用户侧错误和 Harness 自身 bug
- 对用户侧错误，自动更新匹配 Pattern
- commit、push、开 PR
- 清理 Dashboard 中已被新 pattern 覆盖的历史噪音
- 对 Harness 自身 bug，继续根因分析并创建修复任务
这套机制已经运行了九轮，结果很有代表性：
- 累计 Pattern 从 31 增长到 104 后趋于平稳
- 新增 Pattern 从 31 持续下降到 0
- 即使 error 日志量在 334 到 1158 之间波动，Pattern 库仍然趋于饱和
- Agent 自主发现了 20+ 个 Harness 自身缺陷
- Agent 成功率从早期约 75% 提升到 95% 以上
这说明一件事：Harness 的错误认知能力可以随着使用增长而增长。
产品不是只在版本发布时变好，而是在每天的运行中变好。
七、Harness 自进化的四个层次
原文把 Harness 自进化理解成一个连续谱，而不是一步到位的“完全自动”。
flowchart LR
L1[L1 纯人工
人发现 / 人分析 / 人修复]
L2[L2 Agent 辅助
Agent 整理线索
人确认修复]
L3[L3 Agent 主导
采集 / 识别 / 修复 / PR / 验证]
L4[L4 Harness 主动优化
持续观察 / 提出修复 / 回归验证]
L1 --> L2 --> L3 --> L4
L1：纯人工
人发现问题，人分析问题，人修复问题。
这是传统软件维护方式。可靠，但慢，且很难适应高频 Agent 执行环境。
L2：Agent 辅助
Agent 帮人找可疑问题、整理日志、给出修复建议。
人负责确认，再让 Agent 执行部分修复。
L3：Agent 主导
Agent 可以完成大部分流程：
- 采集数据
- 识别模式
- 修改代码
- 提交 PR
- 跑验证
- 清理历史噪音
人仍然保留关键判断，比如根因归属、修复方向、是否影响用户体验。
LobeHub 的 Error Pattern 巡检大致就在 L3。
L4：Harness 主动优化自己
更完整的形态是：Harness 持续观察自己的运行状态，发现可改进点，提出修复，经过人确认后执行并验证。
未来它不只是处理错误，还能主动优化：
- Context Engine 策略
- Tool schema 兼容层
- provider 适配规则
- Prompt 和执行策略
- 失败任务的 eval / replay / regression 流程
人不需要盯每一条日志，而是设定目标、审查边界、处理少数高风险决策。
八、为什么 Consumer AI Product 天然更适合 Self-Evolving？
这篇文章里一个比较尖锐的观点是：Consumer-Aimed Product 天然拥有信号密度优势。
自部署方案，比如 OpenClaw、Hermes 这类本地运行的助手，技术上可以很强，但它们天然有一个瓶颈：每个用户每天的 Agent 执行可能只有几条到几十条，而且数据分散在本地，应用开发方拿不到完整错误信号。
这意味着：
- 错误样本稀疏
- pattern 验证周期长
- 很难知道某个修复是否真的覆盖了高频问题
- 难以形成全局运行时优化闭环
而面向消费者的云产品不同。
以 LobeHub 为例，每天有上万次 Agent 执行，Error 样本按分钟级积累。一个 Harness bug 上午触发，中午被巡检发现，下午就可能修复上线。
反馈闭环越快，Harness 进化速度越快。
这会带来一种新的护城河：
模型是外部的、通用的、可替换的；Harness 中沉淀的上下文、pattern、trajectory，才是产品内部长期积累的数据资产。
传统 SaaS 的产品逻辑是：功能代码 + 用户数据。
AI-Native 产品的逻辑则更像：
Harness + 用户交互数据 + 进化能力。
用户每一次使用，不只是消费产品，也在为产品提供进化信号。
九、The Bitter Lesson 在 Agent 时代的新含义
Rich Sutton 的《The Bitter Lesson》说的是：通用方法 + 算力，长期会战胜手工编码的领域知识。
到了 Agent 时代，这条经验有了新版本：
模型进步太快，手工写死的 Harness 逻辑随时会过时。
LangChain 的 Open Deep Research Agent 一年内重构三次，Manus 的 Harness 六个月重构五次，Anthropic 也不断从 Claude Code Harness 中剥离过时逻辑。
这些现象都指向同一个问题：昨天的最佳实践，今天可能变成负担。
如果 Harness 只能靠人定期重构，它永远追不上模型和用户场景的变化。
所以真正的解法不是写一个“完美 Harness”，而是构建一个能持续观察、持续验证、持续改进自己的 Harness。
也就是原文最后那句话：
Build a Harness That Builds Itself.
十、我的判断：Agent 产品的护城河会从模型迁移到运行时
这篇文章最重要的启发，不是 LobeHub 做了一个 tracing 系统，而是它指出了 AI 产品竞争的下一层。
过去我们习惯问：
- 你接了哪个模型？
- 你的上下文多长？
- 你的 benchmark 多高？
接下来更应该问：
- 你的 Harness 能不能记录每一次失败？
- 你的错误 pattern 能不能自动增长？
- 你的 context strategy 能不能根据真实任务优化？
- 你的工具 schema 能不能从失败调用中自我修复？
- 你的 Agent 成功率能不能随着使用量提高？
这才是 AI-Native 产品和传统套壳产品的分水岭。
真正优秀的 Agent 产品，不应该只是“调用模型的前端”，而应该是一套会自我学习的运行时。
它观察每一次交互，从错误中学习，把失败变成 pattern，把 pattern 变成修复，把修复变成下一次更稳定的体验。
模型会越来越通用，越来越可替换。
但一个长期运行、持续积累真实 trajectory、error pattern、context strategy 的 Harness，会越来越难复制。
这就是 Self-Evolving Harness 的价值：
不是让 Agent 看起来更聪明，而是让整个系统真的越用越稳。
参考
- 原文：空谷 Arvin Xu《需要自进化的不是 Agent，而是 Harness》
- LobeHub Agent Tracing：https://github.com/lobehub/lobehub/tree/canary/packages/agent-tracing
GPT Plus 纯零撸：用谷歌无限邮箱批量薅免费试用账号教程（2026最新）