AI 代理能力路由指南：AutoAttach、Suggest、Fallback 如何讓 Android 任務選對能力

從一個 Android 請求排出候選能力

什麼是 AI 代理能力路由？先看一個具體 Android 請求：「幫我把這個頁面的地址存成備忘，順便導航過去，但先讓我確認。」這句話看起來簡單，實際上會產生多個候選能力：讀目前畫面、抽取地址、建立備忘、查地點、開啟地圖、啟動導航、顯示確認、處理權限不足。能力路由就是把這些候選能力排出順序，決定哪些情境可以自動附加，哪些要顯示建議，哪些要改走 Fallback。

代理不能把所有工具、Skill、Workflow、Plugin 和 App metadata 都塞進每一次模型上下文。那會增加延遲、成本與誤配機率，也會讓模型在不需要的能力之間亂選。比較可靠的做法，是先用任務文字、目前 App、畫面類型、使用者歷史、權限狀態、已啟用能力與目標風險，縮小候選集合。

候選排名不是授權。語意上「導航」很像 map_navigate，代表它可以進入候選名單；但真正執行前仍要看地址是否明確、地圖 App 是否可用、位置權限是否需要、是否要顯示目的地與路線。這是我們做 FoneClaw 時最重視的分界：能力配對能讓代理更快找到路，但不會自動代表使用者同意執行。

如果你想先理解工具、Plugin、Skill 與 Workflow 的能力層差異，可讀 FoneClaw 工具、外掛、技能與工作流程指南：Android Agent 能力層怎麼選。本文不重複那份 glossary，而是專注一個請求如何通過候選排名、AutoAttach、Suggest、Fallback、activation、approval、execution 與 recovery。

AutoAttach、Suggest、Fallback 該怎麼選

AutoAttach、Suggest、Fallback 的差異，可以用「信心與風險」來看。AutoAttach 是高信心、低外部影響的路由：它把相關本地情境或能力 metadata 附加到任務裡，幫模型理解目前要處理什麼。它不代表工具已執行，也不代表 Plugin 已安裝。以剛才的地址任務來說，使用者明確說「這個頁面」，FoneClaw 可在使用者觸發下附加目前畫面資訊，讓模型更準確找到地址。

Suggest 是可見選擇。當候選能力很像可以幫忙，但還需要使用者決定時，代理應該把它變成建議，而不是直接進入執行。例如頁面裡有兩個地址，或使用者說「幫我處理這個店家」，可能需要建議「建立備忘」、「開地圖導航」、「搜尋附近停車場」幾種路線。Suggest 的價值，是把代理的推測轉成使用者看得懂的選項。

Fallback 是可接續處理。當沒有能力、能力不穩、權限被拒、候選不明確，或系統狀態和計畫不一致時，Fallback 讓任務回到可處理狀態。它不是繞過政策，也不是硬試另一個工具。好的 Fallback 會說清楚：目前卡在哪裡、還能做什麼、需要使用者補哪個資訊、是否可以改成手動接手。

回到地址範例，AutoAttach 可以附上目前畫面文字；Suggest 可以提示「存成備忘」與「開地圖」兩個可見候選；Fallback 可以在未找到地址時請使用者圈選文字，或在沒有地圖 App 時建議先搜尋地點。這三種路由彼此搭配，讓 Android 代理工具路由不必在「全自動」和「完全手動」之間二選一。

把 discovery、附加、啟用、核准與執行分開

能力路由最常見的錯誤，是把 discovery、attachment、activation、approval 和 execution 混成一件事。它們應該是不同狀態。Discovery 是發現可能有用的能力；attachment 是把相關情境或 metadata 加進任務；activation 是把能力放到可用狀態；approval 是使用者同意某個具體動作；execution 是真正執行並驗證結果。

這個分界正在成為整個 Agent 生態的共同語言。Google Developers 對 Agent Plugins 的說明把 Agent Skills 和 MCP servers 放進開放、vendor-neutral 的包裝規格，讓能力可以帶有共用 metadata。這有助於 discovery 和候選判斷，但 packaging metadata 只提供可理解的能力描述，不會自動產生信任、啟用或執行授權。

GitHub 的 Agent finder 更新也提供了類似參考：它會按需排名相關資源，並遵守設定好的 registry 與管理設定；發現與排名不等於靜默安裝。這個原則放到手機 Agent 更重要，因為 Android 任務會碰到聯絡人、訊息、位置、檔案、系統設定與外部效果。

在 FoneClaw 的設計裡，使用者看到一個能力建議，不代表它已被啟用；啟用 Plugin 也不代表所有工具動作都已核准；核准某次任務，也不代表未來所有相似任務都能自動執行。狀態機越清楚，代理越容易被使用者信任，也越容易在失敗時復原。

安全使用 manifest、dependencies、情境 metadata 與信心分數

可靠的 Plugin 與 Skill 路由，需要幾類輸入。第一是 manifest identity：能力的名稱、用途、版本相容性、提供者、需要的權限與可呼叫介面。manifest 讓候選能力可被比較，但 metadata 本身不保證可信；它只是讓代理知道「這個能力聲稱可以做什麼」。

第二是 dependencies。某個 Plugin 可能需要特定 App、帳號、網路、檔案存取、地圖服務或 MCP server；某個 Skill 可能需要特定工具已啟用。dependencies 沒有解決前，不應把能力當成可執行路線。更穩的做法，是在 activation 前把缺少項目顯示出來，讓使用者選擇補齊、跳過或改走 Fallback。

第三是 context metadata。Android 代理工具路由需要知道目前 App、畫面類型、使用者語言、網路狀態、權限狀態、已啟用工具、任務風險與候選目標是否唯一。舉例來說，同樣是「幫我分享這個」，在相簿、瀏覽器、檔案管理器和聊天 App 中需要不同能力；若目標聯絡人不唯一，路由就應降低信心並改成 Suggest 或 Fallback。

第四是 confidence。信心分數應該影響路由模式，而不是取代治理。高信心可支持 AutoAttach；中等信心適合 Suggest；低信心或高風險任務要走 Fallback 或請使用者補資訊。FoneClaw 的能力快照思路也遵守同一原則：刷新能力時維持可接受狀態，避免半套能力進入 active state，讓路由結果穩定可解釋。

如果你的重點是 Skill 權限風險與匯入能力安全，建議延伸讀 AI Agent 技能安全：為什麼手機 Agent 不能只靠安裝前掃描。能力路由做得越聰明，越需要把 identity、dependency、permission 和 approval 分開處理。

能力缺失、過期、被拒或目標模糊時如何復原

能力路由要把失敗當成正常路徑，而不是只做模型 retry。缺能力時，代理應指出目前沒有可用能力，並提供接續方式：改成手動步驟、建議安裝或啟用某個能力、用較保守的內建工具完成一部分，或把任務保存成稍後處理。這比讓模型換一種說法重試更有用。

dependency 過期時，復原重點是狀態更新。例如 Plugin metadata 顯示可以處理檔案，但依賴的 App 未安裝，或 MCP server 不可用；此時應停在 activation 或 Fallback，而不是繼續執行。能力快照可以避免路由看到一半舊資料、一半新資料，讓使用者更容易理解為什麼某個能力現在不可用。

權限被拒時，permission recovery 和模型 retry 是兩件事。模型再會規劃，也不能替使用者授權聯絡人、通知、位置或系統設定。FoneClaw 的做法，是把權限需求帶到可見 Android 設定或說明，讓使用者選擇是否授權；如果使用者拒絕，任務就改走不需要該權限的路徑，或清楚停止。

目標模糊時，最好的 recovery 是縮小選項。例如「傳給 Alex」但聯絡人有三個 Alex，或「導航到店家」但頁面有兩個地址，代理應提出候選並要求選擇。False positive 也要測：如果畫面上出現地址格式但其實是廣告，AutoAttach 不應過度自信。No-match 也要測：沒有地址時應請使用者補文字，而不是編造目的地。

這些 recovery 設計會直接影響使用者是否信任 AI 代理能力路由。任務中斷不可怕；不可見的中斷、錯誤的自動選擇和無限重試才會讓手機代理失去掌握感。

FoneClaw 如何套用受治理能力路由

FoneClaw 如何路由 Android 能力？我們先從請求和目前狀態建立候選，再把候選分成可附加情境、可建議能力、需要啟用的延伸能力、可執行工具和需要 Fallback 的路徑。FoneClaw 是 Android phone-agent runtime，模型負責理解與規劃，FoneClaw 負責把支援的 Android 能力放進可見、可核准、可復原的流程。

目前 FoneClaw 提供 100+ built-in tools，並支援 Skills、Workflows 和經審查的 Plugins 路徑。完整能力範圍可查看 FoneClaw 功能頁。我們在產品裡把 built-in tool、Skill、Workflow 和 Plugin 視為不同能力來源；路由器的任務，是為當前請求找到合適候選，而不是把所有能力一次丟給模型。

AutoAttach 在 FoneClaw 裡偏向情境附加。當使用者從浮動入口或目前任務中明確需要畫面脈絡，FoneClaw 可以把目前畫面、任務狀態或相關 metadata 帶進模型判斷。Suggest 則把候選能力變成可見選項，例如「建立備忘」、「開啟地圖」、「準備訊息草稿」。Fallback 則在能力不足、信心不夠、權限被拒或目標不唯一時，給出可接續的下一步。

Plugin activation review 是另一個重要邊界。當某個 Plugin 可能有用，FoneClaw 會把啟用視為明確狀態，而不是路由命中後靜默啟用。Skill learning 也採取 preview 和 confirmation：使用者先看到將要學習或保存的內容，確認後保存為 disabled draft，再由使用者決定何時啟用。這讓能力成長和任務執行保持分離。

執行階段仍然保留核准。路由命中一個傳訊息工具，不代表可以直接送出；命中地圖能力，不代表可以忽略定位權限；命中刪除、分享、撥號或設定工具，仍要顯示對象、內容、理由和結果。若你正在設計信心分級、理由與手機接管流程，可以讀 AI Agent 操作核准介面指南：建議、信心分級、理由與手機接管設計。

從建造 FoneClaw 的經驗看，能力路由的價值不在於讓代理更大膽，而在於讓代理更精準：知道何時帶入情境、何時建議、何時停下、何時要求核准、何時復原。這讓 Android 任務能在真實手機狀態中前進，而不是只停在模型對話裡。

用七項檢查設計與測試能力路由器

設計 AI 代理能力路由器時，第一，測 candidate quality：同一個請求是否能排出合理候選，而不是只命中最常見工具。第二，測 false attachment：畫面上有類似地址、聯絡人或日期時，AutoAttach 是否會過度附加錯誤情境。第三，測 no-match：沒有合適能力時，系統是否清楚說明缺口，而不是編造能力。

第四，測 dependency state：Plugin、Skill、App、帳號、權限、網路或 MCP server 缺失時，是否停在 activation 或 Fallback。第五，測 approval boundary：路由命中高影響工具後，是否仍顯示對象、內容與後果。第六，測 recovery evidence：權限被拒、App 畫面不符、目標不唯一時，是否能回到可接手狀態。

第七，測 repeatability。能力路由不能只在 demo 成功一次，而要在不同 App、不同語言、不同權限狀態、不同失敗情境下保持可解釋。記錄的指標也不應只有準確率，還要包含錯誤附加、建議過多、fallback 品質、activation 卡點、核准清楚度與結果驗證。

若你的重點是 registry、ai-catalog.json、工具目錄與資源信任，可以閱讀 Agentic Resource Discovery 智慧代理資源發現：ai-catalog.json、工具目錄與手機代理授權邊界。本文的責任範圍是下一步：當資源或能力已可被發現，Android 手機代理如何把它放進 AutoAttach、Suggest、Fallback、activation、approval、execution 和 recovery 的決策流程。