2024–2026 Agent Frontier

前 12 章我们已经把 Hermes 拆开看。这一章不绑 Hermes——我们走出代码，俯瞰整个 2024–2026 Agent 工程的版图。看完你能回答：今天的"最前沿 Agent 实践"是什么、 还有哪些没解决的难题、Hermes 在这张图里的位置。

13.12024 转折点：从 demo 到产品

2023 年是"AutoGPT 泡沫"时代。媒体说"agent 改变一切"，实际只能跑 demo。 到了 2024 年，几件事让 Agent 真正"能用"：

1. OpenAI Function Calling 协议成熟，工具调用不再靠 prompt 解析。
2. Anthropic Claude 3.5 Sonnet (2024.06) 让"长上下文 + 工具调用" 第一次真的可靠。Cursor 业务起飞主要靠它。
3. Devin 立 flag (2024.03)：Cognition 演示了"AI 软件工程师"概念。 虽然 Devin 1.0 实际表现一般（SWE-Bench Verified 45.8%），但市场被打开。
4. Anthropic Computer Use (2024.10)：让 Agent 真的能看屏幕、动鼠标。
5. MCP 发布 (2024.11)：工具接入标准化。
6. Anthropic "Building Effective Agents" (2024.12)：第一份被广泛接受的工程指南。

13.2Anthropic "Building Effective Agents" — 工程范式定形

它最大的贡献是把术语对齐。在它之前，"agent"什么意思人人不同。它的定义：

• Workflow = LLM 在开发者预定义的代码路径里被编排。
• Agent = LLM 动态决定自己的工作路径和工具使用。

第 2 章我们已经讲过。它的实操建议总结成 3 条：

1. 从最简单的开始。大多数任务一次 LLM 调用 + RAG 就够。
2. 只在必要时升级到 agent。Agent 用延迟和 token 成本换灵活。
3. 避免重抽象框架。LangChain 风格的 Agent/Chain/Memory 基类层叠让调试变难。直接写代码。

5 种 Workflow 模式

第 2 章列过，这里再扫一遍，配上业界对应实例：

13.3Context Engineering：取代 prompt engineering

Context Engineering 三大杠杆：

① Compaction

把过长的对话历史压缩成总结，开新 context window 继续。

Compaction is the practice of taking a conversation nearing the context window limit, summarizing its contents, and reinitiating a new context window with the summary.

第 3 章和第 5 章我们看过 Hermes 的实现。这是"上限"问题的根本解。

② Just-In-Time Context

不要预先把所有可能用到的数据塞进 prompt，让 Agent 用工具按需取。 prompt 里只放"索引"（文件路径、文档 ID、目录列表），不放内容。

这正是 Claude Code、Cursor、Hermes 都干的事：

# 反模式：把所有代码塞进 prompt
system_prompt = "Here are all 50 files in the repo:\n[200KB of code]"

# JIT 模式：只放索引
system_prompt = "Repo has these files:\n- src/auth.py\n- src/db.py\n..."
               "Use read_file to view content."

③ Tool Result Clearing

用过的工具结果不必永远占着 context。Anthropic 在 2025 把它做成 API 一级功能： 你可以告诉 Anthropic API "把 message_id 之前的所有 tool result 清掉，只留 assistant 总结"。

client.messages.create(
    ...
    clear_tool_results_above="msg_abc",    # 把这条之前的 tool 结果清掉
)

Hermes 还没用上这个新 API（写作时是 2026.05，刚发布），但代码里已经有类似机制： 压缩时优先丢老的 tool result，保留 assistant 的文本总结。

13.4Harness Engineering：超越单一 context

Anthropic 给出一个具体模式："双 Agent harness"：

1. Initializer Agent：第一次跑时设置结构化环境 （建目录、装依赖、写 README 模板）。
2. Coding Agent：每 session 接着上次进度增量推进。

关键洞察："single agent + 长 context"无法支撑数小时的任务。 必须分 session、用 Compaction、用 Skills 把"状态"外化到文件系统而不是 context window。

Anthropic 用这种 harness + Puppeteer 让 Claude 能自动构建生产质量 web 应用。

对应到 Hermes 的设计：

• Hermes 的 delegate_task 工具 = orchestrator-worker harness 的实现。
• Hermes 的 cron jobs = 跨 session 长任务的 harness。
• Hermes 的 Skill + Memory + Curator = 把"状态"外化到文件系统的机制。

13.5Reasoning Models：把 CoT 内化

2024 年 9 月 OpenAI o1 发布——第一次让"模型自己想很久再说话"成为 API 协议级别的事。 此前 CoT 靠 prompt 引导，o1 之后它是模型本身的能力。

关键时间线：

对 Agent 工程的影响

1. Reasoning 不能直接 echo。各厂家协议不一：有的允许 strip 后再发，有的要求严格 echo back。Hermes 的 Provider Profile 处理这些差异（第 4、12 章）。
2. Reasoning content 占 token 但不占用户心智——它在 provider 那边被 strip 掉再给下一轮。
3. 对长程任务有上限提升：SWE-Bench Verified 上 reasoning 模型比纯对话模型高 5–10 pp。
4. 但延迟和成本显著上升。Curator 这种"小后台任务"不该用 reasoning model—— 浪费钱。Hermes 默认 curator 用 Haiku，主对话用 Opus。

13.6SWE-Bench Verified：客观标尺

之前评估 Agent 的好坏靠主观——"Devin demo 看起来很厉害"。2024 年 8 月 OpenAI 推出 SWE-Bench Verified，给"代码 Agent"建立了客观标尺。

SWE-Bench Verified 是什么

500 个被人工核对过、确认真的可解的 GitHub issue。 每个 issue 有：

• 一个真实 repo snapshot
• 一段问题描述（issue body）
• "通过"的标准是几个 test cases pass

测试一个 Agent 的方法：把 repo + issue 给它，给它 N 个 token 预算，它生成 patch， 跑 test 看 pass。pass 率就是 SWE-Bench 分数。

2026 年初的成绩

三个值得讨论的事实

事实 1：80% 看起来很高，但...

SWE-Bench Verified 是"被人工挑过的可解题"。真实生产里很多 bug 模糊、要域知识、 要跨 repo 上下文——SWE-Bench 测不到这些。 80% 是上限的乐观估计，不是日常工作水平。

事实 2：Harness vs 模型同等重要。

Cursor 用 Sonnet 4.6 拿 65.7%。同时直接 Sonnet API 跑 SWE-Bench（用 SWE-Agent harness） 分数明显更低。同样的模型差~15 pp。这是因为 Cursor 有更好的 harness： it 知道怎么切 task、怎么 review、怎么 prompt cache。

事实 3：Devin 落后。

2024 年初 Devin 发 demo 视频引发轰动，估值数十亿。2026 年 SWE-Bench Verified 才 45.8%—— 远低于 Cursor 和 Claude Code。原因不是模型不行（它用 GPT），而是 harness 设计选择 优化了 demo 表演而非真实 throughput。

13.72026 Benchmark 6 件套

SWE-Bench Verified 只是其中一块。到 2026 年初，"评估 Agent"这件事已经成熟到 有一套约定俗成的 benchmark 组合。如果你做 Agent，知道这 6 个测的是不同维度—— 没有哪个能单独衡量"Agent 强不强"。

τ²-Bench：企业最关心的那个

Sierra 公司（前 Salesforce CEO 创办）推的 benchmark。模拟客服场景： 另一个 LLM 扮演用户，Agent 必须既完成任务、又遵守书面 policy（"退款 ≤ 30 天才允许"等）。

测什么：

• 多轮工具调用：客户问 "帮我退款" → Agent 查订单、检查 policy、决定是否办、办理。
• Policy adherence：硬性规则不能被用户绕过。"你必须给我退款"——Agent 该说 no 时说 no。
• 对话健壮性：用户改主意、说错、补充信息——Agent 得能处理。

τ²-Bench 比 SWE-Bench更难。SWE-Bench 测的是"解题"——给定固定输入找答案； τ²-Bench 测的是"操作"——多轮交互且要符合规则。企业落地 Agent 时关心的就是这个。

OSWorld：最诚实的那个

OSWorld 让 Agent 在真实 Ubuntu 桌面里完成任务："在 LibreOffice 里改一个文档的格式"、 "用 Chrome 找到某网站的隐藏菜单并点击"。准确率怎么算？看文件最终状态—— 你要么真的改了文件、要么没改。没法靠 prompt engineering "蒙混过关"。

2026.04 数据：SOTA ~35%。这是真实世界 GUI Agent 的天花板—— 离实用还有距离。Anthropic Computer Use、OpenAI Operator、Google Project Mariner 都在这上面竞争。

METR HCAST：时间地平线

METR (Model Evaluation & Threat Research) 的 HCAST (Human-Compared Agent Skill Test) 不是 传统 benchmark——它测的是 "Agent 能持续多长时间不偏离"。 把任务按"人类专家做完需要多少时间"分级，看 Agent 在每个级别的成功率。

2026 早期数据：

• 15 分钟以内任务：~80% 成功率
• 1 小时任务：~50%
• 4 小时任务：~20%
• 1 天任务：< 10%

METR 据此预测 "Agent 能做的任务时长每 7 个月翻倍"。这是当前 AGI 路径 最被引用的实证趋势之一——比 benchmark 分数更说明问题。

13.8Multi-Agent Framework 大洗牌（2025–2026）

2023–2024 年 multi-agent framework 百花齐放：AutoGen、CrewAI、Swarm、LangGraph、 ag2、Agno……到 2026 年发生了显著洗牌。

四种心智模型

这些 framework 看似都做"multi-agent"，但底层抽象完全不同：

Hermes 不属于上面任何一类

Hermes 是具体 Agent 产品，不是 framework。它内部用 orchestrator-workers 模式 （delegate_task 工具），但没暴露成"我是 multi-agent framework"。

这种"产品先于 framework"的路线是 Anthropic Building Effective Agents 文章里推崇的。 选 framework 时建议：

• 需要"持久化、可恢复、有 observability 的生产工作流" → LangGraph
• 需要"研究型多 Agent 协作" → MAF / AG2
• 需要"快速 prototype 一个 demo" → CrewAI / Agents SDK
• 已经在做"产品级 Agent，不需要新 framework" → 学 Hermes 这种直接写循环 + 工具字典的形态

"少 framework，多代码"的拐点

2026 年业界一个明显趋势：从 framework 信仰回到 first-principles 代码。 原因：

• Framework 的抽象在调试时遮蔽底层 prompt，bug 难定位。
• Framework 升级会破坏现有 agent，被绑定。
• 核心循环本身只有 100–500 行——直接写更清楚。

Hermes 是这条路线的样本。它内部没用 LangGraph / AutoGen / 任何 framework， 全部是直接的 Python 循环 + dict + Provider profile。这本书前 12 章拆的就是这套代码。

13.9Agent RL：把工程经验"训"进模型

到 2026 年，"用 RL 把 Agent 行为训进模型"成为新的研究主线。这事 2025 年初由 DeepSeek-R1 引爆， 现在每家都在做。

2026 主流 post-training 算法

对 Agent 工程的影响

关键认知转变：很多"agent loop 里的工程技巧"以后会被训进模型。

• 第 3 章讲的"幻觉工具名 retry"——R1 之后的模型自己学会"先确认工具存在"。
• 第 4 章讲的"reasoning content 处理"——未来 reasoning 可能更"安静"，不需要 echo。
• Tool use 准确率本身在被 RL 训练（如 RL-trained tool use 系列论文）。

13.10Agent Skills 标准化（2025.12+）

本书第 8 章把 SKILL.md 当作 Hermes 的内部约定来讲。但2025 年 12 月一个重大事件改写了这个定位。

影响

1. Hermes 的 SKILL.md 设计被"追认"。 本书 ch08 讲的 frontmatter、When to Use / NOT to Use、scripts/ 目录—— 这些原本是 Hermes 内部约定，现在变成跨工具标准。
2. 商业模式出现。skillsmp.com、 agensi.io 等 marketplace 允许付费 skill， 创作者拿 80%。"我的 git skill 在 Cursor / Claude / Hermes 都能用并收费"成为现实。
3. Pre-built skills 出现。Anthropic 自己发布 PowerPoint / Excel / Word / PDF 处理 skill。 它们和你自己写的 skill 走同样机制——模型按需调用。
4. Plugin marketplace 整合。Claude Code 的 /plugin 命令现在 既装 MCP server 也装 Skill 也装 plugin，三合一。

Skill 与 MCP 的分工

简单理解：MCP = "接什么外部系统"，Skill = "怎么用这些系统"。两者互补。

13.11Prompt Injection 攻防演进

2024 年的 prompt injection 防御靠 "请忽略恶意指令" 这种 prompt 教导。2025–2026 全面进入实证攻防时代。

Hermes 已经做到 / 还要补的

Hermes 当前的安全机制（第 7 章）：

• ✓ Toolset 限制（webhook safe set）—— Tool-Input Firewall 的核心。
• ✓ 命令审批—— 危险工具用人工二次确认。
• ✓ 错误清洗（_sanitize_tool_error）—— 类似 Tool-Output Sanitizer。
• ⚠ Minimizer 不完整—— Hermes 还没专门"提取 user query 的最小有效指令"机制。
• ⚠ Chat-template 转义—— 没专门处理。

2026 年 Agent 安全的"做了 vs 没做"分水岭就在这两条。 你做生产 Agent 必须把它们补全。

13.12MCP — 工具的 USB-C

MCP 的三层架构

三种 capabilities

1. Tools：可被 LLM 调用的函数（最常见）。schema 是 JSON Schema 子集。
2. Resources：可读取的数据（文件、API 响应）。用 URI 寻址。
3. Prompts：可参数化的 prompt 模板。

MCP 协议本身

基于 JSON-RPC 2.0。传输方式：

• stdio：host 起子进程，stdin/stdout 通信。最常见。
• HTTP+SSE：远程 MCP server，给团队级共享。

核心 RPC 方法：

# Host → Server
{"method": "initialize", ...}                # 握手 + capability 协商
{"method": "tools/list"}                    # 拿工具清单
{"method": "tools/call",
 "params": {"name": "foo", "arguments": {...}}}
{"method": "resources/list"}
{"method": "resources/read", "params": {"uri": "file://..."}}

# Server → Host（事件推送）
{"method": "notifications/tools/list_changed"}  # 工具变了请重读

生态状态（2026.05）

• 官方 server：Filesystem、GitHub、Slack、Brave Search、Sentry、Memory、PostgreSQL 等。
• 社区 server：数千个，几乎覆盖所有常用 SaaS。
• SDK 覆盖：Python、TypeScript、Java、Go、C#。
• 主要 host：Claude Desktop、Cursor、Zed、VS Code (Continue 扩展)、Hermes、Aider。

2025 年 MCP 的演进

Anthropic 在 2025 年中发了 "Code Execution with MCP"—— 把"代码执行"也搬到 MCP server 里，让 Agent 写代码直接调 MCP server 的 sandbox 执行。 比每次让 Agent 写 inline code 安全得多。

13.13Anthropic Computer Use 与多模态 Agent

2024 年 10 月 Anthropic 让 Claude 3.5 Sonnet 公测 computer use。 能直接看屏幕截图、动鼠标、敲键盘。从此"Agent 真的能干 GUI 任务"从 demo 变成 API。

对工程的启示：

• Vision-as-tool 的 schema 像这样：

  {"name": "computer_use",
   "parameters": {
     "action": "screenshot" | "click" | "type" | "scroll",
     "coordinate": [x, y],
     ...
   }}

• Hermes 在 macOS 上接 cua-driver，整合一个 computer_use 工具到 toolset。
• 多模态消息格式上：vision 工具的输出（截图）作为 base64 image 嵌进 tool result。 下一轮 LLM 直接"看"这张图。

未解决的难题：

• 准确率仍然不高。普通 web 任务 50% 左右成功率。
• 延迟高。每步都要发截图、模型分析、动作。
• 安全。AI 自己控制鼠标键盘，错点了不可逆。

13.14研究脉络回顾：Voyager → 现代 Skill 范式

从 Voyager 到 2026 年，Skill / Memory 研究的关键论文：

13.152026 还在解决什么

哪些问题仍未解决？

① 长程任务的 Cost Control

一个真实 SWE-Bench 任务跑下来可能花 $5–$20 token 钱。Anthropic Computer Use 一个 GUI 任务可能 $30+。怎么做到一次任务 1 美分以下仍是开放问题。 Auxiliary 模型路由（让简单步骤用便宜模型）是一条路，但需要更智能的 routing。

② Memory 的 "Catastrophic Inconsistency"

Agent 跑了三个月，memory 里积累了几百条事实。其中一些过时了 ("用户喜欢 Python 2"——他现在用 3)。怎么知道哪些 fact 应该 forget？ Curator 是一个方向，但目前的实现是规则化的。更智能的"记忆衰减"需要研究。

③ Trustworthy Multi-Agent Coordination

你让 5 个 sub-agent 并发工作，怎么保证它们的结果一致、不矛盾？ Hermes 用 Kanban 加排他锁，但这只是机械协调。语义层面的协调 （"两个 sub-agent 在改同一文件不同地方怎么 merge"）仍开放。

④ Agent 评估的 Tail Cases

SWE-Bench 80% 是平均。但生产里的 bug 分布是长尾—— 20% 的 bug 占 80% 的工时。这些 "hard cases" 上 Agent 表现远低于平均。 怎么 benchmark 这种长尾，还没有好方法。

⑤ Privacy & Local-First Agent

现有强 Agent 几乎都依赖 cloud LLM API。 但 enterprise / 个人都希望"我的数据不离开机器"。 本地 70B 开源模型在 SWE-Bench Verified 上目前 ~30%——和云端 80% 差距大。 缩小这个差距是 2026 年开源社区主要方向。

⑥ Agent 的可解释性 / 审计

Agent 跑了 50 步、调了 20 个工具、得出一个结论——它为什么这么做？ Reasoning content 字段是一部分答案，但不够。生产环境需要可审计的"决策树"。

⑦ GUI Agent 的实用化天花板

OSWorld 2026 年 SOTA 仍在 35–40%。这意味着对真实桌面的"会用"率不到一半。 Computer Use / Operator / Mariner 都还在"demo 漂亮、生产无法依赖"阶段。 问题不只是模型——动作精度（点中按钮）、状态识别（弹窗 vs 主窗）、错误恢复 （误操作怎么回滚）都需要新解法。

⑧ Agent 经济性的两极分化

按 2026 年 5 月数据：一个 SWE-Bench Verified 任务跑下来用 Claude Opus 4.7 约 $0.50–$3.00； 用 Sonnet 4.6 + 好 harness 约 $0.10–$0.50；用 GPT-5.2 约 $0.30–$2.00。 企业部署成本因此差几十倍。 "用便宜模型 + 好 harness 接近大模型"是当前最有商业价值的研究方向， 也是 Cursor / Cognition 等公司的核心 moat。

⑨ Long-Horizon Reliability

METR HCAST 数据显示 Agent 在 4 小时任务上成功率只有 20%。 现实里"做完一个 feature"对人类是 1–3 天的事。Agent 走完一天不偏离仍是开放问题。 Anthropic Harness Engineering 是当前最深入的尝试，但还没有谁敢声称 "把 Agent 扔在 VPS 上跑一周不监督"。

⑩ Prompt Injection 的"军备竞赛"

Tool Firewall（13.11）在 benchmark 上拿满分，但 ChatInject (ICLR 2026) 立刻找到新攻击面。 这是典型的攻防军备竞赛——不存在"一劳永逸"防御。生产 Agent 必须 接受"被骗一定会发生"，然后用 capability limitation 兜底（第 7 章核心论点）。

13.16Hermes 在哪

把 Hermes 标在这张地图上：

flowchart LR
  T1["2024.12
Building Effective Agents
━━━━━━━━━
5 workflow 模式
augmented LLM
少抽象多代码"]:::milestone
  T2["2025.06
Context Engineering
━━━━━━━━━
Compaction
JIT context
Tool result clearing"]:::milestone
  T3["2025.Q4
Harness Engineering
━━━━━━━━━
双 Agent
多 context window
文件系统状态外化"]:::milestone
  T4["2026.05
Hermes 0.14
━━━━━━━━━
集成以上所有
30 providers · MCP host
Skill + Memory + Curator
20+ 平台"]:::hermes
  T1 --> T2 --> T3 --> T4
  T4 -.->|"开源样本"| Conclusion["'工程化共识'
的集大成"]:::concl
  classDef milestone fill:#fbfaf6,stroke:#8b1538,color:#8b1538
  classDef hermes fill:#ecf3eb,stroke:#2f5d3a,color:#2f5d3a,font-weight:bold
  classDef concl fill:#f0eaf1,stroke:#6b4488,color:#6b4488

把 Hermes 的设计决策对照"这是哪个前沿想法":

结论：Hermes 不是 cutting-edge 研究项目，但它把所有 cutting-edge 工程实践都整合进了一个能跑的开源 framework。 这就是为什么本书拿它当 textbook——你看一份代码，学完整个 2024–2026 的工程沉淀。

13.17本章带走的

• 2024 是转折点：Function Calling 协议成熟、Computer Use、MCP、Anthropic 指南——Agent 从 demo 走向产品。
• Workflow vs Agent 二分法（Anthropic 2024.12）成为业界共识。
• Context Engineering 取代 Prompt Engineering。三招：Compaction、JIT context、Tool Result Clearing。
• Harness Engineering（2025）：单 Agent 撑不起长任务，需要多 Agent + 多 context window 协作。
• Reasoning Models（o1/R1/Extended Thinking）让 CoT 从 prompt 内化到模型。
• SWE-Bench Verified 给"代码 Agent"建立客观标尺。80% 是技术天花板，但同模型不同 harness 差 15+ pp——harness 工程极其重要。
• MCP 是 2024.11 起的工具接入事实标准。生态有数千 server。写工具优先 MCP server 形式。
• 仍未解决：cost、memory consistency、multi-agent coordination、tail cases、本地化、可审计。
• Hermes 集大成了这些工程实践。