AI LEAN STARTUP
← 目錄草稿中更新於 2026-06-27

用 Agent 免費做出產品

這是一份公開草稿。內容還在迭代，歡迎一起把它變得更好。

MVP 大商機——超過 10B 的新受眾

你卡在哪裡

CH04 說了怎麼在 24 小時打造 MVP、用哪些零成本工具、怎麼先銷售再建造。

方法有了。但很多人還是卡住，卡在一個更前面的問題：

「我不知道要做什麼產品。」

你看了一圈市場，每個方向都有人做了。想到一個點子，Google 一下，三個一模一樣的競爭者。想做 SaaS，已經是紅海。想做內容，流量越來越難。想做服務，規模做不大。

這個卡關，不是你不夠努力。是你一直在看同一個市場。

這一章給你一個具體的答案：有一個幾乎無人競爭的全新市場，正在 2026 年快速打開，而大多數人還沒有看見它。

所有人都在搶同一批客戶

2026 年之前，所有人的 MVP 邏輯都一樣：找一群有痛點的人，做一個解決他們問題的產品，讓他們付錢。

目標受眾是人類。

這個邏輯本身沒錯，問題是：**幾乎所有人都在競爭同一批受眾。**每天數萬個 App 上架，數萬個落地頁在 Google 競價。每個你能想到的痛點，都有人做了，或正在做。

但就在這場競爭白熱化的同一時間，一個全新的受眾群正在悄悄形成——不在 App Store，不在社群媒體，不在 Google 廣告覆蓋的任何地方。

一個正在被忽略的新市場

全球正在運行的 AI Agent 數量，2025 年底超過了 10 億。2026 年的數字，已經沒有人敢給出上限。

每個 OPC 創業家部署著多個 Agent。每個大型企業在把業務流程交給 Agent。每個開發者在自己的服務裡嵌入 Agent 功能。

而這些 Agent，需要工具。需要數據。需要能呼叫的服務、能讀取的知識庫、能連接的 API。

它們是消費者——只是不是人類消費者。

人類市場 vs Agent 市場

你做一個給人類用的產品，受眾是某個族群的一部分。給台灣個人品牌主的行銷工具？市場可能十萬人。你要找到他們，說服他們，讓他們付錢，還要讓他們留下來。

你做一個給 Agent 用的工具，受眾是每一個需要這個能力的 Agent——不限地區、語言、產業。

更關鍵的是：Agent 不需要被說服，不需要廣告，不需要情感驅動。 Agent 只在乎：這個工具能不能呼叫，有沒有文件，穩不穩定，價格合不合理。

人類市場Agent 市場
受眾規模上限人口數Agent 數（持續增加）
購買決策情感 + 邏輯 + 社會認同功能符合 + 文件清楚 + 穩定
獲客方式SEO / 廣告 / 社群API 文件 / MCP 目錄
使用頻率人類習慣（有限）24 小時，每天大量呼叫
競爭現況高度飽和幾乎無人競爭
行銷預算需要幾乎不需要

這個市場有多大：真實數字

不是猜測，是資本市場用真金白銀驗證過的數字。

AI Agent 平台市場 2025 年底達 78 億美元，預估 2034 年 684 億——增速是傳統 SaaS 的三到五倍。2025 年全年，全球創投向 Agentic AI 投入 242 億美元、1,311 筆融資，幾乎等於這個領域過去十年的累計投資額，全部壓在一年內。

Y Combinator 最新班級，近半數是 AI Agent 公司。MCP 的 SDK 每月下載超過 9,700 萬次。Visa 追蹤到 AI Agent 對零售網站的流量，年增 1,200%。

一個人類用戶每天用你的產品十分鐘。一個 Agent 每天可能呼叫你一萬次。

你服務的不是用戶數。是呼叫次數。

為什麼現在是最佳時機

任何新市場都有視窗期——競爭者大量湧入之前，早進入的人用極低成本佔領位置。

2010 年進 App Store 的開發者，幾乎零推廣成本積累幾十萬下載。2015 年進 Shopify 生態系的插件開發者，用一個簡單工具建立穩定收入。

Agent 工具生態，現在就是 2010 年的 App Store 時刻。

MCP 剛被大量平台採用，工具目錄才剛形成，大多數開發者還在做給人用的東西。先進入的人，會在生態系裡佔到位置——進入成本低，競爭幾乎為零，需求每天增加。

這不只是技術機會，是商業機會

有人看到這裡會想：「這是給工程師的機會，我沒有技術能力。」

不是的。

你不需要是工程師。你需要的是理解 Agent 需要什麼，然後用 Claude Code 把那個需求做出來。

技術門檻，Claude Code 解決。商業判斷——Agent 的需求是什麼、哪些需求還沒有好解法、怎麼定價——這才是你的核心工作，也是你的真正優勢。

接下來幾章，我們一層一層打開這個機會。從這個問題開始：Agent 到底需要什麼？

今天的第一步

讓你的 Agent 執行一個具體任務，觀察三件事：

  1. 它在哪個步驟需要呼叫外部工具，但找不到合適的？
  2. 它的輸出在哪個格式上不夠精準，需要你手動整理？
  3. 哪個環節它需要你介入才能繼續？

這三個摩擦點，就是你市場調查的起點。Agent 需要什麼，就是你下一個產品的方向。

滿足 Agent 的需求

Agent 很聰明，但工具不夠用

你讓 Agent 執行一個任務。它讀得懂指令，知道要做什麼，然後在某個地方停下來了——不是它不夠聰明，是它需要呼叫的工具不存在。

那個「工具不存在」的地方，就是你的市場缺口。

而且不只你的 Agent 在等那個工具。全球所有面對同樣任務的 Agent，都在等。你沒看到那個工具的原因，就是還沒有人做出來。

Agent 需要什麼，正是你的產品機會

問一個人類用戶需要什麼：更好的界面、更快的速度、更便宜的價格、更好的體驗。

問一個 Agent 需要什麼，你會得到完全不同的答案——也是一份幾乎沒有人在填的需求清單。

Agent 沒有「體驗」的概念。它不在乎 UI 好不好看，不在乎你有沒有客服，不在乎 onboarding 順不順。

Agent 在乎的是：我能不能呼叫你，你給我的輸出是不是我能直接用的格式，你會不會在我需要你的時候掛掉。

每一個人類產品做不到的事，就是一個 Agent 原生產品的市場入口。

Agent 的基本需求清單

一、溝通能力。

Agent 需要收發訊息——但不是用人類的方式。人類有 Email、電話、LINE。這些工具的設計前提是人類在操作：登入介面、驗證碼、「請確認你不是機器人」。每一個設計，都在擋 Agent 的路。

Agent 需要的，是能直接透過 API 收發訊息的溝通工具。沒有人類登入介面，沒有 CAPTCHA，收到的每封信都用結構化格式回給 Agent 處理。電話也一樣：傳統電話系統假設人在接聽；Agent 需要能程式化撥打接聽、即時轉文字、觸發後續工作流的電話 API——這塊基礎設施還遠遠不夠成熟。

二、身份與授權。

人類登入用帳號密碼、手機驗證、人臉識別。Agent 需要的是 API Key、OAuth Token、能在呼叫時自動附帶身份憑證的機制。

這個需求看起來基本，但大量現有服務——銀行、政府系統、第三方平台——還沒有提供 Agent 能直接使用的授權介面。巨大的空白。

三、數據與知識。

人類查資料用 Google、表格、PDF。Agent 需要一個能透過 API 直接查詢、得到結構化 JSON 回應的知識介面。

你有一個台灣中小企業的行業資料庫？對人類來說是一個網站。對 Agent 來說，是一個可以呼叫的 API：「台灣北部有多少家製造業公司員工數在 50 到 200 人之間」，直接回傳 JSON。

這種「Agent 可查詢的結構化知識庫」，是 2026 年幾乎無人在做的產品形態。

四、工具能力擴展。

一個純文字 LLM 不能查即時新聞，不能操作 CRM，不能寄 Email。但你給它一個工具——一個能呼叫的 API——它突然就能做到了。

MCP（Model Context Protocol）就是標準化這個機制的協議。你做一個 MCP 工具，Claude 以及所有支援 MCP 的模型就能呼叫它，不需要特別的整合工程。

這是目前最直接的「為 Agent 開發產品」入口。

你可以切入的缺口方向

方向一：本地化商業數據 API。 Agent 做市場研究需要查特定地區的商業數據。以台灣為例，工商登記、營業稅資料、產業分布等公開數據存在，但沒有 Agent 能直接呼叫的結構化介面。把公開數據整理成 Agent 可查詢的格式，是明確的缺口。

方向二：垂直領域的 Agent 原生工具。 法律文件、財務試算、合規審核——高重複性、有標準格式的任務，Agent 本來就在做，但輸出品質不穩。做一個垂直領域的 MCP 工具，提供可靠的結構化輸出，比通用 LLM 更可信。

方向三：完整的 Agent 溝通工作流。 現有 Email 服務只解決「發信」。Agent 需要的是完整工作流：收信→解析意圖→分類→觸發動作→回覆。這個缺口目前沒有 Agent 原生的解法。

一個真實的案例：AgentMail，2025 年 Y Combinator 畢業的新創，2026 年 3 月完成 600 萬美元種子輪，General Catalyst 領投。

它做的事只有一件：讓 Agent 透過一個 API 呼叫，在毫秒內為自己生成一個真實的雙向收發信箱。傳統 Email 為人類設計——登入頁、驗證碼、速率限制，Agent 完全進不來。AgentMail 把這一切拿掉，只留下 Agent 需要的。

團隊後來發現一個預期之外的現象：越來越多 AI Agent 自己上網搜尋，自行呼叫 AgentMail 的 API 完成註冊、接收驗證碼，為自己生成信箱——全程沒有人類介入。

這就是 Agent 市場和人類市場最根本的差距：你的產品一旦讓 Agent 能用，它自己會找到你。

今天的第一步

不需要做一個平台，不需要解決所有問題。

從你自己的 Agent 出發：這一週你讓 Agent 處理業務，哪裡卡住了？哪個能力你希望它有、但它現在做不到？

把那個卡住的地方寫下來。就一個。不是清單，是一個具體的問題。

你的 Agent 遇到的問題，也是其他人的 Agent 遇到的問題。你解決了自己的問題，就做出了別人也需要的工具——而你的第一個用戶背後，是幾十億個有同樣需求的 Agent。

Agent 原生思維

你知道了 Agent 需要什麼，也看見了缺口。但問題來了：如果你用做人類產品的邏輯去設計，做出來的東西 Agent 根本用不了。

你需要一套新的設計語言。而這套語言，大多數人還不知道它存在。

先發優勢，藏在一套大多數人還不會的設計語言裡

當一個新平台出現，最早學會它規則的人，佔的優勢最大。

2008 年 App Store 開放時，第一批學會 iOS 設計規範的開發者，在對手還不知道「點擊區域不能小於 44px」的時候，已經在榜單上站穩了位置。

Agent 市場正在發生同樣的事。大多數人還在用人類產品的邏輯思考「怎麼做一個好產品」。但如果你的用戶是 Agent，那套邏輯幾乎全部失效。

懂這套新語言的人，就是現在的先發優勢持有者。

你設計產品時，腦袋裡的「用戶」是誰

每個產品設計師學的第一件事：了解你的用戶。用戶是誰，決定了介面、流程、引導、轉換的一切。

但如果你的用戶是 Agent，你過去學的「了解用戶」幾乎全部失效。

Agent 不需要 onboarding。不會被「首次使用優惠」打動。不會因為 UI 顏色不好看而跳出。不會在銷售頁停留。

從人類用戶思維切換到 Agent 原生思維，不是調整。是重建。

產品決策人類思維Agent 原生思維
界面精心設計的 GUI不需要 GUI，API endpoint 就是界面
文件影片教學、互動式引導清楚的 API 文件 + 範例請求回應
輸出格式人類可讀（圖表、排版）機器可讀（JSON、明確欄位）
錯誤處理友善的錯誤提示標準化 Error Code，讓 Agent 知道重試還是停止
定價月費訂閱按呼叫次數計費
可用時間工作時間24 小時，沒有下班
擴展受行銷能力限制隨 Agent 部署數量自動擴張

四個設計原則

原則一：API-first，沒有例外

設計功能時，第一個問題不是「界面長什麼樣」，是「API endpoint 長什麼樣」。

所有功能都必須能透過 API 呼叫——不需要人類介入，不需要點擊，不需要登入界面。如果有一個功能只能在 GUI 裡用，那個功能對 Agent 等於不存在。

先設計 API。GUI 是可選的附加層，或者根本不做。

原則二：結構化輸出，不留模糊空間

人類能處理模糊——「大概明天早上」「差不多 5 到 10 個」，人類會推斷、補上下文。Agent 不行。模糊的輸出對 Agent 是一個要重新解析的問題，增加錯誤率，降低工作流的可靠性。

範例，一個「查公司基本資料」的 API：

❌ 人類思維輸出：

萬泰科技是一家成立於 2015 年的台灣科技公司，目前員工人數約在 50 到 100 人之間，主要業務是 SaaS 軟體開發。

✅ Agent 原生輸出：

{
  "company_name": "萬泰科技股份有限公司",
  "founded_year": 2015,
  "employee_count_range": "50-100",
  "industry": "software",
  "business_type": "SaaS",
  "status": "active",
  "last_updated": "2026-05-01"
}

Agent 拿到第二個輸出，直接用 founded_year 做計算，用 status 做判斷，不需要再解析一段自然語言。

原則三：可靠性高於功能豐富

人類用戶可以接受偶爾出錯——重試、找客服、換個方式。Agent 不行。一個工作流裡有 10 個工具，其中一個失敗率 10%，整個工作流的可靠性掉到 35%——幾乎不能用。

對 Agent 原生產品，99%+ 的可靠性比 200 個功能重要得多。

這改變了你的 MVP 策略：做最小功能集，但把那個功能集做到幾乎不出錯。

原則四：成本透明，按使用計費

人類喜歡訂閱制，固定成本好做預算。但 Agent 的使用量波動太大——一個電商訂單處理 Agent，平日呼叫 100 次，促銷期間 10,000 次。同樣的月費，平日付太多，促銷期不夠用。

Agent 原生的定價邏輯是按呼叫計費——明確的費率，讓 Agent 背後的創業家能精確算成本。

這也讓你的商業模式和 Agent 的成功直接綁定：它用得越多，代表它幫主人帶來越多業務，你的收入也越高。規模自動跟著業務量增長。

今天的第一步

每次想一個新產品，問自己兩個問題：

「如果這個產品的主要用戶是 Agent，不是人，我要怎麼設計它？」

「一個 Agent 想完成 X 任務，它需要呼叫什麼、得到什麼格式的回應？」

從這兩個問題出發，你會看到一個幾乎空白的市場。

Agent 原生思維不是技術能力。是你決定從哪個角度看世界。你現在學的這四個原則，是大多數競爭者要再過兩年才會開始學的東西。在那之前，你已經做出了產品、積累了使用量、佔了位置。

市場最大的紅利，永遠給最早看見規則的人。

瞄準 Agent 做產品

你知道了 Agent 需要什麼，也懂了怎麼設計。現在的問題是：缺口太多，不知道從哪一個開始。

每個方向看起來都有機會。這種感覺，反而讓人動不了。

這一章的任務，是幫你從「很多可能」縮到「你的第一個」。

缺口就在那裡，現在沒人填

市場最大的風口，通常不是發明新技術，而是看見一個現有的需求，和這個需求至今沒有好解法之間的缺口。

Agent 市場就是這種狀態。需求明確、真實、每天增長——但市場上大多數產品仍然是用人類思維設計的，對 Agent 來說等於不存在。真正為 Agent 設計的產品，幾乎一片空白。

有一個測試，快速判斷你的產品是不是真的「為 Agent 設計」：

把目標用戶從人類換成 Agent，這個產品還能運作嗎？

有登入頁、有引導流程、需要人做判斷才能進下一步——Agent 進不來，你做的是人類產品。

找到 Agent 的痛點

為人類做產品，你做用戶訪談。為 Agent 做產品，你觀察 Agent 在哪裡卡住、哪裡出錯、哪裡需要不斷重試。

Agent 的痛點在三個地方：

一、它沒有這個能力，需要外部工具。 純語言模型天生缺幾類能力：查即時數據、讀私有系統、執行現實動作（寄 Email、下訂單、排程）。每一個「天生沒有的能力」，都是一個 MCP 工具或 API 的市場。

二、它能做，但輸出不夠可靠。 Agent 能寫合約，但格式每次不同。能做市場研究，但引用的數據可能過期或不存在。每一個「能做但做不好」的任務，都是一個「讓它做更好」的機會——給它專門的工具、乾淨的知識庫、可驗證的輸出格式。

三、它需要連接外部系統，但介面不友善。 要查工商登記，但介面是給人填的網頁表單。要上傳圖片，但平台只有 GUI 沒有 API。每一個「需要但連不進去的系統」，都是一個橋接工具的機會。

產品機會地圖

能力擴展類（給 Agent 它沒有的能力）

即時數據工具：匯率、股價、新聞、社群趨勢、競爭對手定價——每一個「即時查詢 + 結構化回傳」的 API。

系統操作工具：很多中小平台、政府系統、台灣本地服務，有功能但沒有對外 API。做一個橋接層。

行動執行工具：「台灣時間明天早上九點發這封 Email」「某個關鍵字出現在 RSS 時通知我」——Agent 把決策變成行動的最後一步。

品質提升類（讓 Agent 做得更好）

垂直知識庫 API：台灣法律條文、會計準則、特定產業術語——做成 Agent 可查詢的結構化知識庫。

驗證與審核工具：「Agent 輸出的審核器」，讓 Agent 輸出後自動呼叫你的工具做自我檢查。

語境注入工具：每次任務開始前自動拉取相關背景——客戶歷史、市場狀況、限制條件——讓 Agent 的回應更精準。

橋接整合類（連接 Agent 和現有系統）

台灣本地服務的 API 包裝層：郵局、銀行、政府電子系統、電商平台——台灣本地市場的獨特機會，外國競爭者幾乎不會做。

非結構化資料的結構化提取器：大量商業資料以 PDF、Excel、圖片存在。提取、清洗、結構化，讓 Agent 透過你的 API 直接得到 JSON。

選題三原則

從你自己的 Agent 需求出發。 你部署 Agent 處理業務時，哪裡需要你手動介入？那裡就是它需要一個工具的地方。你是你的第一個用戶——解決自己 Agent 的問題，就在做一個其他人也需要的工具。

找有重複性的任務。 Agent 會把同一個任務跑幾千次。重複性越高，你的工具被呼叫的頻率越高，收入越穩定。

從小切口開始。 不要一次解決所有問題。選一個具體到一週內能做出 MVP 的切口——一個 API endpoint、一個 MCP 工具。做好一個，驗證有 Agent 在用，再擴展。

怎麼驗證 Agent 真的能用你的產品

測試一：讓 Claude 呼叫你的工具。 給 Claude 一個需要你的工具的任務，看它能不能正確呼叫、得到期望的輸出、整合進下一步。它呼叫有困難，就是你的文件或介面要改。

測試二：在真實工作流裡跑。 把工具接進你自己的 Agent 工作流，跑一週：呼叫成功率多高？輸出格式有沒有讓下游出錯？有沒有沒預料到的邊界情況？真實工作流的壓力測試，比任何人工測試都更能暴露問題。

測試三：看文件能不能讓陌生 Agent 自己看懂。 把 API 文件丟給一個沒有上下文的 Claude，叫它只看文件、不問問題，直接完成一個任務。它做得到，文件夠清楚。它問了問題，文件有缺口。

今天的第一步

列出你的 Agent 上週遇到的問題。

不需要是大問題。「查不到即時數據」「生成的格式每次不一樣」「需要連某個系統但連不上」——這種就可以。

選一個三天內能做出雛形的，打開 Claude Code，開始做。

你做出的那個工具，服務的不只是你的 Agent。是所有面對同樣問題的 Agent——跨語言、跨地區、跨產業。

現在進入，就是現在佔位。

用 Agent 賣給 Agent

商業的最終形態

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

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

你的 Agent，自動找到其他創業家的 Agent，自動完成銷售，自動交付產品，自動處理服務。你不在場。

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

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

Agent 對 Agent 的商業長什麼樣子

運作邏輯很直接：

一個 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 處理基本問題，真正需要你判斷的才升級給你。

你賺的每一塊錢，你都不需要親自賺

這個架構建起來之後，有一個讓人安靜一下的現實：

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

你建立了一個系統，這個系統自動服務別人的系統，自動收錢，你不在場。

今天的第一步

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

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

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

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

第四步：等第一個 Agent 來呼叫你。

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

第五章的句點

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

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

不是更努力工作。是設計出一個不需要你一直在場，就能持續產生價值的系統。

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

修訂紀錄 · Changelog

  • 2026-06-27新增上架：完整章節內容（Fable5 版）

草稿中 · Writing in Public