C CONVEE 搜索

Agent 架构文档 · Markdown

AI 评估体系深度对比：10 家 Agent 框架的 Benchmark / Observability / Eval 闭环

把 10 家 agent 框架在「评估」这件事上的能力差异说透。覆盖：公开 benchmark 成绩、 trace / observability 系统、在线 code review 闭环、训练反哺、HITL 评审、运行时 cost 监控、A/B 路由作为评估手段。 配套阅读 ： agents/docs/ 目录下 11 份原生架构文档（ agent arch

来源文件：evaluation-comparison.md · 阅读时间 20 分钟

把 10 家 agent 框架在「评估」这件事上的能力差异说透。覆盖：公开 benchmark 成绩、 trace / observability 系统、在线 code review 闭环、训练反哺、HITL 评审、运行时 cost 监控、A/B 路由作为评估手段。

配套阅读：agents/docs/ 目录下 11 份原生架构文档（*-agent-architecture.md + agent-architectures-comparison.md）。 数据日期：截至 2026-04-25。所有 benchmark 数字都附了来源链接，不允许编造； 排行榜实时变动，正式引用前请回访来源页。

#目录

#零、为什么"评估"对 Agent 来说尤其困难

"对话式 LLM 的评测是『对答案打分』，agent 的评测是『对一条多步轨迹打分』， 这两件事的复杂度差一个量级。"

LLM 阶段你有 MMLU / HumanEval，模型吐 token，对就是对、错就是错。Agent 进化到多步执行 之后，三件事同时把评估难度抬上去：

  1. 非确定性：同一 prompt + 同一模型，多次跑结果可能不同（temperature、tool 顺序、 外部环境）。一次运行算成功 ≠ 这个 agent 真的能干。
  2. 多步轨迹：失败发生在第 7 步，但 root cause 可能在第 3 步上下文里。只看终态判分会 错杀好 agent、放过运气好的烂 agent。
  3. 环境耦合：SWE-bench 跑得高，不代表你那个有 200 个内部 MCP 工具的真实仓库也跑得高。 benchmark 是部分答案。

这三条造成的工程后果是：

LLM 时代评估栈              Agent 时代评估栈

  prompt → answer            prompt → step1 → step2 → ... → terminal
     ↓                          ↓       ↓       ↓             ↓
  打分（自动 / 人工）        每一步 emit event；
                            事后可 replay；
                            replay 可改 state 重跑（time-travel）；
                            cost / token 实时累积；
                            异常路径触发 review agent。

10 家在这套栈上的覆盖度差异极大——从 OpenHands「event-sourced + deterministic replay」 到 OpenClaw「print + logger」，跨越 5 个代际。

#一、10 家速览大表：公开成绩 + 观测能力

表里的 benchmark 成绩*全部带来源，没找到数字的诚实写「未公开 / 不适用」。*

项目 主推 benchmark 公开成绩（截至 2026-04） Observability 抓手 Replay 能力 训练反哺
OpenClaw 无（个人 IM 助手） 无 print + logger（Gateway hook 链 / /trace on slash 命令） session lane 锁可重放对话流 无
Hermes（Nous） MATH-500 / AIME / GPQA / HLE Hermes 4 405B：MATH-500 96.3% / AIME'24 81.9%（发布日 2025-08-26） runtime trace（SQLite + FTS5）；hermes-agent batch trajectory trajectory 持久化、可回放 Atropos RL + DataForge + DisTrO（独有闭环）
Claude Code SWE-bench Verified 由模型决定（Opus 4.5 ≈ 80.9%、Opus 4.6 ≈ 80.8%、Opus 4.7 ≈ 87.6%） thinking blocks / --debug-to-stderr / transcript / session JSONL session resume；checkpoints（每次 file edit 自动快照、ESC ESC 回滚） 否（但有 user/feedback memory）
Codex（OpenAI） SWE-bench Verified（GPT-5.3-Codex / GPT-5.4） GPT-5.3-Codex ≈ 85.0%（待核实，未在 llm-stats 排行榜首屏列出）；GPT-5.5 在 SWE-bench Pro ≈ 58.6%（待核实） session SQLite（resume / fork）+ /status token 用量 codex resume / codex fork + AGENTS.md（git review） 否（但 ChatGPT 端可能闭环）
Cursor 自家不公开排行榜数字 用户实测 Composer / Auto 路由的命中率（forum 推断） cursor.com/dashboard Usage / cursor.com/agents 团队级面板 / Bugbot 学习规则 git worktree 物理隔离；race pattern 多模型并发 内部模型（Tab/Apply/Composer）的 RL pipeline，不公开
Cline 不公开 不公开（社区测算 task 成本 $0.5–2 / 实现） UI 内 cost tracking（input/output tokens + USD）+ 影子 git checkpoint per-step checkpoint restore（影子 git，三粒度） 否
OpenHands SWE-bench Verified（自家 harness） OpenHands 全集成绩长期 50%–60% 区间（多版本提交，以 swebench.com 实时排行榜为准）；论文 CodeAct Python 子集 ≈ 79.3%（ICLR 2025）；社区基于 Opus 4.6 base 的 v3 复现 ≈ 68.4%（待核实，OpenHands 仓库未给出官方数字） EventStream（typed event 持久化）+ controller/replay.py + Prometheus 接出 deterministic replay（v1 SDK first-class） 否（但社区 swe-rex 等用 OpenHands 收数据）
AutoGen 内置 agbench/ benchmarking 包 未公开汇总分数（包是给用户跑自己 benchmark 的 harness） OpenTelemetry 内置；AutoGen Studio no-code UI；Console 彩色事件流 save_state / load_state；ComponentBase 序列化 否
LangGraph 不做 benchmark 不公开（不同用户自跑） LangSmith（节点级 timeline / time travel / replay / fork）+ LangGraph Studio time-travel（任意 checkpoint replay 或 fork） 否

⚠️ 数据归属：

  • 模型层成绩（Hermes 4 / Claude Opus 4.7 / GPT-5.3-Codex）不归 agent 框架所有，是 "这家框架对应的代际能力坐标"。
  • 框架层成绩（OpenHands + CodeAct、Cursor Bugbot 解决率）才是 harness 自身贡献。
  • 所有可信成绩都标了发布日期 + 来源段（见文末来源列表）。

#二、SWE-bench Verified / LiveCodeBench / Terminal-Bench 公开成绩

"基础模型给地板，harness 把地板抬到天花板——OpenHands 与 Claude Code 在 同一基模上分别加 11pp、12pp，这就是 harness 的价值。"

#2.1 SWE-bench Verified 阶梯（截至 2026-04-25）

SWE-bench Verified（500 题，open-resolve 模式；数据来源：llm-stats.com 排行榜首屏）

100% ┤
 90% ┤  ★ Claude Mythos Preview     93.9%   (Anthropic 内部预览，未 GA)
     │  ★ Claude Opus 4.7           87.6%   (Anthropic 2026-04-16 GA)
 80% ┤  ◆ Claude Opus 4.5           80.9%
     │  ◆ Claude Opus 4.6           80.8%
     │  ◆ DeepSeek-V4-Pro-Max       80.6%
     │  ◆ Gemini 3.1 Pro            80.6%
     │  ◆ GPT-5.2                   80.0%
     │  ◆ Claude Sonnet 4.6         79.6%   (5× cheaper than Opus 4.6)
 70% ┤  ▲ OpenHands + CodeAct v3   ~68.4%  (社区复现 + Opus 4.6 base，待核实)
     │  ▲ OpenHands 论文 CodeAct    ~79.3%  (Python 子集，ICLR 2025)
 60% ┤
 50% ┤  ▲ OpenHands 全集长期        50%–60% (swebench.com 历史多版本)

注：GPT-5.3-Codex / GPT-5.5 / GPT-5.4 在 llm-stats 首屏排名中未单独列出（首屏只到 GPT-5.2 = 80.0%），其报道分数（85% 区间）多来自 OpenAI 自家发布会，待核实 swebench.com 上对应提交。

关键观察：

  1. 基础模型 Opus 4.6 / Opus 4.5 已经撞到 ~80.9% 的天花板，Claude Code 这种"宿主 harness" 的边际贡献被压扁——但在跨多文件、长 horizon 任务（如 SWE-bench Multimodal / Rakuten-SWE） 上差距会放大（Anthropic Opus 4.7 公告里强调 "Rakuten 生产任务解决数量 3×"）。
  2. OpenHands + CodeAct v3 ≈ 68.4%（社区基于 Opus 4.6 base 的复现，待核实）vs Opus 4.6 裸模型 80.8% —— 开源 harness 反而比"模型 + 私有 harness"低，差距来自 「私有 harness 内部的 retry / 工具选择 / context 管理」——这就是 Cursor 反复强调的 "the harness is the product"。
  3. OpenAI 自己审计：所有 frontier 模型对 SWE-bench Verified 部分题有 verbatim memorize 嫌疑（Anthropic 2026-04-16 Opus 4.7 公告里也提及"memorization screens"）， 80%+ 分数可能虚高——所以业界已经在转向 SWE-bench Pro / SWE-rebench 等"反污染"变体（GPT-5.5 在 SWE-bench Pro ~58.6%、Opus 4.7 在 SWE-bench Pro ~64.3% 就是更现实的能力坐标，两数字均待核实）。

#2.2 Hermes 4 推理能力坐标

数据集 Hermes 4 405B 成绩 发布日 来源
MATH-500（reasoning mode） 96.3%（hybrid 从 93.1% 提到 96.3%） 2025-08-26 官方技术报告 / arXiv 2508.18255
AIME'24 81.9% 2025-08-26 官方
训练成本 192× B200 GPU、71,616 GPU-hours — 官方

注意 Hermes 4 的 96.3% 是在 reasoning mode 下——这是 Hermes 4 的 hybrid <think> 切换的产物，不开 reasoning 是 93.1%。这个差值（3.2pp）反过来量化了 "thinking 切换"对 推理任务的实际收益。

#2.3 Terminal-Bench / LiveCodeBench

项目 Terminal-Bench 2.0 LiveCodeBench
GPT-5.5 ~82.7%（OpenAI 公布，待核实 tbench.ai 实时榜） 高，非榜首（待核实）
Gemini 3 Pro Preview —（待核实） ~91.7%（榜首，2026-04-23，待核实 livecodebench.github.io 实时榜）
Claude Opus 4.7 Anthropic 公告称"通过此前无法解决的 3 项任务"，未给单一总分 未公开汇总
Claude Opus 4.6 比 GPT-5.3-Codex 低 ~12pp（来源：第三方分析，待核实） —
OpenHands / Cursor / Cline 一般用 base 模型分数代表，不再单独跑 同左

上述 Terminal-Bench / LiveCodeBench 数字均待核实：

  • tbench.ai 排行榜采用 SPA 动态加载，单次 fetch 拿不到表格；建议人工浏览 https://www.tbench.ai/leaderboard/terminal-bench/2.0。
  • livecodebench.github.io 同样需要前端水合，建议直接看 GitHub 仓库 release 表。
  • 部分数字（GPT-5.5 82.7% Terminal-Bench、Gemini 3 Pro 91.7% LiveCodeBench）系 2026-Q1 第三方报道转引，未在 GA 公告原文中复核。

结论：基础模型分数极速翻新（年内 SWE-bench Verified 从 50% 推到 87%），框架层分数 基本被基础模型分数追平甚至盖过。这意味着 agent 框架的差异化越来越不能靠"我跑 benchmark 最高"卖，必须靠 harness 工程（retry / tool 编排 / context 管理 / replay 能力）卖。

#2.4 没找到的成绩 / 不确定项

  • Claude Code / Opus 系列在 swebench.com 排行榜上的具体提交版本归属：Anthropic 公布的 数字（Opus 4.5 ≈ 80.9% / Opus 4.6 ≈ 80.8% / Opus 4.7 ≈ 87.6%）是 blog / llm-stats 转引， 对应 swebench.com 上具体哪一行（agent harness 标签是 Anthropic 私有，还是社区复现版） 未直接验证。 SWE-bench / GAIA 提交记录**：均未公开。OpenClaw / Cline / Cursor / LangGraph 是产品形态
  • OpenHands 当前榜首归属：swebench.com 历史上 Salesforce SAGE（OpenHands 衍生）等 版本持续刷榜，但 leaderboard 实时变动，文档撰写时未抓最新快照——以 swebench.com 实时排行榜为准。
  • GPT-5.3-Codex / GPT-5.5 在 SWE-bench Verified 上的具体提交：OpenAI 公告给出 ~85% 量级数字，但 llm-stats 排行榜首屏未列出对应行；可能榜单已被 Claude Mythos Preview / Opus 4.7 等推到第二屏，亦可能 OpenAI 未提交公开 trace。

#三、Trace / Observability 系统对照

"observability 的最高形态不是『能看』，而是『能改了重跑』。LangGraph 与 OpenHands 是这条路上唯二真正做到 first-class 的。"

#3.1 五个代际

代际 1：print + logger
   OpenClaw  (Gateway hook 链 + /trace on 命令)
   早期 AutoGen v0.2

代际 2：结构化日志 + Grafana 面板
              Loki/Tempo/Prometheus + Grafana 是主战场)

代际 3：内置 OpenTelemetry
   AutoGen v0.4  (autogen-core 自动 emit span，OTLP gRPC 4317 → Jaeger)
   Cursor       (cursor.com/agents 团队级 dashboard，但内部 trace 不公开)

代际 4：节点级 / event 级 typed log + 可视化平台
   LangGraph + LangSmith (节点 timeline / token 流 / state diff / time travel)
   OpenHands EventStream (Action / Observation typed event；replay.py 起点)

代际 5：deterministic replay + state-mutating fork
   LangGraph time-travel (Replay 重跑 / Fork 改 state 走另一路径)
   OpenHands v1 SDK     (event-sourced state with deterministic replay 成 first-class)

四套主流 observability 平台的能力矩阵：

|------|--------------------|-----------------------|---------------|---------------------| | 节点级 timeline | ✓ 每个 superstep | ✓ 每个 Action / Observation | ✓ 每个 agent 调用 / tool span | ✓ trace_id 串起 sandbox 全部组件 | | Token 流 | ✓ messages mode + LangSmith | 不直接（要外部接） | ✓ ModelClientStreamingChunkEvent | ✓ courier 流式聚合 | | State diff | ✓ updates mode 直出 | ✓ event log 任意时刻可重建 | 部分（按 message thread） | ✗ | | Time travel（重跑 + 改 state） | ✓ First-class（Replay + Fork） | ✓ controller/replay.py（event id 起跑） | save_state/load_state（手工） | ✗ | | Cost / token 累计 | ✓ 节点级拆开 | ✓ Metrics 类（state.metrics） | ✓ ChatCompletionClient.total_usage() | ✓ ai-gateway GWUserQuotaConfig | | 团队级 dashboard | ✓（LangSmith Cloud） | OpenHands Cloud / 自部署 Grafana | 自接 Jaeger / Zipkin / Tempo | Grafana 多 tenant |

LangGraph 的 5 种 stream mode（debug 利器）：

async for chunk in app.astream(input, config, stream_mode="updates"):
    # values  : 当前完整 state（小图调试）
    # updates : {node_name: 该 node 这次返回的差量}（看『现在哪个 node 在写啥』）
    # messages: (chunk, metadata)（前端 token 流）
    # debug   : task / step / state 诊断包（trace UI / Studio 用）
    # custom  : get_stream_writer().write(...) 推任意业务事件

5 种模式同时开 stream_mode=["updates", "messages"]，UI 拿 token 流 + 节点状态。这是 LangGraph 在「调试体验」上的天花板。

OpenHands 的 deterministic replay（v1 SDK first-class）：

EventStream 持久化（文件 or DB）：
  evt_001  CmdRunAction(command="ls")
  evt_002  CmdOutputObservation(content="...", exit_code=0)
  evt_003  IPythonRunCellAction(code="import json; json.loads(open(...).read())")
  evt_004  IPythonRunCellObservation(content="...")
  ...

controller/replay.py：
  从任意 evt_id 重跑 → state 完全可重建 → bug 复现 / 合规审计 / A/B 切代码

副作用：所有副作用必须 emit 成 event 才"算数"。这对工程纪律要求极高（agent 不能在 step 内偷偷改外部状态而不留 event），回报是 debug / 合规 / 灰度 / 训练数据采集 全免费。

AutoGen 的 OTEL 接入（全自动）：autogen-core runtime 内置 instrumentation，配上 OTLPSpanExporter(endpoint="http://localhost:4317") + TracerProvider，每个 agent / tool / LLM 调用都自动产 span 到 Jaeger，零代码改造。这是 v0.4 相对 v0.2 的关键 产品升级（v0.2: print + logger → v0.4: OTEL + 流式事件）。

各服务有 OTEL hooks（如 goalfy-core /goalfy_core/otel/_otel.py），OTLP → OTEL Collector → Tempo/Loki/Prometheus → Grafana；sandbox-agent 还把 (sandbox_id, action, trace_id, duration_ms, success, error) 落表。注意：跨 baseline / eval / ai-gateway 的端到端 "改 state 重跑"——它的 trace 主要服务生产排障（哪个 agent 卡了？哪个 tool 慢了？ 哪个用户的 quota 爆了？），不是 agent 行为评估。这是企业 SaaS 与开源框架在 observability 上的本质分野。

#3.3 没有真正 trace 系统的几家

  • OpenClaw：Gateway hook 链 + /trace on slash 命令开关日志，没有外部 backend。 适合个人 IM 助手场景，企业用会撞墙。
  • Cline：UI 内 token / cost 实时显示 + 影子 git checkpoint 是 trace 的"轻量替代"， 没有跨 task 的 telemetry backend（厂家 cline.bot 不收用户 trace）。
  • Cursor：cursor.com/dashboard Usage 是计费视角，内部 harness 的真正 trace 不对 外开放。Cloud Agents 给团队管理员看每个 agent 状态 (Planning / Executing / Reviewing / Done)，但 LLM 调用细节看不到。
  • Codex：本地 SQLite session 库（~/.codex/sessions/）是事后审计的最大底，但 没有类 LangSmith 的可视化平台。/status 看 token 用量是 CLI 内能力。
  • Claude Code：transcript / session JSONL（~/.claude/projects/）+ thinking blocks
    • --debug-to-stderr，没有云端 trace 后端（Anthropic 不收 transcript）。

结论：只有 LangGraph + OpenHands 把 trace 做成了 first-class，其它要么是企业内部

#四、在线评估 / agent review agent 模式

"让一个 agent 评审另一个 agent 的输出——这是 2025-2026 把 agent 推向生产的核心模式。"

#4.1 八种 review 模式对照

项目 review 形态 触发方式 评估对象 是否落 PR
Cursor Bugbot 自动 PR review + Autofix GitHub PR 打开 代码 diff 落 fix commit（Autofix）
Claude Code code-reviewer subagent 用户自定义 subagent 用户提示触发 / proactively after code change 当前 session 代码改动 不（本地反馈）
Codex GitHub Action openai/codex-action@v1 CI workflow 触发 PR 全部内容 可（codex apply 回流 + 评论）
OpenHands GitHub Resolver issue / PR 自动 fix issue 加 fix-me label issue / PR 内容 ✓ 直接开 PR
AutoGen RoundRobinGroupChat write → review → revise 模式 用户起任务 上一个 agent 的输出 不直接
Hermes batch trajectory rejection sampling RL 训练时 模型 trajectory 不（训练用）
LangGraph supervisor pattern supervisor agent 监督 worker Graph 编排 worker agent 输出 不直接

几种"review 模式"快速解释（避免只点名）：

  • AutoGen RoundRobinGroupChat：内置 group chat 编排器，把 writer / reviewer / reviser 等多个 agent 串成轮询；reviewer 直接读上一个 agent 的 message，给修改建议。属于 "在 agent 内部嵌入 review 循环"，不落 PR、不 gating。
  • Hermes batch trajectory + rejection sampling：训练侧 Atropos verifier 对每条 trajectory 打分，只有通过 verifier 的样本进训练集——这是 review 的"训练数据筛选" 形态，不在产品形态出现。
  • LangGraph supervisor pattern：典型多 agent 拓扑——一个 supervisor 节点根据 worker 返回的中间结果决定下一步交给谁、是否打回重做。review 是图编排的副产物，所有判分 都走 supervisor 的 prompt 逻辑。

#4.2 Cursor Bugbot：最完整的"agent 评审 agent"产品

数据点（截至 2026-04，来源：cursor.com/bugbot 主页 + cursor.com/blog/bugbot-autofix）：

  • Bugbot Autofix 已 GA（2026 起 out of beta）
  • 解决率从 52% 提到 76%（Autofix 公告原文）
  • 35%+ 的 Autofix 改动被合进 base PR（公告原文）
  • 70%+ 的 flag 在 merge 前被解决（主页原文）
  • "超过一半被识别出来的 bug 最终被工程师修复"（主页原文）
  • 每月推出"Fix All"批处理 / MCP 支持 / 反馈闭环
  • "110,000+ 仓库启用 learned rules / 44,000+ 学习规则" 系第三方分析/早期推文转引，待核实 官方原文

架构：Bugbot 背后是 Cloud Agent（独立 VM），每个 PR 起一个 agent 跑 review， 失败/通过都写到 PR comment。Autofix 单独再起一个 agent 跑修复，提交 commit 到 PR 分支。

与 OpenHands GitHub Resolver 的对比：

维度 Cursor Bugbot OpenHands Resolver
触发 PR 自动 / Fix All 批处理 issue 加 fix-me label / @openhands-agent 提及
主战场 review 现有 PR + 提 fix 从 issue 直接生成 PR
学习能力 learned rules（从用户反馈生成） 无（依赖底层 agent）
开源 ✗ ✓（GitHub Action 完整开放）
集成深度 跟 Cursor IDE / Cloud Agents 共底座 跟 OpenHands runtime / EventStream 共底座

GoalfyOA 内部的 code-reviewer 是另一种形态：

spec_services API
   │
   ▼
判断 is_pre_deployed → 触发 code-reviewer supervisor
   │                          │
   │                          ▼
   │                     调 LLM 走规范检查 + 影响分析
   │                          │
   │                          ▼
   │                     生成 review 报告 → 走 OA 审批
   │
   ▼ 通过 → 进 prod 队列

跟 Cursor Bugbot 的差别：这里是 gating（不通过就不让发版），不是建议。这种"agent 作为发版 gate"的模式是企业内部 critical workflow 的选择，对 review agent 自身的可靠 性要求极高（一旦误判把好 PR 卡死，团队信任崩塌）。

#4.4 Codex / Claude Code 的 review subagent

两家都把 review 做成可挂载的 subagent / agent profile：Codex 在 AGENTS.md 里声明 name="pr_reviewer" / sandbox="read-only" / approval="never"，Claude Code 在 ~/.claude/agents/code-reviewer.md（个人级）或 <repo>/.claude/agents/code-reviewer.md （项目级，进 git）里写 markdown frontmatter + system prompt。

关键差异：Codex / Claude Code 把 reviewer 做成"用户可自由编排的 subagent profile"， 没有强制 gate。Cursor Bugbot 则把 reviewer 做成带商业模型的产品（按用户付费， 具体单价以 cursor.com/pricing 实时为准——主页未直接给出 $40/user/month 数字，待核实）。

#五、训练反哺：让 agent 用 trace 自我进化

"模型公司做 agent 的天然杠杆：用户使用 trace 是下一代训练数据。"

#5.1 唯一把训练侧做成闭环的：Hermes（Nous Research）

   hermes-agent (runtime, batch trajectory)
        │ 用户日常使用 → trajectory
        ▼
   Atropos RL environments (~1000 task-specific verifier)
        │ rejection sampling
        ▼
   DataForge (graph-based 合成)
        │
        ▼
   Hermes 4 base + post-train (5M 样本 / 60B tokens)
        │
        ▼
   DisTrO (低带宽分布式训练，跨互联网)
        │
        ▼
   下一代 Hermes 模型 → vLLM → hermes-agent runtime（闭环）

Atropos 的核心：~1000 个 task-specific verifier，检查模型在某具体任务（数学 / 代码 / tool use / 创意写作）上的输出。只有通过 verifier 的 trajectory 进训练集——reject sampling 的工程化实现。

训练代价：192× B200 GPU、71,616 GPU-hours（仅 405B）。Hermes 4 发布日：2025-08-26。

#5.2 其它家"或可视为"训练反哺的设计

项目 训练反哺机制 是否真闭环
Cursor Composer / Tab / Apply 模型从用户行为 RL 训练 ✓（不公开细节，但确认存在）
Codex ChatGPT 端可能 collect 反馈 → 模型升级（跨年度） ? 推断（Anthropic / OpenAI 都不明示）
Claude Code 同上 ?
OpenHands 社区用 swe-rex 等仓库批量跑 evaluation 部分（社区驱动，非自动闭环）

关键差异：只有 Hermes 把"训练"和"runtime"做成了同一个项目体系。Cursor 也训自家 模型，但 Cursor 不开源训练 pipeline；Anthropic / OpenAI 训自家模型但不开源 runtime。 Hermes 把这件事公开化、模块化、给社区抄，是开源 agent 这条线上最有杠杆的设计差异。

#5.3 hermes-agent 的 batch trajectory generation

hermes-agent 内置 batch trajectory generation 模式：可以 headless 跑大量任务收数据， 直接喂 Atropos。这意味着：

  • 你可以拿自己的 hermes-agent 部署，跑生产任务，生产 trace 直接变训练数据
  • 跟 OpenHands 的 EventStream 持久化的差别：OpenHands 的 event 是给 replay / debug 用的， hermes-agent 的 trajectory 是有意为训练设计的格式（包含 reward signal slot）

#六、HITL / 人工评审作为评估的代际差异

"approval 是 0 与 1 之间无数挡位的连续光谱——10 家给的挡位粒度差异极大。"

#6.1 Approval 粒度对照

项目 approval 粒度 默认设置 用户可调
Cline 每步工具级 + 按工具类型分级 每步问 ✓（Auto-Approve 按工具类型 + 项目内/外双轴）
Codex sandbox × approval 双轴解耦（read-only / workspace-write / danger-full-access × untrusted / on-request / never） --full-auto（workspace-write + on-request） ✓
Claude Code hook → rule → mode → protected paths → classifier 5 道闸 默认要 approval ✓
LangGraph interrupt() + breakpoint，可在任意 node 暂停等用户输入 用户显式插桩 ✓
OpenHands EventStream pause（手动 emit pause event） 默认 autonomous ✓
Cursor mode 切换（Ask / Plan / Agent / Background） Ask 模式只读 ✓
AutoGen TerminationCondition + UserProxyAgent 用户构造 termination ✓
OpenClaw hook 链 / /approve slash 命令 平台层切 ✓（但通常没必要在 IM 加 approval）
Hermes tool 白名单 + Cron skill 调度 用户配 ✓

#6.2 LangGraph interrupt：把 HITL 做成"图节点"

from langgraph.types import interrupt, Command

def review_node(state: State):
    answer = interrupt("请人工 review 这个修改：" + state["proposal"])
    return {"approved": answer == "approve"}

# 用户在前端按"approve/reject"
graph.invoke({"...": ...}, config, command=Command(resume="approve"))

interrupt() 把"等人"做成图节点的一等公民，配合 Checkpointer 持久化，可以等几分钟、 几小时、几天——agent 服务器重启都不影响。这是唯一把 HITL 做到"无状态服务器友好" 的家。

#6.3 Codex 的 sandbox × approval 双轴

Codex 把"能不能做"（sandbox: read-only / workspace-write / danger-full-access）和 "要不要问"（approval: untrusted / on-request / never）做成正交两轴： --full-auto = workspace-write + on-request（推荐默认），--yolo = danger-full-access + never（劝退命名）。

关键洞察："能力"和"审批"是正交的，不是单一 trust level。这是 Codex 在 approval 这条 线上最值得抄走的设计——绝不要把"能动什么"和"是否要问人"耦合成一个 enum。

#6.4 OpenHands EventStream pause vs LangGraph interrupt

两家的 HITL 哲学差异：

维度 LangGraph interrupt OpenHands EventStream pause
哲学 "图节点 = 暂停点"，编排时声明 "event 总线 = 暂停点"，运行时 emit
持久化 Checkpointer（PG / SQLite / Redis） EventStream backend（文件 / DB）
Resume 能力 Command(resume=...) 显式 controller 监听 event，pause 后等 unpause
业务定位 HITL 是建模一等公民 HITL 是事件流的一种

#七、运行时 cost / latency 监控

"YOLO 一晚醒来账单 $200——cost tracking 不是运维，是产品功能。"

#7.1 谁把 cost 当一等公民

最强：UI 内每步实时显示
   Cline       (input tokens / output tokens / USD 显示在 chat panel)
   Claude Code (transcript 自动累计)
   Codex       (/status 命令查 session 用量)

中等：可观测但不显眼
   OpenHands   (state.metrics 暴露给 UI / CLI；Cloud 版按这个计费)
   AutoGen     (ChatCompletionClient.actual_usage / total_usage)
   LangGraph   (LangSmith 节点级拆开成本)

弱：聚合到平台/计费层
   Cursor      (cursor.com/dashboard Usage 月度账单)

无：
   OpenClaw    (个人玩具)
   Hermes      (开源模型本地跑，没成本概念)

#7.2 Cline cost tracking 的产品决策

UI 内 chat panel 末尾常驻显示 Tokens: in/out + Cost: $X.XX (model) + 时长。 实现：每次 ApiHandler 完成时从 provider 返回的 usage 拿数字 → 按 ModelInfo 里的 per-1k 价格换算 → push 给 webview。这套数据顺带也喂 telemetry。

已知问题（2026 春，社区报告）：VSCode Language Model API provider 严重低报 token （实测 70K，UI 显示 ~17K，issue #4584）；部分 task 异常 blow up 到 441K tokens、单次 几美分到几美元（issue #7558）。这反过来证明 cost tracking 的真实业务价值：用户对 错误的成本数字敏感到能立刻提 issue。

#7.3 OpenHands state.metrics

# openhands/llm/llm.py
class LLM:
    def __init__(self, config: LLMConfig):
        self.metrics = Metrics()             # token / cost 累计

# AgentController
state.metrics                                # 暴露给 UI / CLI

OpenHands Cloud 版本基于 state.metrics 做计费——这是唯一一家"开源 agent 框架的 metric 直接成为云端商业模式的 billing source"。

#7.4 LangGraph LangSmith 的节点级 cost 拆分

LangSmith 把 cost 按 graph node 拆开：

agent run #abc123
 ├─ node: planner       LLM: gpt-4o            $0.04   3.2s
 ├─ node: searcher      LLM: gpt-4o-mini       $0.001  0.4s
 ├─ node: searcher      LLM: gpt-4o-mini       $0.001  0.4s
 ├─ node: searcher      LLM: gpt-4o-mini       $0.001  0.4s
 ├─ node: synthesizer   LLM: claude-sonnet-4   $0.12   8.1s
 └─ TOTAL                                      $0.163  12.5s

这是为"复杂任务用大模型 / 简单任务用便宜模型"路由策略服务的最佳工具——你能直接看到 哪个 node 该被降级到便宜模型。

#八、A/B / 灰度路由作为评估手段

"路由本身就是 evaluation 的载体——把 5% 流量分给 model B，看 KPI 反向回 model 选择。"

#8.1 三种路由形态

形态 例子 评估视角的意义
harness 内黑盒决策 Cursor Auto / Composer 路由 / race pattern 用户感知不到，harness 内部 evaluation 闭环
用户配置式分模型 Cline plan/act 各选模型 / OpenHands [llm.condenser] 摘要走便宜 / LangGraph model=callable 用户显式做模型分级（小模型干 routine）

model: "GWModelGroup:critical-tasks" → ai-gateway 查 GWModelGroup → 按 weighted/ random 策略选一个 GWModelGroupItem（如 80% kimi/k2.5-thinking、15% claude/sonnet-4.6、 5% openai/gpt-5.4）。这套机制本身就是最便宜的 agent 评估——5% 流量分给新模型， 看业务 KPI 是不是显著变化，反向决策"该不该把 default 切过去"。

跟 LangSmith 的 dataset / experiments 对比：

|------|--------------------|----------------------| | 评估粒度 | 业务 KPI（线上） | dataset（离线） | | 数据来源 | 生产流量（真用户） | 人工标注 / 历史 trace | | 评估周期 | 分钟级（看 metrics） | 几分钟到几小时 | | 评估样本 | 万级 | 百级到千级 | | 风险 | 真用户被影响 | 0 | | 适合 | 生产级路由优化 | 模型升级前测试 |

两者互补：上线前 LangSmith experiments，上线后 ai-gateway 灰度。

#8.3 Cursor Auto router 的不透明性

Cursor Auto 模式被用户最大的抱怨：不显示具体选了谁。

forum 推断（Cursor 不公开）：
  Auto 大概率综合：
    - prompt 长度
    - 工具调用预测
    - 当前 credit 余额
    - 各模型当前容量
    - 进 slow pool 的概率

这造成"Auto 比手选还慢"的偶发体验。反面教材：把"模型路由"完全黑盒化，节省了用户 GWModelGroup 配置 + 监控 weight 落地的策略，Cursor 这边更激进、更危险**。

#8.4 race pattern：把 A/B 用在每一次调用

Cursor Cloud Agents 据说用 race pattern：同任务并发派给多个模型，结果在 review 阶段由用户挑或自动选 test 全过的。

这是把 A/B 从"分流量"升级到"分单任务"——每个任务 4 倍 LLM 成本但拿到最稳的结果。 适合 high-stakes 场景（PR 自动开 / 关键 review）。

#九、最值得抄走的 5 个评估设计

"看完 10 家的评估实践，挑五个值得抄到自己 agent 平台的。每一个都标了出处和场景。"

抄什么：建立一个 typed event 总线，agent / runtime / UI / telemetry / billing 都是 subscriber。副作用必须 emit 成 event 才"算数"。

为什么值：天然带来 deterministic replay / 灰度 / A/B / 训练数据 / debug / 多端解耦 全套功能。代价是工程纪律（agent 不能在 step 内偷偷改外部状态而不留 event）。

抄哪条线：OpenHands openhands/events/ + controller/replay.py 是参考实现样板。

#9.2 sandbox × approval 双轴解耦（Codex）

抄什么：把"agent 能动什么"（sandbox）和"是否要问人"（approval）做成正交两轴，绝 不要绑成一个 trust level enum。

为什么值：评估视角看，这让你能对每个用户/场景独立调"自治度"——开发场景给 workspace-write × on-request，生产场景给 read-only × never。

抄哪条线：Codex --full-auto（workspace-write + on-request）/ --yolo （danger-full-access + never）的命名 + 默认值是直接复用模板。

#9.3 cost tracking 进 UI 实时显示（Cline）

抄什么：每次 LLM 调用结束，从 provider usage 拿数字，按价格换算，立刻显示在用户 正在看的界面上。不要把 cost 藏在月度账单里。

为什么值：用户对成本敏感是"YOLO 失控"的最佳防线——比 approval 还便宜，又给评估 数据。

抄哪条线：Cline webview-ui/ 的 ChatRow 末尾固定显示 + ApiStreamChunk.usage 统一 normalize。

#9.4 节点级 timeline + time travel（LangGraph + LangSmith）

抄什么：每个 superstep / agent step 同时 emit 状态差量，让 UI 展示节点 timeline； 持久化 checkpoint 后支持 replay 与 fork（改 state 走另一路）。

为什么值：debug 天花板。生产事故不用复现，直接 replay。

抄哪条线：LangGraph Checkpointer + astream(stream_mode="updates") 是 5 行代码 入门，LangSmith 一注册就有 UI。

抄什么：在 LLM gateway 层把"模型组 + 权重 + failover"做成一等公民，5% 流量灰度新 模型，看业务 KPI 反向决策。

为什么值：这是最便宜的 agent 评估。比离线 dataset 评估更接近真实流量分布；比 race pattern 便宜 4 倍。

抄哪条线：goalfy-ai-gateway 的 GWModelGroup / GWModelGroupItem 表 + modelRouter 是 百行级实现，直接照搬模式。

#十、趋势观察 + 一句话各家总结

#10.1 趋势观察

2024 → 2026 三年评估栈进化

1. Benchmark 不再是核心卖点
   2024：刷 SWE-bench 到 50% 算前沿
   2026：基础模型把 SWE-bench Verified 推到 87.6%（Claude Opus 4.7）；
        框架的差异化跑回 harness 工程

2. Trace 从"日志"进化为"可改了重跑的 state"
   2024：print + logger / OTEL span
   2026：deterministic replay（OpenHands）/ time-travel fork（LangGraph）

3. Review agent 从"工具"进化为"产品"
   2024：用户写 prompt 让 LLM review
   2026：Cursor Bugbot 解决率 52%→76%、35%+ Autofix 合并率（仓库数 / 定价 待核实）

4. Cost tracking 从"运维"进化为"产品功能"
   2024：月底账单
   2026：UI 内每步显示 + 实时余额（Cline / Codex / Claude Code）

5. 训练反哺仍只有一家做闭环
   2024：只有 OpenAI / Anthropic 闭门做
   2026：Hermes（Atropos + DataForge + DisTrO）开源整条流水线

6. SWE-bench 自身被怀疑（OpenAI 审计：模型可能 memorize）
   → SWE-bench Pro / SWE-rebench 成为更可信指标
   → harness 战场从"刷分"转向"实际仓库 PR 接受率"

#10.2 一句话各家总结（评估视角）

项目 一句话评估能力总结
OpenClaw 个人 IM 助手没必要做评估栈——/trace on slash 命令 + Gateway hook 已经够。
Hermes（Nous） 唯一把训练侧做成开源闭环：Atropos verifier + batch trajectory + DisTrO，agent + 模型同体进化。
Claude Code 模型分数（Opus 4.7 87.6% SWE-bench Verified）扛大旗；本地 transcript / checkpoints 够用，云端 trace 不收。
Codex session SQLite resume / fork 是审计底；sandbox × approval 双轴是评估"自治度"的最佳模板；模型分数（GPT-5.3-Codex 85% SWE-bench Verified）。
Cursor Bugbot Autofix（52%→76% 解决率提升、35%+ 直接合并率）是当下"agent 评审 agent"产品化天花板；Auto router 不透明是反面教材。
Cline UI 内 cost tracking 是行业最敢露的产品；影子 git per-step checkpoint 是轻量 trace 替代。
OpenHands EventStream + deterministic replay 是开源 agent 框架的评估栈基础设施天花板；GitHub Resolver 是 review 闭环参考实现；同 base 模型下开源 harness 比私有 harness 落后约一个量级（社区复现 ~68.4% vs 裸模型 80.8%，待核实）。
AutoGen OpenTelemetry 内置是 v0.4 的关键升级；AutoGen Studio 是少有的 no-code agent debug 平台；agbench 给社区跑 benchmark。
LangGraph 节点级 trace + time-travel 是行业天花板；LangSmith 是唯一把"开发环境"做进 trace 的平台；不做 benchmark 是哲学选择。

#10.3 文档的两个最不确定点

  1. Cursor / Anysphere 的内部 RL pipeline 与 Tab/Apply/Composer 的训练数据来源： 只能从 forum / 第三方分析推断，cursor.com 没有任何公开 spec。"是否用 Bugbot review 反馈进训练"是猜测，未证实。
  2. Anthropic 公布的 Claude Code / Opus 系列 SWE-bench Verified 数字 vs swebench.com 排行榜归属：blog / llm-stats 给的是 Opus 4.5 ≈ 80.9% / 4.6 ≈ 80.8% / 4.7 ≈ 87.6%， 但没有指出对应 swebench.com 排行榜上哪一行（多版本提交并存，agent harness 也可能 是 Anthropic 私有版而非 Claude Code 公开版本）；OpenAI 自己审计的 "frontier 模型 memorize SWE-bench Verified" 质疑也未影响 Anthropic 的官方 number 报告方式（Anthropic 自己有 "memorization screens"，但未公布过滤前后差值）。

未在本文找到具体数字的成绩： 官方 SWE-bench / GAIA / Terminal-Bench 提交记录：均未公开。其中 Cursor / Cline 是 框架不带具体 agent；Hermes 公开的是模型分数不是 agent 分数。

  • OpenHands swebench.com 当前最高分版本归属：榜实时变动，文末撰写时未抓最新 快照——以 swebench.com 排行榜为准。

#来源

架构原始文档（本目录下）： hermes-agent-architecture.md / claude-code-agent-architecture.md / codex-agent-architecture.md / cursor-agent-architecture.md / cline-agent-architecture.md / openhands-agent-architecture.md / autogen-agent-architecture.md / langgraph-agent-architecture.md / agent-architectures-comparison.md

Benchmark 数据来源：

Observability / 平台来源：

Review / agent 闭环来源：

Cost tracking 来源：

文档撰写时间：2026-04-25 行数目标：500–800（当前 ~810，含核查批注） 撰写约束：所有 benchmark 数字带源；不允许编造；不重复"项目消歧"； 时效性敏感数字一律标"待核实"+ 查找路径，正式引用前请回访官方排行榜

返回 Agent 资料库