代理重繪介面時，使用者究竟確認了什麼？

2026年10月29日，Google發布了利用A2UI與CopilotKit、從應用元件組裝智慧代理介面的教學。這讓一個具體問題更值得討論：介面不斷變化時，使用者的一次確認究竟授權了哪個版本？Google教學。

下文是Open Market Notes的設計分析，並非發現某個漏洞的報導。我們關心的是人閱讀建議到執行動作之間的時間。生成式介面可以讓人直接比較選項，減少來回輸入提示詞；但當代理也在修改建議時，應用程式需要保留一條可靠聯繫：人考慮過的條件，如何對應到最終執行的操作。

同一個按鈕，可能已經換了含義

設想一個客服工作台，以下情境為假設。客服正在審核一筆補寄申請，目的地是客戶原有地址。在客服查看庫存時，另一段對話更新了收貨地址，代理隨後重繪補寄卡片。客服按下了手指原本已經移向的按鈕。

每個欄位都可能合法，客服也可能擁有補寄權限，但系統仍需判斷：他批准的是原來的目的地，還是已經看見並接受了新地址？如果直接把最新表單狀態當作答案，系統便替人解釋了意圖。把介面無限期凍結同樣有問題，因為操作者可能放心地批准已經不能執行的方案。

A2UI的動作文檔允許事件上下文使用字面值，也允許從目前資料模型取值。這提供了事件攜帶的資料；判斷人理解了什麼，仍是應用程式需要處理的問題。動作文檔。

這一區別會影響驗收方式。即使測試證明後端收到的地址與畫面一致，也可能漏掉點擊前一瞬間發生的變化。真正棘手的情況，是系統各層已經同步，而人的理解尚未跟上。

即使底層數值沒有改變，呈現方式也可能製造問題。仍用上述假設：工作卡片只顯示簡寫地址，審核卡片才顯示完整目的地。應用程式應在確認前展示足以區分對象的細節；多人共用一個地點時，收件人也可能很重要。醒目標示變化欄位，只有在標籤能夠解釋其業務含義時才有用。內部編號能夠可靠地綁定操作，卻不一定給人提供可用於決定的資訊。反過來，把全部內部欄位攤開，又可能淹沒真正重要的幾項。審核介面需要有意識地選擇與決定相關的資訊，同時保留查看其他內容的途徑。這個選擇應由產品設計負責，不能完全交給代理為了版面緊湊而自行取捨。

讓待確認方案擁有業務身分

我們建議把持續工作的介面與可供審核的方案分開。代理仍可搜尋、提出建議；當客服進入有實際後果的審核步驟時，應用程式產生一份帶有識別碼、修訂版本和明確業務條件的方案。確認應當指向這份方案，而不是清單中可以被替換的位置，也不是按鈕上的幾個字。

隨後，權威業務服務檢查方案是否仍可執行。在這個例子中，目的地、商品與交付承諾屬於決策條件；卡片顏色、說明段落的排列通常不屬於。如果重要條件發生變化，應用程式應顯示差異並請求新的決定，同時保留其他不受影響的輸入，而不是清空整張表單。解釋究竟變了什麼，比一句沒有緣由的「請重試」更有用。

A2UI規範說明，雙向綁定發生在用戶端本機，輸入透過動作觸發傳送。因此，在應用程式設計裡，呈現欄位與持久化業務紀錄需要分別考慮。協定文檔。

已有技術可以提供部分支撐。例如HTTP的If-Match前置條件，可以讓修改取決於實體標籤是否匹配。RFC 9110。把條件更新用於這裡，是我們的設計推論，並非聲稱教學已經提供此功能。標籤只能保護它代表的資源。如果地址和庫存分屬不同服務，僅檢查卡片版本，並不能證明兩者都仍有效。業務服務需要一致的驗證與提交邊界，或者有明確失效時間的資源預留安排。

哪些變化值得打斷使用者

再次確認也有成本。每次收到更新都打斷，工作人員可能逐漸習慣於跳過提醒；打斷太少，「已確認」又可能失去實際意義。產品團隊應與對結果負責的人一起，用具體任務的語言界定什麼是重要變化。

對於補寄，新目的地即使配送更快，也可能仍需重新審核。一個面向變好，並不等於另一個面向自動獲得同意。相反，如果實際指令完全一致，只是修正內部說明裡的錯字，未必需要再次批准。這些屬於我們提出的產品策略選擇，並非介面協定內建的普遍規則。

介面也應讓並行活動容易理解。例如，可以把「等待審核的新建議」與「目前正在考慮的方案」清楚區分。如果另一位工作人員修改了底層工單，第一位工作人員應在提交前看見具體衝突。只放一個「正在更新」的標記，保護作用有限，尤其是按鈕仍能點擊、操作含義卻持續變化時。

驗收對象應包括決策過程

驗收測試應主動在閱讀、鍵盤導覽與提交期間修改重要條件，還要涵蓋訊息延遲、建議排序變化，以及第二位工作人員同時編輯工單的情況。預期結果未必總是阻止操作：當決策條件未變時，流程應允許繼續，避免無意義地要求人重複勞動。

有用的紀錄應連接被審核的方案、使用者動作與最終業務操作。按照適當的保留政策，保存足以重建這層聯繫的資訊，而不是預設必須存整張截圖或完整對話。單獨的點擊紀錄，以及單獨的API成功回應，都不能充分說明人接受了什麼。

上述文檔無法證明這類不一致在正式環境中有多常見，也不能證明某個具體實作存在此問題。它們支持的是一個及時的設計議題：當代理開始組裝人作出決定的介面，團隊需要明確交代介面何時可以改變、哪些變化會使原決定失效，以及最終操作如何仍然對應到人真正審核過的條件。