最近在給某跨平臺系統(tǒng)做 Agent 框架選型把 Coding Agent 和 Personal Agent 放到一起對比發(fā)現(xiàn)一個特別容易被忽略的斷層兩者看起來都是“AI 助手”可底層架構(gòu)的設(shè)計邏輯幾乎是兩條路線。Coding Agent 的核心是短周期執(zhí)行循環(huán)每次任務(wù)以分鐘級收斂Personal Agent 的核心則是長期委托能力要能在跨會話的時間尺度上持續(xù)服務(wù)。這篇內(nèi)容把我這段時間踩過的坑和對比結(jié)論整理出來適合正在做 Agent 架構(gòu)選型、或者想把手上的工具改造成長期 Agent 的開發(fā)者參考。1. 先搞清楚兩類 Agent 的定位差異與核心矛盾1.1 Coding Agent 的典型場景與能力邊界Coding Agent 最常見的形態(tài)是“自動寫代碼助手”給它一段任務(wù)描述比如“修復(fù)登錄模塊的 token 過期問題”它讀取代碼庫定位相關(guān)文件修改內(nèi)容跑測試最后輸出一個 patch。整個過程通常控制在幾分鐘內(nèi)目標(biāo)是快速收斂到可驗證的結(jié)果。這個場景有幾個鮮明特征。第一任務(wù)邊界清晰輸入是 bug 描述或功能需求輸出是代碼變更。第二驗證機制現(xiàn)成編譯器、單元測試、lint 工具就是天然的裁判改得對不對可以自動判斷。第三環(huán)境可控大部分操作發(fā)生在本地倉庫或獨立的沙箱環(huán)境里。這三個特點決定了 Coding Agent 的架構(gòu)可以圍繞“短循環(huán)”來設(shè)計。任務(wù)拆細(xì)、快速執(zhí)行、自動驗證、失敗重試這套流程在編程場景里跑得通因為每一步都有明確的對錯標(biāo)準(zhǔn)。1.2 Personal Agent 的典型場景與能力邊界Personal Agent 是另一類東西。它的典型任務(wù)是“幫我安排下周去某地的行程”“定期整理項目周報”“跟蹤某份合同到簽收為止”。這些任務(wù)的共同點是周期長、目標(biāo)模糊、邊界開放而且往往跨會話——不是一次對話能完成的需要 Agent 在數(shù)小時甚至數(shù)天的時間里持續(xù)跟進。這里的能力邊界就完全不一樣了。Personal Agent 沒有編譯器這種即時裁判一個決策的對錯往往要等真實世界反饋它也沒有封閉沙箱很多時候操作的是用戶的日歷、郵箱、支付賬戶之類的真實系統(tǒng)。更關(guān)鍵的是任務(wù)目標(biāo)通常不是一次性指令而是帶約束的持續(xù)委托比如“盡量選早班機但別超過預(yù)算”。這種場景對架構(gòu)的要求不再是“單次循環(huán)多快能收斂”而是“下一次交互時 Agent 還記不記得目標(biāo)、有沒有掌握足夠的上下文、能不能自主判斷該不該繼續(xù)”。1.3 核心矛盾確定性任務(wù)與開放式任務(wù)的架構(gòu)權(quán)衡把兩類場景擺在一起看核心矛盾就清楚了Coding Agent 處理的是確定性任務(wù)Personal Agent 處理的是開放式任務(wù)。確定性任務(wù)可以設(shè)計成短循環(huán)因為每一步的執(zhí)行結(jié)果都有客觀標(biāo)準(zhǔn)來判斷開放式任務(wù)則必須考慮長期狀態(tài)因為執(zhí)行路徑無法預(yù)先窮舉而且錯誤代價可能很高。這個差異直接決定了架構(gòu)側(cè)重點。Coding Agent 的架構(gòu)重點是“工具調(diào)用能力”和“驗證反饋速度”Personal Agent 的架構(gòu)重點則是“記憶持久化”“規(guī)劃拆解”和“人類確認(rèn)機制”。如果只是給 Coding Agent 加一個定時器硬說它是 Personal Agent大概率會在長周期任務(wù)上失控反過來如果讓 Personal Agent 用 Coding Agent 那套“快速循環(huán)、頻繁重試”的邏輯去處理真實世界的委托用戶大概率會被攪得心力交瘁。架構(gòu)選型之前先想清楚自己到底要解決哪一類問題這是最重要的一步。2. Coding Agent 的短周期執(zhí)行循環(huán)如何運轉(zhuǎn)2.1 標(biāo)準(zhǔn)執(zhí)行循環(huán)的五步拆解Coding Agent 的執(zhí)行循環(huán)行業(yè)里已經(jīng)形成了比較一致的拆法我一般把它分成五步理解任務(wù)、搜索上下文、制定計劃、執(zhí)行變更、驗證結(jié)果。這五步構(gòu)成一個閉環(huán)跑完一輪如果驗證不通過就回到第三步重新調(diào)整計劃直到通過或達到最大重試次數(shù)。第一步“理解任務(wù)”看起來簡單其實最容易出問題。模型需要把自然語言描述映射到具體的代碼意圖比如“修 bug”到底修的是邏輯錯誤還是邊界條件這需要抽取關(guān)鍵實體。第二步“搜索上下文”是 Coding Agent 區(qū)別于普通聊天的核心能力它不能只靠對話里提供的信息必須主動去倉庫里檢索相關(guān)文件、函數(shù)定義、調(diào)用鏈。第三步的“制定計劃”決定了后續(xù)動作的質(zhì)量這一步往往需要模型把大任務(wù)拆成多個原子步驟比如先加日志定位問題、再改核心邏輯、最后補測試。執(zhí)行變更和驗證結(jié)果是最后兩步也是最吃工具鏈的部分。執(zhí)行變更依賴文件編輯工具驗證結(jié)果依賴測試框架、靜態(tài)檢查、構(gòu)建腳本。整個循環(huán)的粒度通?？刂圃趲资氲綆追昼娨淮瓮暾芡昃湍墚a(chǎn)出一個可評審的 diff。這個周期的選擇不是拍腦袋定的而是因為編程任務(wù)的反饋信號足夠密集壓縮循環(huán)時間能顯著提升試錯效率。注意Coding Agent 在制定計劃階段經(jīng)常犯一個錯——跳過“搜索上下文”直接改代碼。模型憑訓(xùn)練時的記憶猜代碼結(jié)構(gòu)結(jié)果改錯位置。我在實際項目中給 Agent 加了一條硬規(guī)則沒有完成倉庫索引掃描之前不允許生成 diff效果立竿見影。2.2 為什么編程任務(wù)天然適合短循環(huán)編程任務(wù)適合短循環(huán)本質(zhì)原因是“驗證成本極低反饋信號極強”。改一行代碼對不對跑一次測試就知道刪了一個函數(shù)會不會影響調(diào)用方靜態(tài)檢查立刻報警。這種即時反饋讓 Agent 可以在循環(huán)里反復(fù)試錯不需要驚動用戶。對比一下真實世界的任務(wù)就能感受到差距。讓 Agent 幫你訂一張機票它訂完了無法立即知道“這個選擇用戶是否滿意”更不可能在幾秒內(nèi)反復(fù)改方案而修一段代碼編譯失敗的報錯就擺在眼前改到通過為止是合理的策略。另一個原因是錯誤代價可控。代碼改錯了版本回滾、git 恢復(fù)就能解決最大損失是幾分鐘時間而訂錯機票、發(fā)錯郵件這類操作挽回成本要高得多。所以 Coding Agent 可以放心地把“自動重試”寫進循環(huán)里Personal Agent 則必須謹(jǐn)慎設(shè)計每一步的確認(rèn)節(jié)點。2.3 上下文窗口與代碼庫檢索的博弈Coding Agent 的一個隱蔽難點是對抗上下文窗口的物理限制。代碼倉庫動輒幾萬個文件模型上下文窗口再大也裝不下而程序邏輯又是高度網(wǎng)絡(luò)化的改一個函數(shù)往往牽涉調(diào)用鏈上下游。這迫使架構(gòu)里必須有“按需檢索”的層而不是把整個倉庫塞給模型。我常用的做法是分三層檢索第一層是關(guān)鍵詞檢索定位可能相關(guān)的文件第二層是符號索引找到函數(shù)、類、變量的定義和引用點第三層是調(diào)用鏈展開把測試文件、配置里相關(guān)片段拉進上下文。這個過程本質(zhì)上是把“短循環(huán)”和“大倉庫”之間的鴻溝用檢索管道填平。設(shè)計這個管道時要特別注意控制每次檢索返回的信息量一次返回太多反而會讓模型失去焦點。實測下來把單次檢索結(jié)果限制在相關(guān)文件的前幾百行內(nèi)模型的修改準(zhǔn)確率比“一次性給一堆文件”要高不少這個數(shù)據(jù)在多個模擬項目上都能復(fù)現(xiàn)。3. Personal Agent 的長期委托模型設(shè)計3.1 長期委托到底“長”在哪里很多人以為 Personal Agent 的“長期”是指單次任務(wù)要執(zhí)行很久比如讓 Agent 跑一個耗時幾個小時的腳本。這其實是誤解。長期委托的核心特征是跨會話、跨時間尺度地保持目標(biāo)一致性用戶周一委托了一個任務(wù)Agent 周三主動回來匯報進展周五需要根據(jù)中途變化調(diào)整方案。它要求 Agent 在使用者不在場的時間段里仍然保有目標(biāo)和狀態(tài)。這個“保有”說起來容易做起來牽扯到一整套架構(gòu)。任務(wù)目標(biāo)、中間產(chǎn)物、用戶偏好、歷史決策記錄這些東西必須從上下文窗口里“卸載”到持久化存儲中并在下次會話時重新“裝載”。沒有這一步跨會話就是一個偽命題——每次重新開始對話Agent 都是失憶的只能靠用戶重新把需求完整說一遍。我見過不少團隊試圖用“每次對話前把聊天記錄拼進 prompt”的辦法來解決問題短期撐得住但對話超過十幾輪之后 token 成本和注意力丟失問題就會一起爆發(fā)。3.2 三件套記憶層、規(guī)劃器、事件驅(qū)動長期委托的架構(gòu)我拆下來核心是三件套記憶層、規(guī)劃器、事件驅(qū)動。記憶層負(fù)責(zé)持久化把每次交互的結(jié)論提煉成結(jié)構(gòu)化記錄包括用戶偏好、任務(wù)狀態(tài)、關(guān)鍵約束點。規(guī)劃器負(fù)責(zé)把高層目標(biāo)拆成可執(zhí)行的階段性計劃并維護“當(dāng)前進行到哪一步”的進度視圖。事件驅(qū)動則是觸發(fā) Agent 行動的機制它既可以被用戶消息觸發(fā)也可以被定時器、外部通知、任務(wù)里程碑觸發(fā)。這三個組件之間是強耦合的。規(guī)劃器拆分出的每個階段必須能從記憶層讀出足夠上下文事件系統(tǒng)收到的每個信號需要更新記憶層里的狀態(tài)。舉個例子用戶委托“跟進供應(yīng)商合同”規(guī)劃器拆成“整理條款摘要—確認(rèn)審批流程—發(fā)出簽約提醒—歸檔最終版本”四個階段。當(dāng) Agent 收到一封新郵件事件驅(qū)動機制先判斷這封郵件是否與合同任務(wù)相關(guān)如果是就更新記憶層中的任務(wù)狀態(tài)然后推進規(guī)劃器的下一階段。實操提示記憶層不是越大越好。我踩過幾次坑之后總結(jié)出的經(jīng)驗是優(yōu)先記錄“約束條件”和“決策理由”而不是流水賬式的操作日志。比如記憶里應(yīng)該存“用戶對預(yù)算上限很堅持超過三萬的方案不用提”這比存“用戶說了一串關(guān)于預(yù)算的話”有用得多。3.3 信任與安全邊界怎么畫長期委托意味著 Agent 獲得了比單次助手更大的自主權(quán)這就帶來信任與安全問題。Personal Agent 會在用戶授權(quán)范圍內(nèi)操作真實系統(tǒng)因此必須在架構(gòu)層面明確“什么能自主做、什么必須請示”的邊界。我的做法是為 Agent 配置三層權(quán)限梯度。第一層是純信息收集比如查日歷、讀郵件摘要這類操作低風(fēng)險可以自主執(zhí)行第二層是寫入操作比如新建日程項、保存筆記這類操作必須先經(jīng)過規(guī)則校驗比如檢查時間沖突、確認(rèn)收件人列表第三層是外部動作比如發(fā)送郵件、提交表單、預(yù)訂服務(wù)這類操作必須顯式請示用戶等確認(rèn)之后才能執(zhí)行。把權(quán)限梯度寫進 Agent 的提示詞還不夠要在工具調(diào)用的代碼層做硬校驗否則模型一旦上下文漂移就可能越權(quán)操作。4. 兩類 Agent 的系統(tǒng)性架構(gòu)對比4.1 一張表看清循環(huán)粒度差異這里我把兩類 Agent 的關(guān)鍵差異整理成一張對比表方便直接對照。維度Coding AgentPersonal Agent任務(wù)周期分鐘級到小時級小時級到周級執(zhí)行循環(huán)粒度單次工具調(diào)用階段式任務(wù)步驟驗證方式編譯器、測試、靜態(tài)檢查用戶確認(rèn)、規(guī)則校驗、事實核查上下文策略滑動窗口 按需代碼檢索分層持久化記憶 會話內(nèi)加載失敗處理自動重試、快速調(diào)整方案上報用戶、等待授權(quán)、降級處理用戶介入頻率低生成 diff 后統(tǒng)一評審高關(guān)鍵決策點逐步確認(rèn)典型風(fēng)險改錯代碼、破壞構(gòu)建越權(quán)操作、隱私泄露、目標(biāo)漂移這張表最值得琢磨的是“執(zhí)行循環(huán)粒度”這一行。Coding Agent 的循環(huán)單位是“一次工具調(diào)用”比如編輯一個文件、跑一次測試Personal Agent 的循環(huán)單位則是“一個任務(wù)階段”比如完成一輪信息收集、產(chǎn)出一份摘要。粒度放大之后循環(huán)的每個節(jié)點都承載了更多不可逆操作所以必須在節(jié)點之間插入人工或規(guī)則的閘門。4.2 狀態(tài)管理短期上下文與長期記憶的分工兩類 Agent 在狀態(tài)管理上的策略截然不同。Coding Agent 信奉“用完即走”每次循環(huán)的中間狀態(tài)都盡量留在上下文窗口里任務(wù)結(jié)束就丟棄最多保留一份 diff 供用戶審閱。這種策略的原因很現(xiàn)實代碼修改是一個可回溯、可重放的過程git 歷史本身就是狀態(tài)管理Agent 不需要額外負(fù)擔(dān)。Personal Agent 則不能這么干。它面對的任務(wù)沒有 git 這種天然持久化工具而且目標(biāo)本身會隨時間演化比如“安排旅行”在行程訂完后就變成“提醒用戶準(zhǔn)備簽證材料”狀態(tài)的流轉(zhuǎn)需要 Agent 自己跟蹤。我的方案是引入分層記憶第一層是工作記憶存在當(dāng)前上下文里對應(yīng)正在執(zhí)行的活動步驟第二層是任務(wù)記憶存到本地數(shù)據(jù)庫記錄每個任務(wù)當(dāng)前階段、依賴關(guān)系、阻塞項第三層是用戶元記憶記錄歷史偏好、長期約束、常見決策模式。每次新會話啟動時工作記憶從任務(wù)記憶和用戶元記憶中動態(tài)加載而不是從零開始。4.3 失敗處理與人類介入策略的差異失敗處理策略最能體現(xiàn)兩類 Agent 的哲學(xué)差異。Coding Agent 的默認(rèn)策略是“自己搞定”測試掛了先看日志調(diào)整代碼再跑一遍連續(xù)幾次失敗后才考慮換方案。這種策略的高效前提是失敗成本低重試和調(diào)整不會造成額外負(fù)擔(dān)。Personal Agent 的失敗處理要復(fù)雜得多。某個外部操作失敗了直接重試可能造成重復(fù)扣款、重復(fù)發(fā)送等后果。在真實世界場景里Agent 首先要判斷失敗的類型和可重試性。請求超時這種暫時性失敗可以自動重試但要加冪等控制業(yè)務(wù)規(guī)則沖突這種確定性失敗正確做法是停下來把沖突點整理成一份帶選項的說明發(fā)給用戶。我通常在 Personal Agent 的循環(huán)里增加一個“失敗分級”節(jié)點每類失敗映射到不同的處置策略而不是讓模型自由發(fā)揮。5. 落地實踐怎么選型與改造5.1 技術(shù)棧選型的三個判斷標(biāo)準(zhǔn)面對一堆 Agent 框架如何判斷適不適合自己手上的項目我總結(jié)出三個判斷標(biāo)準(zhǔn)。第一個標(biāo)準(zhǔn)是看循環(huán)模型是否可配置。Coding Agent 框架通常把“工具調(diào)用—結(jié)果返回”這個循環(huán)寫得很死改造 Personal Agent 時會發(fā)現(xiàn)很難插入長期記憶節(jié)點。起碼要確認(rèn)框架的循環(huán)是圖結(jié)構(gòu)而不是線性結(jié)構(gòu)LangGraph 這類基于圖編排的框架在這一點上有明顯優(yōu)勢。第二個標(biāo)準(zhǔn)是看記憶和存儲抽象是否成熟。Personal Agent 需要把狀態(tài)持久化到數(shù)據(jù)庫框架得提供清晰的記憶接口或者至少允許自定義存儲后端而不是把狀態(tài)全放在內(nèi)存里。第三個標(biāo)準(zhǔn)是看人類介入原語設(shè)計得怎么樣。長期委托任務(wù)需要“暫?！却_認(rèn)—恢復(fù)”這樣的機制框架是否原生支持這種交互模式直接決定了改造工作量。我在某跨平臺系統(tǒng)項目里對比過幾個方案最后選擇了支持有限狀態(tài)機和人工確認(rèn)節(jié)點的那些改造起來舒服很多。5.2 從 Coding Agent 改造成 Personal Agent 的關(guān)鍵步驟把現(xiàn)成的 Coding Agent 改造成 Personal Agent第一步不是加功能而是重構(gòu)循環(huán)粒度。Coding Agent 的循環(huán)是“感知—思考—行動—驗證”Personal Agent 要變成“感知—思考—行動—存檔—確認(rèn)—行動”。每次完成一個有獨立意義的行為后先存檔狀態(tài)再判斷是否需要用戶確認(rèn)。第二步是把上下文策略從“滑動窗口”切換成“記憶分層”。需要確定哪些信息退出上下文轉(zhuǎn)成持久化數(shù)據(jù)哪些信息在每次會話開始時要主動裝載。這個決策可以做成一個篩選函數(shù)用規(guī)則判斷每條信息的去留。第三步是重新設(shè)計失敗處理分支。Coding Agent 的失敗分支是“重試或換個方案”Personal Agent 必須增加“上報、降級、忽略”的選項。特別是涉及外部系統(tǒng)操作時重試策略必須加冪等校驗。改到這個程度原來的框架如果還是把每一步路由到同一個重試邏輯就說明框架天花板到了。5.3 一個簡化示例帶長期委托能力的輕量 Agent下面是一個簡化版 Personal Agent 的 Python 狀態(tài)機骨架體現(xiàn)長期委托的核心控制邏輯。from enum import Enum class State(Enum): IDLE idle EXECUTING executing ARCHIVING archiving WAITING_CONFIRM waiting_confirm ENDED ended class PersonalAgent: def __init__(self, memory, planner): self.memory memory self.planner planner self.state State.IDLE self.task_context None def start(self, goal): # 目標(biāo)落到規(guī)劃器產(chǎn)出的計劃寫入記憶 self.task_context self.planner.create_plan(goal) self.memory.save(active_plan, self.task_context) self.state State.EXECUTING return self._step() def _step(self): step self.planner.current_step(self.task_context) if step is None: self.state State.ENDED return {status: done} result self._execute(step[action]) self.memory.log(step, result) # 關(guān)鍵步驟強制等待用戶確認(rèn) if step.get(requires_confirmation): self.state State.WAITING_CONFIRM return {status: awaiting_confirmation, step: step} self.state State.ARCHIVING self.memory.commit(step) return self._advance() def confirm(self, approvedTrue): if self.state ! State.WAITING_CONFIRM: raise RuntimeError(not in confirmation state) if approved: self.memory.commit_current_step() return self._advance() else: self.planner.revise(self.task_context) return self._step() def _advance(self): self.planner.advance(self.task_context) self.state State.EXECUTING return self._step()這個骨架刻意把“存檔”和“確認(rèn)”做成循環(huán)里的顯式節(jié)點。ARCHIVING狀態(tài)保證每個動作執(zhí)行后都先把上下文寫進記憶層WAITING_CONFIRM狀態(tài)保證高風(fēng)險動作不會自行放行。實際項目里你還需要在這個基礎(chǔ)之上掛事件驅(qū)動入口比如定時器或者消息訂閱但核心的狀態(tài)流轉(zhuǎn)邏輯是不變的長期委托不是讓 Agent 一次性把任務(wù)干完而是讓它在一個可控狀態(tài)機里按節(jié)奏推進。6. 實戰(zhàn)中踩過的坑與排查心得6.1 記憶漂移Agent 做著做著忘了原始目標(biāo)跑長周期任務(wù)時最常見的問題是記憶漂移Agent 在逐個執(zhí)行子任務(wù)的過程中逐漸偏離最初的用戶目標(biāo)。原因并不神秘每一輪對話的模型注意力都有限中間過程產(chǎn)生的信息會把最初的約束條件“擠”出上下文窗口。我的解決方案是引入“意圖錨點”機制。在新會話或任務(wù)啟動時把原始目標(biāo)和不可變更的約束單獨存成一個固定文件每次循環(huán)開始前強制加載到上下文最前面。無論中間過程新增多少內(nèi)容Agent 每次決策前都會重新看到原始目標(biāo)。實測下來這個改動讓目標(biāo)漂移率下降得非常明顯。避坑心得被擠掉的通常不是任務(wù)主體而是“隱式約束”比如“不要動已有的測試邏輯”“這塊代碼需要保持向后兼容”。這種約束在原始任務(wù)描述里經(jīng)常只是一句話丟了就很難發(fā)現(xiàn)。我的習(xí)慣是讓規(guī)劃器拆解時專門抽出一層“約束列表”跟目標(biāo)錨點一起固定加載。6.2 循環(huán)失控?zé)o意義的迭代重試Personal Agent 接入真實系統(tǒng)后會遇到循環(huán)失控的變體同一個操作反復(fù)失敗、反復(fù)重試每次失敗原因都一樣Agent 卻總是換湯不換藥地試下去。根源是模型的失敗分析不夠深只看到了表層異常沒有定位到根本原因。應(yīng)對辦法是給循環(huán)設(shè)置多維熔斷條件。除了最常見的迭代次數(shù)上限我更推薦加“同類失敗次數(shù)”和“驗證失敗比例”兩個指標(biāo)。比如連續(xù)三次失敗在同一工具調(diào)用直接停止自動重試生成一份排查報告提交用戶。另外每次失敗的信息要結(jié)構(gòu)化返回給 Agent包括錯誤類型、狀態(tài)碼、可能的修復(fù)建議讓下一次循環(huán)的起點信息足夠充足。6.3 工具鏈斷裂權(quán)限與外部依賴的暗坑Agent 的工具調(diào)用鏈條非常脆弱。常見斷點包括環(huán)境變量缺失、外部 API 變更、目標(biāo)系統(tǒng)權(quán)限調(diào)整、以及模型生成的參數(shù)不兼容。這些斷點單個看都不算嚴(yán)重但在長周期任務(wù)里任何一處斷裂都會讓整個計劃阻塞。我在實際項目里有兩層防護。第一層是給每個外部工具定義一份顯式的調(diào)用協(xié)議包括輸入輸出 schema、鑒權(quán)要求和常見錯誤碼Agent 在調(diào)用工具前先“讀取協(xié)議”而不是靠模型記憶去猜。第二層是對外部調(diào)用做一次“預(yù)檢”檢查必要參數(shù)、令牌是否過期、目標(biāo)服務(wù)是否可達預(yù)檢通過后才真正發(fā)起調(diào)用。預(yù)檢成本很低但能把大量“假失敗”攔截在正式執(zhí)行之前。6.4 匯報時機長期任務(wù)要不要頻繁同步長期委托還有一個容易被忽視的體驗問題Agent 應(yīng)該在什么時機向用戶匯報進度。太頻繁會讓用戶煩比如每五分鐘推送一條“我在做什么”太少會讓用戶焦慮擔(dān)心 Agent 是不是卡住了。我采用的策略是“里程碑式匯報 異常即時匯報”。正常執(zhí)行期間Agent 只在完成一個獨立階段后匯報概要遇到需要決策、出現(xiàn)異常、或者等待外部反饋超過閾值時才即時聯(lián)系用戶。把匯報節(jié)奏寫進架構(gòu)而不是交給模型臨場發(fā)揮能省掉大量通知噪音。尤其要注意取消“過程直播”式的匯報大部分用戶要的是結(jié)果和關(guān)鍵選擇點不關(guān)心工具被調(diào)用了幾次。這幾次折騰下來我最大的體會是做 Coding Agent 時腦子要快循環(huán)要短能用工具驗證就不要問用戶做 Personal Agent 時則反過來狀態(tài)要先落盤動作要先想邊界確認(rèn)節(jié)點寧多勿少。兩類 Agent 本質(zhì)上是不同物種拿一邊的架構(gòu)經(jīng)驗直接套另一邊遲早會在真實場景里栽跟頭。