AI 能力演进图谱

一、LLM 解决了什么问题

LLM 本质是一台概率预测机器，通过在海量文本上训练，涌现出了：

核心价值：把人类知识压缩进参数，用自然语言对话即可调用——无需写代码、无需专业培训。

二、LLM 解决不了什么问题

LLM 有六大根本局限：

这些局限共同导致了最核心的工程挑战：幻觉——模型不知道自己不知道，会自信地编造"合理"的错误答案。

三、引入 RAG：解决"知识边界"问题

RAG = Retrieval-Augmented Generation（检索增强生成）

解决的问题：LLM 的知识是静态的、有截止日期的、不含私有内容的。

工作方式：

[离线] 文档 → 切片 → 向量化 → 存入向量数据库

[在线] 用户问题
          ↓ 向量检索：从知识库找最相关片段
          ↓ 组装 Prompt："根据以下资料回答：[检索内容] + [用户问题]"
          ↓ LLM 基于真实文档生成回答

RAG 带来的四大收益：

1. 解决知识截止：内部文档、最新资料可以随时更新入库
2. 减少幻觉：模型有参考资料时倾向于基于资料回答，而非自由发挥
3. 可追溯：回答可附上"来源：第X段"，用户可验证原文
4. 无需重新训练：更新知识库只需更新文档，成本极低

RAG 的局限：检索质量决定回答质量，难点在"切好文档、检索准"，而非 LLM 本身。

四、引入 Function Call：解决"执行边界"问题

根本限制：LLM 只能输出文本，无法执行代码、读写文件、调用 API、控制外部系统。

Function Calling 的核心思想：

LLM 输出的虽然只是文本，但可以是结构化的 JSON。外部程序解析这段 JSON 并真正执行，再把结果反馈给模型——LLM 从未"执行"任何东西，但等效于调用了外部功能。

完整流程：

用户问题 + 工具列表描述
          ↓
     LLM 输出调用指令（JSON）
          ↓
     外部代码解析并真正执行
          ↓
     执行结果注入 Context
          ↓
     LLM 读取结果 → 生成最终回答

Function Call 解锁了什么：

• 查询实时数据（告别幻觉）
• 读写文件、执行命令（从"说"到"做"）
• 调用任意 API（连接整个互联网和内部系统）
• 串联多步工具调用（处理复杂任务）

五、引入 AI Agent：解决"自主执行"问题

纯 LLM 的模式：输入 → 输出，一问一答，被动响应，每次从零开始。

Agent 加了什么：在 LLM 之上加一个执行循环（Agent Loop）：

用户给出目标
      ↓
[循环执行]
  思考：现在应该做什么？        ← LLM 决策
  行动：调用工具               ← 外部工具执行
  观察：工具返回了什么？        ← 结果注入 Context
  判断：任务完成了吗？→ 没有 → 继续循环
      ↓
目标达成，输出结果

Agent = LLM 大脑 + Function Calling 协议 + 外部工具集合

Agent 解决的核心问题：把"对话"变成"行动"——用户只需说出目标，Agent 自行拆解计划、调用工具、处理错误、迭代完成，无需人工逐步介入。

六、引入 MCP：解决"工具能力扩展"问题

Function Call 的局限：工具能力是硬编码在 Agent 框架内部的，第三方无法扩展，也无法跨平台复用。

MCP（Model Context Protocol） 是 Anthropic 提出的开放标准协议，让任何人都可以把工具能力封装成独立服务，Agent 通过统一协议接入——就像 USB 接口，插上即用。

与 Function Call 的关系：

Function Call（LLM 调用工具的协议）
         ↓ 调用的工具来自哪里？
  ┌──────────────────────────────────┐
  │ 内置 Tool（本地直接执行）          │  ← 读文件、执行命令、搜索等
  │   Claude Code 主进程内部实现       │
  └──────────────────────────────────┘
  ┌──────────────────────────────────┐
  │ MCP Tool（外部进程/远程服务执行）   │  ← 支付、数据库、第三方 API 等
  │   独立进程或远程 HTTP 服务提供      │
  └──────────────────────────────────┘

两种部署方式：

MCP 解决的核心问题：

1. 能力无法扩展：内置工具是固定的，MCP 让第三方可以自由开发并插入新能力
2. 跨平台复用：一个 MCP Server 可以被任意 Agent 框架接入，不绑定特定系统
3. 领域隔离：专业领域（钱包、数据库、监控）独立成服务，主 Agent 不需要关心实现细节
4. 状态管理：独立进程可以维护自己的连接池、缓存、认证状态，不污染 Agent 主进程

一句话区分：

Function Call 是 LLM "说我要调用什么"的语言；MCP 是工具能力"住在哪里、怎么被找到"的标准。两者配合，让 Agent 的工具集从固定变成无限可扩展。

七、引入 Skill：解决"复用与标准化"问题

Agent 有了工具，但新问题出现了：同一类任务（如 Git 提交、发送转账、跑测试）每次都要靠 LLM 临时规划步骤，流程不稳定、容易遗漏、无法沉淀经验。

Skill（技能）是什么：用户/团队预先定义的高级工作流模板，把多个 Tool 调用的固定顺序和规则封装成一个命名单元，Agent 直接调用即可。

没有 Skill（纯 Agent）：
  用户: "帮我提交代码"
  LLM 临时推理 → 可能忘记 git diff → 可能格式不规范 → 每次结果不同

有 Skill：
  用户: "/commit"
  → 加载预定义的 commit 工作流
  → 步骤固定: git status → git diff → git log → 生成规范 message → add → commit → 验证
  → 结果稳定、流程可控

Skill 解决的核心问题：

Skill 的结构：

Skill = {
  name:         "/commit"               ← 触发名称
  description:  "创建规范的 git 提交"    ← LLM 判断何时使用
  instructions: "1. git status → 2. git diff → 3. 分析变更 → 4. 生成 message → 5. add → 6. commit"
  tools:        [Bash]                  ← 限定可用工具范围
}

Skill 在整个体系中的位置：

用户指令
    ↓
Skill（高级工作流）   ← 封装领域知识和最佳实践
    ↓
Tools（原子操作）     ← Read / Write / Bash / mcp__xxx
    ↓
Function Call        ← LLM 决策调用哪个工具
    ↓
MCP Server / 外部系统 ← 真正执行

Skill vs 直接用 Agent 的区别：

八、引入 Harness Engineering：解决"工程可靠性"问题

Skill 解决了流程标准化，但新问题出现了：即使有了 Skill，AI 系统在生产环境中仍然是一个"黑盒"——不知道质量如何、不知道何时出错、改了 Prompt 不知道效果好坏、出了故障不知道从哪排查。

Harness Engineering 的核心思想：

给 AI 系统套上一整套控制、测试、管理基础设施，让原本不可预测的模型行为变得可评估、可观测、可信赖。

"Harness" 原意是马具——套在马身上控制方向和力量的装置。在 AI 工程中，它是让 AI 这匹"野马"可以在生产环境中安全奔跑的工程体系。

Harness Engineering 解决的核心问题：

Harness Engineering 的四层架构：

没有 Harness 的 AI：
  输入 → [黑盒模型] → 输出
  问题：不知道为什么出错，无法系统测试，无法评估好坏

有 Harness 的 AI：
  输入
    ↓
  [评估层 Evaluation]      ← 持续测量质量：Eval Suite / Benchmark / LLM-as-Judge
    ↓
  [执行层 Runtime]         ← 安全可靠运行：Guardrails / Prompt 管理 / 输出验证 / 降级策略
    ↓
  [可观测层 Observability]  ← 全链路透明：Tracing / Token 成本监控 / 异常告警
    ↓
  [测试层 CI/CD]           ← 持续验证：PR 触发 Eval / 回归测试 / 安全扫描
    ↓
  输出

三类核心实践：

① 评估体系（Evaluation）——把"感觉"变成"数字"

没有评估：改 Prompt → 手测几个例子 → "感觉好多了" → 上线（不知道哪里变差了）
有评估：  改 Prompt → 跑 500 个测试用例 → 准确率 82%→91%
                    → 发现"否定问句"类别退步了 3% → 针对性优化

• 自动化 Eval：有标准答案的任务直接对比；复杂任务用 LLM-as-Judge（用强模型评判弱模型）
• Pairwise 对比：不打绝对分，让评估者判断"A 和 B 哪个更好"——更符合人类直觉
• 回归测试集：包含核心场景、边界情况、对抗样本、历史 Bug 案例

② 护栏系统（Guardrails）——在模型两侧建立安全过滤层

用户输入 → [输入护栏: PII检测 / Prompt注入防护 / 有害内容过滤]
                ↓
          [模型调用]
                ↓
         [输出护栏: 事实一致性 / 格式验证 / 敏感信息脱敏 / 品牌安全]
                ↓
          最终输出

③ 可观测性（Observability）——AI 系统的专属监控维度

传统服务监控：延迟 / 错误率 / 吞吐量
LLM 额外需要：
  ├── Token 消耗（输入/输出分别统计，直接对应成本）
  ├── Prompt 版本（v2.3 和 v2.4 哪个效果更好）
  ├── 完整 Prompt + Response 记录（调试 AI 问题必需）
  ├── 幻觉检测率（事实错误频率）
  └── 模型降级次数（主模型不可用时的备用触发频率）

与前序技术的关系：

Agent + Skill  →  构建了"能做事"的 AI 系统
Harness Engineering  →  让这个系统"做得好、做得稳、做得透明"

没有 Harness 的 Agent：能完成任务，但质量未知、失败时无法排查
有  Harness 的 Agent：完成任务 + 质量可量化 + 异常可告警 + 失败可追溯 + 成本可控

主流工具生态：

九、引入 Anthropic Harness：解决"长时间 Agent 架构弹性与质量"问题

通用 Harness Engineering 提供了评估、护栏、可观测性等工程实践，但当 AI Agent 需要运行数小时、执行数百个工具调用时，新的矛盾浮现：架构耦合导致任何一处崩溃都全功尽弃；Agent 评估自己产出时存在天然的利益冲突偏差，质量上不去。

Anthropic Harness 的核心洞察：

"Harness 是对模型能力不信任的具象化。随着信任的建立，Harness 应该变薄，而不是变厚。"

Anthropic 在 2025–2026 年设计 Managed Agents 时，从操作系统设计中借鉴了虚拟化思想，形成了三大设计哲学：

哲学一：为"尚未被构想的程序"设计

操作系统的伟大之处在于：磁盘从机械换成 SSD，应用程序调用的 read() 接口从未改变。Anthropic 用同样思路设计了三个永不改变的稳定接口，让底层实现随模型能力自由演化：

底层实现（随模型进化频繁变化）
  ├── 上下文管理策略（今天滑动窗口，明天百万 token 根本不需要管理）
  ├── 沙箱技术（今天 Docker，明天 WebAssembly）
  └── 错误重试逻辑（模型越强，工具调用越稳，兜底逻辑越不需要）
        ↓  虚拟化为三个稳定接口
  Session（记忆）  ←  session.append(event) / session.get_history()
  Harness（大脑）  ←  harness.run(session)
  Sandbox（双手）  ←  sandbox.execute(name, input) → str
        ↓
  上层应用（今天的代码 Agent，明天的研究 Agent，后天尚未被想到的 Agent）

哲学二：Harness 编码的是假设，假设会过时

每一个 Harness 组件都隐含着对模型能力的悲观假设，模型进化后这些假设必须被重新检验并果断删除：

实践：每次模型升级后运行消融测试（Ablation Test），量化各组件的实际贡献。Anthropic 将 Harness 从 7 个核心组件缩减到 3 个，性能不降，成本和延迟显著下降。

哲学三：大脑、双手、记忆彻底解耦

根基原则：状态（发生了什么）和行为（接下来做什么）不应该住在同一个进程里。

传统耦合架构（单容器）：
  [LLM 调用 + 工具执行 + 上下文管理 + 凭证存储] = 一个脆弱整体
  任何部分崩溃 → 状态全部丢失 → 任务从头开始

解耦架构（三层分离）：
  ┌─────────────────────────────────────────────────────────────┐
  │ Session（记忆层）：追加式事件日志，独立持久化，存活于 Harness 之外  │
  │   Harness 崩溃 → Session 完好；新实例 wake(sessionId) 接管继续  │
  ├─────────────────────────────────────────────────────────────┤
  │ Harness（控制层）：完全无状态，读 Session + 路由工具调用           │
  │   崩溃即换，横向扩展 = 多启几个无状态实例（"牛群"，不是"宠物"）   │
  ├─────────────────────────────────────────────────────────────┤
  │ Sandbox（执行层）：隔离容器，懒加载（按需创建），凭证永不进入       │
  │   容器崩溃 = 单次工具调用报错，Claude 决定重试；TTFT ↓60%        │
  └─────────────────────────────────────────────────────────────┘

核心安全设计：凭证从不进入 Sandbox——Git Token 仅用于初始化克隆后即丢弃；API Key 存于 Vault，通过专用代理注入，即使 Sandbox 被完全攻陷，凭证依然安全。

三智能体架构：Planner-Generator-Evaluator

对于长时间复杂任务，Anthropic 借鉴 GAN（生成对抗网络） 哲学，用独立上下文消除 Agent 的自我评估偏差：

GAN 的洞察：生成器与判别器参数独立 → 无法共谋 → 对抗性压力驱动质量提升
Agent 的转化：Generator 与 Evaluator 上下文独立 → 无法共谋 → 对抗性质量提升

Planner（规划者）
  一句话目标 → 功能列表 → Sprint 计划
  输出持久化 Plan Document（全局状态锚点，供所有 Agent 读取）
        ↓
    主循环（5-15 次迭代）
        ↓
  Generator（生成者）             Evaluator（评估者）
  └ 执行具体工作                   └ 完全独立上下文（不参与生成）
  └ 上下文定期重置（非压缩）  ──→   └ 强制怀疑论角色（System Prompt 注入）
    └ 防止上下文漂移                └ 评分维度量化（每项 1-10 分）
    └ 从 Plan Doc 重新加载目标      └ 真实浏览器测试（Playwright MCP）
        ↑────── 具体改进建议 ────────┘

实测数据（同一任务：构建 2D 复古游戏制作工具）：

Managed Agents 平台（2026年4月正式发布）：
将上述三哲学封装为云服务（$0.08/session hour），开发者无需自建 Sandbox 基础设施和状态管理，直接运行多小时 Agent 任务。已落地：Notion（工作区任务委托）、Sentry（自动 Bug 修复）、Rakuten（Slack 企业 Agent）。

与前序技术的关系：

第八章 Harness Engineering  →  通用工程实践：评估体系 + 护栏 + 可观测性，解决 AI 系统可测性
  ↓ 局限：长时间运行任务中，架构耦合导致崩溃即全失；单 Agent 自我评估存在天然偏差
第九章 Anthropic Harness   →  专攻长时间 Agent 的两个核心难题：
                               ① 架构解耦：Session/Harness/Sandbox 三层分离，崩溃不丢状态
                               ② 质量保障：Generator-Evaluator 对抗循环，消除自我评估偏差
                               ③ 动态演进：Harness 随模型进化持续"减负"，不让旧假设成枷锁

十、引入 Hermes Agent：解决"自主进化"问题

Harness Engineering 让 AI 系统变得可测、可信、可运维，但仍有一个根本局限：AI 系统的能力是静态的——Prompt 是人工编写的，Skills 是人工维护的，系统从每次使用中学不到任何东西。使用一年和使用一天，能力没有差别。

Hermes Agent 的核心思想：

AI 智能体应该像人类一样，从每次经历中学习并积累技能，而不是每次对话都从零开始。

"Hermes" 是希腊神话中信使之神，象征信息的传递与积累——在 AI 工程中，它是让 Agent 把每次经验转化为可复用知识的自进化框架（Nous Research 出品，2026 年 4 月发布 v0.9.0，前身为 OpenClaw）。

Hermes Agent 解决的核心问题：

三层记忆架构：

程序性记忆（Skill）     ← 解决问题的"方法论"沉淀
  ~/.hermes/skills/SKILL.md
  结构：YAML frontmatter（名称/版本/平台/依赖）+ Markdown 步骤 + 已知陷阱
  来源：后台自动创建 / 主 Agent 主动调用 / 社区共享（agentskills.io）

情节性记忆（SQLite）   ← 经历过"哪些事"的记录
  SQLite + FTS5 全文检索，轻量替代向量数据库，无额外依赖
  检索时：FTS5 找相关段落 → LLM 压缩摘要 → 注入当前 prompt

工作记忆（Context）    ← 当前对话的临时状态
  达到 token 阈值时自动压缩历史（用 LLM 生成摘要保留关键信息）
  利用 Anthropic prefix caching，可节省最高 75% 输入 token 费用

核心自进化机制：后台 Skill 审查：

[计数器机制]
每次 LLM API 调用，_iters_since_skill 计数器 +1
达到阈值（默认 10 次）→ 设置 review 标志

[执行时机：不阻塞主对话]
用户消息 → LLM 执行 N 次工具调用 → 生成最终 response → 发送给用户 ✓
                                                              ↓
                                          [后台静默] spawn review thread
                                          用户完全感知不到

[后台 review agent]
fork 一个全新的 AIAgent 实例
  - max_iterations=8（有上限，防止失控）
  - quiet_mode=True（完全静默，输出不可见）
  - _skill_nudge_interval=0（禁止递归触发 review）
  注入完整对话历史快照（深拷贝，不修改主对话）
  调用 skills_list() 获取现有技能列表
  LLM 语义判断：新建 / 更新 / "Nothing to save."

LLM 判断是否值得创建 Skill 的标准（非硬编码，完全由模型语义决策）：

Skill 渐进式加载（三级，节省 Token）：

Level 0（总是加载）：技能名称 + 描述列表（约 3,000 tokens）
                    帮助 LLM 知道"有哪些技能可用"

Level 1（按需加载）：完整技能内容（步骤 + 陷阱 + 示例）
                    当 LLM 判断当前任务需要该 Skill 时才加载

Level 2（按需加载）：技能引用的外部文档
                    当 Skill 内容引用额外资料时才加载

自进化闭环：

用户完成复杂任务（≥10 次工具调用迭代）
        ↓
[后台 review agent] 分析完整对话历史
        ↓
  ┌─────────────┴─────────────┐
  ▼                           ▼
值得保存                   不值得保存
  ↓                           ↓
新建 SKILL.md             "Nothing to save."
或更新已有 Skill             静默退出
  ↓
下次同类任务：直接复用（更快、更准）
  ↓
Cron 定期触发：复习使用记录 → 发现缺漏 → patch Skill
  ↓
越用越强的复合收益 ✓

与前序技术的关系：

第七章 Skill               →  人工预定义工作流模板，靠开发者手动维护
第八章 Harness Engineering  →  让 AI 系统可测、可观测，但仍是静态系统
第九章 Hermes Agent         →  在 Skill + Harness 基础上加入自主学习闭环
                                Skill 从"人工编写"变成"自动积累 + 持续优化"

传统 AI Agent 是"工具"——你告诉它做什么，它做完就忘。
Hermes Agent 是"同事"——它记得你们一起解决过什么，
                         并且会在你睡觉的时候自己复习。

总结：能力演进的逻辑链

LLM                  → 解决"理解与生成"：用自然语言处理复杂语言任务
  ↓ 局限：知识静止、私有盲区、幻觉
RAG                  → 解决"知识边界"：接入外部动态知识库，让模型"有据可查"
  ↓ 局限：只能生成文本，无法执行动作
Function Call        → 解决"执行边界"：让模型能驱动外部系统，从"说"到"做"
  ↓ 局限：只能单步响应，无法自主完成多步任务
AI Agent             → 解决"自主执行"：加入循环决策机制，让模型能自主规划和完成复杂目标
  ↓ 局限：工具能力固定在框架内，第三方无法扩展和复用
MCP                  → 解决"工具扩展"：标准化工具接入协议，任何人都可开发并插入新能力
  ↓ 局限：每次临时规划，流程不稳定，经验无法沉淀
Skill                → 解决"复用与标准化"：把最佳实践固化为工作流模板，稳定、可复用、可共享
  ↓ 局限：AI 系统是黑盒，质量不可量化、出错无从排查、改了不知好坏
Harness Engineering  → 解决"工程可靠性"：评估体系+护栏+可观测性，让 AI 系统可测、可信、可运维
  ↓ 局限：长时间 Agent 任务中，架构耦合导致崩溃即全失；单 Agent 自我评估存在天然偏差
Anthropic Harness    → 解决"长时间 Agent 架构弹性与质量"：Session/Harness/Sandbox 三层解耦保证崩溃可恢复，Planner-Generator-Evaluator 对抗循环消除自我评估偏差；Harness 随模型进化持续"减负"
  ↓ 局限：能力是静态的，系统从每次使用中学不到东西，使用一年和一天没有区别
Hermes Agent         → 解决"自主进化"：后台 review agent 自动积累 Skill、Cron 定期优化、SQLite 情节记忆，让 AI 从静态工具变成越用越强的"同事"

附：各技术实际首发年份