Agent 平台的護城河：模型之外，什麼留得住

模型可以換，公司的狀態搬不動。

今天選擇 Claude、GPT、Gemini 或開源模型，明天可能因成本、延遲、資料政策或能力更新而改用另一個。真正困難的是搬走員工身分、專案記憶、內部系統整合、批准規則、事故紀錄，以及團隊已經習慣的工作流。

當模型、工具協定與基本 Agent loop 越來越可替換，平台長期價值會向五個難搬動的層次集中：Identity 與 Policy、Memory 與 Durable State、Connector 與公司資料語意、Evaluation 與 Audit，以及被員工真正採用的 Workflow。

這是根據目前開源專案與協定發展做出的產業判讀，不是已被市場證明的定律。第一季從 YC 開源 QM出發，最後要回答的就是：如果 Agent 本身越來越普及，平台還能留下什麼？

Agent 平台從可替換能力走向累積型護城河的五層架構 — 左側模型、協定與基本 loop 越來越可替換；右側身分、狀態、整合、稽核與工作流會隨組織使用持續累積。這是本文的產業推演框架。

哪些 Agent 能力正在標準化？

Agent 產品早期常把「能呼叫工具」當成核心差異。現在，連接層正在形成公開協定。

Model Context Protocol（MCP）提供 AI 應用連接工具、資料來源與工作流的共同介面。Agent2Agent（A2A）則讓不同 Agent 系統發現彼此能力、協作處理任務，並交換文字、檔案與結構化資料。Google 將 A2A 規格、SDK 與開發工具移交給 Linux Foundation；由中立基金會治理，增加了它成為跨廠商協作基礎的可能性。

同時，開源 harness 讓 agent loop 變得更容易替換。QM 公開支援 Pi、OpenCode、Claude Code 與 Codex；OpenClaw 和 Hermes 也讓使用者在模型、技能及工具之間做選擇。三者的信任邊界與部署方式並不相同，前一篇的 QM、OpenClaw、Hermes 選型比較已拆開說明。

這些變化不代表 Agent 已經完全標準化。MCP server 的安全、tool semantics、模型差異、上下文格式與長任務可靠性仍有大量實作落差。但平台若只把「我們也能呼叫工具」當成唯一賣點，差異會越來越難維持。

容易商品化的三層

以下是趨勢判斷，不是宣告市場已經完成商品化。

基本 Agent Loop

將任務送給模型、解析工具呼叫、執行工具、把結果送回模型，這個基本循環已出現在大量 SDK 與開源專案。可靠性仍需要工程，但單純擁有 loop 的稀缺性正在下降。

通用聊天介面

Web chat、CLI、Slack bot 和 messaging gateway 都很重要，卻容易被競爭者複製。介面只有在承接獨特 workflow、資料與組織政策時，才會變成更深的產品價值。

單一模型 Wrapper

只替某個模型加上 prompt、幾個 API 和品牌介面的產品，最容易受到模型供應商原生功能擠壓。模型品質提升時，它可能受益；供應商直接加入同樣 workflow 時，它也最先失去差異。

因此，「支援最多模型」應被視為平台能力，而不是單獨的護城河。真正值得保留的是換模型之後仍然存在的組織資產。

第一層護城河：Identity 與 Policy

公司不只需要登入。它需要知道 Agent 正在代表員工、專案、部門還是服務帳號；使用者能否代表該 principal；這次任務能用哪些資料和工具；結果又可以交付給誰。

這些政策會連到既有 SSO、目錄、角色、客戶 tenant、資料分類與離職流程。每間公司的例外也不同：某些工程師可讀正式日誌但不能匯出，某些客服可提出退款卻必須由主管 commit。

模型供應商可以提供更聰明的推理，卻不會自動理解這套組織權限。平台一旦把企業規則轉成可執行 policy，又能在每次工具呼叫重新計算，替換成本就不再只是換 API key。

QM 將使用者與 room 建成 scope，正好顯示控制面開始圍繞身分而不是對話。這不是 QM 已經建立商業護城河的證明，而是架構重心轉移的訊號。

第二層護城河：Memory 與 Durable State

對話紀錄很容易匯出，能正確延續工作的狀態則難得多。

公司 Agent 的 durable state 包括專案決策、已批准計畫、工作產物、任務 queue、checkpoint、失敗重試、資料來源、保留期限和 scope 所有權。它必須在模型、Agent loop 甚至員工變動後仍能維持一致。

記得越多不一定越有價值。真正的產品能力是知道什麼應該記、寫到哪個 scope、由誰驗證、何時淘汰，以及如何證明某個結果使用了哪個版本的記憶。

這些狀態會隨使用時間累積，也與工作流程互相塑造。若平台能把它們存成可攜、可稽核的格式，使用者會更信任；若故意讓它們無法匯出，雖然形成 lock-in，卻可能阻礙企業採用。

第三層護城河：Connector 與公司資料語意

「連上 Salesforce」和「知道這家公司如何使用 Salesforce」是兩個不同層次。

通用 connector 能提供物件與 API；公司內部語意則包括欄位實際用途、狀態轉換、例外處理、資料 owner、跨系統 ID 映射和歷史包袱。這些知識通常散落在程式碼、SOP、員工經驗與事故紀錄中。

MCP 可以降低連接工具的格式成本，卻不會自動回答：取消訂單前要檢查哪三個系統？哪一種客戶不能走自動退款？哪個欄位看似可寫但其實由 nightly job 覆蓋？

因此 connector 的深度會比數量重要。少數真正理解公司語意、權限與錯誤模式的連接，可能比大量只暴露原始 API 的工具更有價值。

第四層護城河：Evaluation、Audit 與 Incident Response

Agent 的輸出不是固定函式。模型、context、工具與外部資料都會變，平台必須持續知道「它現在還能不能安全完成這件事」。

成熟的 evaluation 不只測答案相似度，還要測：

是否選對工具與參數
是否遵守 scope 和資料政策
是否在不確定時要求批准
是否能抵抗惡意文件與 tool metadata
重試是否造成重複副作用
換模型或版本後，哪些工作流退化

Audit 則把一次真實行動的 actor、principal、輸入、版本、政策、工具和交付串成事件鏈。Incident response 進一步把這些證據轉成撤銷、隔離、通知與復原流程。

這套測試與事件資料高度貼近公司的實際風險。競爭者可以複製你的 UI，卻拿不到累積多月、已由 owner 驗證的 failure cases。

第五層護城河：被員工真正採用的 Workflow

平台最後仍要回到工作。如果員工只在 Demo 日打開一次，再完整的控制面也不會產生價值。

真正被採用的 workflow 通常經過很多不起眼的磨合：輸入從哪裡來、誰負責例外、何時要批准、結果放在哪裡、怎麼和現有會議及 SOP 接軌。這些細節會讓 Agent 從額外工具變成工作系統的一部分。

採用本身不能靠 lock-in 製造。好的平台應讓人看得懂、能修改、能停用，也能在必要時匯出工作流。護城河不是把客戶困住，而是持續累積可靠性、組織知識和改善速度，讓搬走代表放棄已驗證的運作能力。

兩週低風險試點之所以從單一 workflow 開始，就是因為產品價值必須先在真實工作裡成立，控制層才有值得治理的東西。

三種可能勝出的公司 Agent 平台

平台類型	核心優勢	主要挑戰	可能的護城河
水平 Control Plane／Agent IT	跨模型、跨工具統一管理	必須整合複雜既有環境	身分政策、部署、稽核、fleet operations
垂直產業 Agent 平台	深入特定產業資料與流程	市場較窄、需承擔領域責任	垂直語意、評估資料、合規與 workflow
既有 SaaS 內建 Agent	已掌握使用者、資料和介面	容易形成封閉 silo	原生資料權限、既有採用與交易入口

水平 Control Plane／Agent IT

這類平台像公司 Agent 的作業系統：提供身分、scope、policy、sandbox、排程、模型路由、稽核與成本管理，再讓不同 agent loop 執行。QM 顯示了開源版本可能長什麼樣。

它的優勢是中立與跨系統，挑戰是整合面巨大。若只做一層薄 dashboard，很容易被雲端、模型供應商或既有 IT 平台吸收。

垂直產業 Agent 平台

法律、醫療、金融、製造或電商平台可以深入單一領域的資料模型、審核規則與例外流程。它們不一定支援最多工具，卻更知道什麼是正確結果、什麼動作需要誰負責。

這條路的護城河可能來自領域評估集、合規流程、專有 connector 與長期 workflow 資料；代價是需要承擔更高的專業與安全責任。

既有 SaaS 內建 Agent 與治理層

既有 SaaS 已掌握使用者身分、資料權限和日常介面。它們不必說服員工搬到另一個聊天視窗，就能把 Agent 放進原本的 CRM、客服、文件或開發流程。

弱點是每個 SaaS 都可能形成自己的 Agent silo。企業最後仍需要跨產品的政策、稽核與資料邊界，這會留下 control plane 或開放協定的空間。

三種形態很可能共存，而不是由單一平台吃下所有層。

開源專案與獨立開發者的機會

模型與 loop 開源，不代表所有價值都被大公司拿走。相反地，標準化底層能讓小團隊更專注於缺口：

Deployment tooling：用可重建方式部署 core、database、runner 和 gateway。
Scope-aware skills：讓技能原生理解 principal、memory、credential 和 audience。
Audit／Eval：替真實工具行動建立可重播測試與事件調查。
Migration：搬移 workspace、memory、skill、connector 與 workflow，降低平台綁定。
Vertical connector：處理特定產業真正的欄位語意、權限與例外。
Incident tooling：批次撤銷、隔離 sandbox、封存證據並還原 timeline。

這些工具不一定像新的聊天介面那麼容易 Demo，卻更接近公司需要長期維運的問題。開源也能成為信任優勢：企業可以檢查資料流、部署在自己的邊界，並在供應商消失時保留系統。

對寫作者或研究者而言，口述訪談可以先用 Typeless 整理成草稿，再逐項回查文件與受訪者確認；這是聯盟連結，若透過連結註冊，我們可能獲得少量分潤，不影響你的價格。產業判讀仍應明確分開官方事實、架構推論與個人預測。

第一季結論：不要把護城河押在「支援最多模型」

QM 帶來的訊號，不是所有公司都該立刻部署 QM，而是公司 Agent 的競爭焦點正在從單一模型體驗移向組織控制面。

個人助手可以假設使用者信任自己；公司平台必須處理多個 principal、scope、memory、credential、sandbox 與 audience。連接能力越標準化，這些組織狀態就越重要。

我們的明確立場是：模型選擇要保持彈性，但產品護城河不要押在支援最多模型。 應投資在換模型後仍會留下的身分政策、長期狀態、內部語意、評估證據與真實工作流。

第二季值得追問的是：當 Agent 開始彼此委派工作，組織如何把 scope 與責任沿著 A2A 連線傳下去？協定能傳遞任務，但信任、成本和事故責任仍需要平台回答。

常見問題

AI Agent 平台最重要的護城河是模型嗎？

模型能力很重要，但單純支援某個模型不容易形成長期差異。更難搬動的是組織身分與政策、長期狀態、內部整合、評估稽核，以及真正被採用的工作流。

MCP 和 A2A 會讓 Agent 平台商品化嗎？

它們可能降低工具與 Agent 互通成本，但協定不會自動解決組織授權、資料語意、事件調查與工作流採用，因此只會標準化部分連接層。

開源 Agent 專案還有商業機會嗎？

有。部署工具、scope-aware skill、權限與稽核、評估系統、遷移工具及垂直 connector，都能在開源 loop 之上提供難以被通用模型取代的價值。

公司應該避免模型綁定嗎？

應保留可替換模型的能力，但不必追求每個模型都能無差別切換。重要的是把身分、狀態、政策和事件紀錄留在模型供應商之外。