本地端 Agentic AI：不依賴雲端的企業部署

Agentic AI——不只是生成文字而是採取行動的 AI 系統——是企業 AI 部署中增長最快的模式。Gartner 預測到 2028 年，33% 的企業軟體應用程式將包含 Agentic AI，而 2024 年還不到 1%。吸引力顯而易見：你得到的不是回答問題的聊天機器人，而是一個真正做事的系統。它查詢資料庫、更新記錄、起草文件、路由工單，並執行多步驟工作流程。

但有一個隱藏在顯而易見之處的問題。幾乎所有的 Agentic AI 內容、工具和框架都假設雲端部署。LangChain 的預設範例呼叫 OpenAI。CrewAI 的教學使用 GPT-4。AutoGen 的文件假設 API 存取。隱含的訊息很明確：Agent 存在於雲端。

對於處理敏感資料、在受監管產業中營運，或僅僅想控制自己基礎設施的企業而言，這個假設是不可接受的起點。本指南涵蓋為什麼本地端 Agent 很重要、如何架構它們，以及當前工具生態系統的狀況。

為什麼本地端 Agent 不同於本地端聊天機器人

在本地端運行聊天機器人相對簡單。使用者發送問題，模型生成回應，回應回到使用者。資料流很簡單：文字進，文字出。

Agent 根本上不同。一個 Agent：

從企業系統讀取 — 資料庫、ERP、CRM、文件管理、郵件伺服器
做出決策 — 決定呼叫哪個工具、使用什麼參數、是否升級處理
採取行動 — 寫入資料、發送訊息、觸發工作流程、更新記錄
串連多個步驟 — 單一使用者請求可能涉及依序 5-15 次工具呼叫

這意味著資料流不是文字進、文字出。資料流是：企業資料進入，對該資料進行推理，在企業系統上採取行動。如果 Agent 在雲端運行，你的企業資料在每一步都流經雲端。

本地端 Agent 不可妥協的三個原因

1. 資料流經 Agent

當 Agent 查詢你的 CRM 以找到客戶的合約細節時，這些細節流經 Agent 的上下文視窗。當它讀取患者記錄以起草臨床摘要時，PHI 在 Agent 的記憶體中。當它搜尋你的法律文件庫尋找相關先例時，特權資訊通過模型。

如果 Agent 是雲端 API，它接觸的每一筆資料都會傳輸到第三方伺服器。資料暴露的範圍隨 Agent 能力擴展——Agent 越有用，它處理的資料越多，你的暴露面就越大。

使用本地端 Agent，資料永遠不會離開你的網路。模型在本地運行。工具在本地執行。向量儲存是本地的。整個推理鏈都留在你的安全邊界內。

2. Agent 做出影響受監管流程的決策

聊天機器人給建議。Agent 採取行動。這個區別在受監管產業中非常重要。

如果醫療場景中的 Agent 建議調整藥物，而該建議自動輸入 EHR，那就是臨床決策。它必須可稽核、可追蹤，並符合 FDA 和 HIPAA 要求。通過 OpenAI 的 API 運行該 Agent 意味著你的臨床決策路徑包含一個對該特定互動模式沒有 BAA 涵蓋的第三方服務。

如果金融服務公司的 Agent 基於市場分析執行交易，該行動受 SEC 和 FINRA 監管。決策鏈必須可重建。「我們把資料發送到雲端 API，它做了決定」不是一個可接受的稽核回應。

本地部署將整個決策鏈——輸入資料、推理步驟、工具呼叫、採取的行動——保持在你的合規邊界內。

3. 延遲在 Agent 步驟中複合

這是受到最少關注但對 Agent 可用性有最實際影響的原因。每次雲端 API 呼叫都增加延遲：

組件	雲端延遲	本地端延遲
LLM 推論（每步）	200-800ms	50-200ms
向量儲存查詢	100-300ms	5-20ms
工具執行	50-200ms（網路開銷）	1-10ms（本地）
每個 Agent 步驟的總計	350-1,300ms	56-230ms

一個 5 步驟的 Agent 工作流程——對於像「找到客戶的合約、檢查續約日期、查詢當前定價、起草續約郵件、排程後續追蹤」這樣的任務很常見——使用雲端 API 需要 1.75-6.5 秒。在本地端，同樣的工作流程在 280ms-1.15 秒內完成。

這不僅僅是效能最佳化。它是 Agent 感覺靈敏與感覺遲鈍的差別。使用者會放棄慢速的工具。

本地端 Agent 的架構

本地端 Agent 堆疊有四層：

第 1 層：本地 LLM

模型通過 Ollama、llama.cpp 或 vLLM 等推論執行環境在你的硬體上運行。模型檔案（GGUF、safetensors 或類似格式）儲存在本地。推論時無外部 API 呼叫。

模型選擇很重要。對於 Agent 工作負載，你需要具有強大指令遵循和工具呼叫能力的模型。目前在 7B-14B 參數範圍內的最佳選項：

Qwen2.5-7B / 14B — 強大的工具呼叫效能，良好的指令遵循
Mistral 7B 變體 — 支援良好，速度和品質的良好平衡
Llama 3.1 8B — 穩固的基線，廣泛的工具支援
Phi-3.5 / Phi-4 — 在其尺寸級別中推理能力強

對大多數企業 Agent 工作流程，微調的 7B 模型優於通用的 70B 模型，因為它已在你的特定工具和資料模式上訓練。

第 2 層：工具定義

Agent 需要工具——它們可以呼叫以與企業系統互動的函式。在本地端，這些工具是連接到你內部系統的本地函式定義：

tools = [
    {
        "name": "query_customer_database",
        "description": "Look up customer information by ID or name",
        "parameters": {
            "customer_id": {"type": "string", "description": "Customer ID"},
            "fields": {"type": "array", "description": "Fields to return"}
        }
    },
    {
        "name": "create_support_ticket",
        "description": "Create a new support ticket in the internal system",
        "parameters": {
            "customer_id": {"type": "string"},
            "priority": {"type": "string", "enum": ["low", "medium", "high"]},
            "description": {"type": "string"}
        }
    }
]

工具在本地對你的內部 API、資料庫和服務執行。沒有資料離開網路。

第 3 層：用於 RAG 的本地向量儲存

Agent 需要知識——文件、政策、程序、產品資訊——來做出明智的決策。本地向量儲存（Qdrant、Milvus、ChromaDB）持有你企業文件的嵌入表示。

Agent 決策的品質直接受限於此向量儲存中資料的品質。如果知識庫包含過時的政策、重複的內容，或將表格分割跨塊的不良分塊文件，Agent 就會檢索到不良資訊並做出不良決策。

第 4 層：稽核日誌

每個 Agent 行動都必須記錄：它存取了什麼資料、執行了什麼推理、呼叫了什麼工具、使用了什麼參數、產生了什麼結果。這對企業部署不是可選的——它是責任制的基礎。

稽核日誌應捕捉：

時間戳和工作階段 ID
發起請求的使用者
輸入查詢
每個推理步驟（模型輸出）
每次工具呼叫（函式名稱、參數、回傳值）
交付給使用者的最終回應
存取的資料來源（從向量儲存中檢索了哪些文件）

本地模型真的能驅動 Agent 嗎？

這是阻止大多數企業團隊的問題。假設是只有 GPT-4 級別的模型才能進行可靠的 Agent 行為——工具呼叫、多步驟推理和決策。

資料說的是另一個故事。對於工具定義明確且決策空間有限的結構化企業任務：

微調 7B 模型在企業工具呼叫任務上達到 85-92% 準確率，當在 500 個以上特定工具 schema 的範例上訓練時
微調 14B 模型在相同任務上達到 90-95% 準確率
通用（未微調）7B 模型僅達到 40-60% 準確率 — 這就是為什麼 fine-tuning 是必要的，不是可選的

關鍵短語是「結構化企業任務」。如果 Agent 需要處理需要創意推理的任意開放式請求，7B 模型會有困難。如果 Agent 處理一組定義的工作流程和一組定義的工具——這描述了大多數企業使用案例——微調的小型模型就足夠了，而且通常比更大的通用模型更可靠。

Fine-tuning 教導模型你的特定工具 schema、參數格式和業務邏輯。微調模型不需要每次都從第一原理推算如何呼叫 query_customer_database——它已經看過數百個範例並學會了模式。

部署本地端 Agent 需要什麼

硬體

7B Agent 模型的最低可行設定：

GPU：NVIDIA RTX 4090（24GB VRAM）或 A6000（48GB VRAM）
RAM：64GB 系統記憶體
儲存：500GB NVMe SSD（模型檔案 + 向量儲存 + 稽核日誌）
成本：根據 GPU 選擇 $5,000-$15,000

對於 14B 模型或更高吞吐量：

GPU：NVIDIA A100（80GB）或 H100
RAM：128GB 系統記憶體
成本：$15,000-$40,000

與雲端 Agent API 成本比較：每月 100,000 次 Agent 互動（每次 5 個步驟，500,000 次 API 呼叫），GPT-4 級別定價為 $15,000-$30,000/月。硬體在 1-3 個月內就收回成本。

軟體堆疊

組件	選項	用途
推論執行環境	Ollama、vLLM、llama.cpp	在本地運行模型
Agent 框架	LangChain、LlamaIndex、自定義	協調工具呼叫
向量儲存	Qdrant、Milvus、ChromaDB	儲存嵌入文件
嵌入模型	all-MiniLM、E5、BGE	在本地嵌入文件
稽核日誌	Elasticsearch、PostgreSQL	記錄所有 Agent 行動

微調模型

通用模型是不夠的。你需要在以下方面微調的模型：

你的工具 schema — 你特定工具的正確工具呼叫範例
你的業務上下文 — 你的組織如何談論其流程、產品和政策
你的品質標準 — 你期望的格式、語氣和準確度水平

訓練資料：500-2,000 個已標註的使用者查詢範例，配對正確的 Agent 回應（包括工具呼叫）。這些資料來自你的領域專家和現有企業文件。

乾淨的企業資料

Agent 的知識庫需要經過準備，不能只是傾倒到向量儲存中。原始企業文件需要：

解析（PDF、Word 文件、電子郵件、試算表）
清理（移除範本文字、修正編碼、去重）
分塊（語義邊界，不是任意字元計數）
中繼資料標記（來源、日期、作者、文件類型）
嵌入（本地嵌入模型，無外部 API）

這個資料準備步驟是大多數 Agent 專案成功或失敗的地方。一個建構良好但資料不好的 Agent 做出不良決策。一個普通但資料乾淨、結構良好的 Agent 始終表現更好。

支援本地端 Agent 的平台

本地端 Agent 的工具生態系統正在成熟：

預配置設備：Cortexa、NayaFlow——為企業本地端 AI 部署設計的硬體 + 軟體套件。將設定時間從數週減少到數天。

開源 Agent 框架：Open WebUI（提供帶工具呼叫支援的聊天介面）、OpenClaw（為本地部署設計的 Agent 框架）、LangChain/LlamaIndex（支援本地模型的熱門框架）。

自定義堆疊：對於有 ML 工程能力的團隊，結合 Ollama + 本地向量儲存 + 自定義 Agent 迴圈提供最大的靈活性和控制。

資料準備：Ertas Data Suite——為 Agent 知識庫和 fine-tuning 資料集準備企業文件的端對端流程。處理解析、清理、分塊、標註和匯出。完全在本地端運行。

資料準備依賴性

這是大多數 Agentic AI 討論跳過的部分：Agent 品質受限於知識庫品質。

你可以有最好的模型、最好的框架和最好的硬體。如果向量儲存中的資料是混亂的——重複文件、過時政策、將表格分割跨塊的不良分塊文字、缺失的中繼資料——Agent 就會檢索到不良上下文並產生不良結果。

失敗模式是隱蔽的，因為它看起來像模型問題。Agent 自信地給出錯誤答案，團隊責怪模型。但模型是從檢索系統收到了錯誤的資訊，而檢索系統檢索了錯誤的塊，因為知識庫沒有經過適當準備。

資料準備是基礎。做對了，7B 模型作為企業 Agent 表現出色。做錯了，即使 GPT-4 也會產生不可靠的結果。

開始使用

本地端 Agent 的實際路徑：

識別一個定義明確的工作流程 — 一個具有明確輸入、工具和預期輸出的可重複任務
準備知識庫 — 清理和分塊 Agent 將需要的文件
Fine-tune 模型 — 500 個以上的工作流程範例，包括工具呼叫模式
在本地部署 — Ollama + 你選擇的向量儲存 + 稽核日誌
與領域專家一起測試 — 讓目前執行該任務的人評估 Agent 的輸出
迭代資料品質 — 大多數改善來自修正知識庫，而非更換模型

從一個工作流程開始。讓它可靠地運作。然後擴展。無論你運行一個 Agent 還是十個，基礎設施投資都是相同的——額外 Agent 的邊際成本主要是資料準備和 fine-tuning，而非硬體。