@dotey：為 Agent 設計產品 原文：Designing for Agents 作者：Teddy Riker 如果你和我一樣，經常混在 X 上同一個資訊…

為 Agent 設計產品 原文：Designing for Agents 作者：Teddy Riker 如果你和我一樣，經常混在 X 上同一個資訊圈裡刷動態，那麼你大概也見過這種說法：使用者介面已經死了。 你會一邊刷到「我如何用 Obsidian 搭建第二大腦」，一邊刷到「Anthropic 徹底殺死了某某行業」這類貼文。然後很快，你就會看到有人說：一個產品如果不能被 AI Agent 透過 MCP、API、CLI，或者介於它們之間的方式使用，那它就活不下去。 這個趨勢在 Ramp 已經很明顯。過去三個月裡，隨著越來越多客戶開始透過 Claude、ChatGPT 和其他 AI Agent 進入我們的產品，我們 MCP 上的每週活躍使用者成長了 10 倍。（MCP，Model Context Protocol，模型上下文協定，可以理解為一種讓 AI Agent 呼叫外部工具和資料的標準方式。） 上週，Salesforce 成了最早主動擁抱這個判斷的傳統軟體巨頭之一。 來自 https://venturebeat.com/ai/salesforce-launches-headless-360-to-turn-its-entire-platform-into-infrastructure-for-ai-agents: https://www.salesforce.com/ 週三宣布了這家公司 27 年歷史上最激進的一次架構轉型，推出了「https://www.salesforce.com/news/stories/salesforce-headless-360-announcement/」——這是一項覆蓋整個平台的大計畫：把平台裡的每一項能力都暴露成 API、MCP 工具或 CLI 命令，讓 AI Agent 可以在完全不打開瀏覽器的情況下操作整個系統。 這項發布是在 Salesforce 於舊金山舉辦的年度 https://www.salesforce.com/tdx/ 大會上宣布的，並且立刻向開發者開放了 100 多個新工具和技能。它也正面回應了一個懸在企業軟體頭頂的生死問題：當 AI Agent 已經能夠推理、規劃和執行時，一家公司還需要一個帶圖形介面的 CRM 嗎？ Salesforce 的回答是：不需要——而這正是重點。 Salesforce 這一步很聰明，而且我很難想像這會是一個容易做出的決定。你問大多數銷售，他們大概率會告訴你，他們並不喜歡用 Salesforce。但 Salesforce 之所以無處不在，很大一部分原因正是它的使用者體驗 (UX) 足夠熟悉。銷售負責人通常並不想讓整個團隊重新適應一套新技術；在很多時候，一致性比功能強大更重要。 Benioff 和他的團隊正在承認：這條護城河正在被侵蝕。他們也開始主動擁抱一個現實——未來大量使用行為會透過 Claude、ChatGPT 以及其他使用者根本看不見的後台流程來完成。 我並不認為使用者介面 (UI) 正在死亡。人類仍然想要點擊按鈕、查看配置、確認任務已經完成。但二八法則已經反過來了：未來人與軟體之間 80% 的互動，都會透過 AI Agent 完成。這不僅會改變你需要建構什麼，也會改變你建構它的方式。 新的互動模式 過去二十年裡，人們和軟體互動的主要方式是： 使用者 → 介面 → 資料庫 你打開一個產品，點來點去，把事情做完。介面就是你體驗軟體的方式。對大多數人來說，介面本身就是產品。 但隨著 AI Agent 接手越來越多工作，一個新的中間層出現了： 使用者 → 使用者的 AI Agent（比如 Claude）→ 資料庫 AI Agent 代表使用者行動。它讀取、寫入、瀏覽產品，這樣使用者就不用親自操作。突然之間，介面消失了。Agent 開始直接和底層系統對話。 不過，這個模式也在迅速變化。軟體公司正在——而且也應該——設計自己的 AI Agent 和能力。所以新的模式更像這樣： 使用者 → 使用者的 AI Agent → 軟體的 AI Agent → 資料庫 在這個模型裡，軟體的 AI Agent 會替使用者的 Agent 處理複雜性：執行業務邏輯、落實規則、補充後者沒有的上下文。兩個大型語言模型 (LLM) 一起協作，朝著同一個結果推進。 教會 AI Agent 如何成功 我現在大部分腦力激盪、寫作和構思，都是與大型語言模型一起完成的。當一篇草稿準備好分享時，我會透過 Notion 的 MCP 伺服器把它推到 Notion 裡。我曾經是 Google Docs 的忠實使用者很多年，但 Notion 的 MCP 改變了我的習慣。 作為 Notion MCP 的使用者，我很欣賞的一點是：每次我讓 AI Agent 寫點什麼，它幾乎都能一次到位。表格、項目符號、斜體、列表，你能想到的格式，它都不會出錯。 這不是偶然，而是設計出來的。 Notion 的 notion-create-pages 工具描述一開始就寫著：「如需完整 Markdown 規範，必須先獲取 MCP 資源 notion://docs/enhanced-markdown-spec。不要猜測或幻覺 Markdown 語法。」當我讓 Agent 寫入一個頁面時，它做的第一件事就是獲取這份規範。先讀規範，再動筆。所有 Notion 特有的假設，都會被明確指出，而不是依賴通用模型的預設理解。 在舊世界裡，這類規範會放在 API 文件裡。接入 Notion 的開發者會讀文件、理解規則，然後寫一個轉換層。現在，Notion 會在 AI Agent 真正需要的時候，直接把規範交到它手裡。 如果你用過 Slack MCP，可能就體驗過相反的情況。你的 AI Agent 會預設使用標準 Markdown，卻沒有遵守 Slack 自己那套特定格式。結果是，你花在修改格式上的時間，可能比自己手寫訊息還多： 當然，Slack 的格式指南在網上能找到，你也可以把它保存下來，再教你的 Agent 怎麼用。但這很煩，而且本來就不該是使用者需要操心的事。 你應該思考：呼叫你家 Agent 的人，需要知道什麼才能成功？然後主動把這些資訊交給它。不要讓它自己摸索。 建立回饋循環 當我們剛在 Ramp 發布 MCP 時，最大的問題是可觀測性 (observability)。我們能看到工具呼叫量，但看不到觸發這些呼叫的聊天上下文。僅僅知道呼叫量，並不能告訴我們什麼有效、什麼壞了、使用者到底想完成什麼。 後來我們用幾種方式解決了這個問題： 每次工具呼叫都要求填寫「理由」。 每一次 MCP 或 CLI 工具呼叫，都要求 AI Agent 帶上一個 rationale 參數，解釋它為什麼要發起這個請求。我們看不到聊天內容，但這個理由可以重建意圖。理由裡的模式，會告訴我們使用者到底想做什麼。 提供一個回饋工具。 我們發布了一個獨立工具。當 AI Agent 遇到阻礙，或者發現某種模式行不通時，它可以呼叫這個工具。它會提交自己原本想做什麼、嘗試了什麼、卡在了哪裡。 給特定工具加入上下文種子。 我們會給單個工具加入專門設計的參數，用來捕捉之後會有用的上下文：這些資訊 Agent 能拿到，但如果不主動收集，我們之後只能靠猜。 想像一下，你正在做一個客戶支援平台，並提供工具讓客戶抓取工單。過了一段時間，你開始在理由日誌裡反覆看到類似表達：「正在生成事故報告」、「正在起草事故摘要」、「正在收集停機復盤相關工單」。 這就是一個新產品功能的訊號！你可以做一個 build-incident-report 工具，用來識別相關工單、評估嚴重程度、拉取受影響的客戶群體，並用一種強約束的格式起草摘要。 這個工具上線後，你可能又會開始收到回饋：「報告拉進了三天前的工單，但那些不屬於這次事故」，或者「它總是把免費套餐使用者的工單也放進復盤裡，但這些使用者不應該出現在事故復盤中」。突然之間，你的 AI Agent 開始告訴你的 AI Agent：接下來到底該建構什麼。 AI Agent 當然會幻覺。但在回饋這件事上，它們往往比你真正發給產品的多數人類使用者更具體，也更一致。 如果報告拉進了無關工單，你就增加一個日期範圍參數。如果不該包含免費套餐客戶，你就增加一個客戶分組篩選器。每一個回饋循環，都會變成產品改進的新入口。 留意上下文缺口 在任何 AI Agent 互動中，你的系統掌握一些呼叫方 Agent 不知道的上下文；而呼叫方 Agent 也掌握一些你的系統不知道的上下文。設計這些互動時，你應該清楚地判斷：哪一方在哪些資訊上更有優勢。 比如 Diego 去出了一趟差。他的 AI 首席幕僚收到一條來自費用管理系統 Agent 的 Slack 提醒：他最近這趟出差還有未完成的報銷。現在，兩個 AI Agent 都指向同一個目標：正確提交這些報銷。 這兩個 Agent 各自帶著不同的上下文。 Diego 的 AI 首席幕僚知道： Diego 的日曆：知道哪些會議發生了、在什麼時候、和誰一起 Diego 的信箱：有飯店和航班確認郵件附件 Diego 的 Slack：能把 Kokkari 那頓晚餐關聯到一個他邀請 Acme 團隊的對話執行緒 Diego 的收據：來自…