到前一篇為止，我們討論的 AI 功能，大多還是由人類直接操作產品。AI 可能負責回答問題、呼叫 Tool 或完成某一段工作，但使用者仍然在我們設計的介面裡和它互動。

另一種情況也開始變得常見：使用者不打開產品，而是直接對 Claude Code、Codex、Cursor 或其他 Agent 說「幫我查這週的 Checkout Conversion」、「建立一個 Experiment」，再由 Agent 去操作產品。

這時產品真正接收到操作的來源已經不是人類點擊 UI，而是 Agent 代替使用者完成一連串工作。人類仍然是最終要解決問題的人，但產品的直接操作者多了一種新的形式。

MCP：讓 Agent 可以操作產品

對人類來說，產品通常會提供 UI；對程式來說，則會提供 API。Agent 理論上也可以閱讀 API 文件、自己組 Request，但它還需要知道有哪些能力、需要哪些參數、目前擁有哪些權限，以及操作完成後該如何理解結果。

MCP（Model Context Protocol）提供了一種標準方式，讓產品把這些能力提供給 Agent。以 PostHog 為例，目前的 Hosted MCP Server 會把 Feature Flags、Product Analytics、Error Tracking、Experiments、SQL、Surveys 等能力提供成 MCP Tools，讓支援 MCP 的 Agent 直接使用。PostHog 官方文件目前建議透過 Wizard 安裝：

npx @posthog/wizard mcp add

安裝後，就可以直接要求 Agent 查詢錯誤、分析數據、建立 Feature Flag 或 Experiment，而不是讓 Agent 去模擬點擊 PostHog 的網頁介面。

PostHog 在 2026 年 3 月回顧自己的 Agent 開發時提到，當時由 AI 建立的 Dashboard 中有 34% 是透過 MCP Server 完成，占所有 Dashboard 的 18%。這是 PostHog 自己在特定時間的使用資料，不能直接推論其他產品也會有相同比例，但至少可以看到 Agent 已經實際成為產品的一種操作介面。來源

MCP 與 API

MCP 並不是用來取代 API。實際上，許多 MCP Tool 最後仍然會呼叫原本的 API；差別在於產品可以另外決定要把哪些能力、用什麼抽象層級提供給 Agent。

假設電商系統已經有訂單、付款、物流等 API，Agent 需要的介面不一定是把每一個 HTTP Endpoint 原封不動轉成 Tool。它可能更適合看到 get_order、cancel_order、create_refund 這類和任務直接相關的能力，再由產品內部處理底下需要組合哪些 API。

PostHog 自己也曾經遇到類似問題。他們在 Agent-first Product Engineering 的回顧中提到，第一版曾經讓 Agent 經過多個偏向 UI / API 結構的操作才能回答一個分析問題；後來把部分讀取能力拉到 Agent 更熟悉的 SQL 層次，讓同一件事可以用更直接的方式完成。

因此，當 Agent 成為產品的直接操作者時，工程設計多了一個問題：產品目前提供的能力，是否處在 Agent 能夠有效使用的抽象層級？

Skills：補上產品知識

把能力做成 Tool 之後，Agent 已經知道產品「可以做什麼」，但不一定知道「在這個產品裡應該怎麼做」。

例如產品提供查詢 Event、建立 Insight 與建立 Dashboard 的能力，使用者要求「幫我建立一個觀察 Checkout 表現的 Dashboard」時，真正需要的資訊還包含 Checkout 使用哪些 Event、Conversion 怎麼定義、測試帳號怎麼排除，以及 Revenue 應該採用哪個欄位。

這些知識不適合全部塞進每一個 Tool Definition。PostHog 目前的 Agent 架構會另外使用 Skills：以 Markdown 文件提供 Workflow、Query Pattern、Schema、Example 與相關 Tool Reference，讓 Agent 在需要時取得產品知識。PostHog 對目前架構的說明也把 MCP Tools 與 Skills 分成兩個不同角色：Tool 提供可以執行的能力，Skill 則補充如何在產品情境中正確使用這些能力。

以退款功能為例，產品可能已經提供 get_order、get_refund_policy 與 create_refund。Skill 可以再補充只有產品團隊知道的規則，例如哪些訂單需要人工 Review、政策資料不足時不能自行推測，以及退款完成後應該確認付款狀態。

這裡的重點也不是把所有操作寫成嚴格的 Step-by-step SOP。PostHog 在後續整理 Agent-first Product Engineering 經驗時反而建議，Skill 應該優先放 Agent 自己無法從 Tool 或資料中推導出的內容，例如內部慣例、容易踩到的 Edge Case，以及團隊對「怎樣才算做得好」的判斷。來源

因此，產品真正提供給 Agent 的不只是 API Schema。能力怎麼被組合、哪些限制必須遵守、哪些產品知識無法從資料本身得知，也會影響 Agent 能不能完成使用者交付的工作。

Agent Experience

這並不代表所有產品現在都需要立刻建立 MCP Server。如果使用者沒有把工作交給 Agent 的需求，增加一套 Agent Interface 一樣可能沒有實際價值。

PostHog 自己的建議也是先看產品與使用情境。Developer-oriented、原本就會進入 Agent Workflow 的產品，很適合先透過 MCP 提供能力；如果使用者主要是非技術族群、產品需要高度控制互動流程，或 Compliance 不允許外部 Agent 取得相關能力，內建 Agent 或原本的 UI 可能更合適。

如果產品確實會被 Agent 操作，工程上可以開始多問幾個問題：

• 人類能完成的主要 Job，Agent 是否也有對應能力？如果沒有，是刻意要求 Human-in-the-loop，還是單純漏掉？
• Tool 的抽象層級是否接近 Agent 想完成的任務，還是要求它理解大量產品內部實作？
• 權限是否能限制到必要範圍，尤其是退款、刪除、付款等有副作用的操作？
• Tool 成功或失敗時，回傳結果是否足以讓 Agent 知道下一步該做什麼？
• 產品中的重要規則是否只存在於人類才看得懂的文件或團隊經驗裡？

這些問題和設計 UI 時考慮可發現性、操作流程與錯誤訊息很類似，只是現在面對的直接操作者變成了 Agent。

MCP Analytics：觀察 Agent 的實際使用方式

MCP Server 上線之後，接下來仍然會遇到和一般產品相同的問題：我們知道 Agent 有在使用這些 Tool，但它到底用得好不好？

只看 Tool Call 數量很容易產生錯誤的理解。使用者要求取消訂單時，一個 Agent 可能查詢一次訂單後就成功取消；另一個 Agent 可能反覆查詢、重試多次，最後仍然失敗。後者的 Tool Call 數量反而比較高，但顯然沒有更成功。

PostHog 目前提供的 MCP Analytics 就是在處理這類問題。對自己的 MCP Server 加入 MCP Analytics SDK 後，每次 Tool Invocation 會記錄成 $mcp_tool_call Event；PostHog 自己的 Hosted MCP Server 也使用相同的資料模型。MCP Analytics 的 Web UI 與 @posthog/mcp SDK 目前仍是 Beta，因此實際介面和 Event Schema 之後仍可能調整。

目前 Web 介面主要可以從幾個角度查看資料。官方文件列出的 Dashboard 會先整理 Session、Tool Calls、Error Rate、p95 Latency、Client 與 Tool Usage；Activity 則可以即時查看新進來的 Tool Call。

Sessions 可以進一步查看一次 Agent Session 裡依序發生的 Tool Call、Intent 與 Error。對 Agent 產品來說，這很接近前面 Session Replay 的用途：先找到一個沒有完成工作的案例，再回頭看它實際做了哪些事情。

Tool quality 則把問題拉回單一 Tool，觀察 Call Volume、Error Rate、Latency 與實際 Failure。假設 cancel_order 的錯誤率突然變高，就可以直接往這個 Tool 的失敗案例調查，而不是先從所有 Session 中人工搜尋。

另一個值得觀察的是 Missing Capability。例如使用者要求取消尚未出貨的訂單，Agent 可以取得 get_order，卻根本沒有 cancel_order，那麼失敗原因就不是 Prompt 或 Model，而是產品沒有提供完成這項工作的能力。

PostHog 對這件事的做法並不是自動猜測缺了什麼 Tool。開啟 reportMissing 後，SDK 會額外提供一個 get_more_tools Virtual Tool；當 Agent 判斷現有 Tool 無法滿足需求並主動呼叫它時，才會產生 $mcp_missing_capability Event。因此這項資料同樣有 Sampling Bias：如果 Client 沒有閱讀 Tool Description 或沒有呼叫它，缺少的能力就不會被記錄。官方文件

回到使用者成功

這些資料最後仍然要回到使用者原本想完成的 Job。

假設使用者的目標是取消一筆尚未出貨的訂單，Session、Tool quality 與 Intent 可以幫助我們了解 Agent 怎麼執行，以及問題卡在哪裡；真正的 Product Outcome 仍然是訂單最後有沒有被取消。Tool Call 很少不一定代表做得好，Tool Call 很多也不一定代表產品有價值。

因為 $mcp_tool_call 本身就是一般 PostHog Event，MCP Analytics 的資料也可以再透過 Product Analytics 或 SQL 和產品中的其他事件一起分析。只要識別資訊與業務事件有正確串接，就能進一步比較不同 Agent、Tool 或 Intent 最後是否帶來不同的 Product Outcome。

這和前面分析一般使用者行為時的思路沒有太大差別：先定義使用者想完成的事情，再找到能反映成功或失敗的信號。差別只是現在產品中間多了一個替使用者操作的 Agent。

而當這些 Error、Latency、Missing Capability 與 Product Outcome 都開始被持續收集後，下一個問題是誰來處理這些訊號。

PostHog 現在已經開始讓 Self-driving 使用 MCP Analytics 的資料找出失敗率高、反覆重試或回應過慢的 Tool；如果 MCP Server 的程式碼也由團隊自己管理，甚至可以把問題交給 Coding Agent 建立修正用的 Pull Request。MCP Analytics 文件目前已經把這條流程列為產品的一部分。

這也帶到最後一篇要討論的問題：當產品不只會被 Agent 使用，還開始讓 Agent 參與自己的改善流程時，產品工程會變成什麼樣子？

如果你願意花 30 秒留下回饋，我會用這些意見來調整後續文章：分享你的意見