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