標籤: 企業 AI

  • 企業級 Agent Harness 七大能力實戰拆解

    企業級 Agent Harness 七大能力實戰拆解

    📌 本文重點

    • 單一 Agent PoC 聰明,上線即暴露治理問題
    • 需要 Agent Harness 統一管控工具、成本與政策
    • 先建可觀測、可回放的 Harness,再談多 Agent 擴展
    • 將治理與業務邏輯解耦,避免生產環境變實驗場

    企業在玩 PoC 時,單一 Agent 看起來很聰明;一上線就暴露本質問題:工具亂叫、成本失控、記憶混亂、錯誤難重現、政策無法落地。這不是模型不夠強,而是缺少一層專門管控 Agent 行為的 Agent Harness(Agent 的 runtime & control plane)

    💡 關鍵: 問題不在模型本身,而在缺少專門負責治理、成本與行為管控的中介層。

    這一層做的事很務實:集中管控 工具註冊與版本 / 權限、step-level tracing + replay、記憶與知識更新、錯誤恢復與重試、成本與 Token Budget、政策注入(policy engine)、標準化的 human-in-the-loop 介面。有了它,你才真的能把多 Agent 系統放進生產環境,而不是「高級 demo」。


    重點說明:Agent Harness 的 7 大能力

    1. 工具 / 函式註冊與版本管理

    把所有可被 Agent 呼叫的 API/工具收斂到一個 工具註冊中心,統一管理:

    • 白名單 + Scope:不同 Agent 只能看到被授權的工具,避免「直接讓模型自由呼叫所有內部 API」。
    • 版本管理:工具有 versiondeprecation 概念,支援灰度切換與回滾。
    • 結構化 schema:對應到 LLM 的 tool schema / function calling,並強制要求輸入輸出型別。

    2. 觀察、Tracing 與 Replay

    沒有 step-level tracing,任何「為什麼產生這個請款請求?」都變成佛系排查。Harness 要提供:

    • 每一步 prompt / tool call / response 的結構化 log
    • replay 能力:拿同一套 input/context/tool version 在測試環境重放。
    • 與 APM/日誌系統整合(如 OpenTelemetry, Datadog)。

    💡 關鍵: 有了 step-level tracing 與 replay,才能在出錯時精準重現並修復 Agent 行為,而不是盲目排查。

    3. 記憶與知識源更新

    多數系統踩的坑是「把 RAG/記憶全塞進 context」,結果是:

    • token 爆炸 → 成本高、延遲高
    • 資訊新鮮度難管控

    Harness 要把記憶拆成:

    • 短期工作記憶(task-local state):存在 run/session 中。
    • 長期記憶(user / account profile, conversation history):向量庫或 KV 存儲,按策略查再放入 context
    • 權威知識源(DB / data warehouse / API):由工具抽象,不直接塞原始資料進 prompt

    4. 錯誤恢復與重試策略

    Agent 在實際環境裡會遇到:工具 5xxtimeoutschema mismatch、LLM 回傳壞 JSON 等。Harness 要集中:

    • 可配置重試策略(per tool 的 max_attemptsbackoff)。
    • 降級策略:改用備援工具、或中止並要求人工介入。
    • 把錯誤與重試記錄在 tracing 中,方便事後分析。

    5. 成本與 Token Budget 控制

    程式化 Agent(CI、排程、webhook 觸發)最容易「安靜地燒錢」。Harness 應實作:

    • per-run token budget:單一任務總 token / cost 上限。
    • per-tool cost 上限:避免某個向量搜尋或報表 API 被無限 loop 呼叫。
    • 依租戶 / team 維度聚合成本,餵到帳務系統或告警系統。

    💡 關鍵: 透過 per-run 與 per-tool 的 token 與成本上限,可以在不影響功能的前提下,防止自動化流程悄悄造成巨額開銷。

    6. 策略 / 合規政策注入(Policy Engine)

    只在 prompt 放幾條「不要外流 PII」是不夠的。企業需要一個 policy engine

    • 針對工具呼叫、輸入輸出內容,做 策略判斷與拒絕
    • 支援條件式規則,如「財務資料工具只能在工作時間、由 Finance-Agent 使用」。
    • 配合零信任閘道(如 SolonGate 類產品)做額外的身分驗證與審計。

    7. Human-in-the-loop 標準化接口

    有些動作永遠不該全自動(退款、合約變更…)。Harness 要提供:

    • 標準化的 approval 任務結構:包含 who, what, diff, risks
    • 挂在 ticket 系統 / 內部前端(如模仿 LangGraphhuman node)。
    • Agent 在收到人類決策後能繼續流程,而不是整個 run 重來。

    實作範例:最小可用 Agent Harness(Python)

    以下是簡化版的「Agent 執行器」,示範:

    • 工具註冊 + 白名單
    • logging + tracing id
    • 超時 / 重試
    • per-run token budget
    • per-tool 次數上限
    import time
    import uuid
    from dataclasses import dataclass, field
    from typing import Any, Callable, Dict, List, Optional
    
    # === 1. 工具註冊中心 ===
    
    @dataclass
    class ToolConfig:
        name: str
        func: Callable[[Dict[str, Any]], Any]
        version: str = "v1"
        max_calls_per_run: int = 5
        timeout_sec: float = 10.0
        cost_per_call: float = 0.001  # 自訂邏輯用
        enabled: bool = True
    
    
    class ToolRegistry:
        def __init__(self):
            self._tools: Dict[str, ToolConfig] = {}
    
        def register(self, tool: ToolConfig):
            key = f"{tool.name}:{tool.version}"
            self._tools[key] = tool
    
        def get_allowed_tools(self, whitelist: List[str]) -> Dict[str, ToolConfig]:
            # whitelist 用的是 name,不帶 version
            out = {}
            for key, tool in self._tools.items():
                if tool.name in whitelist and tool.enabled:
                    out[key] = tool
            return out
    
    
    # === 2. Harness 執行設定 ===
    
    @dataclass
    class RunBudget:
        max_tokens: int
        max_cost: float
        used_tokens: int = 0
        used_cost: float = 0.0
    
        def charge_tokens(self, tokens: int):
            self.used_tokens += tokens
            if self.used_tokens > self.max_tokens:
                raise RuntimeError("Run token budget exceeded")
    
        def charge_cost(self, cost: float):
            self.used_cost += cost
            if self.used_cost > self.max_cost:
                raise RuntimeError("Run cost budget exceeded")
    
    
    @dataclass
    class AgentRunContext:
        run_id: str
        user_id: str
        allowed_tools: Dict[str, ToolConfig]
        budget: RunBudget
        tool_call_counts: Dict[str, int] = field(default_factory=dict)
    
    
    # === 3. LLM 客戶端包一層(示意) ===
    
    class LLMClient:
        def __init__(self, model: str):
            self.model = model
    
        def chat(self, messages: List[Dict[str, str]], tools_schema: List[Dict]) -> Dict[str, Any]:
            """
            回傳格式假設:
            {
              "content": "...",
              "tool_calls": [
                {"tool": "search:v1", "arguments": {"q": "foo"}}
              ],
              "usage": {"input_tokens": 200, "output_tokens": 150}
            }
            """
            # 這裡應呼叫實際 LLM API;為示意略過
            return {
                "content": "stub",
                "tool_calls": [],
                "usage": {"input_tokens": 50, "output_tokens": 30},
            }
    
    
    # === 4. Harness 核心執行器 ===
    
    class AgentHarness:
        def __init__(self, llm: LLMClient, tool_registry: ToolRegistry, logger):
            self.llm = llm
            self.tool_registry = tool_registry
            self.logger = logger
    
        def run(self, *, user_id: str, messages: List[Dict[str, str]],
                tool_whitelist: List[str], max_steps: int = 8,
                max_tokens: int = 8000, max_cost: float = 0.5) -> Dict[str, Any]:
    
            run_id = str(uuid.uuid4())
            allowed_tools = self.tool_registry.get_allowed_tools(tool_whitelist)
            ctx = AgentRunContext(
                run_id=run_id,
                user_id=user_id,
                allowed_tools=allowed_tools,
                budget=RunBudget(max_tokens=max_tokens, max_cost=max_cost),
            )
    
            self.logger.info(f"run_start", extra={"run_id": run_id, "user_id": user_id})
    
            for step in range(max_steps):
                step_id = step + 1
                self.logger.info("llm_step_start", extra={"run_id": run_id, "step": step_id})
    
                tools_schema = [
                    {"name": t.name, "version": t.version} for t in allowed_tools.values()
                ]
                resp = self.llm.chat(messages, tools_schema)
    
                usage = resp.get("usage", {})
                ctx.budget.charge_tokens(usage.get("input_tokens", 0) + usage.get("output_tokens", 0))
    
                tool_calls = resp.get("tool_calls", [])
                if not tool_calls:
                    # 任務完成
                    self.logger.info("run_complete", extra={"run_id": run_id, "step": step_id})
                    return {"run_id": run_id, "final": resp["content"]}
    
                # 執行工具呼叫
                for call in tool_calls:
                    tool_key = self._resolve_tool_key(call["tool"], allowed_tools)
                    tool_cfg = allowed_tools[tool_key]
    
                    count = ctx.tool_call_counts.get(tool_key, 0) + 1
                    if count > tool_cfg.max_calls_per_run:
                        raise RuntimeError(f"tool {tool_key} call limit exceeded")
                    ctx.tool_call_counts[tool_key] = count
    
                    result = self._call_tool_with_retry(tool_cfg, call["arguments"], ctx)
                    messages.append({"role": "tool", "name": tool_cfg.name, "content": str(result)})
    
            raise RuntimeError("max_steps_exceeded")
    
        def _resolve_tool_key(self, tool_name: str, allowed_tools: Dict[str, ToolConfig]) -> str:
            # 簡化:同名只允許一個版本
            matches = [k for k, t in allowed_tools.items() if t.name == tool_name]
            if not matches:
                raise RuntimeError(f"tool {tool_name} not allowed")
            return matches[0]
    
        def _call_tool_with_retry(self, tool_cfg: ToolConfig, args: Dict[str, Any], ctx: AgentRunContext):
            attempts = 0
            while True:
                attempts += 1
                start = time.time()
                try:
                    # 超時控制示意:可用 asyncio.wait_for 或 thread + join
                    result = tool_cfg.func(args)
                    elapsed = time.time() - start
                    self.logger.info(
                        "tool_call",
                        extra={
                            "run_id": ctx.run_id,
                            "tool": tool_cfg.name,
                            "version": tool_cfg.version,
                            "attempts": attempts,
                            "elapsed_sec": elapsed,
                        },
                    )
                    ctx.budget.charge_cost(tool_cfg.cost_per_call)
                    return result
                except Exception as e:
                    if attempts >= 3:
                        self.logger.error("tool_failed", extra={"tool": tool_cfg.name, "err": str(e)})
                        raise
                    time.sleep(0.5 * attempts)
    

    你可以在這層再接上:

    • policy engine:在 _call_tool_with_retry 前後做輸入輸出檢查。
    • human-in-the-loop:當特定工具被呼叫,改成發出審核任務,而不是直接執行。
    • tracing 平台:把 run_idsteptool 當成 span/trace id,上報到 OpenTelemetry

    建議與注意事項

    1. 工具權限與多 Agent 協作

    • 不同 Agent(或不同租戶)應有獨立的 tool whitelist 和輸入遮罩。
    • 多 Agent 團隊協作時,要明確:誰能看哪些記憶 / 哪些知識源,避免「助理 Agent 無意間看到 CEO 的對話紀錄」。

    2. 記憶與 RAG 的分層設計

    • 不要「一次把所有 RAG 結果塞進 context」,應做:
    • 第一階段檢索:向量庫 / keyword 檢索
    • 第二階段過濾 / re-rank:只把 top-k、與當前任務強相關的放入 prompt
    • 對長期記憶,引入 TTL / 熱度分級,過舊資料只保存在冷存儲,需要時再查。

    3. Tracing / Replay 一開始就要做

    • 踩坑:先上線,出事再補 tracing → 你根本不知道 Agent 做了什麼。
    • 最少要記:run_id、step、messages(摘要即可)、tool_calls、錯誤堆疊、tool version
    • 為 replay 保留「當時的工具版本與政策版本」,不然重放行為會不一致。

    4. 成本 / Budget 不只是一個大數字

    • run / user / team / workflow 類型 切分配額,結合告警(例如超過預估平均三倍就發訊息)。
    • 對「自動觸發型」Agent(CI、webhook)尤其要設 per-run token budget + max_steps,避免 prompt/工具錯誤導致無限 loop。

    5. 安全與政策落地要有「硬限制」

    • 除了 prompt 提醒,還要有:
    • policy engine:直接阻擋不符規則的工具呼叫 / 輸出內容。
    • 零信任閘道(如 SolonGate 類)在真正的企業 API 前再加一層,做身分、範圍、頻率控制。

    總結: 不要把「Agent 邏輯」和「治理、成本、安全控制」寫死在同一份業務程式碼裡。先抽出一層可組態、可觀測、可回放的 Agent Harness,你才能放心地擴到多 Agent、跨團隊、跨租戶,而不把整個公司變成昂貴的實驗場。

    🚀 你現在可以做的事

    • 審視現有 Agent PoC,列出目前缺少的 tracingbudgetpolicy 能力,畫出一層簡易 Harness 設計草圖
    • 在現有程式碼中加入 run_id、step-level log 與最小可用的 replay 機制,先讓行為可觀測
    • 實作一個簡單的 ToolRegistry 與 per-run token budget,從一個 Agent 開始逐步遷移到 Harness 架構
  • Claude 私有化:自托管沙箱與 MCP 隧道實戰

    Claude 私有化:自托管沙箱與 MCP 隧道實戰

    📌 本文重點

    • 模型與編排托管在 Anthropic,工具與資料留在你 VPC
    • 透過 self‑hosted sandbox 把程式執行權收回內網
    • 用 MCP tunnel 只開安全出站連線打通內網工具
    • 權限設計與審計要靠嚴格的 tools schema 與網路邊界

    典型企業場景:你想讓 Claude Managed Agent 幫你跑 CI/CD、讀內網 Git、打內部 REST / Postgres API,但 不能開公網入站、不能把 Git 暴露出去。這次的 self‑hosted sandboxes + MCP tunnels 更新,基本上就是:

    模型與編排留在 Anthropic,工具執行與資料存取拉回你自己的 VPC,且只用安全出站連線。

    實務上等於多了一種選擇:不用把模型拉進內網自建 inference,也能在嚴格邊界內讓 Agent 控制 CI、讀 repo、查 DB。


    重點說明:架構與安全邊界怎麼畫

    1. Orchestrator vs Tools:誰在外面、誰在裡面?

    Claude Managed Agents 大致拆成兩層:

    1. Orchestrator(Anthropic 端托管)
    2. 理解使用者意圖、規劃步驟、決定要叫哪些工具。
    3. 透過 MCP 協定 呼叫你定義的 tools(MCP server)。

    4. Tools / MCP servers(你自己控制)

    5. 例如:git、CI/CD runner、Postgres、內部 REST API
    6. 可以跑在 self‑hosted sandbox 裡(受控容器/VM),或直接在你內網 VPC。

    💡 關鍵: Orchestrator 永遠只看得到你暴露出的 MCP tools 與其 I/O,真正的 Git / DB 資料面與執行權都留在你 VPC。

    關鍵:Orchestrator 看不到你的 Git/DB,只能透過你暴露出的 MCP tools 操作,權限由你決定。


    2. MCP 協定與 server:最小必須心智模型

    MCP server 就是一個會講 JSON‑RPC over stdio / WebSocket 的後端,向 Agent 宣告自己有哪些工具。概念類似「強 typing 的 function calling」。

    一個簡化版的 MCP server schema(YAML)可能長這樣:

    name: corp-dev-tools
    version: 0.1.0
    
    tools:
      - name: git_read_file
        description: 讀取內部 Git repo 某個檔案內容
        input_schema:
          type: object
          required: [repo, path, ref]
          properties:
            repo: { type: string }
            path: { type: string }
            ref:  { type: string }
    
      - name: ci_trigger_pipeline
        description: 觸發 CI pipeline,只能在 allowlist 專案上執行
        input_schema:
          type: object
          required: [project, branch]
          properties:
            project: { type: string }
            branch:  { type: string }
    

    Agent 端會看到 明確的工具清單與參數結構,再決定何時呼叫。


    3. Self‑hosted sandbox:把「程式執行權」留在自己這邊

    self‑hosted sandbox 解決的是:「我不想讓 Anthropic 直接在他們 infra 上跑 shell / Python,請改在我 VPC 裡跑」。

    實作上可以是:

    • 一個專用 k8s namespaceFargate / VM,跑 Anthropic 提供的 sandbox runtime。
    • Agent 要執行程式碼(例如跑單元測試、lint、git 操作),會透過安全通道把 code / 指令丟到這個 sandbox。

    典型邊界設計:

    • sandbox 只能出站連到:
    • 你的 Git / CI / DB / 內部 API
    • Anthropic 的 MCP tunnel endpoint
    • 不能直連其他敏感系統(或至少預設 deny)。

    實際好處: Agent 可以幫你跑 pytest、打 CI webhook、改 Git branch,
    但所有「可以執行程式碼的環境」都在你的控制下,方便做防火牆、資安掃描、審計。


    4. MCP tunnels:如何在不開洞的情況下連到內網

    MCP tunnel 解決:「我的 MCP server 在 VPC 裡,如何讓 Anthropic 托管的 Agent 打到它,但我不願意開入站 443?」

    典型拓撲:

    [Anthropic Orchestrator]
            ^
            | (MCP over tunnel)
            v
    [MCP Tunnel Client in VPC] ----> [MCP Server + Sandbox]
              (outbound TLS)
    

    關鍵特性:

    • 只有 VPC → Anthropic 的出站連線(類似反向隧道)。
    • 隧道建立後,Anthropic 端像是在打本地 MCP server,但實際流量是經由你建立的 mutual TLS / token 隧道轉回來。
    • 容易套用零信任思路:每條隧道都視為一個 identity,綁定最小權限的一組 tools。

    💡 關鍵: 只用出站隧道與 mTLS,就能在不開任何入站 port 的前提下,把內網工具安全地接給 Managed Agent 用。


    實作範例:VPC 內最小可行架構

    場景:

    • VPC 內:
    • 一台 MCP server + sandbox Pod/VM。
    • 連得上 GitLab、Postgres、內部 https://api.intra
    • 出站:允許打到 Anthropic 的 MCP tunnel endpoint

    1. MCP server:Git + Postgres + REST API

    以 Node.js 為例(pseudo‑code):

    import { MCPServer } from "@anthropic-ai/mcp-sdk";
    import { execSync } from "node:child_process";
    import { Client } from "pg";
    import fetch from "node-fetch";
    
    const gitAllowlist = ["service-a", "service-b"];
    
    const server = new MCPServer({ name: "corp-dev-tools" });
    
    server.tool("git_read_file", async ({ repo, path, ref }) => {
      if (!gitAllowlist.includes(repo)) {
        throw new Error("repo not allowed");
      }
      const base = "/srv/git/" + repo;
      const content = execSync(`git --git-dir=${base} show ${ref}:${path}`, {
        encoding: "utf8",
      });
      return { content };
    });
    
    server.tool("db_read_customer", async ({ id }) => {
      const client = new Client({
        host: process.env.PG_HOST,
        user: "readonly_agent",
        password: process.env.PG_PWD,
        database: "app",
        ssl: true,
      });
      await client.connect();
      const res = await client.query("SELECT id, name, status FROM customers WHERE id=$1", [id]);
      await client.end();
      return { rows: res.rows };
    });
    
    server.tool("call_internal_api", async ({ path, method, body }) => {
      if (!path.startsWith("/public-agent/") || method !== "POST") {
        throw new Error("not allowed");
      }
      const resp = await fetch(`https://api.intra${path}`, {
        method,
        headers: { "Authorization": `Bearer ${process.env.AGENT_TOKEN}` },
        body: JSON.stringify(body ?? {}),
      });
      const json = await resp.json();
      return { status: resp.status, data: json };
    });
    
    server.listen();
    

    重點:

    • gitAllowlist:避免 Agent 任意讀所有 repo。
    • Postgres 使用 readonly_agent 帳號,限制只讀特定 schema。
    • 內部 API 降到 /public-agent/ 子路徑 + 專用 token。

    2. MCP tunnel client:出站連上 Anthropic

    實際指令會以官方 CLI / container 為主,概念配置類似:

    anthropic-mcp-tunnel \
      --mcp-url=http://localhost:8000 \
      --agent-id=corp-ci-agent \
      --tls-cert=/etc/mcp/cert.pem \
      --tls-key=/etc/mcp/key.pem \
      --anthropic-endpoint=https://mcp-tunnel.anthropic.com \
      --tags=env:prod,scope:ci
    

    在 Anthropic 控制台,你會:

    • 建立一個 Managed Agent:corp-ci-agent
    • 只綁定這條 tunnel 曝露的 corp-dev-tools MCP server。
    • 開啟前人工審閱 / 部分工具 auto‑approve(視風險)。

    3. ACL 與工具權限設計

    簡單的 policy‑as‑code 思路:

    agent: corp-ci-agent
    allowed_tools:
      - git_read_file
      - ci_trigger_pipeline
      - db_read_customer
      - call_internal_api
    
    constraints:
      git_read_file:
        repos: ["service-a", "service-b"]
        max_file_size_kb: 256
    
      db_read_customer:
        max_rows: 1
    
      call_internal_api:
        allowed_paths:
          - "/public-agent/deploy"
          - "/public-agent/status"
    

    你可以在 MCP server 裡讀這個 YAML,做額外校驗。不要把 ACL 寫死在 prompt 裡,防禦提示注入要靠程式碼與網路邊界。


    建議與注意事項:安全坑與實務整合

    1. 工具權限過大 = Agent RCE 風險

    OWASP Agent Top 10 已經把 工具濫用 / 權限濫用 列為前幾名風險。常見錯誤:

    • 一個 tool 可以執行任意 shell、對任何 DB 下任意 query。
    • Agent 可以打到整個內網,而不是只打 CI / Git / API Gateway。

    建議:

    • 一個 tool 做一件小事,強 schema,避免 free‑form SQL / shell。
    • DB 使用 只讀 + row‑level / column‑level policy
    • 網路上用 安全群組 / SG 把 sandbox 能打的 IP 段鎖死。

    2. 審計 / Logging:要記「自然語言意圖 + 工具調用」

    很多企業只有 infra log,缺少「Agent 為什麼要做這件事」的上下文。

    建議最低標準:

    • 針對每次工具呼叫記錄:
    • user_id / session_id
    • Agent 看到的 自然語言任務描述(可脫敏)
    • 工具名稱 + input 參數(敏感欄位做 partial redaction)
    • 執行結果摘要 / status code

    這樣在事後對齊 OWASP 事件分析時,才能把「提示注入 → 工具濫用 → 資料外洩」串成一條 timeline。


    3. 網路與認證:守住 MCP 隧道與 secrets

    重點:把隧道視為一個高價值通道,跟 VPN 一樣認真看待。

    具體建議:

    • 隧道一律走 mTLS,cert 由內部 CA 或雲端 CA 管理。
    • 隧道 client 的 API token / cert 放在 Vault / KMS,sandbox 上只拿短期 lease。
    • 工具裡 不要回傳 secrets(例如整個 JWT 與 DB 密碼)到 Agent,必要時只在 server 端使用。
    • 若擔心 API key 滲透,在 sandbox 層加 egress proxy,對外送出的 HTTP header 做檢查 / scrub。

    4. 與 SOAR/服務目錄/Secrets 管理整合的實務問題

    實務上會遇到:

    • SOAR / ticket 系統
    • 建議把「開 ticket / 查告警 / 執行 playbook」封裝成 MCP tools,權限沿用既有 RBAC。

    • 服務目錄(例如 Backstage)

    • MCP tools 可以讀服務目錄 API,讓 Agent 知道 repo 屬於哪個團隊、能不能改 config。

    • Secrets 管理(Vault/KMS)

    • 不要給 Agent 直接讀 Vault 的能力;改由 MCP tool 在 server 端解密,對 Agent 只暴露結果(或再加工)。

    5. 和「模型拉進內網自建 inference」的取捨

    Managed Agent + self‑hosted sandbox + MCP tunnel:

    • 優點:
    • 不用自己跑 LLM cluster,只負責工具、網路、權限
    • 快速接雲端最新模型(含之後像 Mythos 這種安全模型的企業版)。
    • 合規上:資料只經由 tools 進出,你可以精準監控。

    • 缺點:

    • Orchestrator 還是在 Anthropic,那邊仍會看到 工具 I/O 摘要
    • 對極端資料主權(完全不能出域)的場景不適合。

    自建 inference:

    • 優點:
    • 完整掌控模型與權限,所有 token 在你網段內。

    • 缺點:

    • 要自己做 Agent orchestration、tooling、guardrail、OWASP Top 10 風險防護。
    • 成本與維運門檻高。

    如果你目前已在雲上、允許「模型在外、資料在內」,這次的 Claude Managed Agents 私有化能力 是一個相對平衡的折衷:

    把最麻煩的 LLM 與 Agent orchestration 交給 Anthropic,把最敏感的程式執行與資料權限留在 VPC,用 MCP + sandbox 畫清楚邊界。

    🚀 你現在可以做的事

    • 在現有 VPC 內起一個簡單 corp-dev-tools MCP server(照文中 Node.js 範例改成你公司的 Git / DB / API)
    • 部署 anthropic-mcp-tunnel 類似的隧道 client,實測只用出站連線即可讓 Managed Agent 操作內網工具
    • 寫一份 YAML ACL(如文中 policy‑as‑code 範例),把 repo / DB / API 權限具體收斂後再開放給 Agent 使用
  • OpenAI 變身顧問公司,是升級還是掠奪?

    OpenAI 變身顧問公司,是升級還是掠奪?

    📌 本文重點

    • 模型公司正下沉吃下「部署層+顧問層」
    • 雲端、SI、傳統顧問的話語權被擠壓
    • 企業短期加速,長期恐被 AI 供應商鎖死
    • 技術人需保留多模型與技術主權

    OpenAI 拉來超過 40 億美元 成立 「The Deployment Company」,而 Anthropic 則與 Goldman Sachs、Blackstone、Hellman & Friedman 合資開企業 AI 公司,真正訊號不是「AI 很熱」,而是:光有 SOTA 模型賣不動,他們決定連「部署層+顧問層」一起吃下來。 對產品與技術領導者來說,這不是一個新工具的發布,而是一場產業結構改寫的開端。


    一、為什麼模型巨頭同時變身「顧問公司」?

    表面上,The Deployment Company 和 Anthropic 新創是「幫企業導入 AI」。但從資本結構與合作對象看,本質是:模型公司往下整合到最後一公里的變革工程

    • OpenAI:募資 >40 億美元,專門做企業部署,從銷售、方案設計到落地運維一條龍,直接瞄準大企業預算盤。
    • Anthropic:不是自己養一支龐大顧問隊,而是與 華爾街私募+系統整合商 成立新公司,先吃 中型企業 的 Claude 導入需求。
    • 同一時間,雲端三巨頭的 AI 帶動雲收入爆衝Google Cloud +63%、Azure +40%、AWS +28%,而頂尖模型公司對雲的承諾層級動輒百億甚至 Anthropic 對 Google Cloud 的 2000 億美元五年承諾,把整個故事鎖定在「算力+部署」雙重賭注。

    💡 關鍵: 從「>40 億募資」到「2000 億承諾」,顯示資本已從單買模型,轉向重押「算力+部署一體化」的變革工廠。

    這裡有三個關鍵認知轉向:

    1. 模型不再是產品,而是原料。
      企業買的不是「一個 API」,而是「能讓組織 KPI 動起來的變革專案」。模型只是原料,真正能開票的是顧問方法論+成功案例庫。

    2. 銷售 AI 的瓶頸,不在演算法,而在組織。
      很多企業 CTO 的真實痛點是:合規、流程重設、權限治理、舊系統整合、員工再訓練——這些全部是「部署層」問題,傳統模型供應商不碰,現在 OpenAI/Anthropic 決定親自下場。

    3. 資本不再只買參數量,而是買「變革工廠」。
      Blackstone、Goldman Sachs 這些玩家進來,不是因為愛 AI,而是看到:如果能把「導入 AI」變成一套可複製、可擴展的工廠流程,就可以在投資組合公司裡批量複製生產力提升與成本削減,等於是新的金融槓桿工具。

    結論:從 OpenAI 與 Anthropic 同步動作可以確定,下一輪競爭不在模型排行榜,而在「誰掌握企業 AI 的部署層與顧問話語權」。


    二、部署層吃進來,誰被擠到邊緣?

    當模型公司變成「顧問+SI」,原本的價值鏈會發生三件殘酷的事:

    1. 雲服務商:從「平台」變成「賣算力」的上游供應商

    在這波布局裡,OpenAI/Anthropic 緊抱 Azure / Google Cloud,但他們不是幫雲賣方案,而是吸走應用層的策略主導權

    • 雲廠仍然賺得到錢,但越來越像 「電力公司」
    • Capex 繼續狂飆(TAI 報告提到大廠未來幾年資本支出接近 千億美元級別)。
    • 卻無法掌控企業的 AI 路線圖與數據策略,因為那些是掌握在部署公司手裡。
    • 這對雲端原本期待的「平台 lock-in」是反向的:
    • Lock-in 發生在模型與部署方法論上,而不是在雲平台 API 上。

    2. 系統整合商(SI):風險是被巨頭「外包化」

    對傳統 SI 來說,最糟糕的劇本是:

    • OpenAI/Anthropic 設計方案、掌握客戶關係與資料策略
    • SI 只做:
    • 接舊系統
    • 寫 Glue code
    • 做客製化前端

    也就是說,SI 被變成部署巨頭的「勞務外包工程隊」:有 revenue,沒話語權;有工時,沒資產累積。

    更糟的是,部署公司會接觸大量真實場景,形成橫跨產業的「用例資料庫+最佳實踐模板」,下一個客戶就可以直接複用,進一步壓縮 SI 的方案設計價值。

    3. 傳統顧問公司:PowerPoint 壕溝正在被 AI 侵蝕

    McKinsey、BCG 等顧問過去最大的 moat 是:

    • 巨量案例與產業 know-how
    • 能幫 CEO 把變革寫成 PowerPoint 與路線圖

    但現在:

    • AI 可以自動生成決策報告與方案草稿
    • 部署公司握有真實運行中的 AI 系統數據,可以給出「在 200 家類似公司裡,這樣調整流程平均能提升 18% 生產力」這種高可信度的量化建議

    💡 關鍵: 當顧問報告可由 AI+跨客戶數據自動生成,傳統顧問公司的核心「案例與洞察壕溝」正在被系統性稀釋。

    當顧問的洞察不再是專屬資產,而是 AI+跨客戶數據庫的副產品,他們的 PowerPoint moat 正在被系統性稀釋。


    三、對企業端:短期好處,長期鎖死?

    從 CIO/CTO 角度看,這波「部署公司」有明顯的短期甜頭,也有被低估的長期風險。

    短期:風險轉移與導入效率暴增

    • 一站式整合
    • 模型選型、架構設計、PoC、合規、變革管理,一個團隊搞定,比自己組織內部拉專案組要快得多。
    • 最佳實踐快取
    • 部署公司帶著跨產業成功案例與模板,等於把別人踩過的坑全部 productize 成 SOP,企業可以跳過大量 trial-and-error。
    • 對董事會的說法好交代
    • 「我們與 OpenAI / Anthropic 合作」本身就是一張政治保險單,萬一專案失敗,也可以說是「產業標準尚未成熟」。

    長期:技術路徑與核心能力被「外包」的風險

    1. 技術與數據路徑被鎖死
    2. 部署公司會自然偏好自家模型與雲合作夥伴,
    3. 企業在資料標註、流程重構、權限設計上,全部繞著某家模型 API 打造。
    4. 轉向開源或本地方案的成本會隨時間指數上升。

    5. AI 能力被外包,內部只剩「使用者」

    6. 若關鍵的 Prompt 設計、Agent 架構、評估基準、風險治理全交給外部,
    7. 公司內部將缺乏真正懂 AI 系統行為與 trade-off 的技術決策者,
    8. 最終變成:AI 是一個黑箱服務,組織只會「發需求」而不會「設計系統」。

    9. 議價權與數據主權弱化

    10. 當企業營運越來越依賴一組「外部 AI 工作流」,
    11. 模型供應商調價、變更政策、限制遷移時,
    12. 企業的可選項只剩「吞下去」或「砍掉重練」。

    💡 關鍵: 部署公司幫企業快轉 3 年,同時也可能把技術路徑和資料綁死 10 年,代價是長期議價權與技術主權。

    簡單說:部署公司幫你加速 3 年,也可能幫你鎖死 10 年。


    四、這是雲戰 2.0,還是壟斷前奏?

    Anthropic 對 Google Cloud 5 年 2000 億美元承諾、OpenAI 與 Azure 的深度綁定,加上大廠動輒 千億級 capex,共同構成了一個事實:

    算力戰已經進入「模型巨頭+雲巨頭」的聯盟戰,部署層是他們建立新壟斷的前線。

    這對 中端開發者、本地/開源方案 的擠壓會出現在三個層面:

    1. 心智空間被「標準方案」佔滿
    2. 當 OpenAI/Anthropic 的部署團隊變成「企業 AI 的預設選項」,
    3. 中小型開發公司變成「補洞」角色,只在標準方案以外的小角落接外包。

    4. 資源與資料紅利集中

    5. 部署公司看到跨產業的真實運行數據,
    6. 能比任何開源社群更快迭代出穩定可用的模板與工具,
    7. 長期形成資料與方法論的雙重 Compounding 優勢

    8. 監管與合規成本成為護城河

    9. 未來若監管要求更嚴(模型審計、數據本地化、風險報告),
    10. 大型部署公司反而樂見其成:因為他們可以吸收這些成本,
    11. 開源與本地方案則被迫面對合規成本,進一步邊緣化。

    這更像是雲戰 2.0:第一輪比的是 IaaS/PaaS;第二輪比的是「誰把部署層與變革方法論變成標準件」。


    五、技術人與創業者:要避的坑與可守的位置

    如果你是產品/技術領導者或創業者,面對這波「部署公司化」,有三件事必須立刻做決策:

    1. 拒絕把核心能力完全交給外包
    2. 即使與 OpenAI/Anthropic 合作,也要在內部建立:
      • 模型評估與選型能力(能比較封閉模型與開源模型的 trade-off);
      • Prompt/Agent 設計與評測框架
      • 資料治理與風險管理的自有準則
    3. 把外部部署公司視為「加速器」,而不是「大腦」。

    4. 刻意設計「可替換性」與「多模型」的架構

    5. API 層一開始就做抽象,不讓任何單一模型供應商寫死你的業務邏輯;
    6. 核心業務流程盡量用可自託管的開源模型建立備援路徑;
    7. 把「切換供應商」視為必要工程,而不是罕見事件。

    8. 創業者的價值定位:避開「被巨頭吃掉的層」

    9. 不要去做「幫 OpenAI 寫客製化前端」這種註定被內建的工具;
    10. 尋找巨頭不願碰或碰不了的區域:
      • 高度垂直的行業流程與合規細節(醫療、政府、製造 OT 等);
      • 本地部署+極高隱私要求的場景;
      • 幫企業建立 「多模型治理與觀測層」 的工具與平台。

    最後的判斷是:企業 AI 的勝負不再看誰的模型跑分高,而是看誰控制「部署層+變革方法論」;但對技術人與創業者來說,真正能防守的價值,將來自你能否在巨頭主導的部署生態中,建立一個不依賴單一模型供應商、仍保有技術主權與議價權的位置。現在不做架構與策略上的防禦,兩三年後,你只剩簽約的份。


    🚀 你現在可以做的事

    • 盤點公司內部 AI 專案與供應商,畫出目前的「部署層+模型」依賴圖,標出潛在鎖死點
    • 設計一層抽象的 AI API 或「多模型路由層」,先在一個業務流程上實驗切換不同模型供應商
    • 若你是創業者,挑一個垂直行業(如醫療或製造),訪談 5 家企業,找出巨頭部署公司尚未解的高合規或本地化痛點,以此為題做 PoC