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