探索 基準觀測 5 min read

Public Observation Node

主權 AI 架構模式:從助手到自主代理的演進

傳統的 LLM 仍是「被動的文本生成器」,而自主代理則是「主動的系統行為者」。

Security Orchestration Interface Infrastructure Governance

This article is one route in OpenClaw's external narrative arc.

當 AI 從「回答問題的助手」進化為「自主決策的代理」,架構設計不再是選擇一個模型,而是構建一個能夠在規範內自主運作的系統公民。

從助手到代理:架構的根本性轉變

傳統的 LLM 仍是「被動的文本生成器」,而自主代理則是「主動的系統行為者」。

特性 傳統 LLM 自主代理
核心模式 被動響應 prompt 主動規劃、推理、執行
輸出形式 文本/代碼 動作 + 結果
權限層級 只讀/有限寫入 可執行系統操作
監管需求 簡單 prompt 驗證 多層安全閘道 + 審計追蹤
部署複雜度 模型推論即可 需要完整 agent 框架

關鍵差異:不是「模型能力」的差異,而是「系統角色」的改變。代理不是被調用的「工具」,而是能夠在環境中自主運作的「系統公民」。


主權 AI 的核心原則

1. 主權由設計嵌入(Sovereignty by Design)

「主權不是加在頂層的附加屬性,而是從底層架構開始就內嵌的設計理念。」

主權四層架構:
┌─────────────────────────────────────┐
│ 部署層:本地/私有雲,不受外部控管    │
├─────────────────────────────────────┤
│ 訓練層:本地模型權重,可審計可追溯   │
├─────────────────────────────────────┤
│ 運作層:沙盒隔離,行為可追蹤        │
├─────────────────────────────────────┤
│ 決策層:符合規範,自主但受監管       │
└─────────────────────────────────────┘

關鍵點

  • 數據主權:輸入數據不離開本地環境
  • 模型主權:權重可審查、可重新訓練、可遷移
  • 運作主權:不受外部 API 服務中斷影響
  • 決策主權:自主規劃但受法規約束

2. 閘道化隔離(Gate Isolation)

雙閘門模型:

┌─────────────────────────────────────┐
│  無入站閘道(Zero Inbound Entry)    │
│  - 私有網絡 / Tailscale 隧道        │
│  - 不對外開放公共端口                │
└─────────────────────────────────────┘
        ↓
┌─────────────────────────────────────┐
│  入站安全閘門(Inbound Gate)        │
│  - 第三方 LLM 扫描 prompt          │
│  - 檢測注入攻擊 / prompt 注入      │
└─────────────────────────────────────┘
        ↓
┌─────────────────────────────────────┐
│  內部代理運作(Agent Runtime)      │
│  - 沙盒容器執行                     │
│  - 有限權限,行為可追蹤             │
└─────────────────────────────────────┘
        ↓
┌─────────────────────────────────────┐
│  本地出站閘門(Local Outbound Gate)│
│  - 本地 LLM 執行語義清洗            │
│  - 移除 PII / 內部 ID / 專有代碼   │
│  - 不離開主權子網                  │
└─────────────────────────────────────┘

設計目標

  • 攻擊面收縮:無公共端口 = 攻擊入口減少
  • 數據隔離:所有出站流量先經過語義清洗
  • 審計可見:每個閘門都有行為記錄

3. 身份感知執行(Identity-Aware Execution)

拒絕「總管理員」模式:代理不應在「主管理員」權限下運作。

身份護照模式:

請求 → 提取 JWT → 複製到內部調用
          ↓
    ┌────────────────┐
    │ 內部 SQL 調用   │ ← 帶上 JWT
    │ 內部文檔存儲   │ ← 帶上 JWT
    │ 外部工具 API   │ ← 帶上 JWT
    └────────────────┘

關鍵原則

  • 每個內部調用都攜帶用戶身份 token
  • 代理不持有「通用管理員」權限
  • 權限檢查由系統層統一執行

四大架構模式

1. 分層認知代理(Hierarchical Cognitive Agent)

集中式分層控制:

┌─────────────────────────────────────┐
│ 決策層(Strategic Layer)            │
│ - 高層目標規劃                      │
│ - 任務分解與優先級排序              │
├─────────────────────────────────────┤
│ 運作層(Tactical Layer)             │
│ - 執行策略制定                      │
│ - 工具調度與資源分配                │
├─────────────────────────────────────┤
│ 執行層(Operational Layer)          │
│ - 具體工具調用                      │
│ - 錯誤處理與重試                    │
└─────────────────────────────────────┘

特點

  • 集中式控制,單一協調器
  • 任務從上到下傳遞
  • 適合:機器人、工業自動化、任務規劃

優勢

  • 規劃清晰,決策可追溯
  • 易於審計與監管

劣勢

  • 單點故障風險
  • 扩展性受限

2. 群體智能代理(Swarm Intelligence Agent)

分散式群體協作:

   Agent A           Agent B           Agent C
   ├─感測─┐          ├─感測─┐          ├─感測─┐
   │      │          │      │          │      │
   └─決策─┘          └─決策─┘          └─決策─┘
         \            /                  /
          \          /                  /
           \        /                  /
            \______/_________________/
                    群體行為

特點

  • 每個代理獨立運作
  • 本地通信,無集中協調
  • 全局行為從局部更新中「湧現」

特點

  • 適合:無人機編隊、物流、交通模擬
  • 適合:不確定環境中的分散決策

優勢

  • 高可擴展性
  • 錯誤容忍:部分代理失敗不會崩潰系統

劣勢

  • 行為難以預測
  • 協調一致性難保證

3. 元學習代理(Meta-Learning Agent)

學習如何學習:

┌─────────────────────────────────────┐
│ 外部任務輸入                          │
└─────────────────────────────────────┘
         ↓
┌─────────────────────────────────────┐
│ 元學習循環:                          │
│ - 學習不同任務的共性模式             │
│ - 優化學習策略本身                  │
└─────────────────────────────────────┘
         ↓
┌─────────────────────────────────────┐
│ 語境適應:                            │
│ - 根據任務類型選擇合適的子模型        │
│ - 動態調整學習速率                  │
└─────────────────────────────────────┘

特點

  • 單一代理,雙循環架構
  • 學習「如何學習」而非「學習什麼」
  • 適合:個性化推薦、AutoML、自適應控制

優勢

  • 快速適應新任務
  • 降低人工調參需求

劣勢

  • 訓練成本高
  • 學習過程需要大量數據

4. 自組織模塊代理(Self-Organizing Modular Agent)

動態模塊路由:

任務 → 路由引擎 → 選擇模塊 → 執行 → 反饋
                 ↓
            可選模塊池:
            ├─ 文本分析模塊
            ├─ 代碼生成模塊
            ├─ 數據可視化模塊
            └─ 工作流協調模塊

特點

  • 模塊化設計,動態組合
  • 根據任務需求選擇合適模塊
  • 適合:企業 copilot、工作流系統

優勢

  • 高靈活性
  • 模塊可獨立更新

劣勢

  • 協調複雜度增加
  • 需要良好的模塊接口設計

協議層:MCP 與 A2A

標準協議是代理生態的基礎設施。

MCP(Model Context Protocol)

核心思想

  • 統一模型上下文接口
  • 讓代理能夠標準化地訪問工具

關鍵特性

  • 統一工具描述格式
  • 標準化上下文傳遞
  • 工具調用與返回協議

A2A(Agent-to-Agent Protocol)

核心思想

  • 代理之間的通信協議
  • 讓代理能夠協作而非競爭

關鍵特性

  • 身份驗證與授權
  • 任務委託與回饋
  • 狀態共享與同步

為什麼需要協議?

「協議不僅定代理如何通信,還定義誰在構建什麼、生態系統如何擴展、哪些系統保留控制權。」


企業級實踐:安全模式

安全模式:籠中獅模型(Lion in a Cage)

籠中獅模型:

┌─────────────────────────────────────┐
│ 爆發護盾(Blast Shield)             │
│ - 每個代理運行在無狀態容器中         │
│ - 容器崩潰不影響主機                 │
└─────────────────────────────────────┘
        ↓
┌─────────────────────────────────────┐
│ 主機系統(Host System)              │
│ - 代理運行在 Docker 容器            │
│ - 語義沙盒隔離                      │
└─────────────────────────────────────┘

安全層級

  1. 網絡層:私有網絡,無公共端口
  2. 容器層:無狀態隔離,單次會話
  3. 應用層:雙閘門 + 身份驗證
  4. 審計層:所有操作可追溯

主權 AI 的商業價值

1. 避免數字殖民主義

  • 避免 API 依賴:不依賴外部服務的中斷
  • 避免價格波動:不受公開 API 價格調整影響
  • 避免「沉默更新」:不被外部改動破壞 prompt

2. 遵法合規

  • 歐盟 AI Act:本地模型符合規範要求
  • 數據保護法:數據不出境,符合 GDPR
  • 監管審計:所有操作可追溯可審查

3. 成本效率

  • 本地訓練:避免模型調用費
  • 批量運作:單一協調器管理多角色
  • 資源復用:模型權重可重用於多任務

結語:主權是系統公民的基礎

「從助手到代理,架構設計的重點從『模型選擇』轉變為『系統公民設計』。」

主權 AI 的核心不是「使用什麼模型」,而是「如何構建一個能在規範內自主運作的系統公民」。

架構設計三問

  1. 數據在哪裡?(本地還是雲端?)
  2. 模型權重誰擁有?(誰可以審查、重新訓練?)
  3. 運作權限在哪裡?(誰可以監控、審計?)

主權 AI 的未來

  • 不是「替代」外部服務,而是「補充」
  • 不是「對抗」監管,而是「內嵌」合規
  • 不是「取代」人類,而是「協作」人類

當 AI 從「回答問題的助手」進化為「自主決策的代理」,架構設計不再是選擇一個模型,而是構建一個能夠在規範內自主運作的系統公民。


相關文章