1. 面試官第一問你寫的那個(gè)聊天機(jī)器人算不算Agent上周我去某頭部電商平臺面一個(gè)AI Agent方向的崗位面試官沒讓我自我介紹上來就拋了一個(gè)問題你簡歷上寫的那個(gè)智能助手能聊天、能推薦商品、還能生成文案它算Agent嗎我當(dāng)時(shí)下意識點(diǎn)頭覺得當(dāng)然算。但面試官緊接著補(bǔ)了一句如果我把你寫的Prompt模板抽掉它還能自己決定下一步干什么嗎如果不能那它只是套了Agent外殼的ChatBot。這一下把我問住了?；厝ブ笪野颜麠l技術(shù)鏈路重新捋了一遍才發(fā)現(xiàn)自己之前對Agent的理解確實(shí)浮在表面。這篇文章就是把那次追問的完整過程復(fù)盤出來用大白話拆清楚大模型究竟是怎么從會聊天變成會干活的Agent的靈魂到底藏在哪以及一套能直接落地的設(shè)計(jì)思路。不管你是剛?cè)腴T的小白還是已經(jīng)在寫Agent應(yīng)用的開發(fā)者這篇都值得收藏。我會盡量少用黑話遇到繞不開的術(shù)語就用生活里的例子解釋保證你看完能復(fù)述給別人聽。面試官其實(shí)是在提醒一個(gè)關(guān)鍵事實(shí)會調(diào)用大模型不等于懂Agent會設(shè)計(jì)Agent不等于懂Agent靈魂。靈魂這個(gè)東西聽起來玄但落到工程上完全可以拆解成可檢驗(yàn)的模塊。下面我從那場面試的追問鏈開始講。1.1 Agent與ChatBot的分界線主動權(quán)在哪里先放下概念想一個(gè)最簡單的場景。你讓聊天機(jī)器人幫我訂一張周五去杭州的高鐵票普通ChatBot會怎么做它給你一段回答好的建議您登錄12306選擇周五出發(fā)的車次……它把訂票這件事做成了教你怎么訂票。Agent會怎么做它會先拆解訂票需要哪些信息出發(fā)地、目的地、時(shí)間、車次偏好缺什么就問什么然后調(diào)用訂票接口、支付接口一步一步把票訂完再把訂單號給你。前者的主動權(quán)在用戶手里后者的主動權(quán)在系統(tǒng)手里。主動權(quán)是否發(fā)生轉(zhuǎn)移就是ChatBot和Agent的第一條分界線。這條線看起來簡單實(shí)際落地時(shí)大部分人在這里就翻車了。因?yàn)樽屨Z言模型主動決定下一步很容易實(shí)現(xiàn)難的是讓它的每一個(gè)主動決定都是可預(yù)期的、可追溯的、不會跑偏的。面試官想聽的其實(shí)不是Agent會拆解任務(wù)這種泛泛之談而是你知不知道拆解之后有哪幾個(gè)環(huán)節(jié)最容易失控。我后來把這條追問鏈整理成了四層感知層、規(guī)劃層、行動層、反思層。ChatBot基本只有感知層和一層很薄的話術(shù)生成Agent則把后面三層真正做得有厚度。下一節(jié)就按這個(gè)鏈條展開。1.2 能干活的三個(gè)硬指標(biāo)工具、狀態(tài)、反饋聽面試官連續(xù)追問了幾個(gè)項(xiàng)目之后我總結(jié)出他判斷你是不是真做過Agent的三個(gè)硬指標(biāo)這三個(gè)詞在簡歷里都見過但多數(shù)人沒往深里想第一個(gè)硬指標(biāo)是工具調(diào)用。你的Agent能不能真正操作外部系統(tǒng)而不是把操作步驟寫成文字回復(fù)比如查天氣、發(fā)郵件、改訂單狀態(tài)、寫數(shù)據(jù)庫這些動作必須通過真實(shí)的函數(shù)調(diào)用完成。代碼實(shí)現(xiàn)上通常是一個(gè)tools列表加一個(gè)解析循環(huán)大模型輸出結(jié)構(gòu)化參數(shù)系統(tǒng)執(zhí)行函數(shù)并把結(jié)果喂回模型。第二個(gè)硬指標(biāo)是狀態(tài)管理。你的Agent能不能記住當(dāng)前做到哪一步了、已經(jīng)拿到了什么信息、還缺什么信息聊天機(jī)器人只需要記住對話歷史Agent需要維護(hù)一個(gè)任務(wù)狀態(tài)這和上下文完全是兩碼事。很多新手把整個(gè)對話歷史全部塞進(jìn)Prompt看起來是記住了其實(shí)模型對有效狀態(tài)的感知被大量廢話稀釋了。第三個(gè)硬指標(biāo)是反饋閉環(huán)。工具的返回結(jié)果能不能真正影響Agent的下一步?jīng)Q策如果工具返回了支付失敗、余額不足Agent是機(jī)械地回復(fù)支付失敗還是能自動轉(zhuǎn)入引導(dǎo)用戶換支付方式的新分支后者的本質(zhì)是讓模型根據(jù)真實(shí)世界反饋去做下一輪規(guī)劃這也是Agent和腳本的本質(zhì)區(qū)別。腳本是寫死的if-elseAgent是模型自己決定if后面的分支怎么走。面試官說了一句我印象特別深的話Agent不是大模型的加強(qiáng)版大模型只是Agent的發(fā)動機(jī)。你是不是真在造車要看輪子、方向盤和儀表盤不能光看引擎參數(shù)。工具、狀態(tài)、反饋這三個(gè)指標(biāo)就是輪子、方向盤和儀表盤。2. 追問鏈條拆解從能聊天到能干活中間隔著一臺規(guī)劃器面試的第二個(gè)環(huán)節(jié)面試官指著我簡歷里的一個(gè)項(xiàng)目問這里面哪一段代碼是你認(rèn)為最像Agent靈魂的我猶豫了一下說是模型調(diào)用那段。他搖頭說那段代碼最多算靈魂的嘴巴真正的靈魂應(yīng)該在調(diào)用之前——在模型開口之前誰決定它這一秒該調(diào)用哪個(gè)工具、該回答哪個(gè)問題這個(gè)誰來決定就是Agent里常說的規(guī)劃器Planner。市面上所有主流Agent框架不管宣傳得多花哨核心都是一個(gè)循環(huán)感知→規(guī)劃→行動→觀察→再規(guī)劃。這個(gè)循環(huán)在學(xué)術(shù)圈叫ReAct在公司里叫主循環(huán)在小白的理解里其實(shí)就是一個(gè)問題下一步做什么由誰說了算大多數(shù)人的第一版Agent下一步做什么是由用戶說的用戶問什么模型答什么。進(jìn)階版是模型自己說了算但經(jīng)常跑飛。成熟版是由模型提出方案由約束條件做裁決——模型的自由度還在但被任務(wù)邊界、格式約束、安全護(hù)欄框住了。這一段我把規(guī)劃器的幾種主流形態(tài)拆開講。2.1 為什么拆任務(wù)是Agent的第一基本功想象一個(gè)新人入職第一天領(lǐng)導(dǎo)讓他辦一場產(chǎn)品發(fā)布會。正常人的第一反應(yīng)不是沖出去訂場地而是先拆發(fā)布會包含哪些子任務(wù)場地、物料、嘉賓、流程、預(yù)算、每個(gè)子任務(wù)需要什么資源、先后順序是什么、哪些可以并行。大模型也一樣。你告訴它幫我制定一個(gè)三亞五日游攻略它如果不拆解直接生成一段三千字的指南那就又退化成了ChatBot。Agent的做法是先把三亞五日游拆成確定預(yù)算→選擇日期→確定航班→預(yù)訂酒店→規(guī)劃每日行程→生成行李清單然后逐個(gè)執(zhí)行。執(zhí)行確定航班時(shí)可能還要再拆一層——調(diào)用航班查詢工具、解析返回結(jié)果、對比價(jià)格、輸出選擇建議。這個(gè)層層拆解的能力是Agent和ChatBot在任務(wù)處理上的分水嶺。工程上我們通常會把任務(wù)拆解和狀態(tài)管理綁定在一起形成一個(gè)任務(wù)樹。每個(gè)節(jié)點(diǎn)記錄狀態(tài)待執(zhí)行、執(zhí)行中、已完成、已失敗。主循環(huán)每次只盯住當(dāng)前該執(zhí)行哪個(gè)葉子節(jié)點(diǎn)執(zhí)行完再回到父節(jié)點(diǎn)判斷是否全部完成。我在實(shí)際項(xiàng)目里發(fā)現(xiàn)一個(gè)新手容易忽略的點(diǎn)拆解不是一次性的。模型先拆出一版方案真正執(zhí)行時(shí)會發(fā)現(xiàn)航班查詢接口返回超時(shí)或者預(yù)算超了這時(shí)候任務(wù)樹必須支持動態(tài)調(diào)整。好比發(fā)布會籌備到一半發(fā)現(xiàn)預(yù)定的場地被臨時(shí)征用你得馬上改方案而不是對著舊計(jì)劃死磕。所以任務(wù)樹的設(shè)計(jì)要考慮兩個(gè)能力節(jié)點(diǎn)間的依賴關(guān)系、失敗節(jié)點(diǎn)的重規(guī)劃入口。這兩點(diǎn)做扎實(shí)了Agent才經(jīng)得起真實(shí)世界的折騰。2.2 三種主流規(guī)劃形態(tài)ReAct、Plan-and-Execute、混合模式規(guī)劃器不是只有一種寫法我梳理了三種主流形態(tài)面試時(shí)如果能把它們的取舍講清楚基本就能證明你不是只會調(diào)庫。第一種是ReAct推理和行動交替進(jìn)行。模型的每一次輸出既有思考過程Thought又有行動決策Action還有一個(gè)觀察結(jié)果Observation三個(gè)字段串成一個(gè)循環(huán)。它的優(yōu)點(diǎn)是簡單直接模型看到最新觀察立刻做下一步?jīng)Q策上下文信息天然連貫缺點(diǎn)是長任務(wù)容易陷入走一步看一步缺乏全局視野就像一個(gè)人蒙著眼睛下樓每一步都踩穩(wěn)了才邁下一步但不知道整棟樓有幾層。第二種是Plan-and-Execute先規(guī)劃再執(zhí)行。模型在開始行動前先產(chǎn)出一份完整計(jì)劃然后逐步執(zhí)行計(jì)劃里的每一項(xiàng)。每一步執(zhí)行完可以根據(jù)結(jié)果微調(diào)后續(xù)計(jì)劃。它的優(yōu)點(diǎn)是全局規(guī)劃讓Agent不容易跑偏適合多步驟任務(wù)比如自動寫調(diào)查報(bào)告、批量處理數(shù)據(jù)缺點(diǎn)是計(jì)劃本身可能不合理一旦初始規(guī)劃有錯(cuò)后面每一步都在一個(gè)錯(cuò)誤的框架里打轉(zhuǎn)就像按照一份錯(cuò)版地圖開車每走一步都自信地錯(cuò)得更遠(yuǎn)。第三種是混合模式這也是我現(xiàn)在最推薦的。先讓模型產(chǎn)出一版完整計(jì)劃但執(zhí)行路徑上允許在必要時(shí)跳出計(jì)劃重新規(guī)劃。具體做法是設(shè)置一個(gè)重新規(guī)劃觸發(fā)器當(dāng)工具返回異常、執(zhí)行結(jié)果與預(yù)期嚴(yán)重不符、或者某個(gè)子任務(wù)連續(xù)重試三次失敗就暫停當(dāng)前計(jì)劃讓模型復(fù)盤并生成新計(jì)劃。這種模式在真實(shí)業(yè)務(wù)里最抗造因?yàn)樗嫒萘饲皟煞N的優(yōu)點(diǎn)又給了失敗兜底。從面試官的追問來看他真正在意的是你能否解釋為什么這個(gè)任務(wù)適合這種規(guī)劃方式。規(guī)劃不是越復(fù)雜越好而是越匹配任務(wù)性質(zhì)越好。比如查詢類任務(wù)用ReAct就夠了硬套Plan-and-Execute反而增加延遲而一個(gè)需要二十步操作的數(shù)據(jù)處理流程只用ReAct不做全局規(guī)劃跑到第五步大概率就忘了最終目標(biāo)。2.3 工具調(diào)用Agent的手是怎么伸出去的規(guī)劃器決定了下一步做什么工具調(diào)用決定了這一步怎么做。我在項(xiàng)目里見過最蠢的做法是把所有工具塞在一段超長的System Prompt里讓模型自己看著選。這么做的問題和把所有代碼寫在一個(gè)文件里一樣看起來都能跑實(shí)際維護(hù)起來想死。規(guī)范的Agent工具設(shè)計(jì)至少要包含三層。第一層是工具注冊表每個(gè)工具聲明名字、用途描述、入?yún)SON Schema、返回類型大模型靠這些元信息決定什么時(shí)候用哪個(gè)工具。描述寫得好不好直接影響模型的調(diào)用準(zhǔn)確率——我實(shí)測過同樣一個(gè)天氣查詢工具描述寫成查天氣和根據(jù)城市名與日期返回實(shí)時(shí)天氣數(shù)據(jù)適用于出行前氣候評估后者的調(diào)用觸發(fā)準(zhǔn)確率能高十幾個(gè)百分點(diǎn)。第二層是參數(shù)注入與校驗(yàn)。模型輸出的是結(jié)構(gòu)化參數(shù)系統(tǒng)負(fù)責(zé)將參數(shù)映射到真實(shí)函數(shù)。這里必須加一道校驗(yàn)參數(shù)類型對不對、必填字段有沒有、數(shù)值范圍合不合理、有沒有注入風(fēng)險(xiǎn)。你不可能讓模型直接拼SQL但很多人忽略的是——也不能讓模型直接拼URL。參數(shù)拼接處就是安全邊界哪怕內(nèi)部系統(tǒng)也必須過一層白名單校驗(yàn)。第三層是返回結(jié)果的后處理。工具返回的數(shù)據(jù)通常是臟的字段名不對、格式不統(tǒng)一、內(nèi)容超長。直接把這些臟數(shù)據(jù)原樣塞回上下文模型的注意力會被垃圾信息打亂。正確做法是設(shè)置一個(gè)格式化層比如把數(shù)據(jù)庫返回的行記錄壓成商品名xxx價(jià)格xxx的摘要把超長的列表截?cái)喑汕癗條并注明總數(shù)。這層處理做得好不好直接影響長鏈路任務(wù)的穩(wěn)定性。我踩過最深的坑是工具返回結(jié)果太長。一次調(diào)用某個(gè)接口返回了上萬字的JSON我原樣塞進(jìn)上下文結(jié)果模型徹底失焦開始強(qiáng)行理解堆在一起的字段名。后來養(yǎng)成的習(xí)慣是所有工具返回都做摘要且摘要里永遠(yuǎn)帶上本次調(diào)用是否成功這個(gè)信息。帶狀態(tài)的結(jié)果是Agent觀察環(huán)節(jié)的地基。3. Agent靈魂之一讓模型自己決定下一步的狀態(tài)感知機(jī)制面試進(jìn)行到第三個(gè)環(huán)節(jié)面試官的問題開始變得更尖銳。他問如果一個(gè)Agent一直重復(fù)做同一件事比如反復(fù)調(diào)用同一個(gè)查詢接口你會怎么處理你會在代碼里用if-else判斷次數(shù)還是會讓模型自己意識到這樣不對該換一種方法了這個(gè)問題聽起來簡單其實(shí)是靈魂級的。它考驗(yàn)的是你對Agent自主性的理解深度。規(guī)約式的防重復(fù)機(jī)制是一種方案但它沒有讓Agent擁有真正的自我認(rèn)知基于狀態(tài)的自我調(diào)整是另一種方案它讓Agent具備了我覺得這樣下去不行的判斷力。后者是我理解的Agent靈魂第一大要素。市面上Agent框架普遍有一個(gè)誤區(qū)把System Prompt寫得越長以為Agent就越聰明。實(shí)際上真正讓Agent靈光一現(xiàn)的往往是運(yùn)行時(shí)的狀態(tài)信息——現(xiàn)在執(zhí)行到哪一步、已經(jīng)嘗試過哪些方案、哪些方案被證明無效、剩余預(yù)算還有多少。這些信息如果在每一輪決策時(shí)都被模型看到它就有了自我感知的依據(jù)。3.1 ReAct循環(huán)里的Thought字段其實(shí)是思維黑匣子前面提到ReAct循環(huán)有三個(gè)核心字段Thought、Action、Observation。面試官尤其在意Thought字段。他說他面試時(shí)會讓候選人當(dāng)場寫一個(gè)Agent的調(diào)試日志然后問他如果某一步出了問題你憑什么知道是模型想錯(cuò)了還是工具執(zhí)行錯(cuò)了還是觀察結(jié)果被格式污染了這個(gè)問題我當(dāng)時(shí)其實(shí)是答不上來的。因?yàn)槲以陂_發(fā)中主要看最終輸出對不對很少去審中間過程對不對。后來才明白Thought字段就是Agent的思維黑匣子它記錄模型在每一步?jīng)Q策前的推理過程。如果調(diào)試時(shí)發(fā)現(xiàn)Action不對去看Thought通常能找到根因——可能是工具描述誤導(dǎo)了模型可能是上下文里混入了矛盾信息也可能模型真的理解偏了。比如有一次我做的商品推薦Agent在某個(gè)類目下頻繁推薦錯(cuò)品查日志發(fā)現(xiàn)Thought里出現(xiàn)了一句話用戶需求不明確嘗試根據(jù)類目推斷偏好。問題就出在推斷兩個(gè)字上——這個(gè)場景下模型本應(yīng)調(diào)用歷史偏好查詢工具但它選擇了猜。這既不是工具的問題也不是模型的問題是工具調(diào)用規(guī)則沒有在Prompt里寫清楚。原來系統(tǒng)Prompt只寫了可以用查詢工具獲取用戶偏好沒有寫必須優(yōu)先使用該工具禁止在無數(shù)據(jù)時(shí)猜測。加了這條硬約束并更新了工具描述之后錯(cuò)誤率直接降了一半。所以你看Thought字段不只是給模型思考用的它更是給人調(diào)試用的。一個(gè)合格的Agent系統(tǒng)必須做到每一個(gè)Action都有對應(yīng)的Thought可回溯。這比準(zhǔn)確率指標(biāo)更底層因?yàn)椴豢苫厮莸臏?zhǔn)確率出了問題也沒法定位。3.2 上下文不是越長越好短期記憶的有效期設(shè)計(jì)另一個(gè)關(guān)于狀態(tài)感知的痛點(diǎn)是上下文管理。很多新人做Agent恨不得把所有歷史對話、工具結(jié)果、中間思考全部堆在上下文里以為信息越多決策越準(zhǔn)。但模型對上下文的注意力是有限的而且超過一定長度之后中間部分的信息很容易被壓扁。就像你開一個(gè)超長會議開頭和結(jié)尾記得清楚中間討論的細(xì)節(jié)反而模糊了。我后來在項(xiàng)目里把上下文分成三個(gè)區(qū)核心區(qū)放當(dāng)前的用戶目標(biāo)、關(guān)鍵約束、最近的決策狀態(tài)工作區(qū)放當(dāng)前步驟需要的工具結(jié)果和局部信息歸檔區(qū)放已經(jīng)完成的子任務(wù)的摘要不再保留完整過程。每一輪主循環(huán)開始前系統(tǒng)自動裁剪歸檔區(qū)把超過N輪之前的過程壓成一行摘要。這套設(shè)計(jì)的思路很簡單模型做決策依賴的不是所有信息而是和當(dāng)前決策相關(guān)的信息。信息過載和信息缺失一樣致命甚至更致命——因?yàn)樗屇Ｐ彤a(chǎn)生虛假的確定性在錯(cuò)誤的方向上自信地執(zhí)行。面試官還追問了一個(gè)細(xì)節(jié)如果用戶中途改了需求你的Agent怎么感知到這種變化這其實(shí)就是狀態(tài)感知的另一個(gè)維度——目標(biāo)漂移檢測。我當(dāng)時(shí)的做法是在每輪循環(huán)開始時(shí)做一個(gè)目標(biāo)一致性校驗(yàn)把當(dāng)前狀態(tài)和原始目標(biāo)做一次語義相似度比對低于閾值就觸發(fā)目標(biāo)重規(guī)劃分支。后來發(fā)現(xiàn)效果不錯(cuò)但代價(jià)是多一次模型調(diào)用。如果對延遲敏感也可以用輕量規(guī)則先做關(guān)鍵詞級校驗(yàn)命中變化信號再走語義級確認(rèn)。3.3 反思機(jī)制讓Agent學(xué)會這次不行換個(gè)思路反思Reflection這個(gè)詞這兩年很熱但真正做好的人不多。我理解的反思機(jī)制分成三層任務(wù)級反思、策略級反思、認(rèn)知級反思。任務(wù)級反思是這一步結(jié)果不對我換一種執(zhí)行方式策略級反思是這套拆解方案整體效率低我重新規(guī)劃認(rèn)知級反思是我的工具調(diào)用原則有問題需要更新后續(xù)所有決策的偏好。很多Agent框架做到了第一層少數(shù)做到第二層第三層幾乎沒人做。原因是第三層意味著要讓模型改寫自己的決策偏好風(fēng)險(xiǎn)很大。但面試官恰恰最看重這個(gè)他說了一句話讓我記憶猶新Agent和腳本的本質(zhì)區(qū)別就是Agent可以否定自己之前的決定。如果它只會按照既定路徑執(zhí)行那和Shell腳本沒有區(qū)別只是包裝得更像人。我當(dāng)時(shí)舉了一個(gè)案例我的自動化數(shù)據(jù)采集Agent連續(xù)跑了兩小時(shí)突然開始頻繁調(diào)用一個(gè)高延遲接口導(dǎo)致任務(wù)超時(shí)。我加了反思節(jié)點(diǎn)之后模型在執(zhí)行超過五次、平均延遲超過閾值時(shí)主動改了策略跳過那個(gè)接口改用備用數(shù)據(jù)源任務(wù)最終在預(yù)算時(shí)間內(nèi)完成。這個(gè)案例不是炫技它說明一個(gè)道理反思機(jī)制不是額外功能而是Agent在真實(shí)世界長期存活的關(guān)鍵器官。反思機(jī)制的工程實(shí)現(xiàn)其實(shí)不復(fù)雜本質(zhì)是在主循環(huán)里加一個(gè)檢查點(diǎn)當(dāng)某種模式反復(fù)出現(xiàn)時(shí)把之前的完整行動軌跡和歷史觀察打包發(fā)給大模型讓它產(chǎn)出一個(gè)后續(xù)策略調(diào)整建議。這個(gè)建議經(jīng)過安全校驗(yàn)之后以臨時(shí)規(guī)則的形式覆蓋到后續(xù)決策中。關(guān)鍵是觸發(fā)條件和覆蓋范圍的設(shè)置這兩個(gè)參數(shù)需要大量實(shí)驗(yàn)才能調(diào)穩(wěn)。4. Agent靈魂之二記憶不是緩存是忘掉什么和記住什么的藝術(shù)面試官第四輪開始考記憶。他問得特別直接如果你的Agent服務(wù)一千個(gè)用戶每個(gè)用戶都有自己的偏好和上下文你怎么設(shè)計(jì)記憶系統(tǒng)你打算把所有人的對話記錄都存進(jìn)向量數(shù)據(jù)庫嗎這個(gè)問題很多人的第一反應(yīng)是那就上向量檢索。但面試官想聽的顯然不是這個(gè)。他接著補(bǔ)充如果存了一百萬條記憶但檢索時(shí)每次都召回五十條其中四十條是噪聲那你覺得記憶多了是幫助還是負(fù)擔(dān)這一下又把問題拉回到了記憶的核心矛盾記憶不是存得越多越好越精準(zhǔn)才越好。Agent的記憶系統(tǒng)設(shè)計(jì)本質(zhì)上是在回答三個(gè)問題什么該記、什么時(shí)候記、什么時(shí)候忘。這三個(gè)問題對應(yīng)三種不同的存儲機(jī)制。很多人只做了記完全沒設(shè)計(jì)忘和取最后系統(tǒng)就像一間堆滿雜物的房間找東西比沒東西還難。4.1 工作記憶會話內(nèi)的上下文折疊策略工作記憶是Agent在當(dāng)前任務(wù)或當(dāng)前會話內(nèi)的短期存儲對應(yīng)人類的正在手頭處理的事情。它和技術(shù)上的上下文窗口Context Window直接相關(guān)但不等于上下文窗口——窗口是大模型能看到的全部信息的上限工作記憶是Agent在每輪主動挑選并維持的有用信息集合。我在第三節(jié)提過三個(gè)區(qū)的設(shè)計(jì)這里展開說。核心區(qū)要有硬性的長度上限比如固定幾百字裝的是用戶目標(biāo)、硬性約束、關(guān)鍵進(jìn)度。工作區(qū)存當(dāng)前正在執(zhí)行的子任務(wù)的中間結(jié)果長度可以靈活但也要設(shè)置上限。歸檔區(qū)是摘要集中營每條摘要必須控制在幾十字以內(nèi)。這套策略的核心目的是保證模型每一輪決策時(shí)核心決策信息始終在注意力的黃金位置。實(shí)驗(yàn)數(shù)據(jù)也很能說明問題同樣一個(gè)多步驟任務(wù)使用上下文折疊策略的Agent比全量堆疊上下文的Agent任務(wù)完成率提高了接近兩成響應(yīng)延遲也明顯降低。折疊不是偷懶是刻意制造信息稀缺讓模型不得不聚焦在最關(guān)鍵的信號上。折疊策略的設(shè)計(jì)細(xì)節(jié)也有講究。折疊動作不是每輪都做而是只有在新信息要寫進(jìn)核心區(qū)、核心區(qū)空間不足時(shí)才觸發(fā)。折疊的對象是當(dāng)前最不相關(guān)的已完成子任務(wù)的完整過程折疊產(chǎn)物是一條結(jié)構(gòu)化摘要。折疊之前系統(tǒng)會把被折疊的原始內(nèi)容先寫入長期記憶存儲避免重要信息丟失。4.2 長期記憶向量檢索召回率不是越高越好長期記憶解決的是跨會話、跨任務(wù)的經(jīng)驗(yàn)沉淀?，F(xiàn)在主流方案是把重要信息向量化存進(jìn)向量數(shù)據(jù)庫需要時(shí)做相似度召回。但這里有一個(gè)反直覺的點(diǎn)召回率不是越高越好。召回五十條信息讓模型從中挑不如召回精挑細(xì)選的五條讓模型直接用。信息召回的本質(zhì)是引入決策依據(jù)不是提供可選閱讀材料。長期記憶的寫入時(shí)機(jī)比檢索方法更值得花心思。我的策略是只有三類信息允許寫入長期記憶。第一類是用戶明確表達(dá)過的偏好比如我訂酒店從來不要低樓層第二類是任務(wù)結(jié)果里被驗(yàn)證為成功或失敗的關(guān)鍵經(jīng)驗(yàn)比如上次用這個(gè)接口超時(shí)了三次第三類是用戶畫像類信息比如身份、常駐地、常用支付方式。其他對話內(nèi)容一律不寫入。寫入前還有一道過濾關(guān)卡模型先對候選信息做一次結(jié)構(gòu)化抽取輸出主體屬性取值置信度置信度低于閾值就丟棄。這套過濾機(jī)制能有效防止把閑聊內(nèi)容當(dāng)成偏好存入長期記憶。比如用戶說這家店真難吃不應(yīng)該存成用戶認(rèn)為這家店難吃而應(yīng)該提取為用戶偏好避開該餐廳或者干脆不存因?yàn)閱未吻榫w化表達(dá)不足以形成穩(wěn)定偏好。檢索側(cè)的技巧是給每條記憶打上元數(shù)據(jù)標(biāo)簽記憶類型、創(chuàng)建時(shí)間、最近訪問時(shí)間、來源任務(wù)ID。召回時(shí)可以疊加時(shí)間衰減權(quán)重和類型過濾比如當(dāng)前任務(wù)是訂酒店只從偏好類記憶中召回。這種過濾能讓召回命中率大幅提升——把一百條同類型記憶塞給模型和只給十條高度相關(guān)的記憶決策質(zhì)量完全不是一個(gè)級別。4.3 遺忘機(jī)制為什么說會忘比會記更高級最后說遺忘。這可能是Agent記憶設(shè)計(jì)里最不受重視、卻又最影響體驗(yàn)的環(huán)節(jié)。很多人設(shè)計(jì)記憶系統(tǒng)只想著怎么記從沒想過怎么刪。但真實(shí)用戶是變化的一個(gè)用戶去年喜歡重口味川菜今年開始健身飲食清淡一個(gè)用戶三年前喜歡某個(gè)明星現(xiàn)在早就脫粉了。如果Agent把過時(shí)的偏好一直當(dāng)作決策依據(jù)體驗(yàn)會越做越差。我的做法是給每條長期記憶一個(gè)保質(zhì)期和刷新機(jī)制。保質(zhì)期按記憶類型設(shè)定用戶畫像類最長偏好類中等臨時(shí)經(jīng)驗(yàn)類最短。每次成功使用一條記憶系統(tǒng)自動延長它的有效期如果在有效期內(nèi)從未被使用到期后先降級為低置信度記憶檢索權(quán)重降低連續(xù)兩個(gè)周期未使用就直接刪除。這種機(jī)制背后有一個(gè)樸素的信念A(yù)gent應(yīng)該像一個(gè)人一樣既記得住重要的事也放得下過時(shí)的事。一個(gè)人的記憶如果從不遺忘反而會形成思維定式。我在項(xiàng)目里專門設(shè)計(jì)了一個(gè)記憶矛盾檢測步驟如果用戶新的表述和長期記憶里的舊偏好沖突系統(tǒng)不直接覆蓋而是標(biāo)記為待確認(rèn)沖突在下一輪對話里溫和地跟用戶核對。這個(gè)方法很笨但實(shí)測效果比盲目相信記憶庫好很多——因?yàn)橛脩魰驗(yàn)槟阌浀盟@喜也會因?yàn)槟阌涘e(cuò)了他而失望這兩個(gè)體驗(yàn)的差距直接決定了一個(gè)Agent能用多久。5. 拿得出手的實(shí)戰(zhàn)一個(gè)可直接復(fù)刻的最小Agent設(shè)計(jì)與跑通記錄前面聊了這么多理論和設(shè)計(jì)原則可能有些讀者已經(jīng)有點(diǎn)飄了覺得Agent不過如此。但面試官從來不會因?yàn)槟銜f而滿意他一定會追問那你現(xiàn)場寫一個(gè)給我看看第五輪面試面試官的原話是從零開始設(shè)計(jì)一個(gè)面向客服場景的售后處理Agent只給三十分鐘你會怎么搭既能演示又不會有大量BUG的完整流程這個(gè)要求其實(shí)很考驗(yàn)基本功。你在紙上寫一堆漂亮的設(shè)計(jì)圖沒有用得能落成運(yùn)行起來的代碼。下面我把當(dāng)時(shí)的搭建思路和核心步驟完整復(fù)現(xiàn)一遍你照著走也能跑出一個(gè)能演示的最小Agent。5.1 需求收斂第一件事不是寫代碼而是砍需求接到售后處理Agent這個(gè)命題的時(shí)候我做的第一件事是先砍范圍。三十分鐘能演示的Agent絕對不能做成全品類全場景智能客服否則光意圖識別模型就要選半天。我把需求收斂成了三個(gè)主流程查單、改地址、退款申請。覆蓋了查詢類、操作類、高風(fēng)險(xiǎn)類三種典型Agent動作足夠演示但也足夠簡單?？承枨蟮脑瓌t是先證明主循環(huán)能跑通再考慮業(yè)務(wù)復(fù)雜度。你能在十分鐘內(nèi)讓Agent完整走一遍用戶提問→規(guī)劃→調(diào)用工具→格式化結(jié)果→回復(fù)這個(gè)閉環(huán)的價(jià)值比堆一百個(gè)功能點(diǎn)大得多。業(yè)務(wù)場景可以后續(xù)慢慢擴(kuò)展主循環(huán)是靈魂必須先立住。接下來定義工具集。查單需要一個(gè)訂單查詢函數(shù)輸入訂單號輸出訂單狀態(tài)改地址需要一個(gè)更簡單的模擬工具只做參數(shù)校驗(yàn)并返回成功或失敗退款申請同理想做成模擬工具。工具數(shù)量控制在三個(gè)以內(nèi)既能體現(xiàn)多工具協(xié)同又不會讓演示時(shí)手忙腳亂。每個(gè)工具都配上JSON Schema格式的入?yún)⒍x方便模型生成結(jié)構(gòu)化調(diào)用參數(shù)。5.2 核心主循環(huán)Python代碼骨架與執(zhí)行流程架構(gòu)上我只用一個(gè)Python文件不引入重型Agent框架把主循環(huán)寫得清清楚楚。模型的角色只有一個(gè)根據(jù)當(dāng)前狀態(tài)和工具描述決定調(diào)用哪個(gè)工具或者直接回復(fù)用戶。下面是核心代碼骨架我簡化了錯(cuò)誤處理讓邏輯更清晰import json from typing import Dict, List # 偽代碼以任意支持function calling的大模型接口為例 # llm_chat_with_tools(messages, tools) - response TOOLS [ { name: query_order, description: 根據(jù)訂單號查詢訂單狀態(tài)、物流信息、商品清單, parameters: { type: object, properties: { order_id: {type: string, description: 用戶提供的訂單號} }, required: [order_id] } }, { name: modify_address, description: 修改未發(fā)貨訂單的收貨地址。發(fā)貨后不可修改, parameters: { type: object, properties: { order_id: {type: string}, new_address: {type: string} }, required: [order_id, new_address] } }, { name: apply_refund, description: 為訂單發(fā)起退款申請。退款金額由系統(tǒng)根據(jù)訂單狀態(tài)計(jì)算, parameters: { type: object, properties: { order_id: {type: string}, reason: {type: string} }, required: [order_id, reason] } } ] def run_agent(user_message: str) - str: messages [ {role: system, content: 你是售后處理助手。請嚴(yán)格按工具描述執(zhí)行用戶請求。 如果需要額外信息直接向用戶提問不要編造訂單數(shù)據(jù)。}, {role: user, content: user_message} ] max_steps 10 for step in range(max_steps): response llm_chat_with_tools(messages, TOOLS) # 情形一模型決定調(diào)用工具 if response.get(tool_calls): for call in response[tool_calls]: result execute_tool(call[name], json.loads(call[arguments])) messages.append({ role: tool, tool_call_id: call[id], content: json.dumps(result, ensure_asciiFalse) }) continue # 情形二模型直接回復(fù)用戶 return response[content] return 處理超時(shí)請稍后重試或聯(lián)系人工客服 def execute_tool(name: str, arguments: Dict) - Dict: if name query_order: return query_order(arguments[order_id]) if name modify_address: return modify_address(arguments[order_id], arguments[new_address]) if name apply_refund: return apply_refund(arguments[order_id], arguments[reason]) return {error: unknown tool}這段代碼麻雀雖小五臟俱全System Prompt定義了行為邊界TOOLS注冊了工具元信息主循環(huán)讓模型自己決定調(diào)工具還是回復(fù)用戶工具返回作為新消息追加到上下文中。實(shí)際演示時(shí)我會準(zhǔn)備三條測試路徑。路徑一是直接查單幫我看看訂單20240601到哪了模型應(yīng)調(diào)用query_order并返回物流信息。路徑二是改地址訂單20240602的收貨地址改成某某路某號模型應(yīng)調(diào)用modify_address。路徑三是個(gè)陷阱場景我要退款但沒有給訂單號——好的Agent應(yīng)該反問要訂單號而不是編一個(gè)假單號去調(diào)apply_refund。這三條路徑能覆蓋主循環(huán)的基本形態(tài)已經(jīng)足夠應(yīng)對三十分鐘的演示。5.3 跑通后的三輪自問邊界、容錯(cuò)、成本代碼能跑通只是第一步面試官通常會繼續(xù)追問三個(gè)深度問題。第一問你的Agent邊界在哪比如用戶說我要罵人模型是會乖乖接話還是禮貌拒絕如果用戶問你能幫我寫周報(bào)嗎你一個(gè)售后Agent會不會跑去做文檔任務(wù)這是System Prompt和工具集共同決定的沒有對應(yīng)工具的任務(wù)模型應(yīng)該回復(fù)不在我的處理范圍內(nèi)而不是用大模型通用能力硬接。我在System Prompt里特意加了一條僅處理與訂單售后服務(wù)相關(guān)的任務(wù)其他請求一律拒絕。第二問工具調(diào)用失敗怎么容錯(cuò)比如modify_address被調(diào)用時(shí)參數(shù)里沒有new_address或者訂單已發(fā)貨不能修改。我在execute_tool里做了兜底返回錯(cuò)誤信息會以JSON形式回到上下文。模型看到錯(cuò)誤信息后應(yīng)該能主動判斷需要補(bǔ)充信息或告知用戶無法修改。這個(gè)應(yīng)對邏輯不用寫死在代碼里靠模型自然推理就能完成但要保證錯(cuò)誤信息是結(jié)構(gòu)化、可解析的不要讓模型在垃圾文本里撈線索。第三問一次任務(wù)的成本大概多少這是所有Agent上生產(chǎn)前都必須算的賬。每次主循環(huán)都是一次模型調(diào)用一次復(fù)雜任務(wù)可能循環(huán)五到十次。如果用的是商業(yè)大模型API按token計(jì)費(fèi)一次售后任務(wù)可能消耗幾千甚至上萬token。所以在演示版里我故意把max_steps設(shè)成了10既是防死循環(huán)也是在暗示面試官成本控制靠的不是模型而是主循環(huán)的退出條件設(shè)計(jì)。支持用戶提供完備信息、工具返回高質(zhì)量結(jié)果、減少無效循環(huán)這三個(gè)方向的優(yōu)化空間比換低價(jià)模型大得多。我后來在真實(shí)項(xiàng)目里對這套最小骨架做了擴(kuò)展加上了任務(wù)狀態(tài)記錄、工具結(jié)果緩存、失敗重規(guī)劃分支整體架構(gòu)沒有變但穩(wěn)定性上了好幾個(gè)臺階。先跑通主循環(huán)再逐步加護(hù)欄這是Agent項(xiàng)目最穩(wěn)妥的推進(jìn)路徑。你不需要一上來就上Agent框架也不需要對標(biāo)那些復(fù)雜的生產(chǎn)級中間件一個(gè)文件加上清晰的主循環(huán)足夠你理解Agent的全部核心機(jī)制。6. 復(fù)盤那次面試之后我總結(jié)出的Agent設(shè)計(jì)鐵律面試結(jié)束之后我把整個(gè)過程又完整回顧了好幾遍。有些道理是當(dāng)時(shí)面試官直接點(diǎn)醒我的有些是后來在實(shí)踐中摔了跟頭才明白的。這些東西不一定寫在任何技術(shù)文檔里但它們決定了一個(gè)Agent系統(tǒng)是能站起來還是能跑起來。作為最后一部分我直接分享幾條個(gè)人總結(jié)的設(shè)計(jì)鐵律。6.1 Agent的靈魂在反饋閉環(huán)里不在模型參數(shù)里很多人以為Agent的靈魂在大模型的參數(shù)量、在推理能力、在prompt技巧上。我的結(jié)論和面試官高度一致Agent的靈魂在反饋閉環(huán)的完整性上。一個(gè)Agent系統(tǒng)可以拆成五個(gè)節(jié)點(diǎn)目標(biāo)設(shè)定、狀態(tài)感知、規(guī)劃決策、行動執(zhí)行、反饋吸收。參數(shù)量只是行動執(zhí)行這一環(huán)的底座而多數(shù)人會把精力全砸在這一環(huán)上——換更大的模型、調(diào)更長的上下文、寫更花哨的prompt。但真正讓Agent顯得有靈性的是反饋吸收這個(gè)環(huán)節(jié)做得好不好工具返回的結(jié)果有沒有被正確解析狀態(tài)有沒有被及時(shí)更新失敗有沒有觸發(fā)反思這些鏈路如果不閉合模型參數(shù)再大也只是個(gè)更聰明的ChatBot。放一個(gè)具體例子。我做過一個(gè)測試同一個(gè)任務(wù)一套系統(tǒng)每次工具返回后都做結(jié)構(gòu)化摘要另一套系統(tǒng)把原始結(jié)果直接塞上下文。前者的任務(wù)完成率高出接近三成。同一個(gè)模型、同一個(gè)Prompt差異只在反饋吸收這一步。這個(gè)實(shí)驗(yàn)很樸素但說服力極強(qiáng)——優(yōu)化Agent優(yōu)先優(yōu)化信息流轉(zhuǎn)而不是優(yōu)化模型。6.2 評估Agent要看最差表現(xiàn)而不是平均表現(xiàn)第二條鐵律關(guān)于評估。Agent系統(tǒng)的平均表現(xiàn)很容易做得好看因?yàn)榇蠖鄶?shù)任務(wù)會落在常見路徑上模型正常推理就能通過。但一個(gè)Agent能不能上生產(chǎn)看的是極端情況下的表現(xiàn)用戶亂給參數(shù)、工具接口返回超時(shí)、上下文里混入干擾信息、多步操作在第三步失敗……這些場景才是Agent系統(tǒng)的短板所在。我現(xiàn)在的習(xí)慣是維護(hù)一份刁鉆測試集專門收錄真實(shí)環(huán)境中出現(xiàn)過的異常輸入。每改一版Agent先用這套測試集跑一遍把失敗case按根因分類是工具描述不清晰、是上下文管理不到位、還是規(guī)劃策略有問題。修的時(shí)候也是按根因修而不是打補(bǔ)丁式地給Prompt加規(guī)則。評估Agent不僅要問它能不能做對更要問它能不能知道自己錯(cuò)了。把自己放到Agent的位置上想你會更清楚哪里還不夠穩(wěn)。一個(gè)知道自己錯(cuò)了、能主動澄清、能換一種方法繼續(xù)嘗試的Agent比一個(gè)90%場景表現(xiàn)優(yōu)秀但10%場景沉默亂來的Agent更值得信任。這也是面試官反復(fù)強(qiáng)調(diào)的可靠優(yōu)先于聰明。6.3 給正在入門Agent的朋友們?nèi)齻€(gè)行動建議最后如果你正在入門Agent我給你三條直接可執(zhí)行的建議都是我當(dāng)初走了彎路之后總結(jié)的。第一條親手寫一個(gè)不帶框架的最小主循環(huán)。不要一上來就上那些流行的Agent框架因?yàn)榭蚣軒湍汶[藏了大量關(guān)鍵機(jī)制你用它跑通了Demo但不知道哪里是靈魂?；ㄒ粋€(gè)周末寫一個(gè)像我上面演示的最小Agent一個(gè)文件、三個(gè)工具、一個(gè)循環(huán)。這個(gè)過程的收獲比讀十篇框架文檔都大。第二條給Agent寫思考日志。生產(chǎn)環(huán)境里把每一輪的Thought、Action、Observation都記錄下來不僅是調(diào)試?yán)鞲呛罄m(xù)優(yōu)化的第一手素材。我至少三次在思考日志里發(fā)現(xiàn)性能問題的根因而這些根因在最終答案里根本看不出來。第三條每做一個(gè)Agent先定義它不該做什么。能力邊界比能力本身更重要。寫系統(tǒng)提示詞時(shí)先寫絕對禁止清單再寫應(yīng)該做什么。這個(gè)順序顛倒了Agent的確定性就很難保證。如果你已經(jīng)看到了這里說明你對Agent是真的有興趣。那就用我這套思路去拆解你手頭的項(xiàng)目先從最小主循環(huán)開始把反饋閉環(huán)做完整把記憶的取舍和遺忘機(jī)制設(shè)計(jì)好。等這些核心模塊真正內(nèi)化了再回頭看看那些花哨的框架和論文你會有一種原來它們只是在給這幾個(gè)鐵律包殼的通透感。那時(shí)候你就算真正看懂Agent的靈魂了。