# 策展 · X (Twitter) 🔥🔥🔥🔥

> 作者：宝玉 (@dotey) · 平台：X (Twitter) · 日期：2026-04-27

> 原始來源：https://x.com/dotey/status/2048135262606393777

## 中文摘要

# 為 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 開始直接和底層系統對話。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777250166179-iaHGxv0NEWkAAWCzSjpg.jpg)

不過，這個模式也在迅速變化。軟體公司正在——而且也應該——設計自己的 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 自己那套特定格式。結果是，你花在修改格式上的時間，可能比自己手寫訊息還多：

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777250166167-iaHGxv3nFXsAAtRG8png.png)

當然，Slack 的格式指南在網上能找到，你也可以把它保存下來，再教你的 Agent 怎麼用。但這很煩，而且本來就不該是使用者需要操心的事。

你應該思考：呼叫你家 Agent 的人，需要知道什麼才能成功？然後主動把這些資訊交給它。不要讓它自己摸索。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777250166173-iaHGxv6cHaIAA7moijpg.jpg)

## 建立回饋循環

當我們剛在 Ramp 發布 MCP 時，最大的問題是可觀測性 (observability)。我們能看到工具呼叫量，但看不到觸發這些呼叫的聊天上下文。僅僅知道呼叫量，並不能告訴我們什麼有效、什麼壞了、使用者到底想完成什麼。

後來我們用幾種方式解決了這個問題：

1. 每次工具呼叫都要求填寫「理由」。 每一次 MCP 或 CLI 工具呼叫，都要求 AI Agent 帶上一個 rationale 參數，解釋它為什麼要發起這個請求。我們看不到聊天內容，但這個理由可以重建意圖。理由裡的模式，會告訴我們使用者到底想做什麼。

1. 提供一個回饋工具。 我們發布了一個獨立工具。當 AI Agent 遇到阻礙，或者發現某種模式行不通時，它可以呼叫這個工具。它會提交自己原本想做什麼、嘗試了什麼、卡在了哪裡。

1. 給特定工具加入上下文種子。 我們會給單個工具加入專門設計的參數，用來捕捉之後會有用的上下文：這些資訊 Agent 能拿到，但如果不主動收集，我們之後只能靠猜。

想像一下，你正在做一個客戶支援平台，並提供工具讓客戶抓取工單。過了一段時間，你開始在理由日誌裡反覆看到類似表達：「正在生成事故報告」、「正在起草事故摘要」、「正在收集停機復盤相關工單」。

這就是一個新產品功能的訊號！你可以做一個 build-incident-report 工具，用來識別相關工單、評估嚴重程度、拉取受影響的客戶群體，並用一種強約束的格式起草摘要。

這個工具上線後，你可能又會開始收到回饋：「報告拉進了三天前的工單，但那些不屬於這次事故」，或者「它總是把免費套餐使用者的工單也放進復盤裡，但這些使用者不應該出現在事故復盤中」。突然之間，你的 AI Agent 開始告訴你的 AI Agent：接下來到底該建構什麼。

AI Agent 當然會幻覺。但在回饋這件事上，它們往往比你真正發給產品的多數人類使用者更具體，也更一致。

如果報告拉進了無關工單，你就增加一個日期範圍參數。如果不該包含免費套餐客戶，你就增加一個客戶分組篩選器。每一個回饋循環，都會變成產品改進的新入口。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777250166171-ediaHGxvS9WkAEnCJjpg.jpg)

## 留意上下文缺口

在任何 AI Agent 互動中，你的系統掌握一些呼叫方 Agent 不知道的上下文；而呼叫方 Agent 也掌握一些你的系統不知道的上下文。設計這些互動時，你應該清楚地判斷：哪一方在哪些資訊上更有優勢。

比如 Diego 去出了一趟差。他的 AI 首席幕僚收到一條來自費用管理系統 Agent 的 Slack 提醒：他最近這趟出差還有未完成的報銷。現在，兩個 AI Agent 都指向同一個目標：正確提交這些報銷。

這兩個 Agent 各自帶著不同的上下文。

Diego 的 AI 首席幕僚知道：

- Diego 的日曆：知道哪些會議發生了、在什麼時候、和誰一起

- Diego 的信箱：有飯店和航班確認郵件附件

- Diego 的 Slack：能把 Kokkari 那頓晚餐關聯到一個他邀請 Acme 團隊的對話執行緒

- Diego 的收據：來自郵件附件和照片圖庫

費用管理系統知道：

- 原始交易資料，比如商戶、交易時間

- 公司關於報銷提交的政策

- 公司的總帳科目 (GL accounts)（GL 通常指 General Ledger，也就是財務記帳裡的總帳分類）

- 公司過往的費用歸類習慣

傳統 API 會把問題丟回給使用者：「這裡有一筆交易需要填寫 GL code。請呼叫這個介面獲取 150 個 GL code 選項，然後自己選一個。」

設計得好的 AI Agent 互動會反過來處理這件事——它不會直接索要 GL code，而是索要上下文：這是一頓客戶餐、團隊餐，還是個人旅行支出？AI 首席幕僚可以從日曆條目或 Slack 對話裡找到答案。然後費用管理系統根據自己原本缺失的那部分上下文，自動套用正確的科目。

Diego 和他的 Agent 都不需要知道 GL code 到底是什麼。財務團隊也能得到準確的分類。雙方各自貢獻自己知道的資訊，最終交付一個對 Diego——也對他的會計——都更好的結果。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777250166215-iaHGxwB7IWEAAs9zHjpg.jpg)

當你設計這種 Agent 到 Agent 的互動時，一定要留意上下文缺口。承認你的 Agent 在哪些地方不擅長，是完全可以的——因為你們其實是在服務同一個使用者。

過去，介面夾在 Diego 和他的費用系統之間。現在，介面夾在他的 Agent 和你的 Agent 之間。

這個變化重新定義了產品團隊的工作。過去，你是在為一個想快速完成任務、避免犯錯、看得見自己工作的真人設計產品。現在，你仍然是在服務同一個人，只不過中間多了一個代理者。它的直覺、上下文和局限，都和人類不同。

教會 AI Agent 如何成功、建立回饋循環、留意上下文缺口，這三件事背後其實都在問同一個問題：呼叫你家 Agent 的一方，到底需要什麼才能把工作做好？你有沒有把這些東西交給它？

大多數公司會發布一個 MCP，勾上「我們也支援 AI Agent 了」這個框，然後繼續往前走。它們的使用量可能會成長幾個季度，然後停滯。隨著時間推移，客戶會流向那些真正打磨細節的產品，也會繞開那些只是敷衍了事的產品。

像當初為人類使用者設計產品一樣，認真為 AI Agent 設計產品。因為你很快就會發現，最後簽支票的，可能正是它。

## 標籤

Agent, MCP, CLI, 產業趨勢, Anthropic, Claude, ChatGPT