用 Agent 賣給 Agent · AI LEAN STARTUP

OPC 商業模式的新形態，是你的 Agent 自動找到並服務另一個創業家的 Agent、完成交易——你不用逐筆介入，但價格、品質標準、什麼時候要升級給你，都是你定的。

這本書從第一章開始說的核心邏輯是：你是 AI 的老闆，Agent 幫你工作。你設計目標，Agent 執行。

但有一個更進一步的形態：

你的 Agent，自動找到其他創業家的 Agent，自動完成銷售，自動交付產品，自動處理服務。你不用逐筆介入。

不是你在賣。不是你的 Agent 在幫你賣給人類客戶。是你的 Agent，直接服務另一個 Agent。

這是 OPC 商業模式的一種新形態，也是 2026 年正在開始發生的事。

運作邏輯很直接：

一個 OPC 創業家做了一個 Agent 能呼叫的工具——API 或 MCP 工具，部署上線，設定好文件和計費。另一個創業家的 Agent，在執行工作流的過程中發現需要這個能力，透過 API 呼叫它，自動完成交易，拿到結果，繼續跑下一步。

交付自動、收費自動，但這不代表你不用管——是不需要你逐筆盯著。 定價、服務範圍、什麼情況要中止交易，這些標準一開始就是你訂的。系統照你的標準跑，異常才會被拋回給你。

這個模式已經有真實的基礎設施在支撐。A2A（Agent-to-Agent）協定是 Google 推動的開放標準，讓不同平台上的 Agent 直接交談——驗證身份、委派任務、拿到結果，全程不需要人逐次介入。

把它想成網路時代的 HTTP，只是對象從瀏覽器換成了 Agent。一個 Agent 不需要知道對方用什麼框架建的、跑在哪裡——雙方都說 A2A，就能直接交易。

你做的 MCP 工具或 API，就是這個 Agent 經濟裡的一個節點。

組件一：一個可以被 Agent 呼叫的產品。 前幾章說的：API-first、清楚的文件、穩定的可靠性、按呼叫計費。能在你不逐筆介入的情況下被自動使用——但服務條件、品質底線，仍然是你定義的。

組件二：出現在 Agent 能找到你的地方。 人類客戶在 Google 找到你，Agent 不是。Agent 找工具的渠道：

MCP 目錄：支援 MCP 的工具有目錄，Agent 需要特定能力時在這裡查詢。上架 MCP，你就出現在 Agent 的工具清單裡。
GitHub 和開發者文件：很多 Agent 工作流是開發者設定的，他們在 GitHub、npm、PyPI 搜尋工具。
其他 Agent 的推薦：一個 Agent 回答「我需要查台灣電商數據」的時候，如果你的工具文件清楚，LLM 可能直接把你的 API 推薦給它。這個現象正在發生。

組件三：自動化的交付和客服，但標準由你設。 另一個 Agent 呼叫你的服務，你不能等上線了才處理。API 直接回傳結果，帳單自動計算，異常自動通知——客服 Agent 處理你事先定義好的基本問題，真正需要判斷的，還是升級給你決定。

這個架構建起來之後，有一個值得說清楚的現實：

你的產品被用了幾萬次。你知道這件事，是因為你看了儀表板上的使用量報表——不是因為你親自處理了幾萬個請求。

你建立了一個系統，這個系統照你定的標準自動服務別人的系統、自動收錢——你不用逐筆在場，但你仍然是定義規則、審核異常、決定要不要調整的那個人。這跟這本書一貫的 Boss Engineering 邏輯是同一件事：AI CEO 不是你，但你永遠保留定標準、審核的權力。

「用 Agent 賣給 Agent」聽起來很遠，起點很具體：

第一步：選一個你有的知識或能力，能做成 API 或 MCP 工具的。不需要複雜——一個 Prompt 模板包裝成 API、一個整理好的數據集做成查詢介面、一個自動化任務做成 MCP 工具。

第二步：用 Claude Code 做出來，部署上線，寫好 API 文件。文件比程式碼更重要——沒有好文件，你的工具在 Agent 眼中等於不存在。

第三步：上架到至少一個 Agent 能找到你的地方——MCP 目錄、GitHub、你網站的 API 文件頁。

第四步：等第一個 Agent 來呼叫你，同時設好異常通知——什麼情況要立刻讓你知道。

這個過程，用 Claude Code 一週內可以完成。

這本書從第一章說：一個人加上 Agent，可以做到以前需要一個團隊的事。

走到這裡，你看到了更完整的圖景：不只是一個人用 Agent 做事，是一個系統在自動運作——你設計了系統、定了標準，系統服務其他人，其他人的系統使用你的系統，收入在流動，而你可以去想下一個問題。

不是更努力工作。是設計出一個不需要你逐筆介入、但仍在你標準之內運作的系統。

Agent 賣給 Agent，是這個形態目前最前沿的表現。你現在站在這個機會的最前面。