一、LLM 解決了什么問題

LLM 本質是一臺概率預測機器，通過在海量文本上訓練，涌現(xiàn)出了：

核心價值：把人類知識壓縮進參數，用自然語言對話即可調用——無需寫代碼、無需專業(yè)培訓。

二、LLM 解決不了什么問題

LLM 有六大根本局限：

這些局限共同導致了最核心的工程挑戰(zhàn)：幻覺——模型不知道自己不知道，會自信地編造"合理"的錯誤答案。

三、引入 RAG：解決"知識邊界"問題

RAG = Retrieval-Augmented Generation（檢索增強生成）

解決的問題：LLM 的知識是靜態(tài)的、有截止日期的、不含私有內容的。

工作方式：

[離線] 文檔 → 切片 → 向量化 → 存入向量數據庫

[在線] 用戶問題
          ↓ 向量檢索：從知識庫找最相關片段
          ↓ 組裝 Prompt："根據以下資料回答：[檢索內容] + [用戶問題]"
          ↓ LLM 基于真實文檔生成回答

RAG 帶來的四大收益：

1. 解決知識截止：內部文檔、最新資料可以隨時更新入庫
2. 減少幻覺：模型有參考資料時傾向于基于資料回答，而非自由發(fā)揮
3. 可追溯：回答可附上"來源：第X段"，用戶可驗證原文
4. 無需重新訓練：更新知識庫只需更新文檔，成本極低

RAG 的局限：檢索質量決定回答質量，難點在"切好文檔、檢索準"，而非 LLM 本身。

四、引入 Function Call：解決"執(zhí)行邊界"問題

根本限制：LLM 只能輸出文本，無法執(zhí)行代碼、讀寫文件、調用 API、控制外部系統(tǒng)。

Function Calling 的核心思想：

LLM 輸出的雖然只是文本，但可以是結構化的 JSON。外部程序解析這段 JSON 并真正執(zhí)行，再把結果反饋給模型——LLM 從未"執(zhí)行"任何東西，但等效于調用了外部功能。

完整流程：

用戶問題 + 工具列表描述
          ↓
     LLM 輸出調用指令（JSON）
          ↓
     外部代碼解析并真正執(zhí)行
          ↓
     執(zhí)行結果注入 Context
          ↓
     LLM 讀取結果 → 生成最終回答

Function Call 解鎖了什么：

• 查詢實時數據（告別幻覺）
• 讀寫文件、執(zhí)行命令（從"說"到"做"）
• 調用任意 API（連接整個互聯(lián)網和內部系統(tǒng)）
• 串聯(lián)多步工具調用（處理復雜任務）

五、引入 AI Agent：解決"自主執(zhí)行"問題

純 LLM 的模式：輸入 → 輸出，一問一答，被動響應，每次從零開始。

Agent 加了什么：在 LLM 之上加一個執(zhí)行循環(huán)（Agent Loop）：

用戶給出目標
      ↓
[循環(huán)執(zhí)行]
  思考：現(xiàn)在應該做什么？        ← LLM 決策
  行動：調用工具               ← 外部工具執(zhí)行
  觀察：工具返回了什么？        ← 結果注入 Context
  判斷：任務完成了嗎？→ 沒有 → 繼續(xù)循環(huán)
      ↓
目標達成，輸出結果

Agent = LLM 大腦 + Function Calling 協(xié)議 + 外部工具集合

Agent 解決的核心問題：把"對話"變成"行動"——用戶只需說出目標，Agent 自行拆解計劃、調用工具、處理錯誤、迭代完成，無需人工逐步介入。

六、引入 MCP：解決"工具能力擴展"問題

Function Call 的局限：工具能力是硬編碼在 Agent 框架內部的，第三方無法擴展，也無法跨平臺復用。

MCP（Model Context Protocol） 是 Anthropic 提出的開放標準協(xié)議，讓任何人都可以把工具能力封裝成獨立服務，Agent 通過統(tǒng)一協(xié)議接入——就像 USB 接口，插上即用。

與 Function Call 的關系：

Function Call（LLM 調用工具的協(xié)議）
         ↓ 調用的工具來自哪里？
  ┌──────────────────────────────────┐
  │ 內置 Tool（本地直接執(zhí)行）          │  ← 讀文件、執(zhí)行命令、搜索等
  │   Claude Code 主進程內部實現(xiàn)       │
  └──────────────────────────────────┘
  ┌──────────────────────────────────┐
  │ MCP Tool（外部進程/遠程服務執(zhí)行）   │  ← 支付、數據庫、第三方 API 等
  │   獨立進程或遠程 HTTP 服務提供      │
  └──────────────────────────────────┘

兩種部署方式：

MCP 解決的核心問題：

1. 能力無法擴展：內置工具是固定的，MCP 讓第三方可以自由開發(fā)并插入新能力
2. 跨平臺復用：一個 MCP Server 可以被任意 Agent 框架接入，不綁定特定系統(tǒng)
3. 領域隔離：專業(yè)領域（錢包、數據庫、監(jiān)控）獨立成服務，主 Agent 不需要關心實現(xiàn)細節(jié)
4. 狀態(tài)管理：獨立進程可以維護自己的連接池、緩存、認證狀態(tài)，不污染 Agent 主進程

一句話區(qū)分：

Function Call 是 LLM "說我要調用什么"的語言；MCP 是工具能力"住在哪里、怎么被找到"的標準。兩者配合，讓 Agent 的工具集從固定變成無限可擴展。

七、引入 Skill：解決"復用與標準化"問題

Agent 有了工具，但新問題出現(xiàn)了：同一類任務（如 Git 提交、發(fā)送轉賬、跑測試）每次都要靠 LLM 臨時規(guī)劃步驟，流程不穩(wěn)定、容易遺漏、無法沉淀經驗。

Skill（技能）是什么：用戶/團隊預先定義的高級工作流模板，把多個 Tool 調用的固定順序和規(guī)則封裝成一個命名單元，Agent 直接調用即可。

沒有 Skill（純 Agent）：
  用戶: "幫我提交代碼"
  LLM 臨時推理 → 可能忘記 git diff → 可能格式不規(guī)范 → 每次結果不同

有 Skill：
  用戶: "/commit"
  → 加載預定義的 commit 工作流
  → 步驟固定: git status → git diff → git log → 生成規(guī)范 message → add → commit → 驗證
  → 結果穩(wěn)定、流程可控

Skill 解決的核心問題：

Skill 的結構：

Skill = {
  name:         "/commit"               ← 觸發(fā)名稱
  description:  "創(chuàng)建規(guī)范的 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 / 外部系統(tǒng) ← 真正執(zhí)行

Skill vs 直接用 Agent 的區(qū)別：

八、引入 Harness Engineering：解決"工程可靠性"問題

Skill 解決了流程標準化，但新問題出現(xiàn)了：即使有了 Skill，AI 系統(tǒng)在生產環(huán)境中仍然是一個"黑盒"——不知道質量如何、不知道何時出錯、改了 Prompt 不知道效果好壞、出了故障不知道從哪排查。

Harness Engineering 的核心思想：

給 AI 系統(tǒng)套上一整套控制、測試、管理基礎設施，讓原本不可預測的模型行為變得可評估、可觀測、可信賴。

"Harness" 原意是馬具——套在馬身上控制方向和力量的裝置。在 AI 工程中，它是讓 AI 這匹"野馬"可以在生產環(huán)境中安全奔跑的工程體系。

Harness Engineering 解決的核心問題：

Harness Engineering 的四層架構：

沒有 Harness 的 AI：
  輸入 → [黑盒模型] → 輸出
  問題：不知道為什么出錯，無法系統(tǒng)測試，無法評估好壞

有 Harness 的 AI：
  輸入
    ↓
  [評估層 Evaluation]      ← 持續(xù)測量質量：Eval Suite / Benchmark / LLM-as-Judge
    ↓
  [執(zhí)行層 Runtime]         ← 安全可靠運行：Guardrails / Prompt 管理 / 輸出驗證 / 降級策略
    ↓
  [可觀測層 Observability]  ← 全鏈路透明：Tracing / Token 成本監(jiān)控 / 異常告警
    ↓
  [測試層 CI/CD]           ← 持續(xù)驗證：PR 觸發(fā) Eval / 回歸測試 / 安全掃描
    ↓
  輸出

三類核心實踐：

① 評估體系（Evaluation）——把"感覺"變成"數字"

沒有評估：改 Prompt → 手測幾個例子 → "感覺好多了" → 上線（不知道哪里變差了）
有評估：  改 Prompt → 跑 500 個測試用例 → 準確率 82%→91%
                    → 發(fā)現(xiàn)"否定問句"類別退步了 3% → 針對性優(yōu)化

• 自動化 Eval：有標準答案的任務直接對比；復雜任務用 LLM-as-Judge（用強模型評判弱模型）
• Pairwise 對比：不打絕對分，讓評估者判斷"A 和 B 哪個更好"——更符合人類直覺
• 回歸測試集：包含核心場景、邊界情況、對抗樣本、歷史 Bug 案例

② 護欄系統(tǒng)（Guardrails）——在模型兩側建立安全過濾層

用戶輸入 → [輸入護欄: PII檢測 / Prompt注入防護 / 有害內容過濾]
                ↓
          [模型調用]
                ↓
         [輸出護欄: 事實一致性 / 格式驗證 / 敏感信息脫敏 / 品牌安全]
                ↓
          最終輸出

③ 可觀測性（Observability）——AI 系統(tǒng)的專屬監(jiān)控維度

傳統(tǒng)服務監(jiān)控：延遲 / 錯誤率 / 吞吐量
LLM 額外需要：
  ├── Token 消耗（輸入/輸出分別統(tǒng)計，直接對應成本）
  ├── Prompt 版本（v2.3 和 v2.4 哪個效果更好）
  ├── 完整 Prompt + Response 記錄（調試 AI 問題必需）
  ├── 幻覺檢測率（事實錯誤頻率）
  └── 模型降級次數（主模型不可用時的備用觸發(fā)頻率）

與前序技術的關系：

Agent + Skill  →  構建了"能做事"的 AI 系統(tǒng)
Harness Engineering  →  讓這個系統(tǒng)"做得好、做得穩(wěn)、做得透明"

沒有 Harness 的 Agent：能完成任務，但質量未知、失敗時無法排查
有  Harness 的 Agent：完成任務 + 質量可量化 + 異常可告警 + 失敗可追溯 + 成本可控

主流工具生態(tài)：

九、引入 Anthropic Harness：解決"長時間 Agent 架構彈性與質量"問題

通用 Harness Engineering 提供了評估、護欄、可觀測性等工程實踐，但當 AI Agent 需要運行數小時、執(zhí)行數百個工具調用時，新的矛盾浮現(xiàn)：架構耦合導致任何一處崩潰都全功盡棄；Agent 評估自己產出時存在天然的利益沖突偏差，質量上不去。

Anthropic Harness 的核心洞察：

"Harness 是對模型能力不信任的具象化。隨著信任的建立，Harness 應該變薄，而不是變厚。"

Anthropic 在 2025–2026 年設計 Managed Agents 時，從操作系統(tǒng)設計中借鑒了虛擬化思想，形成了三大設計哲學：

哲學一：為"尚未被構想的程序"設計

操作系統(tǒng)的偉大之處在于：磁盤從機械換成 SSD，應用程序調用的 read() 接口從未改變。Anthropic 用同樣思路設計了三個永不改變的穩(wěn)定接口，讓底層實現(xiàn)隨模型能力自由演化：

底層實現(xiàn)（隨模型進化頻繁變化）
  ├── 上下文管理策略（今天滑動窗口，明天百萬 token 根本不需要管理）
  ├── 沙箱技術（今天 Docker，明天 WebAssembly）
  └── 錯誤重試邏輯（模型越強，工具調用越穩(wěn)，兜底邏輯越不需要）
        ↓  虛擬化為三個穩(wěn)定接口
  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 個，性能不降，成本和延遲顯著下降。

哲學三：大腦、雙手、記憶徹底解耦

根基原則：狀態(tài)（發(fā)生了什么）和行為（接下來做什么）不應該住在同一個進程里。

傳統(tǒng)耦合架構（單容器）：
  [LLM 調用 + 工具執(zhí)行 + 上下文管理 + 憑證存儲] = 一個脆弱整體
  任何部分崩潰 → 狀態(tài)全部丟失 → 任務從頭開始

解耦架構（三層分離）：
  ┌─────────────────────────────────────────────────────────────┐
  │ Session（記憶層）：追加式事件日志，獨立持久化，存活于 Harness 之外  │
  │   Harness 崩潰 → Session 完好；新實例 wake(sessionId) 接管繼續(xù)  │
  ├─────────────────────────────────────────────────────────────┤
  │ Harness（控制層）：完全無狀態(tài)，讀 Session + 路由工具調用           │
  │   崩潰即換，橫向擴展 = 多啟幾個無狀態(tài)實例（"牛群"，不是"寵物"）   │
  ├─────────────────────────────────────────────────────────────┤
  │ Sandbox（執(zhí)行層）：隔離容器，懶加載（按需創(chuàng)建），憑證永不進入       │
  │   容器崩潰 = 單次工具調用報錯，Claude 決定重試；TTFT ↓60%        │
  └─────────────────────────────────────────────────────────────┘

核心安全設計：憑證從不進入 Sandbox——Git Token 僅用于初始化克隆后即丟棄；API Key 存于 Vault，通過專用代理注入，即使 Sandbox 被完全攻陷，憑證依然安全。

三智能體架構：Planner-Generator-Evaluator

對于長時間復雜任務，Anthropic 借鑒 GAN（生成對抗網絡） 哲學，用獨立上下文消除 Agent 的自我評估偏差：

GAN 的洞察：生成器與判別器參數獨立 → 無法共謀 → 對抗性壓力驅動質量提升
Agent 的轉化：Generator 與 Evaluator 上下文獨立 → 無法共謀 → 對抗性質量提升

Planner（規(guī)劃者）
  一句話目標 → 功能列表 → Sprint 計劃
  輸出持久化 Plan Document（全局狀態(tài)錨點，供所有 Agent 讀取）
        ↓
    主循環(huán)（5-15 次迭代）
        ↓
  Generator（生成者）             Evaluator（評估者）
  └ 執(zhí)行具體工作                   └ 完全獨立上下文（不參與生成）
  └ 上下文定期重置（非壓縮）  ──→   └ 強制懷疑論角色（System Prompt 注入）
    └ 防止上下文漂移                └ 評分維度量化（每項 1-10 分）
    └ 從 Plan Doc 重新加載目標      └ 真實瀏覽器測試（Playwright MCP）
        ↑────── 具體改進建議 ────────┘

實測數據（同一任務：構建 2D 復古游戲制作工具）：

Managed Agents 平臺（2026年4月正式發(fā)布）：
將上述三哲學封裝為云服務（$0.08/session hour），開發(fā)者無需自建 Sandbox 基礎設施和狀態(tài)管理，直接運行多小時 Agent 任務。已落地：Notion（工作區(qū)任務委托）、Sentry（自動 Bug 修復）、Rakuten（Slack 企業(yè) Agent）。

與前序技術的關系：

第八章 Harness Engineering  →  通用工程實踐：評估體系 + 護欄 + 可觀測性，解決 AI 系統(tǒng)可測性
  ↓ 局限：長時間運行任務中，架構耦合導致崩潰即全失；單 Agent 自我評估存在天然偏差
第九章 Anthropic Harness   →  專攻長時間 Agent 的兩個核心難題：
                               ① 架構解耦：Session/Harness/Sandbox 三層分離，崩潰不丟狀態(tài)
                               ② 質量保障：Generator-Evaluator 對抗循環(huán)，消除自我評估偏差
                               ③ 動態(tài)演進：Harness 隨模型進化持續(xù)"減負"，不讓舊假設成枷鎖

十、引入 Hermes Agent：解決"自主進化"問題

Harness Engineering 讓 AI 系統(tǒng)變得可測、可信、可運維，但仍有一個根本局限：AI 系統(tǒng)的能力是靜態(tài)的——Prompt 是人工編寫的，Skills 是人工維護的，系統(tǒng)從每次使用中學不到任何東西。使用一年和使用一天，能力沒有差別。

Hermes Agent 的核心思想：

AI 智能體應該像人類一樣，從每次經歷中學習并積累技能，而不是每次對話都從零開始。

"Hermes" 是希臘神話中信使之神，象征信息的傳遞與積累——在 AI 工程中，它是讓 Agent 把每次經驗轉化為可復用知識的自進化框架（Nous Research 出品，2026 年 4 月發(fā)布 v0.9.0，前身為 OpenClaw）。

Hermes Agent 解決的核心問題：

三層記憶架構：

程序性記憶（Skill）     ← 解決問題的"方法論"沉淀
  ~/.hermes/skills/SKILL.md
  結構：YAML frontmatter（名稱/版本/平臺/依賴）+ Markdown 步驟 + 已知陷阱
  來源：后臺自動創(chuàng)建 / 主 Agent 主動調用 / 社區(qū)共享（agentskills.io）

情節(jié)性記憶（SQLite）   ← 經歷過"哪些事"的記錄
  SQLite + FTS5 全文檢索，輕量替代向量數據庫，無額外依賴
  檢索時：FTS5 找相關段落 → LLM 壓縮摘要 → 注入當前 prompt

工作記憶（Context）    ← 當前對話的臨時狀態(tài)
  達到 token 閾值時自動壓縮歷史（用 LLM 生成摘要保留關鍵信息）
  利用 Anthropic prefix caching，可節(jié)省最高 75% 輸入 token 費用

核心自進化機制：后臺 Skill 審查：

[計數器機制]
每次 LLM API 調用，_iters_since_skill 計數器 +1
達到閾值（默認 10 次）→ 設置 review 標志

[執(zhí)行時機：不阻塞主對話]
用戶消息 → LLM 執(zhí)行 N 次工具調用 → 生成最終 response → 發(fā)送給用戶 ?
                                                              ↓
                                          [后臺靜默] spawn review thread
                                          用戶完全感知不到

[后臺 review agent]
fork 一個全新的 AIAgent 實例
  - max_iterations=8（有上限，防止失控）
  - quiet_mode=True（完全靜默，輸出不可見）
  - _skill_nudge_interval=0（禁止遞歸觸發(fā) review）
  注入完整對話歷史快照（深拷貝，不修改主對話）
  調用 skills_list() 獲取現(xiàn)有技能列表
  LLM 語義判斷：新建 / 更新 / "Nothing to save."

LLM 判斷是否值得創(chuàng)建 Skill 的標準（非硬編碼，完全由模型語義決策）：

Skill 漸進式加載（三級，節(jié)省 Token）：

Level 0（總是加載）：技能名稱 + 描述列表（約 3,000 tokens）
                    幫助 LLM 知道"有哪些技能可用"

Level 1（按需加載）：完整技能內容（步驟 + 陷阱 + 示例）
                    當 LLM 判斷當前任務需要該 Skill 時才加載

Level 2（按需加載）：技能引用的外部文檔
                    當 Skill 內容引用額外資料時才加載

自進化閉環(huán)：

用戶完成復雜任務（≥10 次工具調用迭代）
        ↓
[后臺 review agent] 分析完整對話歷史
        ↓
  ┌─────────────┴─────────────┐
  ▼                           ▼
值得保存                   不值得保存
  ↓                           ↓
新建 SKILL.md             "Nothing to save."
或更新已有 Skill             靜默退出
  ↓
下次同類任務：直接復用（更快、更準）
  ↓
Cron 定期觸發(fā)：復習使用記錄 → 發(fā)現(xiàn)缺漏 → patch Skill
  ↓
越用越強的復合收益 ?

與前序技術的關系：

第七章 Skill               →  人工預定義工作流模板，靠開發(fā)者手動維護
第八章 Harness Engineering  →  讓 AI 系統(tǒng)可測、可觀測，但仍是靜態(tài)系統(tǒng)
第九章 Hermes Agent         →  在 Skill + Harness 基礎上加入自主學習閉環(huán)
                                Skill 從"人工編寫"變成"自動積累 + 持續(xù)優(yōu)化"

傳統(tǒng) AI Agent 是"工具"——你告訴它做什么，它做完就忘。
Hermes Agent 是"同事"——它記得你們一起解決過什么，
                         并且會在你睡覺的時候自己復習。

總結：能力演進的邏輯鏈

LLM                  → 解決"理解與生成"：用自然語言處理復雜語言任務
  ↓ 局限：知識靜止、私有盲區(qū)、幻覺
RAG                  → 解決"知識邊界"：接入外部動態(tài)知識庫，讓模型"有據可查"
  ↓ 局限：只能生成文本，無法執(zhí)行動作
Function Call        → 解決"執(zhí)行邊界"：讓模型能驅動外部系統(tǒng)，從"說"到"做"
  ↓ 局限：只能單步響應，無法自主完成多步任務
AI Agent             → 解決"自主執(zhí)行"：加入循環(huán)決策機制，讓模型能自主規(guī)劃和完成復雜目標
  ↓ 局限：工具能力固定在框架內，第三方無法擴展和復用
MCP                  → 解決"工具擴展"：標準化工具接入協(xié)議，任何人都可開發(fā)并插入新能力
  ↓ 局限：每次臨時規(guī)劃，流程不穩(wěn)定，經驗無法沉淀
Skill                → 解決"復用與標準化"：把最佳實踐固化為工作流模板，穩(wěn)定、可復用、可共享
  ↓ 局限：AI 系統(tǒng)是黑盒，質量不可量化、出錯無從排查、改了不知好壞
Harness Engineering  → 解決"工程可靠性"：評估體系+護欄+可觀測性，讓 AI 系統(tǒng)可測、可信、可運維
  ↓ 局限：長時間 Agent 任務中，架構耦合導致崩潰即全失；單 Agent 自我評估存在天然偏差
Anthropic Harness    → 解決"長時間 Agent 架構彈性與質量"：Session/Harness/Sandbox 三層解耦保證崩潰可恢復，Planner-Generator-Evaluator 對抗循環(huán)消除自我評估偏差；Harness 隨模型進化持續(xù)"減負"
  ↓ 局限：能力是靜態(tài)的，系統(tǒng)從每次使用中學不到東西，使用一年和一天沒有區(qū)別
Hermes Agent         → 解決"自主進化"：后臺 review agent 自動積累 Skill、Cron 定期優(yōu)化、SQLite 情節(jié)記憶，讓 AI 從靜態(tài)工具變成越用越強的"同事"

附：各技術實際首發(fā)年份