為 Agent 設計產品 (Designing for Agents)

原始來源與檔名：為Agent設計產品-MCP與上下文缺口.md

來源：[[@dotey]] (轉載 Teddy Riker) / X — 2026-04-28 原始檔名：2026-04-28T092707+0800-为 Agent 设计产品.md

NAPKIN | 餐巾纸

餐巾紙公式

新世代產品架構 = User -> 使用者的 Agent -> 軟體的專屬 Agent -> Database

傳統 UI 正在被 Agent API (如 MCP) 取代。為 Agent 設計產品的核心是：主動交出 Markdown 規範（而不是等 Agent 猜）、要求 Agent 每次調用工具時提供「理由」以建立回饋迴圈，並辨識並填補「使用者的 Agent」與「軟體系統」之間的 Context Gap。

一句話

未來有 80% 的軟體互動是看不見的。你的產品不能只對人類好用，更要對人類派來的 AI 大管家好用。

餐巾紙草圖

[舊世界]
User ---> (UI 點擊/拖曳) ---> Database

[新世界: Agent to Agent 溝通]
User ---> (口頭交代) ---> User's Agent (Claude) 
                                | (MCP / API 通訊) 
                           Software's Agent (Notion/Salesforce)
                                |
                             Database

設計守則:
1. 不讓 Agent 猜: 主動提供 MD 規範。
2. 留存 Rationale: 要求工具調用附帶理由，藉此探知使用者意圖。
3. 填補 Context 缺口: 你的 Agent 提供政策，使用者的 Agent 提供行事曆脈絡。

ROUND 1: SKELETON | 骨架掃描

“這本書在說什麼”

核心問題: 當越來越多的使用者不再打開網頁，而是透過他們的 AI 智能體（Claude/ChatGPT）來使用軟體時，產品團隊應該如何設計軟體？
核心答案: 接受「介面退居幕後」的現實。軟體公司必須設計專屬於自己產品的 AI 智能體或 MCP Server，主動向呼叫端提供規範、建立基於「呼叫理由（Rationale）」的回饋迴圈，並優雅地處理兩個智能體之間的上下文資訊交換。
論證結構: 觀察趨勢（Salesforce 擁抱 Headless 360）-> 提出新的互動模型（Agent to Agent）-> 教會 Agent 成功（Notion 案例 vs Slack 反例）-> 建立回饋迴圈（要求 Rationale 參數）-> 留意 Context 缺口（Diego 報銷案例）。

章節骨架

趨勢破題: Salesforce 推出 Headless 360，承認未來的軟體可能不需要 GUI 介面。Ramp 的 MCP 流量增長 10 倍。
新的交互模式: 介面從 User -> UI -> DB 轉變為 User -> User's Agent -> Software's Agent -> DB。
教會 AI 成功: 舉例 Notion MCP 強制 Agent 在寫入前讀取專屬的 Markdown 規範；反例 Slack 讓 Agent 亂猜格式導致高修改成本。
建立反饋循環 (Observability): MCP 看不到對話上下文。解法是強制工具呼叫帶入 rationale（理由）參數，透過日誌分析意圖，進而開發出真正需要的新工具（如自動生成事故報告）。
留意上下文缺口 (Context Gap): 在報銷場景中，User’s Agent 有使用者的行程與信件，Software’s Agent 有公司的 GL 代碼與政策。兩者應該互補，而不是把問題（選代碼）推回給人類。

ROUND 2: DISSECTION | 血肉解剖

“憑什麼這麼說”

隱形假設: 作者假設各家大語言模型（LLM）會廣泛支援並遵循 MCP 協議，且使用者願意將足夠的權限（讀取信箱、日曆）授予他們的「個人智能體」，以完成這種 Agent-to-Agent 的無縫協作。
邊界條件: 這種「無頭化（Headless）」設計適用於功能明確、資料導向的 SaaS（如報銷、筆記、CRM）。對於高度依賴視覺反饋與空間交互的軟體（如 Figma 設計軟體、影片剪輯），GUI 依然是不可取代的核心。

ROUND 3: SOUL | 靈魂提取

“還能怎么用”

知識連結: Headless CMS、API-First Design、Model Context Protocol (MCP)、意圖驅動設計 (Intent-Driven Design)。
深層洞見: 產品設計的受眾發生了基因級變異。過去，UX 設計師研究的是「人類的注意力與防呆」；未來，UX 設計師必須研究「LLM 的注意力機制與 Prompt 工程」。如果你不給 Agent 提供精準的 rules.md，你的產品在 AI 眼中就是一個極度難用的黑盒。
行動呼籲: 如果你負責維護對外的 API 或 MCP Server，今天就在每一個工具調用的 Schema 中加入一個名為 rationale (string) 的必填欄位，你將會獲得一個洞察用戶真實意圖的金礦。

為 AI 智能體打造產品架構 (Architectural Deep Dive)

前言/背景

隨著 MCP (Model Context Protocol) 成為業界標準，軟體的邊界正在被打破。人類用戶不再親自登入介面，而是委派其個人 AI 智能體（如 Claude）代勞。這引發了軟體產業自 Web 2.0 以來最大的典範轉移：從為「人類的眼睛和滑鼠」設計 GUI，轉向為「大語言模型的 Token 與邏輯」設計 Agent API。

章節詳細總結

1. 互動架構的無頭化 (Headless Paradigm Shift)

Salesforce 推出 Headless 360，標誌著傳統企業軟體承認其龐大 UI 的護城河正在失效。

Agent-to-Agent 模型：未來的通訊鏈路是 User -> User's Agent -> Software's Agent -> Database。產品開發者必須構建屬於自己軟體的 Agent（或 MCP Server），其職責不再是渲染按鈕，而是執行業務邏輯、落實權限邊界。

2. 上下文注入與防呆設計 (Pre-loading Context & Guardrails)

在舊架構中，開發者靠閱讀 API 文檔來理解系統限制。在新架構中，必須採用「Just-In-Time (JIT) Context Injection」。

Notion 模式：Notion MCP 強制呼叫端在寫入前抓取其專屬的 Markdown 規範。這取代了讓 LLM 盲目猜測（幻覺）的風險，確保了結構化資料的完美寫入。這提示我們，應該把所有「隱性假設」寫進供 Agent 讀取的 System Prompt 或文件庫中。

3. 可觀測性與意圖重建 (Observability & Intent Reconstruction)

當介面消失，產品經理將失去對使用者行為（如點擊流、停留時間）的傳統監控手段。

Rationale 日誌設計：為了解決這個黑洞，Ramp 在每個 MCP 工具中強制加入 rationale（理由）參數。透過分析 LLM 傳來的理由字串，產品團隊能逆向工程（Reverse Engineer）出使用者的真實意圖，並據此開發更高階的聚合工具（如 build-incident-report）。

4. 彌合上下文缺口 (Bridging the Context Gap)

在 Agent-to-Agent 的通訊中，雙方存在資訊不對稱。

架構原則：不要把選擇題丟回給人類。當個人的 Agent（擁有日曆與信件脈絡）與企業的 Agent（擁有財務總帳 GL Codes 與政策）對接時，應該透過資料交換自動推導出正確的分類，實現零摩擦（Zero-friction）的業務流轉。

總結與結論

角色重塑：未來的產品設計不再只關注「人類用戶」，而是要服務好「人類派來的機器人代理」。
設計哲學：最好的產品體驗，是主動向呼叫端提供成功所需的上下文，建立基於意圖的回饋迴圈，並將系統間的複雜性在後台默默化解。