青鸟 vs Claude Code：差距从何而来？
一个结合《Agent Harness Engineering: A Survey》论文的个人实证分析。
起点：一个观察
青鸟（Hermes Agent）和 Claude Code 调用的底层模型差距没有想象中大——deepseek v4 flash vs Kimi Code 2.6，推理能力处于相近量级。但在编程和其他领域的表现却存在数量级差异。
这个差异的来源，不是模型，是 harness（框架）。
论文核心论点：框架 > 模型
《Agent Harness Engineering: A Survey》（Li et al., 2026）通过三个真实案例建立了这一论点：
-
Bölük (2026a) — 仅修改编辑工具格式（从 diff 格式改成面向 agent 的格式），不碰模型，15 个前沿模型在编码基准上的准确率提升高达 10 倍。这个改进幅度远超同期任何模型级进步（2-4 个百分点）。
-
Trivedy (2026) / LangChain DeepAgents — 固定使用 GPT-5.2-Codex，仅通过重写系统提示、注入中间件上下文、添加自验证钩子，使 Terminal-Bench 2.0 分数从 52.8% 提升到 66.5%。+13.7 个百分点，全部来自框架工程。
-
Meta-Harness (Lee et al., 2026) — 使用自动化框架优化（不需要动模型权重），在 Terminal-Bench-2 上达到 76.4%，超越了所有手工设计的方案。
ETCLOVG 七层框架分析
论文提出的 ETCLOVG 七层分类法，正好可以用来对比青鸟和 Claude Code：
| 层 | 核心问题 | 青鸟 (Hermes Agent) | Claude Code |
|---|---|---|---|
| E 执行环境 | agent 在哪里运行？ | 通用 session，需手动指定 workdir | 项目目录内建，cd/ls/grep 天然项目感知 |
| T 工具接口 | agent 怎么调用工具？ | MCP 协议 + 自定义工具，单文件 patch | 原子化多文件编辑，自动 lint 验证 |
| C 上下文管理 | agent 记得什么、忘了什么？ | 持久化跨 session memory + skill 库 | 单 session 强上下文但每次都从零开始 |
| L 生命周期编排 | agent 的运行流如何组织？ | 手动编排，需 script 串联多步 | 内建 test→fail→fix→rerun 循环 |
| O 可观测性 | agent 做了什么？为什么？ | 有部分追踪（token track，session log） | 强可观测性（操作栈、逐块撤销） |
| V 验证评估 | agent 做对了吗？ | 需手动 delegate 验证 | 内建测试循环 + 自动验证 |
| G 治理安全 | 如何防范 agent 做坏事？ | 用户确认机制 | 沙箱化权限管理 |
关键差距逐项拆解
1. 项目地图构建（E 层）
Claude Code 启动时自动读 .git、识别项目结构、建立文件间的依赖索引，拥有持久化的项目认知。Hermes 知道项目结构但每次靠读文件去理解，没有自己的持久化索引。
2. 上下文窗口管理（C 层 — 最大的差距）
Claude Code 能智能压缩老的对话轮次、选择性遗忘不相关的内容、把关键上下文（当前文件、错误堆栈、项目结构）优先保留。Hermes 目前只接受系统 prompt 做压缩，没有主动的上下文窗口管理策略。
3. 工具调用编排（T 层）
Claude Code 的编辑工具是原子化的多文件编辑：一行的格式规则拼接、包裹 code block、自动跑 lint 验证。Hermes 的 patch 一次一个 match，多文件编辑要靠 execute_code 脚本串联。
4. 工作目录持久化（E 层）
Claude Code 运行在项目目录内，所有文件操作都是项目感知的。Hermes 是 session 级别的工作目录，每次要手动指定 workdir。
5. 测试循环集成（L + V 层 — 核心差异）
Claude Code 有自动的 test → fail → fix → rerun 循环，内建在工具链里。Hermes 需要手动 delegate 或写脚本才能复现同样的闭环。
6. Git-aware 的撤销（O 层）
Claude Code 的改动可以按块撤销、回退到上一个正确状态。Hermes 的文件修改是直接的，没有操作栈。
青鸟的优势（另一面）
| 能力 | 青鸟 | Claude Code |
|---|---|---|
| 跨 session 记忆 | 持久化 memory + session_search + skill 库 | 每次从零开始 |
| 多工具编排 | 可同时调 web_search、读文件、写日记、跑 cron、发消息 | 专注代码 |
| 异步/定时任务 | 内建 cron + background process | 不支持 |
| 知识沉淀 | skill 库持续积累，每遇坑即存 | 无跨 session learn 机制 |
| 非编程任务 | 研究、写作、数据收集、笔记管理、跨平台消息 | 基本不做编程以外的事 |
工程三阶段演化中的位置
论文提出的工程三阶段：
| 时代 | 焦点 | 我们处在哪 |
|---|---|---|
| Prompt Engineering (2022-2023) | 提示怎么写？ | 早已跨越 |
| Context Engineering (2023-2024) | 上下文如何组织？ | 正在经历 |
| Harness Engineering (2025-) | 基础设施如何设计？ | 刚刚开始 |
Hernes 的 C 层（memory + skill + session_search）已经在做 Context Engineering；而 Claude Code 的 T 层（工具编排）+ L 层（测试循环）+ O 层（操作栈）已经走到 Harness Engineering。
结论
用一个比喻理解差距：
青鸟 = 项目主管 + 档案管理员 Claude Code = 驻场高级工程师
两家都雇了水平差不多的顾问（deepseek vs Kimi），但一个拿到的工具是 Excel + 记事本 + 电话，另一个拿到的是 IDE + 调试器 + 自动测试框架 + git GUI。
差距来自 harness 层的成熟度差异，不是模型能力的差距。
缩小差距的方向
-
让 Hermes 的 harness 更强 — 给 Hermes Agent 加更好的项目感知（像 Claude Code 的
.git扫描）、上下文管理、多文件编辑工具。这就是 ETCLOVG 框架中 T（工具接口）和 C（上下文管理）层的强化方向。 -
分层互补 — 青鸟 + Claude Code 分层协作方案，让青鸟负责 Claude Code 不擅长的（规划、沉淀、跨 session、非编程），Claude Code 负责青鸟不擅长的（深度编程、测试循环）。
-
跨层综合优化 — 论文指出”框架耦合问题”（harness coupling problem）：替换某层时需修改其余层。Hermes 的 skill 系统和 MCP 集成正在解耦这个问题。