Your Agent Is an Infinite Canvas：
Agent 不該永遠困在 chat UI

先講結論：聊天框是起點，不是目的地

這支 talk 的核心比「做漂亮 UI」更深。RL Nabors 把 chat 比喻成 agent 軟體的 terminal：開發者會喜歡，因為它透明、可控、好 debug；但大多數使用者最後需要的是更直接的操作表面。就像 desktop computing 沒有停在 terminal，agentic software 也不該永久停在一串文字回覆。

她展示的 comic reader 很能說明問題：工具不是只吐出連結，而是在 Claude 裡直接渲染完整 panels、navigation、transcript mode，並且視覺設計貼近原本網站。使用者不需要開新分頁，也不需要把 agent 的文字摘要轉回瀏覽器操作。

if tool_result.requires_scanning_or_manipulation:
  return mcp_app(
    surface="iframe",
    bundle="html + css + javascript",
    state="panels, filters, navigation, actions"
  )

if existing_site.already_has_forms:
  add_webmcp_attributes(
    tool_name="semantic action",
    description="what browser agents can safely call"
  )

avoid("screenshot parsing as primary integration")

Agent UI 的關鍵不是把聊天框裝飾得更好，而是讓工具回應擁有自己的互動介面。 — 本頁依 YouTube RSS、watch metadata、oEmbed 與影片描述整理

MCP apps：工具回應可以是一個小型 web app

MCP apps 的重要性在於，它把 HTML、CSS、JavaScript 包成單一工具回應，讓 agent 介面以 iframe 呈現。這代表工具可以回傳表格、地圖、reader、editor、dashboard、timeline，甚至專門為當下任務設計的互動控制面，而不是把所有狀態壓成文字。

這也改變開發者對「工具輸出」的想像。以前工具回傳的是資料，agent 再把資料講給使用者聽；現在工具可以回傳一個可以操作的 surface，agent、使用者與資料在同一個介面裡協作。

WebMCP：讓既有網站變成 agent-callable

WebMCP 走的是反方向：不是把 app 塞進 agent，而是讓已經存在的網站表單，透過工具名稱與描述屬性，讓 browser agents 能理解並呼叫它們。這比依賴 screenshot parsing 或 DOM traversal 更穩定，因為網站直接公開「這個表單能做什麼」與「這個動作該怎麼被呼叫」。

實務上，這是一個很低摩擦的導入點。若產品已經有搜尋、篩選、提交、設定、購買、預約等表單，WebMCP 的價值就是替 browser agent 補上語意層，讓它不用猜 UI。

無限畫布其實一直都在：就是 web platform

影片標題裡的 infinite canvas 不是指某個新的白板產品，而是提醒大家 web 本來就是最成熟的互動畫布。它有 layout、media、form、accessibility、script、state、sandbox、iframe，也有既有的設計與前端工程能力。agent 介面若只停在 markdown 和 chat bubbles，就等於把 web platform 的大半能力鎖起來。

這個觀點對 AI 產品開發很實際：不要每次都問「agent 要怎麼用文字回答」，而是問「使用者接下來需要比較、操作、選擇、導航，還是理解」。只要答案不是純閱讀，canvas 介面通常就比聊天泡泡更合適。

實務啟發：替 agent 設計可操作的回應

來源與限制

本頁使用 YouTube RSS、watch 頁 metadata、oEmbed 與影片描述整理；YouTube caption track 有列出英文自動字幕，但 timedtext 端點回傳空內容，因此未使用逐字稿。章節時間為依 23:08 影片長度與描述重點整理的內容地圖，非官方 timecode。