App 裡的智慧功能，和後台 AI Agent 該怎麼分工

先問這次智慧功能是在幫誰把一件具體的事做完

使用者打開 App，通常已有目的：看進度、預約、點餐、回報、查自己的資料。這時需要的是把當下這一步變快，例如用自然語言找過去的訂單、把一張照片轉成報修草稿、依權限顯示可選時段。這些功能應待在原本的畫面附近，做完就回到原來的流程，而不是把人送進一個什麼都能問、什麼保證都沒有的對話。

內部人員的工作則常跨系統：核對客戶、整理需求、建立後續任務、決定要不要送出。這比較像 Agent 的戰場，適合待在有權限控制的後台或工作台，而不是塞進給會員用的 App。若業務開始在客戶 App 裡「問 AI 這單能不能打折」，權限與稽核會立刻變得尷尬。

一家預約類 App 曾想在首頁放聊天機器人，讓會員問什麼都行。實際高頻任務只有改期、取消和查看剩餘次數。後來是把這三件事做成畫面上的輔助，後台再另做一個處理例外改期、對不到會員資料的 Agent。前台變單純，例外也比較有人接。

• 會員當下任務：放在 App 功能裡，範圍要窄
• 跨系統整理與寫回：放在後台 Agent，帶核准
• 兩者都不要變成沒有邊界的全能對話

App 端更在意延遲、權限和失敗時怎麼繼續用

手機上的人不會等一段「正在思考」太久，也不接受功能失敗就整頁不能用。智慧搜尋或草稿若呼叫失敗，應退回原本的列表、表單或人工入口。Agent 在後台可以走確認佇列；App 上每一秒都佔著使用者的注意力。

權限也要沿用登入身分。會員只能觸及自己的訂單與資料，不能因為加了自然語言，就查到別人的預約。這一點看起來理所當然，實作時卻常在「為了讓模型理解上下文」時被放寬。上下文仍應來自該使用者被授權的資料，而不是整張表。

推播更要小心。Agent 可以在後台判斷該不該提醒負責人；直接對會員推送的內容，仍應通過你們原本的通知規則與頻率限制。智慧功能不是另開一條可以隨時打擾人的通道。

後台 Agent 負責跨系統，App 負責把結果呈現好

比較穩的架構，是讓後台 Agent 處理讀取、規則、草稿與寫回，App 只呈現已被允許的結果。例如 Agent 在權限內整理出「可改期的時段」或「報修草稿」，App 用原本的元件讓使用者選和送。使用者不必知道後面有沒有 Agent；他們只看到任務完成。

這樣拆還有一個好處：同一套 Agent 將來可以服務內部人員、客服工作台，不一定要出現在 App 裡。App 保持產品節奏，Agent 保持作業節奏，兩邊的改版才不會綁死。

AgentTech 在同時做 App 與 Agent 時，會先寫共用的資料與權限，再分別設計前台互動和後台作業。避免先做一個聊天 API，然後前台後台都去打它。那個 API 很快會變成什麼都能問、什麼都難以驗收的中間層。

資料寫回仍應只有一個來源

App 自己改一筆預約、Agent 在後台也改一筆，卻沒有共同狀態機，最後一定對不上。智慧功能可以提案，正式狀態仍應通過原本的 API 與驗證。Agent 不是第二個後台，App 也不是第二個資料庫。

若一定要讓 App 裡的輔助直接提交，提交的仍應是使用者按過的內容，並留下是輔助產生、經使用者確認。這對客服事後追查「我沒有要取消」這類爭議很重要。

第一個 App 智慧功能，選正在被重複操作的那一步

從搜尋、填表、分類這類每週都在發生的動作開始，通常比做一個開放聊天更容易驗收。成功標準可以很素：找到正確紀錄的比例、草稿被修改的幅度、使用者有沒有改走原本入口。這些比「對話輪數」更能說明產品有沒有變好。

若團隊其實痛的是內部建檔和跨系統追蹤，那就不要先改 App 首頁。把 Agent 放在後台，App 維持清楚的會員任務。兩個產品問題，用兩種介面處理，會比全部塞進同一個機器人更接近能上線的範圍。