Harness 和 Agent：AI 系统的分層架構
探索工具層和 Agent 層的關係，以及 MCPlato 如何實現 MCP 原生架構
發布於 2026-03-19
Harness 和 Agent：AI 系統的分層架構
從 MCP 協議到 MCPlato 的工具層和 Agent 層設計
1. 引言：AI 系統的架構覺醒
從模型至上到架構至上
過去三年，AI 行業沉迷於一個單一指標：模型能力。基準分數、參數數量和上下文窗口大小主導了技術討論。隱含的假設很清楚——模型越好，系統越好。
但 2024 年發生了變化。
當大語言模型（LLM）跨過了對大多數實際任務「足夠好」的閾值時，從業者發現了一個令人清醒的真相：AI 系統的瓶頸很少是模型本身。工具集成設計糟糕的 GPT-4 級模型表現不如工具層設計良好的 GPT-3.5 級模型。競爭的焦點已從原始智能轉向架構優雅。
為什麼 Harness 層比模型更重要
考慮這個場景：你擁有世界上最強大的 AI 模型。它可以推理複雜問題、編寫複雜代碼、理解微妙的指令。但當它嘗試與現實世界交互——讀取文件、調用 API、瀏覽網站——時，它通過設計糟糕、格式不一致、實現不安全的工具來完成這些操作。
結果是什麼？沮喪、錯誤，最終無法交付價值。
Harness 層（也稱為工具層）代表了使 AI 與外部世界交互的一切：工具定義、執行環境、安全策略、錯誤處理、結果格式化和記憶體管理。這是被困在房間裡的天才與擁有能力改變世界的天才之間的區別。
核心挑戰：安全可靠的工具使用
現代 AI 架構面臨的基本問題看似簡單：我們如何讓 Agent 安全、可靠、有效地使用工具？
這個問題涵蓋：
- 安全性：我們如何防止未授權的文件訪問、數據洩露或惡意代碼執行？
- 可靠性：我們如何確保工具行為一致、優雅地處理錯誤、從故障中恢復？
- 組合性：我們如何讓 Agent 組合多個工具來完成複雜任務？
- 可發現性：Agent 如何知道哪些工具可用以及何時使用它們？
回答這些問題需要刻意的架構方法——一種分離關注點、建立清晰接口、優先考慮健壯性而非便利性的方法。
2. 分層架構：Harness 和 Agent 的理論模型
為了應對這些挑戰，我們提出在兩個不同的架構層之間進行清晰的關注點分離：Harness 層和 Agent 層。這種分離不僅僅是組織上的——它反映了根本不同的責任、故障模式和優化目標。
2.1 Harness 層（工具層）
Harness 層作為 AI 推理和外部世界之間的接口。其責任是具體的、操作性的，主要關注執行而非決策。
核心責任
| 責任 | 描述 |
|---|---|
| 工具封裝 | 將外部能力（文件系統、API、數據庫、瀏覽器）包裝成定義良好的、可調用的接口 |
| 執行編排 | 管理工具調用的生命週期：驗證、執行、超時處理和清理 |
| 驗證和保護 | 執行安全策略、沙箱不受信任的操作、防止未授權訪問 |
| 記憶體管理 | 處理狀態持久化、會話存儲、工具調用之間的上下文共享 |
| 結果格式化 | 將原始工具輸出轉換為適合模型使用的結構化格式 |
關鍵洞察：Harness 處理「其他一切」
Harness 層的定義特徵是它處理純模型推理之外的一切。當模型生成計劃以「分析銷售數據 CSV 並生成摘要報告」時，Harness 層：
- 定位並讀取 CSV 文件
- 驗證文件權限和格式
- 執行分析（可能調用代碼）
- 處理任何錯誤或邊界情況
- 為模型使用格式化結果
- 管理臨時資源和清理
模型關注應該做什麼；Harness 確保它能安全可靠地完成。
2.2 Agent 層（代理層）
如果 Harness 層是關於執行，Agent 層就是關於決策制定。它在更高的抽象層次上運作，關注目標、計劃和策略，而不是具體的工具調用。
核心責任
| 責任 | 描述 |
|---|---|
| 任務規劃 | 將高級目標分解為可執行的子任務，確定執行順序 |
| 工具選擇 | 為給定的子任務選擇適當的工具（如果有） |
| 推理和決策制定 | 評估中間結果、根據反饋調整計劃、處理歧義 |
| 上下文管理 | 維護相關的對話歷史、過濾噪音、優先考慮重要信息 |
| 用戶交互 | 確定何時要求澄清、提供中間結果或請求批准 |
關鍵洞察：Agent 通過抽象操作
Agent 層不直接操縱文件或執行代碼。相反，它在工具的抽象上運作——理解它們的能力、限制和適當用途。當 Agent 決定「搜索相關文檔」時，它將實際搜索操作委託給 Harness 層，相信 Harness 將處理查詢公式化、API 調用和結果檢索的具體細節。
2.3 交互模型：文本流圖
Agent 和 Harness 之間的關係遵循請求-響應模式，具有清晰的邊界：
┌─────────────────────────────────────────────────────────────────────┐
│ 交互流程 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ 工具發現 ┌──────────────────────┐ │
│ │ │ ─────────────────> │ │ │
│ │ AGENT │ │ HARNESS │ │
│ │ 層 │ │ 層 │ │
│ │ │ <───────────────── │ │ │
│ │ │ 工具清單 │ │ │
│ └──────┬───────┘ └──────────────────────┘ │
│ │ │
│ │ 1. Agent 分析任務並選擇合適的工具 │
│ │ 2. Agent 用參數制定調用請求 │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 調用請求 │ │
│ │ { │ │
│ │ "tool": "file_read", │ │
│ │ "params": { "path": "/data/sales.csv" }, │ │
│ │ "context": { "session_id": "abc123" } │ │
│ │ } │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ HARNESS 處理 │ │
│ │ │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ 驗證 │ ─>│ 執行 │ ─>│ 格式化 │ │ │
│ │ │ 請求 │ │ 工具 │ │ 結果 │ │ │
│ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 響應消息 │ │
│ │ { │ │
│ │ "status": "success", │ │
│ │ "result": { "content": "...", "metadata": {...} }, │ │
│ │ "elapsed_ms": 150 │ │
│ │ } │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ AGENT │ ← Agent 整合結果，繼續推理 │
│ └──────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘
2.4 分離的好處
這種分層架構提供了幾個關鍵優勢：
1. 獨立演進 Harness 層可以擴展新工具而不修改 Agent 層。當新 API 可用時，只需更改工具實現——Agent 在工具清單中看到新能力。
2. 可重現性和測試 Harness 操作是確定性和可測試的。你可以驗證文件讀取操作正確工作，獨立於 Agent 決定讀取該文件。這種分離在兩層都啟用單元測試。
3. 安全邊界 安全策略在 Harness 層執行，創建 Agent 無法繞過的硬邊界。即使 Agent 被破壞或誤導，它也在 Harness 沙箱的約束內運作。
4. 多 Agent 支持 多個 Agent 可以共享相同的 Harness 層，每個都從一致的工具行為和安全策略中受益。這啟用了協作場景，其中不同的 Agent 處理複雜任務的不同方面。
3. MCP 協議：AI 的 USB-C 接口
2024 年 11 月，Anthropic 發布了Model Context Protocol（MCP），一個開放標準，承諾為 AI 工具集成做 USB-C 為設備連接所做的事情：提供單一、通用的接口，消除分割並啟用真正的互操作性。
3.1 MCP 解決的問題
在 MCP 之前，將新數據源或工具集成到 AI 應用中通常需要構建自定義連接器。想讓你的 AI 查詢 Postgres 數據庫？編寫連接器。想讓它訪問你公司的 CRM？編寫另一個連接器。每個集成都是定制的、脆弱的，與特定 AI 平台綁定。
MCP 通過定義 AI 應用如何連接到外部系統的標準協議來消除這種集成成本。MCP 不是 N×M 集成（N 個工具 × M 個 AI 平台），而是 N+M 集成（每個工具實現 MCP 一次，每個平台支持 MCP 一次）。
3.2 MCP 架構：三個核心角色
MCP 定義了三個對應於工具生態中不同責任的架構角色：
┌─────────────────────────────────────────────────────────────────────┐
│ MCP 架構 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌────────────┐ │
│ │ │ │ │ │ │ │
│ │ HOST │◄───────►│ CLIENT │◄───────►│ SERVER │ │
│ │ │ │ │ │ │ │
│ │ AI 應用 │ │ 連接 │ │ 工具/數據 │ │
│ │ (MCPlato, │ │ 管理 │ │ 提供者 │ │
│ │ Claude, │ │ │ │ │ │
│ │ Cursor) │ │ • 協議 │ │ • 工具 │ │
│ │ │ │ 處理 │ │ • 資源 │ │
│ │ 編排 │ │ • 能力 │ │ • 提示 │ │
│ │ 交互 │ │ 發現 │ │ │ │
│ │ │ │ • 狀態管理 │ │ │ │
│ └──────────────┘ └──────────────┘ └────────────┘ │
│ │
│ 責任： │
│ • HOST：UX、編排、生命週期管理 │
│ • CLIENT：協議合規、能力協商 │
│ • SERVER：工具實現、數據訪問、執行 │
│ │
└─────────────────────────────────────────────────────────────────────┘
| 角色 | 描述 | 例子 |
|---|---|---|
| Host | 用戶交互的 AI 應用；管理連接和編排交互 | MCPlato、Claude Desktop、Cursor |
| Client | 管理與特定 MCP 服務器的連接；處理協議合規和能力發現 | Host 內置的 MCP 客戶端 |
| Server | 通過 MCP 協議提供特定能力（工具、資源、提示） | 文件系統服務器、GitHub 服務器、Postgres 服務器 |
3.3 MCP 核心原語
MCP 定義了服務器可以提供的三個基本原語：
Tools（可執行函數） Tools 是執行操作的函數——讀取文件、查詢數據庫、發送消息或執行代碼。它們接受結構化參數並返回結構化結果。Tools 由 AI 基於上下文和需要顯式調用。
{
"name": "file_read",
"description": "讀取文件內容",
"inputSchema": {
"type": "object",
"properties": {
"path": { "type": "string", "description": "文件路徑" }
},
"required": ["path"]
}
}
Resources（數據源） Resources 代表 AI 可以參考的數據——文件內容、數據庫架構、API 文檔或配置文件。與工具不同，資源通常是只讀的，充當上下文而不是操作。
Prompts（交互模板） Prompts 提供預定義的交互模式或模板，指導 AI 在特定任務中的行為。它們可以包括系統指令、示例交互或結構化請求格式。
3.4 MCP 為什麼對架構重要
MCP 不僅僅是便利——它代表了我們如何思考 AI 工具集成的根本轉變：
標準化啟用競爭 當工具實現通用標準時，競爭從「誰有最多集成」轉向「誰提供那些集成的最佳體驗」。這對用戶有益，並推動工具質量和 AI 能力方面的創新。
解耦啟用專業化 通過 MCP，工具開發者可以專注於構建偉大的工具，而不用擔心 AI 平台兼容性。AI 平台可以專注於編排和推理，而無需維護無數自定義連接器。
組合性啟用生態系統 MCP 創建網絡效應：每個新 MCP 服務器使所有 MCP 兼容的 Host 受益，每個新 MCP Host 為所有現有服務器創建價值。這個飛輪效應加快了生態系統增長。
4. MCPlato 的架構實踐
MCPlato 代表了 Harness-Agent 分層架構的具體實現，以 MCP 為基礎原則而不是事後考慮。其設計反映了從學術研究和 AI 系統實際部署中學到的經驗。
4.1 三層架構模型
MCPlato 的架構圍繞三個不同的層組織，每個都有清晰的責任和邊界：
┌─────────────────────────────────────────────────────────────────────┐
│ MCPLATO 架構 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 工作區層 │ │
│ │ │ │
│ │ • 工作區管理和隔離 │ │
│ │ • 多目錄掛載 │ │
│ │ • 跨會話記憶體（日記） │ │
│ │ • 環境配置 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ ▲ │
│ │ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ SESSION 層 │ │
│ │ │ │
│ │ • 上下文維護和消息歷史 │ │
│ │ • 消息路由和分發 │ │
│ │ • Session 級別狀態管理 │ │
│ │ • 多 Session 協調 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ ▲ │
│ │ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ AGENT 層 │ │
│ │ │ │
│ │ • ClawMode 自主執行 │ │
│ │ • 任務規劃和分解 │ │
│ │ • 工具選擇和調用 │ │
│ │ • 多步推理和恢復 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ HARNESS 層 │ │
│ │ │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌────────┐ │ │
│ │ │ @Tool │ │ 信息圖表 │ │ 瀏覽器 │ │ PDF │ │ │
│ │ │ 套件 │ │ Creator │ │ Automation │ │ Tools │ │ │
│ │ └─────────────┘ └─────────────┘ └─────────────┘ └────────┘ │ │
│ │ │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌────────────────────────┐ │ │
│ │ │ MCP │ │ 圖像生成 │ │ 文檔分析 │ │ │
│ │ │ Host │ │ 和編輯 │ │ (OCR/理解) │ │ │
│ │ └─────────────┘ └─────────────┘ └────────────────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘
工作區層
工作區層提供組織邊界和跨越各個會話的持久存儲。它是 MCPlato 層次結構中最高的抽象級別。
關鍵能力：
- 隔離：每個工作區維護單獨的配置、掛載目錄和環境變量
- 多目錄掛載：工作區可以包含多個項目目錄，啟用跨項目工作流
- 持久化記憶體：日記系統在會話間維護長期記憶體，保存見解和決策
- 環境管理：MCP 服務器、自定義工具和行為設置的工作區級配置
Session 層
Session 層管理即時交互上下文——與特定對話或任務相關聯的消息、狀態和短暫數據。
關鍵能力：
- 上下文維護：Session 內的消息歷史、工具結果和中間狀態
- 消息路由：將用戶輸入分發給適當的處理程序，並將輸出路由回去
- 並行執行：支持單個工作區內的多個並發會話
- 狀態持久化：為長期運行的任務保存和恢復 Session 狀態的能力
Agent 層
Agent 層實現了系統的推理和決策能力，體現在 MCPlato 的 ClawMode 自主執行引擎中。
關鍵能力：
- 自主執行：ClawMode 使 Agent 能夠獨立工作，在沒有持續用戶輸入的情況下做出決策
- 任務規劃：將複雜目標分解為可執行步驟，具有依賴管理
- 多 Session 協調：為並行或順序執行跨多個 Session 編排工作
- 自我改進：從執行模式學習和優化未來行為的能力
4.2 Harness 集成特徵
MCPlato 的 Harness 層以幾個關鍵設計決策為特徵：
MCP 原生支持
與其他將 MCP 支持作為插件或擴展添加的系統不同，MCPlato 將 MCP 實現為核心架構原則：
- 內置 MCP Host：支持 stdio 和 HTTP 傳輸的完整 MCP Host 實現
- 動態服務器管理：運行時添加、刪除和配置 MCP 服務器
- 能力發現：可用工具、資源和提示的自動檢測和公開
- 熱加載：無需重啟應用即可添加新 MCP 服務器
內置工具套件
除了 MCP，MCPlato 提供為生產力工作流設計的完整工具集：
| 工具類別 | 能力 |
|---|---|
| @Tool 套件 | 文件操作、bash 執行、代碼編輯、網路搜尋 |
| 信息圖表 Creator | 數據可視化、圖表生成、圖表創建 |
| 瀏覽器自動化 | 網路導航、表單填充、截圖、元素交互 |
| 圖像工具 | 生成（多個模型）、編輯（內畫/外畫）、合成、風格轉移 |
| 文檔工具 | PDF 分析、OCR、結構化提取、格式轉換 |
內置套件中的每個工具都遵循與 MCP 工具相同的接口標準，確保無論使用原生能力還是外部服務器，行為都一致。
動態工具發現
Harness 層實現了複雜的工具發現機制：
- 運行時內省：工具動態聲告其能力、參數和要求
- 語義匹配：Agent 可以基於自然語言需求描述發現工具
- 版本管理：支持相同工具的多個版本，具有優雅的棄用
- 依賴解決：自動處理工具依賴和先決條件檢查
4.3 Agent 能力
MCPlato 的 Agent 層（ClawMode）實現了幾個高級能力，將其與更簡單的聊天界面區分開：
任務規劃和分解
當面對複雜目標時，Agent：
- 分析目標以識別所需的步驟和依賴關係
- 為每個步驟選擇適當的工具
- 建立成功標準和檢查點
- 創建可恢復的執行計劃，可以在中斷後存活
多 Session 協調
Agent 可以跨多個會話編排工作：
- 並行執行：在單獨的會話中運行獨立的子任務
- 順序管道：鏈接會話，其中一個的輸出成為另一個的輸入
- 跨 Session 記憶體：在會話之間共享相關上下文，同時維護隔離
長期運行任務支持
MCPlato 支持超越單個交互的任務：
- 計劃執行：基於 Cron 和週期性任務調度
- 檢查點和恢復：在任務邊界處保存狀態以供恢復
- 進度報告：長期運行操作的實時更新
- 人類在迴圈中：需要人類判斷的決策的適當升級點
5. 競爭架構比較
為了理解 MCPlato 的架構選擇，將它們與 AI Agent 景觀中的其他系統進行比較很有用。下表總結了關鍵的架構差異：
| 產品 | Harness 設計 | Agent 設計 | 架構特徵 |
|---|---|---|---|
| Claude Code | 內置工具 + MCP 支持 | 單個 Agent，長期運行的會話 | Agent-Harness 集成的先驅；以終端為中心；CLAUDE.md 用於記憶體 |
| Cursor | MCP 生態系統 + 內置編輯器工具 | Agent 2.0 具有自主能力 | Agent 優先的 IDE；用於多文件更改的 Composer；並行 Agent 執行（最多 8 個） |
| OpenClaw | 工具沙箱 + Skills 框架 | 分層多 Agent 設計 | 開源框架；多渠道訪問的網關層；自託管 |
| Devin | 雲集成工具套件 | 端到端工程 Agent | Agent 原生 IDE；完整雲沙箱；SWE-bench 優化 |
| MCPlato | 內置工具 + MCP 原生 Host | ClawMode 自主執行 | 三層解耦架構；本地優先；完整工具鏈 |
5.1 設計選擇分析
Claude Code 強調簡潔性和與現有開發者工作流的集成。其 Harness 精簡，專注於基本的文件和終端操作。Agent 層維護一個單一的長期運行會話，簡化上下文管理，但限制並行化。
Cursor 強調 IDE 上下文中的開發者生產力。其 Harness 利用編輯器現有的能力，同時添加 MCP 支持以實現可擴展性。Agent 2.0 架構在代碼編輯的有界上下文內引入自主性。
OpenClaw（MCPlato 的開源基礎）通過其網關-Agent-Tools 層次結構提供最大靈活性。作為框架而不是產品，它優先考慮可配置性而非開箱即用的體驗。
Devin 代表雲原生極端：整個環境是虛擬化和託管的。這啟用了強大的能力，但需要向雲基礎設施獻出控制權。
MCPlato 佔據獨特的位置：它結合了 OpenClaw 的靈活性與產品級的精良，添加了本地優先原則，並實現了一個清晰分離關注點的三層架構。
5.2 關鍵區別
| 維度 | MCPlato 優勢 |
|---|---|
| 架構深度 | 三層設計（工作區-Session-Agent）vs 兩層或平面設計 |
| MCP 集成 | 原生 Host 實現 vs 附加支持 |
| 本地優先 | 完整本地工具鏈 vs 雲依賴或沙箱限制 |
| 工具完整性 | 內置圖像、文檔、信息圖表和瀏覽器工具，超越基本文件操作 |
| 記憶體架構 | 三層持久化（工作區/Session/日記）vs 單上下文或手動記憶體文件 |
| 調度 | 原生基於 cron 的調度 vs 外部調度器依賴或無支持 |
6. 架構設計原則和最佳實踐
基於 MCPlato 和可比系統的分析，我們可以提煉用於設計有效 Harness-Agent 架構的幾個原則：
6.1 原則 1：分層解耦
Harness 和 Agent 層應該有清晰、穩定的接口。
- 定義層之間的顯式合約（如 MCP 的協議提供這些）
- 避免跨層邊界洩露實現細節
- 啟用每層的獨立測試、部署和演進
- 抵制「便利」的誘惑，模糊層責任
6.2 原則 2：標準優先
在構建自定義解決方案之前採用開放標準。
- MCP 等標準提供即時的生態系統利益
- 自定義協議創建技術債務和集成挑戰
- 標準來自集體智慧——尊重那些累積的知識
- 貢獻於標準演進而不是不必要地分叉
6.3 原則 3：動態發現
工具應該在運行時可發現，而不是硬編碼。
- Agent 應該適應可用的工具，無需代碼更改
- 工具清單應包括豐富的元數據（描述、參數、示例）
- 支持熱加載以實現零停機工具更新
- 通過標準接口啟用工具鏈接和合成
6.4 原則 4：安全隔離
工具執行應該是沙箱化和策略執行的。
- 假設 Agent 可能出錯或被誤導
- 實現深層防御：在多層驗證
- 使用最小權限原則——工具僅獲得它們需要的權限
- 為安全敏感操作提供清晰的審計跟踪
6.5 原則 5：狀態持久化
長期運行的任務需要穩健的狀態管理。
- 為中斷進行設計——任務將被暫停、殺死或失敗
- 在任務邊界處實現檢查點/恢復機制
- 將短暫狀態與持久狀態分離
- 當狀態丟失時啟用優雅降級
6.6 最佳實踐檢查清單
在實現 Harness-Agent 架構時，考慮：
- 工具定義：工具是否良好記錄，具有清晰的架構和示例？
- 錯誤處理：工具是否提供可操作的錯誤消息和恢復建議？
- 可觀察性：你能追踪從 Agent 決策到 Harness 執行的請求嗎？
- 速率限制：是否有防止意外濫用或無限迴圈的保護？
- 用戶控制：用戶能否檢查、批准或覆蓋 Agent 工具選擇？
- 備用策略：當首選工具不可用時會發生什麼？
- 資源清理：臨時文件、連接和進程是否正確釋放？
7. 結論：架構作為競爭優勢
當我們展望 AI 系統的未來時，清晰的模式出現：模型能力正在商品化，但架構卓越仍然是持久的競爭優勢。
7.1 模型能力平台
邊界模型和有能力的開源替代品之間的差距正在縮小。蒸餾、量化和高效訓練等技術正在民主化對強大推理能力的訪問。在幾年內，「模型質量」將對大多數應用而言是一個已解決的問題。
不會被解決的是集成挑戰——將這些強大的模型連接到混亂、異構的企業系統、個人工作流和外部數據源現實。這是架構的領域。
7.2 Harness 可靠性作為決定性因素
當模型「足夠好」時，決定性因素變成：
- 可靠性：系統是否在不同情景中一致工作？
- 安全性：用戶能否相信系統處理他們的數據和系統？
- 可擴展性：系統是否能適應新需求而無需重新設計？
- 可觀察性：操作者能否理解和調試系統行為？
這些是架構關注點，不是模型關注點。Harness 層就是解決這些關注點的地方。
7.3 MCP 和工具訪問的統一
MCP 代表了 AI 架構中的關鍵時刻——真正標準的出現以實現工具集成。隨著 MCP 採用的增長，我們可以期待：
- 可用工具的爆炸性增長（每個 SaaS 產品、數據庫和 API 都變成 AI 可訪問的）
- AI 平台之間在編排質量而不是集成數量方面的競爭增加
- 專業化 Harness 提供者的出現（安全專注、性能優化、領域特定）
7.4 從單 Agent 到多 Agent 協作
當前一代 AI 系統主要將 Agent 視為單一實體。下一代將擁抱多 Agent 架構，其中專業化 Agent 在複雜任務上協作：
- 研究 Agent 收集和綜合信息
- 規劃 Agent 分解目標和分配資源
- 執行 Agent 與特定系統和工具交互
- 審查 Agent 驗證質量並捕獲錯誤
這些多 Agent 系統將需要複雜的 Harness 層，能夠：
- Agent 間通信和協調
- 跨 Agent 邊界的共享上下文管理
- Agent 不同意時的衝突解決
- 資源分配和優先級設置
MCPlato 的三層架構——具有工作區、Session 和 Agent 關注點的清晰分離——為這個多 Agent 未來提供了基礎。
7.5 最後的想法
從「模型優先」到「架構優先」思維的轉變代表了 AI 領域的成熟。我們正從演示什麼是可能的時代轉向交付什麼是可靠的時代。
對於今天構建 AI 系統的從業者，教訓很明確：投資你的 Harness 層。設計良好的 Harness 將比你當前的模型提供者活得更長，適應新用例，並為尚未想像的能力提供基礎。
MCPlato 的架構——MCP 原生、三層解耦、本地優先——代表了這個基礎看起來像什麼的一個願景。這不是唯一有效的方法，但它演示了將指導成功 AI 架構未來幾年的原則。
架構優先的 AI 時代已經開始。
FAQ
Q：什麼是 AI 系統中的 Harness 層？
Harness 層（工具層）負責工具封裝、執行編排、驗證和保護、記憶體管理。它將外部能力（文件、API、搜尋）包裝成可調用的 Tools/Skills，處理模型推理之外的所有功能，包括安全沙箱、錯誤處理和結果格式化。
Q：MCPlato 如何實現 Harness-Agent 架構？
MCPlato 實現了三層架構：工作區層用於工作區管理和隔離，Session 層用於上下文維護和消息分發，Agent 層用於 ClawMode 自主執行。它提供原生 MCP Host 能力、內置工具集包括 @Tool、信息圖表、瀏覽器、圖像和文檔工具，支持動態工具發現和熱加載。
Q：什麼是 MCP，為什麼它很重要？
MCP（Model Context Protocol）是 Anthropic 在 2024 年 11 月發布的開放標準。它作為 AI 應用和外部系統之間的通用接口，無需為每個數據源構建單獨的連接器。MCP 定義了三個核心原語：Tools（可執行函數）、Resources（數據源）和 Prompts（交互模板）。
Q：為什麼 Harness 層比模型本身更重要？
超過一定閾值後，模型能力變得商品化。Harness 層的可靠性、安全性和工具集成質量成為生產 AI 系統的決定性因素。設計良好的 Harness 能夠實現安全、可靠的工具使用，無論底層模型如何，都提供一致的接口。
Q：設計 Harness-Agent 架構的關鍵原則是什麼？
關鍵原則包括：(1) 分層解耦，明確分離 Harness 和 Agent 的責任，(2) 標準優先採用 MCP 等協議，(3) 動態發現用於運行時工具註冊，(4) 通過沙箱執行實現安全隔離，(5) 長期任務的狀態持久化。
Q：MCPlato 與 Claude Code 和 Cursor 有什麼區別？
MCPlato 通過以下方式區分自己：(1) 三層架構 vs 兩層設計，(2) 原生 MCP Host 實現 vs 附加支持，(3) 本地優先具有完整的本地工具鏈，(4) 內置圖像、文檔、信息圖表和瀏覽器工具，(5) 三層記憶體架構，(6) 原生調度能力。
Q：AI 系統架構的未來方向是什麼？
該行業正在從單 Agent 向多 Agent 協作轉變，從模型中心設計向架構中心設計，從專有集成向 MCP 等標準化協議轉變。未來系統將強調可靠性、可觀察性和可擴展性作為主要設計目標。