做SwiftUI開發(fā)也有三四年了一開始我總覺得它不過是一套比UIKit“叛逆”一點(diǎn)的聲明式UI框架寫界面的方式確實(shí)清爽但真正扎進(jìn)復(fù)雜業(yè)務(wù)之后才發(fā)現(xiàn)難的地方根本不在界面而在“狀態(tài)管理”和“異步任務(wù)”這兩件事上。尤其是當(dāng)你想把一個(gè)智能體Agent塞進(jìn)App里讓它可以調(diào)用各種技能完成任務(wù)SwiftUI那套“狀態(tài)驅(qū)動(dòng)視圖”的線程模型跟Agent天然異步、流式返回的行為方式經(jīng)常打架。這個(gè)項(xiàng)目我命名為SwiftUI-Agent-Skill中心思想就一句話讓Agent技能像插線板一樣可插拔同時(shí)讓技能執(zhí)行過程中的每個(gè)狀態(tài)變化都能被SwiftUI視圖穩(wěn)定、流暢地感知。文章會(huì)從為什么需要這個(gè)抽象講起拆解技能協(xié)議的設(shè)計(jì)、狀態(tài)管理的取舍、流式消息的UI刷新鏈路最后聊幾個(gè)我在實(shí)際調(diào)試中踩到、翻車之后才想明白的坑。不管你是想在App里接大模型做對(duì)話還是想把已有的工具能力以“技能”的形式開放給智能體這篇內(nèi)容應(yīng)該都能給你一些可以直接落地的思路。1. 為什么我想把Agent技能塞進(jìn)SwiftUI應(yīng)用1.1 問題的起點(diǎn)App內(nèi)嵌對(duì)話功能的失控事情是這樣的。某次我開始做一個(gè)實(shí)驗(yàn)性質(zhì)的小項(xiàng)目需求很簡(jiǎn)單在App里加一個(gè)智能助手入口用戶可以用自然語言提需求比如“幫我把右上角的設(shè)置項(xiàng)打開”“給當(dāng)前列表加個(gè)篩選”應(yīng)用內(nèi)的Agent去理解意圖然后調(diào)用相應(yīng)的內(nèi)部能力。最初的做法沒有任何抽象直接在ViewModel里寫了一個(gè)巨大的switch-case。Agent把用戶指令翻譯成一個(gè)動(dòng)作名然后我在視圖層或者業(yè)務(wù)層挨個(gè)判斷動(dòng)作名是“openSettings”就跳設(shè)置頁是“applyFilter”就調(diào)篩選邏輯。這個(gè)方案前幾個(gè)技能還勉強(qiáng)能跑到了第五個(gè)第六個(gè)技能時(shí)已經(jīng)非常痛苦每次加新能力都要改動(dòng)多個(gè)文件還要小心翼翼處理視圖綁定的狀態(tài)技能執(zhí)行中按鈕要不要禁用進(jìn)度提示放哪失敗后的錯(cuò)誤彈窗誰負(fù)責(zé)更讓人頭大的是SwiftUI對(duì)狀態(tài)更新非常敏感。Agent技能的執(zhí)行是異步的可能一個(gè)技能跑好幾秒期間還要不斷往界面上吐中間日志、更新進(jìn)度。如果直接把這些異步回調(diào)散落在各個(gè)視圖里很容易出現(xiàn)“技能執(zhí)行完了界面卻沒刷新”“回調(diào)在主線程外調(diào)用導(dǎo)致SwiftUI更新警告”之類的詭異問題。這促使我去想一個(gè)更系統(tǒng)的方案。1.2 為什么偏偏用SwiftUI來搭這套框架有人可能會(huì)問這種Agent調(diào)度邏輯跟UI框架有什么關(guān)系用UIKit不也一樣能實(shí)現(xiàn)區(qū)別在于SwiftUI的“狀態(tài)驅(qū)動(dòng)視圖”模型天然和Agent技能執(zhí)行過程形成了張力。SwiftUI希望你的界面是狀態(tài)的純函數(shù)給定一份狀態(tài)界面就該長(zhǎng)成那個(gè)樣子。而Agent技能執(zhí)行偏偏是一個(gè)長(zhǎng)時(shí)間、多階段、有中途反饋的過程。如果不在中間加一層“可觀測(cè)的狀態(tài)機(jī)”SwiftUI視圖根本不知道該聽誰的指令來更新。另一方面SwiftUI的Observation框架iOS 17之后的Observable提供了很細(xì)粒度的依賴追蹤。傳統(tǒng)UIKit里你可能要手動(dòng)刷新某個(gè)控件在SwiftUI里只要技能狀態(tài)對(duì)象是一個(gè)可觀察對(duì)象視圖會(huì)自己決定哪些部分需要重新渲染。這正是Agent場(chǎng)景需要的技能A執(zhí)行時(shí)希望展示進(jìn)度條技能B執(zhí)行時(shí)希望展示一條確認(rèn)彈窗技能C也許只需要靜默執(zhí)行。你不需要在視圖層寫滿if-else只需讓技能本身去更新自己的狀態(tài)字段視圖天然響應(yīng)這些變化。所以我把“技能抽象”和“SwiftUI狀態(tài)驅(qū)動(dòng)”放在一起設(shè)計(jì)目的不是炫技而是想找到一種能讓異步Agent流程和聲明式UI和諧共處的架構(gòu)模型。2. 讓Agent技能可插拔從一團(tuán)亂麻到協(xié)議驅(qū)動(dòng)2.1 技能協(xié)議的第一版能跑但不好擴(kuò)展在設(shè)計(jì)技能協(xié)議之前我寫了一個(gè)粗糙的版本。每個(gè)技能都是一個(gè)類提供一個(gè)run()方法返回一個(gè)結(jié)果對(duì)象protocol OldSkill { func run(input: String) async throws - String }這看起來很簡(jiǎn)單但實(shí)際使用時(shí)很快遇到了幾個(gè)問題。第一技能沒有“身份描述”。Agent拿到用戶的自然語言以后怎么知道該調(diào)度哪個(gè)技能只能靠if-else去試探或者人工維護(hù)一張映射表。很不靈活。第二技能沒有“能力聲明”。有的技能需要用戶確認(rèn)權(quán)限有的技能需要傳入幾個(gè)參數(shù)有的技能在執(zhí)行過程中需要展示不同的UI。一個(gè)統(tǒng)一的run(input:)簽名把這些差異全都抹掉了導(dǎo)致技能內(nèi)部充滿了字符串解析和類型判斷的臟代碼。第三技能執(zhí)行過程中想更新UI非常尷尬。有的技能執(zhí)行時(shí)要顯示進(jìn)度有的技能執(zhí)行時(shí)會(huì)觸發(fā)一個(gè)中途交互。舊協(xié)議里run(input:)只能返回一個(gè)最終結(jié)果中途狀態(tài)沒有表達(dá)渠道。最后我只能靠回調(diào)閉包傳遞事件代碼變得非常繞。2.2 協(xié)議怎么設(shè)計(jì)才能讓技能“可插拔”后來參考了智能體和插件系統(tǒng)的常見做法我把技能協(xié)議拆分成了幾個(gè)清晰的職責(zé)部分描述、匹配、執(zhí)行、事件輸出。一個(gè)技能對(duì)外暴露出來的信息足夠多Agent才能優(yōu)雅地路由技能自己主動(dòng)產(chǎn)出狀態(tài)事件SwiftUI才能響應(yīng)式地更新界面。我最終用的協(xié)議大概長(zhǎng)這樣public struct AgentSkillDescriptor: Sendable { public let identifier: String public let displayName: String public let description: String public let parameterSchema: [String: AgentSkillParameter] } public struct AgentSkillParameter: Sendable { public let key: String public let title: String public let required: Bool public let type: ParameterType } MainActor public protocol AgentSkill: AnyObject { var descriptor: AgentSkillDescriptor { get } func canHandle(instruction: String, context: AgentContext) async - Bool func perform(arguments: [String: Any], context: AgentContext) async throws - AgentSkillResult func onEvent(_ event: AgentSkillEvent) }這里有幾個(gè)關(guān)鍵設(shè)計(jì)點(diǎn)值得展開說一下。descriptor是一個(gè)純數(shù)據(jù)對(duì)象包含了技能的標(biāo)識(shí)、名稱、描述和參數(shù)Schema。它對(duì)應(yīng)生活里的“說明書”概念。Agent需要一套說明書才能理解這個(gè)技能是干什么的、需要什么輸入。這和傳統(tǒng)函數(shù)調(diào)用的區(qū)別在于技能的能力描述不再是隱藏的、靠硬編碼的而是可以被讀取、被路由算法理解的。canHandle負(fù)責(zé)意圖匹配。每個(gè)技能可以自己判斷我能不能處理這條指令這種判斷可以基于關(guān)鍵詞、規(guī)則也可以調(diào)用一個(gè)本地的小模型做語義匹配。實(shí)際做下來讓每個(gè)技能自己聲明“我擅長(zhǎng)什么”比統(tǒng)一訓(xùn)練一個(gè)意圖分類器要靈活得多。新增一個(gè)技能的時(shí)候不需要?jiǎng)永霞寄芤膊挥弥匦掠?xùn)練任何模型只要新技能自己的canHandle寫得靠譜就行。perform是技能真正干活的入口。它接收Agent解析出的參數(shù)表執(zhí)行自己的業(yè)務(wù)邏輯返回一個(gè)結(jié)構(gòu)化的AgentSkillResult。協(xié)議本身不限制你干什么調(diào)網(wǎng)絡(luò)接口、修改App設(shè)置、讀寫本地文件都可以。onEvent是技能向外界廣播事件的口子也是我認(rèn)為“SwiftUI友好”最關(guān)鍵的一點(diǎn)。技能執(zhí)行過程中如果想要更新UI就通過這個(gè)方法發(fā)出事件比如AgentSkillEvent.progressUpdated(正在下載, 0.4)、.askForConfirmation(確認(rèn)要?jiǎng)h除嗎?)。外加有一個(gè)context參數(shù)可以拿到當(dāng)前App環(huán)境、用戶Session之類的共享信息。2.3 注冊(cè)與調(diào)度讓Agent知道現(xiàn)在該叫誰有了協(xié)議之后下一步就是管理這些技能。我寫了一個(gè)技能注冊(cè)表本質(zhì)上是一個(gè)數(shù)組加一層索引MainActor final class SkillRegistry { private(set) var skills: [any AgentSkill] [] func register(_ skill: any AgentSkill) { skills.append(skill) } func resolveSkill(for instruction: String, context: AgentContext) async - (any AgentSkill)? { for skill in skills where await skill.canHandle(instruction: instruction, context: context) { return skill } return nil } }這個(gè)resolveSkill在真實(shí)項(xiàng)目里會(huì)做排序、打分而不是簡(jiǎn)單的第一個(gè)命中。不過核心思路一樣Agent拿到用戶指令后先讓所有技能毛遂自薦然后由調(diào)度器拍板。這很像一個(gè)客服總臺(tái)用戶提出需求總臺(tái)根據(jù)每個(gè)客服的擅長(zhǎng)領(lǐng)域分配工單。如果所有人都搖頭就走兜底邏輯告訴用戶“這個(gè)請(qǐng)求我暫時(shí)還處理不了”。在這個(gè)階段我逐漸意識(shí)到之前的設(shè)計(jì)誤區(qū)把技能當(dāng)作“被調(diào)用的函數(shù)”是錯(cuò)誤的。技能應(yīng)該被當(dāng)作“擁有主觀能動(dòng)性的插件”它自己知道自己擅長(zhǎng)什么自己決定如何用最佳方式執(zhí)行還主動(dòng)把自己的執(zhí)行狀態(tài)分享給外界。把這一層想清楚之后后面的狀態(tài)管理設(shè)計(jì)和視圖綁定才變得順理成章。3. 狀態(tài)管理打通從Agent到視圖的“反應(yīng)鏈”3.1 從ObservableObject到Observable的遷移聊SwiftUI的項(xiàng)目狀態(tài)管理是繞不開的話題。一開始我習(xí)慣性地用ObservableObject配合Published來承載Agent技能的狀態(tài)這也是iOS 17以前最常見的做法。后面在實(shí)際調(diào)試中發(fā)現(xiàn)ObservableObject有一個(gè)非常不利的細(xì)節(jié)它要求所有變化都通過Published屬性觸發(fā)一旦某個(gè)字段變化它會(huì)把所有觀察這個(gè)對(duì)象的視圖都通知一遍。Agent技能執(zhí)行過程中的狀態(tài)變化非常頻繁某一句思考日志、某個(gè)步驟進(jìn)度、某個(gè)中間結(jié)果這些都在變化。如果全用Published廣播出去視圖層的刷新范圍往往比實(shí)際需要大得多App在技能執(zhí)行期間會(huì)明顯掉幀。后來我遷移到了iOS 17的Observable宏。這套Observation框架的最大賣點(diǎn)是“細(xì)粒度依賴追蹤”只有真正讀取了某個(gè)屬性的視圖才會(huì)在該屬性變化時(shí)刷新。Agent技能的新狀態(tài)對(duì)象本身也會(huì)在狀態(tài)變化時(shí)自動(dòng)追蹤。遷移之后刷新的范圍一下子收斂了進(jìn)度條只監(jiān)聽進(jìn)度字段狀態(tài)標(biāo)簽只監(jiān)聽階段字段彼此互不干擾界面流暢度提升非常明顯。3.2 技能執(zhí)行的三個(gè)狀態(tài)維度pending、streaming、done對(duì)技能執(zhí)行過程的建模我最終抽象出了三個(gè)狀態(tài)維度分別對(duì)應(yīng)“技能是否被認(rèn)領(lǐng)”“當(dāng)前有沒有流式輸出”“執(zhí)行結(jié)果是什么”。三個(gè)維度獨(dú)立演化組合起來就能描述絕大多數(shù)界面場(chǎng)景。enum AgentSessionPhase { case idle case resolvingSkill case executing case failed case finished } Observable MainActor final class AgentSessionStore { var messages: [AgentMessage] [] var phase: AgentSessionPhase .idle var activeSkillIdentifier: String? var streamingContent: String var lastError: String? }我在實(shí)際項(xiàng)目里的做法是給Agent的每一輪交互建立一個(gè)“Session”會(huì)話內(nèi)記錄所有消息滾動(dòng)式地存儲(chǔ)Agent回復(fù)。phase字段承擔(dān)“階段指示器”的角色用戶發(fā)送指令后進(jìn)入resolvingSkill找到技能并開始執(zhí)行后進(jìn)入executing技能中途有流式輸出時(shí)streamingContent持續(xù)變化最終落入finished或failed。這三個(gè)維度聽起來簡(jiǎn)單但幫我把大量雜亂的UI邏輯理順了。比如視圖層只需要檢查activeSkillIdentifier就能知道“現(xiàn)在是不是有技能正在工作”檢查lastError就能決定是否展示錯(cuò)誤彈窗。不需要在我原先那個(gè)巨大的switch-case里到處塞狀態(tài)。3.3 視圖怎么綁定技能狀態(tài)一個(gè)實(shí)時(shí)案例我舉一個(gè)實(shí)際界面的例子當(dāng)Agent正在執(zhí)行“查詢天氣并匯報(bào)”的技能時(shí)界面需要顯示一條會(huì)話氣泡里面有一個(gè)動(dòng)態(tài)的“打字式”文本。這個(gè)文本流就是streamingContent的實(shí)時(shí)映射。struct AgentChatView: View { Bindable var store: AgentSessionStore var body: some View { ScrollView { LazyVStack(spacing: 12) { ForEach(store.messages) { message in MessageBubble(message: message) } if store.phase .executing { StreamingTypingView(content: store.streamingContent) } } } } }這里的核心是視圖不需要知道技能內(nèi)部怎么執(zhí)行、怎么生成文本它只需要觀察store.streamingContent這個(gè)字段。技能在perform里不斷調(diào)用onEvent(.responseChunk(今天多云))事件總線把字符串追加到streamingContentSwiftUI自動(dòng)把新內(nèi)容渲染到氣泡里。整個(gè)過程一氣呵成。我在這個(gè)階段最大的體會(huì)是Agent技能系統(tǒng)在設(shè)計(jì)時(shí)一定要把“狀態(tài)存儲(chǔ)”和“業(yè)務(wù)邏輯”分開。技能負(fù)責(zé)“做什么”AgentSessionStore負(fù)責(zé)“狀態(tài)長(zhǎng)什么樣”。如果二者耦合在一起界面邏輯和技能邏輯就會(huì)糾纏不清最后代碼越寫越亂。這中間需要一個(gè)事件出口來明確分割線。4. 流式消息的處理AsyncStream與UI刷新的協(xié)同4.1 Agent的回復(fù)為什么不能等“全部完成”再顯示如果你只是讓Agent一次性返回完整結(jié)果那UI刷新其實(shí)沒有任何難度和普通網(wǎng)絡(luò)請(qǐng)求一樣。但現(xiàn)實(shí)中的Agent尤其是對(duì)接本地推理或云端大模型接口的Agent往往需要幾秒甚至更久才能生成完整回復(fù)。如果讓用戶對(duì)著一個(gè)空白的對(duì)話框等上整整幾秒體驗(yàn)非常糟糕。流式返回的核心意義在于把“正在思考的中間過程”展現(xiàn)給用戶讓用戶感受到Agent是“活”的。這就像看人打字字幕一句一句蹦出來比等一整段文字突然出現(xiàn)要自然得多。但流式返回對(duì)SwiftUI來說并不友好。SwiftUI的視圖更新機(jī)制要求狀態(tài)變化要么發(fā)生在主線程要么通過合理的方式調(diào)度到主線程。而Agent的流式回調(diào)很可能來自后臺(tái)隊(duì)列、網(wǎng)絡(luò)回調(diào)、甚至一個(gè)獨(dú)立的推理線程。直接在這些線程里修改streamingContent輕則觸發(fā)“Publishing changes from background threads is not allowed”的警告重則造成數(shù)據(jù)競(jìng)爭(zhēng)和崩潰。4.2 AsyncStream與Task的配套寫法為了把流式回調(diào)安全地轉(zhuǎn)接到SwiftUI的更新鏈路我采用了AsyncStream加Task的寫法。技能執(zhí)行時(shí)Agent把輸出事件寫入一個(gè)異步流UI側(cè)用Task消費(fèi)這個(gè)異步流并在迭代時(shí)切換到主線程更新狀態(tài)。func executeSkill( _ skill: any AgentSkill, instruction: String, context: AgentContext ) async { let stream AsyncStreamAgentSkillEvent { continuation in Task { await skill.perform(arguments: args, context: context, onEvent: { event in continuation.yield(event) }) continuation.finish() } } let task Task { MainActor in for await event in stream { switch event { case .responseChunk(let text): store.streamingContent text case .progressUpdated(let progress): store.progress progress case .askForConfirmation(let prompt): store.pendingConfirmation prompt case .completed(let result): store.messages.append(.agent(result.summary)) store.phase .finished } } } activeTask task }這里有一個(gè)小細(xì)節(jié)容易踩坑Task { MainActor in }內(nèi)部是一個(gè)MainActor隔離的異步上下文for await迭代事件流的每次循環(huán)默認(rèn)都會(huì)在MainActor上執(zhí)行因此直接更新store就是安全的。這里不需要再嵌套MainActor.run寫起來干凈很多。AsyncStream還有一個(gè)很大的好處便于在技能被取消時(shí)關(guān)閉。只要父Task被取消continuation的底層就會(huì)被正確清理消費(fèi)端也能正常退出循環(huán)。相比老式的回調(diào)閉包這算是真正能配合結(jié)構(gòu)化并發(fā)的做法。4.3 MainActor隔離在Agent回調(diào)里碰UI的第一道紅線很多初學(xué)者在接Agent回調(diào)時(shí)喜歡在回調(diào)閉包里直接操作UI狀態(tài)然后很快撞上線程警告。我想強(qiáng)調(diào)一個(gè)原則AgentSessionStore這類與視圖直接綁定的狀態(tài)對(duì)象應(yīng)該在類聲明處就標(biāo)注MainActor讓編譯器從源頭擋住非主線程更新。MainActor Observable final class AgentSessionStore { ... }這么做之后所有試圖在沒有MainActor隔離的上下文里修改store的行為都會(huì)在編譯階段直接報(bào)錯(cuò)。你會(huì)被迫思考“我這條回調(diào)線程到底怎么把數(shù)據(jù)傳回主線程”而不是等運(yùn)行時(shí)崩潰才意識(shí)到問題。技能本身執(zhí)行復(fù)雜計(jì)算時(shí)perform方法內(nèi)部完全沒必要約束在主線程。比較合理的分工是perform在后臺(tái)隊(duì)列上執(zhí)行重活在產(chǎn)出UI事件時(shí)才通過事件總線回傳AgentSessionStore作為UI狀態(tài)容器只負(fù)責(zé)接收、存儲(chǔ)和暴露數(shù)據(jù)。兩邊用AsyncStream這個(gè)“管道”對(duì)接各司其職。5. 我在實(shí)測(cè)里踩過的幾個(gè)坑5.1 列表卡頓流式消息高頻率刷新與節(jié)流第一次跑通整個(gè)流式鏈路的時(shí)候界面看起來非?！芭d奮”——文字刷新頻率極高但實(shí)測(cè)在低端設(shè)備上明顯掉幀。原因是Agent的流式輸出可能以非常小的粒度源源不斷地產(chǎn)生事件比如每10毫秒就有一個(gè)幾個(gè)字的chunk回傳。如果每個(gè)chunk都觸發(fā)一次streamingContent 再驅(qū)動(dòng)視圖重新計(jì)算一次文本布局很容易讓主線程忙不過來。我的解決方案是“節(jié)流合并”。在消費(fèi)流事件時(shí)不立即把每個(gè)chunk都寫入狀態(tài)而是先攢進(jìn)一個(gè)緩沖區(qū)每隔80毫秒左右把緩沖區(qū)里的內(nèi)容批量添加到streamingContent一次。這樣既保留了打字機(jī)式的視覺效果又把主線程的刷新頻率降到一個(gè)合理范圍。var buffer: [String] [] for await event in stream { buffer.append(text) guard Date().timeIntervalSince(lastFlush) 0.08 else { continue } store.streamingContent buffer.joined() buffer.removeAll() lastFlush Date() }在真機(jī)上測(cè)試80毫秒的節(jié)流間隔在普通文本場(chǎng)景下幾乎感知不到延遲流暢度卻好了很多。5.2 ScrollViewReader自動(dòng)滾動(dòng)的失效與修正流式輸出時(shí)聊天列表需要自動(dòng)滾到底部。大部分人會(huì)想到ScrollViewReader加scrollTo。實(shí)測(cè)中發(fā)現(xiàn)一個(gè)奇怪現(xiàn)象在連續(xù)流式輸出期間調(diào)用scrollTo有時(shí)會(huì)失效有時(shí)能滾到指定位置但畫面顯得非常頓挫。排查之后發(fā)現(xiàn)問題出在滾動(dòng)時(shí)機(jī)。流式輸出每刷新一次界面新文本的行高其實(shí)還沒被布局系統(tǒng)計(jì)算完。此時(shí)強(qiáng)制scrollTo目標(biāo)位置會(huì)被估算得不準(zhǔn)。更合理的做法是在刷新之后短暫延一拍再執(zhí)行滾動(dòng)。我采用的方式是在Task里稍微讓一幀Task { try? await Task.sleep(for: .milliseconds(60)) withAnimation(.easeOut(duration: 0.15)) { proxy.scrollTo(lastMessageID, anchor: .bottom) } }這里有個(gè)細(xì)節(jié)withAnimation會(huì)讓滾動(dòng)不那么生硬但動(dòng)畫時(shí)間別設(shè)太長(zhǎng)否則新消息又出來時(shí)滾動(dòng)可能跟不上。0.15秒左右的輕量動(dòng)畫在實(shí)際體驗(yàn)里比較合適。5.3 Task生命周期管理頁面消失了回調(diào)還在更新流式事件消費(fèi)是通過Task掛在視圖或ViewModel上的如果這個(gè)Task沒有妥善取消頁面已經(jīng)銷毀了回調(diào)還在更新原來的store輕則產(chǎn)生無意義計(jì)算重則持有已經(jīng)釋放的視圖導(dǎo)致隱式泄漏。SwiftUI提供了.task修飾符來綁定生命周期.task { await executeSkill(...) }.task會(huì)在視圖從層級(jí)中消失時(shí)自動(dòng)取消綁定的Task。但如果你把Task手動(dòng)保存在屬性里像我在前面的例子里寫的activeTask就要記得在視圖消失時(shí)主動(dòng)取消。我最后采用的做法是統(tǒng)一使用.task管理會(huì)話執(zhí)行同時(shí)讓AsyncStream的消費(fèi)循環(huán)檢查Task.isCancelled一旦取消就退出并清理狀態(tài)。for await event in stream { guard !Task.isCancelled else { break } ... }這一步看似不起眼實(shí)際上救了我好幾次——技能還在執(zhí)行時(shí)用戶退出頁面回來之后發(fā)現(xiàn)界面狀態(tài)沒被上一輪殘留回調(diào)污染這是一個(gè)很關(guān)鍵的用戶體驗(yàn)細(xì)節(jié)。5.4 技能結(jié)果與狀態(tài)不一致的臟讀問題最后一個(gè)坑比較隱蔽。在一次“技能執(zhí)行中用戶又發(fā)來新指令”的并發(fā)場(chǎng)景下我發(fā)現(xiàn)activeSkillIdentifier和streamingContent偶爾會(huì)對(duì)不上界面上顯示技能A正在執(zhí)行流式文本卻是技能B的內(nèi)容。排查后發(fā)現(xiàn)AgentSessionStore里多個(gè)字段是獨(dú)立存儲(chǔ)的當(dāng)新技能開始執(zhí)行時(shí)舊技能的流式輸出可能還在路上。如果先更新了activeSkillIdentifier舊技能的chunk才被消費(fèi)到視圖就會(huì)看到“技能被換掉了但流式文本還是舊技能”的中間狀態(tài)。解決辦法是引入“會(huì)話標(biāo)識(shí)”機(jī)制。每次開始新技能執(zhí)行時(shí)生成一個(gè)sessionID流式事件里帶上這個(gè)ID消費(fèi)端只處理當(dāng)前sessionID匹配的事件舊技能殘留的chunk直接丟棄。store.phase .executing store.activeSkillIdentifier skill.descriptor.identifier let currentSessionID UUID() store.currentSessionID currentSessionID for await event in stream { guard event.sessionID store.currentSessionID else { continue } ... }這個(gè)改法看起來多了一點(diǎn)樣板但它消除了整個(gè)系統(tǒng)里最讓人頭疼的一類數(shù)據(jù)競(jìng)爭(zhēng)問題。以后不管技能怎么并發(fā)執(zhí)行界面狀態(tài)始終只跟“當(dāng)前會(huì)話”綁定。6. 這個(gè)項(xiàng)目后續(xù)還能往哪走6.1 從單技能到技能編排目前的SkillRegistry是“找一個(gè)人來干一件事”的模式。但實(shí)際用戶需求往往不是單個(gè)技能能搞定的比如“幫我把這個(gè)文件轉(zhuǎn)成PDF發(fā)給會(huì)議里的所有人”就涉及文件轉(zhuǎn)換、聯(lián)系人查找、發(fā)送消息三個(gè)技能。我接下來的方向是給AgentSessionStore增加一個(gè)“工作計(jì)劃”的概念讓Agent不只選擇一個(gè)技能而是拆解成一個(gè)技能序列按順序或按依賴關(guān)系執(zhí)行。這一步在協(xié)議層面并不難擴(kuò)展因?yàn)榧寄鼙旧硪呀?jīng)具備了描述能力Agent可以讀取多個(gè)技能的能力集然后編排任務(wù)鏈。真正復(fù)雜的是狀態(tài)管理編排過程中每個(gè)子技能都有獨(dú)立的進(jìn)度和事件界面需要展示一個(gè)總體的執(zhí)行管線。我目前的想法是引入“任務(wù)組”狀態(tài)把技能各自的AgentSkillEvent匯總成子任務(wù)列表視圖用List展示。6.2 讓技能描述更結(jié)構(gòu)化接入自然語言意圖路由后的方向現(xiàn)在canHandle主要靠關(guān)鍵詞和規(guī)則還挺簡(jiǎn)陋。如果想讓技能匹配更智能可以考慮接入自然語言理解模型來做意圖路由所有技能的descriptor作為候選集用戶的自然語言指令作為查詢把匹配得分最高的技能選出來。這也正是descriptor里description字段的用武之地——語義路由模型需要一個(gè)文本形式的“技能能力說明”。我在測(cè)試中嘗試過用embedding向量做相似度匹配效果比關(guān)鍵詞規(guī)則好不少。技能的description寫得好匹配準(zhǔn)確率顯著提升。比如“打開設(shè)置”和“切換到偏好設(shè)置頁面”可以匹配到同一個(gè)技能前提是技能的描述里能覆蓋這兩種表達(dá)方式。這一步做好之后整個(gè)體質(zhì)就可以從容面對(duì)各種模糊表達(dá)的用戶而不必在canHandle里堆砌大量規(guī)則。6.3 一個(gè)我準(zhǔn)備繼續(xù)做的小實(shí)驗(yàn)去年開始我逐漸意識(shí)到SwiftUI的Observable和Agent技能執(zhí)行過程是天然契合的組合。你越往后做越會(huì)覺得“技能系統(tǒng)”本質(zhì)上就是一個(gè)狀態(tài)機(jī)輸入是一個(gè)自然語言請(qǐng)求輸出是一連串UI狀態(tài)事件技能內(nèi)部不過是狀態(tài)轉(zhuǎn)移的載體。如果你在做一個(gè)SwiftUI的智能交互應(yīng)用不管當(dāng)前是只有一個(gè)技能還是已經(jīng)有一堆技能我都建議你盡早把技能抽象成協(xié)議、狀態(tài)統(tǒng)一收口到MainActor的可觀察對(duì)象里。這個(gè)投入的回報(bào)在項(xiàng)目規(guī)模變大后會(huì)非常明顯。我目前還在繼續(xù)做的一個(gè)小實(shí)驗(yàn)是把技能的權(quán)限彈窗也納入事件體系。技能執(zhí)行到“需要讀取通訊錄”時(shí)通過事件主動(dòng)向會(huì)話請(qǐng)求授權(quán)由界面層生成確認(rèn)彈窗用戶點(diǎn)了“允許”之后再把授權(quán)結(jié)果作為參數(shù)回傳給技能。這樣技能能保持純業(yè)務(wù)邏輯不需要直接管理權(quán)限彈窗的展示層級(jí)視圖層也能根據(jù)自己的設(shè)計(jì)風(fēng)格靈活處理提示交互。等我跑通這個(gè)流程應(yīng)該可以再寫一篇復(fù)盤。