The Agent Is Not the Product

原始來源與檔名：2026-06-26T093317+0800-The Agent Is Not the Product.md

SOURCE | 資訊源評估

• 準確性: 高 - 作者結合了多位企業級 AI 創業者的實戰訪談，論點建立在真實的 B2B 落地經驗上。
• 易理解性: 高 - 清晰區分了「確定性自動化」、「Agent」與「人類」的三者邊界，易於對齊認知。
• 閱讀策略建議: 適合在制定 AI 導入預算或評估內部自動化專案時，作為高階架構與商業決策的參考指南。

NAPKIN | 餐巾纸

餐巾纸公式

企業 AI 轉型 = 流程重構 (Process Reengineering) > 模型能力 (Model Capabilities) 把 Agent 硬塞進壞掉的流程裡，只會得到自動化的災難。

一句话

Agent 本身不是產品，真正的產品是將企業部落知識 (Tribal Knowledge) 轉化為結構化邏輯，並重建營運模式的「部署過程」。

餐巾纸草图

[確定性自動化 (軟體)] -> 處理「規則」
[Agent (AI)]        -> 處理「上下文判斷」
[人類 (Human)]      -> 處理「信任、模糊性與當責」

ROUND 1: SKELETON | 骨架掃描

“這篇文章在說什麼”

• 核心問題: 為什麼即使 AI 模型能力不斷提升，多數的企業級 AI 部署仍然以失敗收場？
• 核心答案: 因為企業搞錯了問題。真正的問題不是「如何把 AI 塞進預算」，而是「如何重構破碎的營運流程」。
• 論證結構: 歸納型與觀點論證（破除迷思 -> 劃定邊界 -> 重新定義產品 -> 護城河分析）。

章节骨架

1. 問題重構: 不是模型問題，是流程問題。
2. 三界分立: 軟體、Agent 與人類各自該做什麼。
3. 部署即產品: 捕捉與清理「部落知識 (Tribal Knowledge)」。
4. 現代化 != 遷移: 在舊系統上建構 Agent 邏輯。
5. 模式庫: 累積的部署經驗才是真正的護城河。

ROUND 2: DISSECTION | 血肉解剖

“憑什麼這麼說”

隐形假设与边界

• 隱形假設:
  • 企業內部的「部落知識」雖然充滿補丁 (Scar tissue)，但仍具有被提取與清洗的價值。
  • 企業不會願意將核心依賴綁定在單一的大模型供應商 (如 OpenAI/Anthropic) 身上。
• 邊界條件:
  • 如果底層架構（如 ERP 權限、資料整潔度）過於脆弱，建立在其上的 Agent 只是在「自動化功能失調」，最終仍會崩塌。

ROUND 3: SOUL | 靈魂提取

“還能怎麼用”

• 知識連接: 軟體工程中的「康威定律 (Conway’s Law)」；企業管理中的「BPR (Business Process Reengineering)」。
• 行動觸發: 在啟動下一個 AI 專案前，先問：「這個流程如果不用 AI，能用傳統軟體解決嗎？」如果能，就不該用 Agent。

留白提問 (Guided Reflection)

• 你的公司內部，有哪些流程是建立在「補丁」和「工作繞道 (Workarounds)」上的？你確定要讓 Agent 學習這些錯誤姿勢嗎？
• 當向第一線員工導入 AI 時，你是在推銷「取代方案」，還是在推銷「更好的工作日」？

DEEP READ | 精讀指引

[!IMPORTANT] 學習的本質需要「認知阻力」。請親自回到原文閱讀以下核心段落，感受原始論述的阻力，不要只依賴 AI 的總結。

1. Not every workflow needs an agent: 清晰劃定了 Deterministic automation (規則), Agents (上下文判斷), 與 Humans (當責) 的界線，是極佳的決策框架。
2. The deployment is the product: 點出捕捉 Tribal knowledge 的陷阱（不要把組織的功能失調也自動化了），這是極高密度的實戰洞見。

The Agent Is Not the Product (Architectural Deep Dive)

前言/背景

隨著 AI 模型能力的基準線逐漸拉高，為何企業導入 AI 依然頻頻失敗？本文提出一個核心論點：Agent (代理) 本身並不是產品。真正的價值在於「流程重構 (Process Engineering)」，以及透過部署過程，將深埋於企業內部的「部落知識 (Tribal Knowledge)」轉化為結構化的營運邏輯。

章節詳細總結

1. 並非所有工作流都需要 Agent

導入 AI 的第一個問題是「知道什麼不該交給 Agent」。作者提出了一個精準的三分法架構模型：

• Deterministic automation is for rules (確定性自動化處理規則)：如果輸入是結構化的，且行為可預測，你不需要 Agent，你需要的是「軟體」。例如：發票路由、CRM 欄位同步。
• Agents are for judgment under context (Agent 處理基於上下文的判斷)：當工作需要解釋輸入、跨系統提取上下文，或根據發現改變執行路徑時，Agent 才是合理的選擇。
• Humans are for accountability, ambiguity, and trust (人類處理當責、模糊與信任)：因為後果太嚴重，或組織還不知道「正確」長什麼樣時，AI 只能作為 Copilot 或 QA 層。

架構洞察：技術決策者必須評估 ROI。「10倍 ROI 的工作流應該優先，2倍的可能要考慮，低於 1倍的請別碰。」最痛苦的流程未必是最值得自動化的。

2. 部署過程本身就是「產品」

企業中許多工作流存在於人們的大腦中，被稱為「部落知識 (Tribal Knowledge)」。

• 陷阱：這些知識中有很大一部分不是真正的專業，而是為了應付破舊系統而產生的「繞道工作法 (Workarounds) / 補丁 (Scar tissue)」。如果直接把這些抓取並編碼到 Agent 中，你只是在**「自動化組織的功能失調 (Automated the dysfunction)」**。
• 雙重推銷 (Two Sales)：成功的 AI 導入需要賣給高層「結果」，同時賣給操作員「更好的一天」。沒有第一線操作員的買單，部署必定失敗。
• 學徒模式 (Apprenticeship model)：導入 Agent 就像訓練一個新進員工，核心產出不是模型，而是工作流地圖、例外分類法、決策規則與邊界測試庫。

3. 現代化不等於系統遷移 (Modernization != Migration)

對多數企業來說，硬生生拔掉現有的 ERP 或 CRM 是不切實際的。

• 在舊系統上建構：最好的做法是在現有系統之上 (Build on top) 建立 Agent，讓 Agent 獲得跨系統執行的上下文。
• 邊界條件：如果底層資料不乾淨、權限機制損壞，在上面建構 Agent 只會變成災難。現代化不再只是「將舊程式碼翻新給開發者看」，而是**「讓舊有的營運流程能被 Agent 讀懂並執行」**。

4. 模式庫 (The Pattern Library) 才是護城河

為何大模型實驗室 (如 OpenAI) 或傳統顧問巨頭 (如 McKinsey) 無法輕易吃下這個市場？

• 模型實驗室優化的是「可擴展的智力」，但企業轉型是高度客製化的，無法乾淨地擴展。
• 傳統顧問公司動作太慢，無法跟上 AI 系統每 6 個月就翻新一次的最佳實踐。
• 真正的護城河：來自於跨客戶部署時積累的「模式庫 (Pattern Library)」。例如，做過多次財務部門導入後，會學到財務部門的通病、評估框架與治理模型。這是無法輕易複製的 know-how。

總結與結論

• 工具錯置的危險：永遠不要用 LLM 去解決傳統 API 和 If-Else 就能解決的問題。Agent 應該被保留給高度依賴上下文判斷 (Context-dependent judgment) 的場景。
• 清洗業務邏輯先於寫 Code：在實作 Agent 之前，必須先進行「流程清洗」。將真正的業務邏輯與過去因系統缺陷而產生的 Workaround 剝離開來。
• 架構定位：Agent 不是萬靈丹，它只是一個「機制 (Mechanism)」。企業需要的是在確保當責 (Accountability) 的前提下，重新架構軟體、AI 與人類的協作邊界。