HarmonyOS 7.0 / API 26 小藝智能體高風險動作確認為什么不能識別到意圖就執行這篇只講一個問題小藝智能體識別出用戶意圖以后哪些動作可以直接執行哪些動作必須再確認一次。版本邊界先寫清楚下面的思路面向 HarmonyOS 7.0 / API 26。這里不寫泛泛的“智能化體驗”而是站在應用開發者的角度看一個更實際的問題智能體可以幫用戶省步驟但不能替用戶做高風險決定。尤其是刪除、支付、提交、公開發布、修改賬號資料這類動作一旦做錯用戶不會覺得應用智能只會覺得應用不可靠。為什么這個問題容易被忽略很多頁面一開始都是按鈕觸發的用戶點按鈕頁面彈確認框確認后再調用接口。接入智能體以后入口變了用戶可能說一句“幫我清掉這些記錄”系統就識別成一個 action。如果代碼里直接把這個 action 交給業務層執行就會繞過原來的確認鏈路。這類問題通常不是編譯報錯而是流程設計錯誤。代碼能跑測試也可能只測到正常路徑但一到真實用戶場景就容易出事。我自己的判斷方式比較簡單只要這個動作執行后很難撤回或者會影響用戶資產、隱私、數據完整性就不能只靠意圖識別結果直接執行必須進入二次確認。先把動作分級不要把所有智能體動作都寫成同一種處理方式。建議先做一層動作分級讓頁面只處理結果不直接猜風險。動作類型例子是否需要確認原因查詢類查天氣、查訂單狀態、查頁面內容一般不需要不改數據出錯也容易糾正頁面跳轉類打開設置頁、打開收藏列表通常不需要只是換頁面沒有直接副作用輕量修改類切換主題、調整排序視情況確認可以撤回時風險較低高風險修改類刪除記錄、提交表單、公開發布必須確認執行后可能造成數據或隱私風險資產相關類支付、兌換、訂閱、扣積分必須確認需要用戶明確授權這個表不要只寫在文檔里最好落到代碼里。否則后面每加一個動作開發者都會按自己的理解寫風險邊界會越來越亂。例子一刪除歷史記錄不能只靠一句話復現場景用戶在應用里打開歷史記錄頁。用戶對小藝說“把最近瀏覽記錄清掉”。智能體識別出clearHistory意圖。如果代碼直接執行刪除用戶可能來不及發現刪的是全部記錄還是篩選后的記錄。這個問題的核心不在智能體識別準不準而在執行前有沒有把影響范圍說清楚。建議做法是先構造待確認動作把動作名稱、影響范圍、數量、是否可撤回都列出來再交給確認層處理。typeRiskLevellow|middle|high;interfaceAgentAction{actionId:string;name:string;riskLevel:RiskLevel;targetCount:number;reversible:boolean;reason:string;}interfaceConfirmResult{canRun:boolean;message:string;}classAgentActionGuard{check(action:AgentAction):ConfirmResult{if(action.riskLevelhigh){return{canRun:false,message:${action.name}會影響${action.targetCount}條數據需要用戶確認后再執行};}if(!action.reversibleaction.targetCount0){return{canRun:false,message:${action.name}不支持撤回先彈確認框};}return{canRun:true,message:低風險動作可以直接執行};}}頁面里不要直接調用刪除接口而是先走 guard。EntryComponentstruct AgentActionPage{privateguard:AgentActionGuardnewAgentActionGuard();StateconfirmText:string等待智能體動作;StatependingActionId:string;handleClearHistoryIntent(){constaction:AgentAction{actionId:clear_history_recent,name:清理最近瀏覽記錄,riskLevel:high,targetCount:28,reversible:false,reason:用戶通過智能體觸發清理動作};constresultthis.guard.check(action);if(!result.canRun){this.pendingActionIdaction.actionId;this.confirmTextresult.message;return;}this.runAction(action.actionId);}runAction(actionId:string){console.info([agent-action] run actionId${actionId});}build(){Column({space:12}){Text(小藝智能體動作確認).fontSize(20).fontWeight(FontWeight.Bold)Text(this.confirmText).fontSize(14)Button(確認執行).enabled(this.pendingActionId.length0).onClick((){this.runAction(this.pendingActionId);this.pendingActionId;this.confirmText動作已確認執行;})}.padding(16)}}這樣做的好處是智能體只負責識別意圖真正執行前仍然由應用自己的安全鏈路兜住。后面如果要加“刪除收藏”“清空緩存”“批量取消訂閱”也能復用同一套判斷邏輯。例子二公開提交類動作要先讓用戶看結果第二個常見場景是提交內容。比如用戶說“幫我把這段反饋發出去”。智能體可能已經幫用戶整理好了文本但公開發布、提交工單、反饋到社區這類動作最好不要直接執行。這里的風險不是技術接口復雜而是內容可能不符合用戶真實想法。用戶說的是一句模糊指令系統生成的是一段具體內容中間必須給用戶一次確認機會。可以把提交動作拆成三個階段prepare生成待提交內容。preview展示內容、目標位置和影響范圍。submit用戶確認后再提交。typeSubmitStepprepare|preview|submit;interfaceAgentSubmitDraft{step:SubmitStep;title:string;content:string;target:string;confirmed:boolean;}classAgentSubmitFlow{next(draft:AgentSubmitDraft):AgentSubmitDraft{if(draft.stepprepare){return{...draft,step:preview};}if(draft.steppreviewdraft.confirmed){return{...draft,step:submit};}returndraft;}}頁面層只根據階段渲染不要把提交按鈕一直放開。Componentstruct SubmitPreviewPanel{Statedraft:AgentSubmitDraft{step:prepare,title:應用反饋,content:頁面在弱網恢復后提示不夠明確希望增加重試說明。,target:反饋中心,confirmed:false};privateflow:AgentSubmitFlownewAgentSubmitFlow();build(){Column({space:10}){Text(this.draft.title).fontSize(18).fontWeight(FontWeight.Medium)Text(提交位置${this.draft.target}).fontSize(13)Text(this.draft.content).fontSize(14)if(this.draft.steppreview){Checkbox().select(this.draft.confirmed).onChange((checked:boolean){this.draft.confirmedchecked;})Text(我已確認提交內容和提交位置)}Button(this.draft.stepprepare?生成預覽:提交).enabled(this.draft.stepprepare||this.draft.confirmed).onClick((){this.draftthis.flow.next(this.draft);if(this.draft.stepsubmit){console.info([agent-submit] user confirmed, submit now);}})}.padding(16)}}這個拆法看起來多了一步但能避免兩個問題一是誤提交二是用戶不知道系統到底替自己提交了什么。對智能體入口來說這一步很關鍵。我會怎么選方案方案適合場景問題識別到意圖就執行查詢、跳轉、無副作用動作不適合刪除、提交、支付等高風險動作每個頁面自己寫確認小項目、動作很少后面動作多了容易漏統一動作分級和確認流多入口、多頁面、多設備前期要把動作模型設計好我更建議第三種。不是因為它看起來復雜而是因為智能體入口會越來越多語音、卡片、桌面入口、跨設備入口都可能觸發同一個動作。確認邏輯如果散在各個頁面里后面很難排查到底哪個入口繞過了安全判斷。怎么驗證不是紙上談兵我會至少測這幾條測試項輸入預期查詢類動作打開某個頁面直接執行刪除類動作清理 28 條歷史記錄進入確認態不直接刪除提交類動作生成反饋并提交先預覽勾選確認后才能提交異常動作actionId 為空攔截并打印原因恢復場景應用切后臺再回來pendingActionId 不丟用戶仍能看見待確認動作日志也要留清楚不然問題很難查[agent-action] intentclearHistory riskhigh targetCount28 resultneed_confirm [agent-submit] steppreview confirmedfalse resultblocked [agent-submit] stepsubmit confirmedtrue resultrun總結小藝智能體接入應用以后真正要守住的不是“能不能識別出意圖”而是“識別出來以后能不能安全執行”。查詢和跳轉可以快高風險動作必須穩。我的建議是把動作分級、二次確認、影響范圍、可撤回性這些規則抽成統一模塊。頁面只接收結果不自己臨時判斷。這樣后面接更多 HarmonyOS 7.0 / API 26 新能力時應用不會因為入口變多而把安全邊界寫亂。