聊 Agent 的文章這半年多太多了但大部分停在概念層要么講 Prompt 技巧要么貼個框架 Demo。我這篇不太一樣想從一個實際做過的工程角度把 Agent 系統(tǒng)這套東西掰開揉碎講清楚它到底解決什么問題、理想形態(tài)長什么樣、框架怎么選、代碼怎么寫、坑在哪里。文章后半部分還會給一個真實落地的完整拆解包括工具 Schema、ReAct 循環(huán)、記憶接入和評測方案你可以直接照著搭。先交代一個反常識的結論Agent 系統(tǒng)最大的難點不在模型而在工程。模型選型、提示詞編排這些東西兩三天就能上手真正難的是把記憶、工具、編排、安全和評測這幾層結構搭穩(wěn)讓系統(tǒng)在真實業(yè)務里不失控、不燒錢、可排查。這篇就按這個思路展開。1. 先想清楚Agent 到底是一套什么系統(tǒng)1.1 別被概念帶偏Agent 的核心是決策閉環(huán)講 Agent 之前先把概念校準一下?，F(xiàn)在市面上很多號稱 Agent 的產(chǎn)品本質上是把 Prompt 寫得很唬人讓模型按照固定格式輸出 JSON外邊再包一層 if-else。這類東西不是不能用但它缺了 Agent 最核心的東西自主決策循環(huán)。真正的 Agent 系統(tǒng)至少要滿足三個特征。第一它能感知環(huán)境比如拿到用戶任務、看到工具返回的狀態(tài)第二它能做決策決定下一步調用哪個工具、按什么順序執(zhí)行第三它能根據(jù)結果修正把工具返回的數(shù)據(jù)喂回模型繼續(xù)推理直到任務完成或者觸發(fā)終止條件。這個閉環(huán)一旦成立系統(tǒng)就能處理那些沒有標準答案、步驟不固定的任務。這也是 Agent 和傳統(tǒng)工作流最本質的區(qū)別——工作流是預先把每一步寫死Agent 是讓模型自己走流程。我判斷一個需求要不要上 Agent就提一個問題任務的步驟是否固定如果固定用傳統(tǒng)工作流引擎更穩(wěn)省 token、好排查、行為可控如果步驟不固定或者各種分支路徑太多這時候才值得考慮 Agent。很多團隊一開始就把架構想復雜了恨不得第一版就上多 Agent、上復雜記憶結果后面調試起來極其痛苦。我的經(jīng)驗是能用規(guī)則解決的就用規(guī)則模型只在規(guī)則的間隙里做決策這樣系統(tǒng)才抗造。還有一個容易被忽略的點執(zhí)行層的存在。很多項目做到模型生成計劃就停了沒有真正調用外部系統(tǒng)因為調用意味著權限、沙箱、審批、超時這些工程負擔。但恰恰是執(zhí)行層決定了一個 Agent 是會說話的文檔還是能干活的系統(tǒng)。我堅持的原則是沒有實際副作用的決策循環(huán)不算 Agent。1.2 方法論從業(yè)務閉環(huán)倒推而不是從框架倒推我見過太多失敗項目開頭就錯了團隊先選好 LangChain 或者 Dify然后才開始想用它做什么。正確順序是反過來的——先畫出任務閉環(huán)再決定哪些環(huán)節(jié)交給模型哪些交給規(guī)則哪些留給人工。舉一個我自己做過的例子。我們要做一個智能客服加工單處理的 Agent用戶輸入是一句自然語言問題最終輸出是解決方案文本 一條已創(chuàng)建的工單 歸檔摘要。把這條鏈路拆開依次是意圖識別、知識檢索、方案生成、工單創(chuàng)建、異常升級。拆到這里架構需求就很清楚了需要一個規(guī)劃器一個檢索工具一個工單工具一個人工審批節(jié)點。每一步用什么模型、要不要調 RAG都是直接從業(yè)務需求反推出來的而不是框架決定的。方法論的第二個要點是從最小可跑閉環(huán)開始。不要第一步就搞長鏈路、復雜記憶、多 Agent 編排先拿一個模型 兩個工具 一個終止條件跑通一遍讓真實用戶用一版再往里加能力。我做工程這多年越來越認同一個說法Agent 系統(tǒng)是長出來的不是設計出來的。這和寫傳統(tǒng)單體軟件的心態(tài)完全相反傳統(tǒng)軟件講究先架構后編碼Agent 系統(tǒng)講究先跑通再生長。因為模型的行為你沒法在設計階段完全預測只有跑起來才發(fā)現(xiàn)工具描述哪里寫反了、上下文在哪里丟失了、哪類問題它天生就處理不了。1.3 理想形態(tài)不是一張架構圖是一組取舍原則很多人喜歡看架構圖但架構圖其實是最終結果真正值錢的是背后的取舍原則。Agent 系統(tǒng)的理想形態(tài)并不是組件越多越高級、也不是越自動化越好而是每一層都有明確的邊界和可控的出口。幾個我長期堅持的原則直接分享在這里。第一模型負責不確定的推理系統(tǒng)負責確定的事實第二所有工具調用必須可追蹤、可回滾高副作用操作必須有人在環(huán)第三記憶必須分層不能指望一個上下文窗口裝下所有東西第四永遠有終止條件包括最大輪數(shù)、超時、預算上限第五評測不是上線之后再做而是從第一天就有的回放機制。這幾條原則貫穿了我在正文后面講的所有設計也是我后來評估別人的 Agent 架構時最先看的幾點。接下來就進入理想形態(tài)的分層拆解。2. 理想形態(tài)拆解一個 Agent 系統(tǒng)應該有哪些層2.1 五要素目標、規(guī)劃、記憶、工具、執(zhí)行我把一個合格的 Agent 系統(tǒng)抽象成五個要素目標、規(guī)劃、記憶、工具、執(zhí)行。目標是指系統(tǒng)必須理解用戶真正想達成的結果而不是停留在禮貌回復。比如用戶說幫我把上周的周報整理出來發(fā)給 leader目標不是生成一段周報文本而是創(chuàng)建版本、寫入內容、調起發(fā)送動作這一條完整鏈路。規(guī)劃是把目標拆成一串可執(zhí)行的步驟也就是 task planning模型需要知道做完第一步之后第二步依賴什么狀態(tài)。記憶是混合體既包含當前對話的短期上下文也包含長期存儲的知識和歷史摘要。工具是系統(tǒng)與外部世界交互的接口比如檢索庫、API、代碼解釋器。執(zhí)行是把規(guī)劃真正落地的過程包含權限控制、超時處理、結果回傳。這五個要素映射到架構上自然就分成規(guī)劃編排層、記憶層、工具層、執(zhí)行層加上橫切整個系統(tǒng)的安全層和觀測層。你回頭看 LangChain 的 agent、tool、memory、callback 這些模塊其實就是這五大塊的工程化包裝。理解這層對應關系之后你再去看任何框架都不會被它繞暈因為所有框架本質上都在做同一件事讓模型在一個可控的循環(huán)里調用外部能力。2.2 記憶層短期窗口、長期向量庫、工作記憶與摘要策略記憶是 Agent 工程里最大的坑沒有之一。LLM 的上下文窗口再大也扛不住多輪工具調用之后的信息堆疊。上下文一旦爆炸模型會開始忽略早期的關鍵信息回復質量直線下滑token 費用也不可控。我的做法是把記憶拆成三層。第一層是短期記憶直接放在 message 列表里但必須做窗口裁剪。我一般只保留最近 3 到 5 輪原始消息更早的內容交給第二層。第二層是長期記憶用向量庫存歷史的語義摘要每個會話按時間切成若干塊每塊壓縮成摘要文本存進去。第三層是工作記憶專門保存任務過程中的結構化狀態(tài)比如訂單號、當前步驟序號、已經(jīng)完成的工具列表。這類數(shù)據(jù)絕對不要扔進語義檢索里應該單獨額度 KV 存儲用精確的鍵值去讀。實際調優(yōu)下來我發(fā)現(xiàn)摘要策略比向量庫更值錢。把長時間對話每隔幾輪做一次壓縮摘要比把所有原文塞進向量庫要經(jīng)濟得多也準確得多。原因是 Agent 在每一步?jīng)Q策時真正需要的往往是上一階段我們完成到什么程度、結論是什么而不是全部原文。全文召回反而經(jīng)常召回到噪聲干擾模型判斷。這個經(jīng)驗是我在一個連續(xù) 40 輪工具調用的任務里踩出來的那次之后我把對話摘要的觸發(fā)頻率從 20 輪調到了 10 輪失敗率明顯下降。摘要有它的必殺坑不能丟結構化字段。任務編號、用戶 ID、金額這類字段一旦被壓縮掉模型后面就會失憶所以摘要模板里我會強制保留這些字段的位置。2.3 工具層與技能層Function Calling 和技能抽象工具層定義了 Agent 的能力邊界。沒有工具模型只能空談有了工具模型才有手。工程上一個工具的本質是一份描述 一個可執(zhí)行函數(shù)描述是給模型看的函數(shù)是給執(zhí)行層調的。拿當前主流的 function calling 來說模型會在推理時輸出一個結構化的 tool_calls 對象里面包含函數(shù)名和參數(shù)系統(tǒng)按參數(shù)真實調用外部系統(tǒng)再把結果返回給模型繼續(xù)推理。這里有幾個細節(jié)直接決定工具層好不好用。工具描述里必須寫清楚什么時候用、什么時候別用比如一個搜索知識庫的工具描述要寫明它只回答公司內部文檔問題不做通用問答否則模型會把所有問題都甩給它。參數(shù)定義最好用嚴格的 JSON Schema模型會照著 schema 填參數(shù)字段名寫模糊了很容易得到空值。工具返回結果一定要截斷我通常只保留前 2000 字符防止大段無關輸出污染后續(xù)推理同時也省 token。再往上一層是技能抽象這是現(xiàn)在越來越流行的做法。一個數(shù)據(jù)分析技能可能包含執(zhí)行 SQL、畫圖表、生成結論三個工具模型按技能粒度去選擇把原來幾百個小工具收斂成十幾個技能調用穩(wěn)定性和可維護性都會大幅提升。Claude 的 Agent Skills、OpenAI 的 Agents SDK 里的 skill 概念本質上都是這個思路。這里也順便回答一個經(jīng)常被問的問題為什么有人用 Rust 做 Agent 框架因為 Rust 在高并發(fā)、低延遲的工具調度和沙箱隔離上有天然優(yōu)勢適合做底層的 Agent Harness。但對大多數(shù)業(yè)務團隊來說Python 生態(tài)的迭代速度仍然是第一位的語言選擇要看你的瓶頸在性能還是開發(fā)效率。2.4 編排層ReAct 循環(huán)、Harness 與多 Agent 觸發(fā)條件編排層負責決策循環(huán)的具體執(zhí)行。最經(jīng)典的范式是 ReAct也就是 Reason Act。流程可以概括成模型思考下一步 - 輸出文本或工具調用 - 系統(tǒng)執(zhí)行工具 - 返回觀察結果 - 模型繼續(xù)思考 - 直到輸出最終答案或達到終止條件。很多框架里的 AgentExecutor、AgentRunner干的就是這個循環(huán)的封裝。它不是一個復雜的東西核心就是一個 for 循環(huán)加終止條件判斷。真正要用心設計的是循環(huán)外面的約束也就是通常說的 Agent Harness。Harness 像韁繩用來限制模型的自由度防止它在錯誤的路徑上無限打轉。最基本的配置包括最大迭代輪數(shù)、單次工具調用超時、整體會話超時、人工中斷機制。我給絕大多數(shù)任務設置的默認值是最多 12 輪、單工具 15 秒超時、整體任務 60 秒上限。沒有這些約束的 Agent要么在死循環(huán)里燒錢要么卡在一個外部調用上讓整個會話僵死。多 Agent 編排是單 Agent 跑通之后才需要考慮的事。為什么這么說因為多意味著決策路徑更多、狀態(tài)同步更難、調試復雜度指數(shù)上升。我只有在三種信號同時出現(xiàn)時才會上多 Agent任務有明顯專業(yè)分工比如一個研究型 Agent 和一個執(zhí)行型 Agent有并行處理多路信息的需求存在天然的角色對沖比如生成者與質檢者。常見編排模式有 Supervisor 統(tǒng)一調度、Hierarchical 分層管理、Pipeline 鏈式流轉、Debate 多角色討論。但我的初始默認永遠是先單 Agent 跑業(yè)務確定瓶頸是上下文混亂或者模型角色沖突再拆成多 Agent。一上來就上多 Agent 的團隊往往是在用系統(tǒng)的復雜度換取架構圖的漂亮。2.5 安全與沙箱層給 Agent 畫紅線的六個方向Agent 安全的特殊之處在于一個有自主性的軟件要去調外部系統(tǒng)而且是模型自己在做決策。因此安全設計不能靠約定要靠結構。我總結了六個必做項。第一權限最小化。Agent 持有的 API Key 只給必要權限絕不能給數(shù)據(jù)庫全局權限這個聽起來像廢話但我見過不止一次事故。第二命令沙箱。凡是模型要執(zhí)行的代碼一律丟進 Docker 或者輕量級虛擬機里跑網(wǎng)絡按需放行默認拒絕出網(wǎng)。第三工具準入白名單。工具層只放行已經(jīng)過審的 API沒有登記注冊的一律拒絕模型沒有權限調用未知接口。第四人工確認節(jié)點。付款、發(fā)郵件、刪數(shù)據(jù)、創(chuàng)建對外工單這類高副作用操作必須配置人工審批Agent 只能提交請求不能直接執(zhí)行。第五審計日志。每一步模型輸出、工具參數(shù)、返回結果、最終狀態(tài)全部落日志出問題才有得回溯。第六限流與配額。對單會話、單用戶的 token 消耗和調用次數(shù)設上限超過直接熔斷。這些都是教訓換來的。我經(jīng)歷過一個事故調試模式下Agent 在一個錯誤循環(huán)里反復調分析工具一晚上燒掉了數(shù)千美元的 API 費用原因就是沒配限流和最大輪數(shù)。從那以后這兩項成了所有 Agent 項目的默認配置。安全層不用做得多花哨把紅線畫清楚系統(tǒng)才敢放開手腳干活。3. 一次真實落地從選型到上線的全過程3.1 框架對比LangChain、Dify、CrewAI、自研到底怎么選框架選擇直接決定你的開發(fā)節(jié)奏和調試體驗。市面上常被提到的四個方案我全都實際用過做個直接對比方案優(yōu)點缺點適合場景LangChain生態(tài)最全、組件豐富、抽象靈活版本迭代快、抽象層厚、出問題難查需要深度定制的業(yè)務Dify可視化編排、內置 RAG、開箱即用可編程性弱、復雜邏輯受限非工程團隊快速驗證CrewAI多 Agent 角色化清晰、上手快復雜編排和精細控制不夠多角色、輕邏輯任務自研編排 裸模型完全可控、調試直接、依賴最少工作量大、底層全要自己處理核心業(yè)務、長期演進我的結論比較直白如果你是小團隊要做的是內部工具直接走自研編排加官方模型 SDK別把核心邏輯外包給框架。如果你要給客戶快速出 DemoDify 是最快的路徑。如果團隊已經(jīng)有了大模型基建LangChain 可以用但要有隨時自己寫替代層的覺悟。CrewAI 適合 demo 性質的多角色場景真上生產(chǎn)你會很快碰到它能力邊界。以我自己那次真實落地為例最終選擇了半自研路線底層模型通信自己封裝編排循環(huán)自己寫工具接入自己管理向量庫和部分工具組件復用了開源庫。這個選擇不是炫技純粹是可控性優(yōu)先——框架的抽象層在排障時太費時間。LangChain 這類框架勝在組件多但也意味著你在查問題時要在它的檢索器、回調、鏈式邏輯里翻很久不如自己的 200 行循環(huán)看得清爽。3.2 落地需求與方案一個研發(fā)助手的完整目標這次落地的產(chǎn)品是個內部研發(fā)助手核心需求一句話讓研發(fā)團隊用自然語言少開幾個頁面。具體來說它要能回答項目背景類問題能幫員工生成周報能創(chuàng)建內部任務還能查詢 CI 構建狀態(tài)。注意這里刻意不做成萬能 AGI只做高頻場景覆蓋目標非常明確。系統(tǒng)的核心組件拆分如下。模型層通過統(tǒng)一網(wǎng)關調用不同廠商的模型默認主力模型是可以支持復雜 function calling 的 Claude 系列也兼容 GPT 系列和國產(chǎn)模型統(tǒng)一封裝在 LLMClient 里服務上層無感知。路由層在第一輪做一次意圖分類將輸入路由到知識問答子路徑或任務助手子路徑避免一個 Prompt 包打天下各自路徑的穩(wěn)定性能獨立調優(yōu)。工具集一共 6 個RAG 檢索、創(chuàng)建任務 API、查 CI 狀態(tài)、查詢用戶信息、發(fā)送群消息、周報生成每個都是獨立函數(shù)。記憶層采用會話窗口裁剪加每 10 輪摘要壓縮入向量庫。編排層是 ReAct 循環(huán)最大 12 輪整體超時 60 秒創(chuàng)建任務這類副作用操作必須人工確認。部署層用 FastAPI 加 Docker Compose 單機部署Redis 做會話緩存。這個架構最大的特點是簡單每個模塊都能單獨測試。因為它簡單后來加功能才沒有被一堆框架抽象綁架想加一個工具就是寫一個函數(shù)再加一份描述想換模型就是改一個網(wǎng)關配置。我建議所有中小團隊的第一版都往這個方向靠先把閉環(huán)搭穩(wěn)。3.3 核心實現(xiàn)拆解工具 Schema、ReAct 循環(huán)、記憶與人工審批核心實現(xiàn)里最關鍵的是工具定義和調度循環(huán)。先看工具定義我用 Pydantic 的 JSON Schema 來定義創(chuàng)建任務接口from pydantic import BaseModel, Field class CreateTaskInput(BaseModel): title: str Field(..., description任務標題總結用戶意圖) assignee: str Field(..., description負責人郵箱) due_days: int Field(2, description截止天數(shù)默認2天) tools_schema [ { type: function, function: { name: create_task, description: 當用戶需要創(chuàng)建內部研發(fā)任務時使用不用于普通知識問答。, parameters: CreateTaskInput.model_json_schema(), } } ]這一段看著簡單但工具描述里的每一句話都直接影響模型是否在正確的時候調用它。我把不用于普通知識問答寫進去就是因為一開始沒寫知識問答意圖也會調這個工具浪費輪次。接下來是最核心的 ReAct 調度循環(huán)偽代碼級別的 Python你可以直接移植到任何語言async def run_agent(user_query, session_id): messages load_history(session_id) messages.append({role: user, content: user_query}) for step in range(MAX_STEPS): response await llm.chat_with_tools( messagesmessages, toolstools_schema, ) messages.append(response.to_message()) if response.tool_calls: for call in response.tool_calls: result await execute_tool(call, usersession_user) messages.append(tool_result_message(call.id, result)) if call.name in SIDE_EFFECT_TOOLS: await notify_human_approval(call, result) else: # 模型已給出最終回答終止循環(huán) return response.content return 已達到最大輪數(shù)請人工介入執(zhí)行順序值得你細看。副作用工具不會當場落庫而是先進入待審批狀態(tài)把已提交審批請等待返回給模型等人工確認后再真正執(zhí)行。這樣模型可以繼續(xù)做后續(xù)步驟不會因為審批而卡死整個循環(huán)。execute_tool 內部還包了一層統(tǒng)一的超時處理每個工具最多跑 15 秒超時返回錯誤讓模型換條路徑走。這就是我在前面反復提的 Harness 思想不是限制模型能力而是保證它永遠有退路。記憶接入代碼不復雜但容易寫歪。會話讀取時我用最近 3 輪原始消息再加向量庫拉到的歷史摘要寫入時每累積 10 輪觸發(fā)一次 summarize把前面的對話壓縮成一段 JSON存進 pgvector。記住我在 2.2 節(jié)強調的那句話摘要必須保留結構化字段。任務編號、用戶 ID、當前審批狀態(tài)一旦丟了后續(xù)輪次的模型決策就是空中樓閣。3.4 評測集設計三個指標、回放機制與迭代方式Agent 系統(tǒng)最難的不是寫代碼而是證明它好用。傳統(tǒng)分類任務的準確率在這里不夠用因為 Agent 的輸出是過程性的模型可能最終答對了但過程中多調了 3 個沒必要的工具。我做了一套三層評測思路。第一層是任務完成率判斷最終結果是否達成用戶的真實目標人工去打標。第二層是工具調用正確率每步調用是否合理也由人去標。第三層是無效循環(huán)率統(tǒng)計有多少輪是重復、卡死或者在兩個工具之間來回橫跳。配合一個 50 條任務的小評測集每條任務實錄完整的對話日志和工具日志每次迭代完跑一遍全量對比三個指標的分數(shù)變化。只有三個指標同時提升我才敢說這次改動是正向的。更關鍵的是把評測做成視頻回放而不是分數(shù)報告。我會寫一個回放工具把 Agent 每一步輸入輸出全部渲染成時間線標出哪一步選錯了工具、哪一步浪費了輪數(shù)、哪一步因為返回截斷信息不足?；胤抛鐾昴銜@訝地發(fā)現(xiàn)大部分失敗不是模型不行而是工具描述寫反了、返回結果截太狠、或者記憶摘要丟了關鍵字段。把這三類問題修掉任務完成率普遍能從 60% 拉到 85% 以上。這個現(xiàn)象讓我形成了一個判斷Agent 調優(yōu)的精力分配大約七成在數(shù)據(jù)和工具側只有三成在模型提示詞上。4. 踩坑實錄高頻問題與排查技巧4.1 高頻問題速查表按癥狀定位病因整理一個高頻問題速查表。這張表里的內容全是我和周圍的同事在不同項目里真實踩過的癥狀常見原因排查方法模型反復調用同一個工具工具描述沒說清邊界、返回結果信息不足檢查返回是否含成功標志完善工具描述模型回答無法找到答案RAG 召回結果為空、結果被截斷查檢索日志調整 chunk 大小和 TopK上下文長度繼續(xù)超限沒有窗口裁剪、摘要沒定期觸發(fā)打開滑動窗口每 N 輪強制摘要Agent 長時間不返回最大輪數(shù)過大、工具超時未處理調低輪數(shù)給每個工具加獨立 timeout多 Agent 互相推諉角色分工不清、公共狀態(tài)缺失強化角色邊界引入共享狀態(tài)黑板API 費用異常暴增缺少配額與限流加全局 token 上限與預算告警有幾個點必須展開強調。工具超時是最容易忽略的如果你的一個外部 HTTP 工具卡了 30 秒不返回模型會一直等整個會話就僵死在那里用戶那邊只看到一個永遠不結束的 loading。所以執(zhí)行層寫一個統(tǒng)一的 timeout 包一層比任何花哨優(yōu)化都管用。另一個點是 RAG 截斷工具返回給模型的內容不是越多越好截斷閾值太狠會丟掉關鍵證據(jù)太寬又引入噪聲。我在這個項目里的經(jīng)驗是先按 2000 字符截斷然后根據(jù)回放日志逐步調整到 2500 到 3000每個知識域的差異還挺大。4.2 三個值得長期投入的工程底座觀測、配置回滾、持續(xù)評測代碼跑通、指標達標只是第一環(huán)。如果你打算把這個 Agent 長期養(yǎng)下去接下來的工作重心不是加功能而是把工程底座做厚。我推薦最先投入三個方向。第一個是觀測性。把每一次模型輸入輸出、token 消耗、工具調用參宿、延遲全部落到統(tǒng)一的 tracing 系統(tǒng)里。沒有觀測你排查問題時只能靠猜第二次事故的定位時間至少翻倍。OpenTelemetry 生態(tài)已經(jīng)有成熟的 LLM tracing 方案FastAPI 中間件掛一下就能做到全鏈路。第二個是可回滾的配置。把 Agent 的 prompt、工具描述、記憶參數(shù)、RAG 參數(shù)全部抽成版本化配置文件上線后隨時能回滾到任意歷史版本。這能避免一個場景你想調一下 prompt 對線上的一次失敗回復結果改完 prompt 又引發(fā)了另 10 個回歸問題手忙腳亂改代碼重發(fā)。第三是持續(xù)評測。把每個線上失敗 case 都收進失敗樣本庫每次迭代都重新跑一遍全量評測防止修了 A 問題又帶出 B 問題的回歸。我自己從第一個 Agent 生產(chǎn)項目開始第一天就會把這三件骨架搭好。它不會讓你的第一個 Demo 更快甚至前期有點繁瑣但它決定了這套東西能不能穩(wěn)定活過三個月而不是在上線后的第三周就變成沒人維護的玩具。4.3 想入行 Agent 的人該怎么學、怎么答面試最后聊點實際的。Agent 學習路線和面試題是最近的熱門但市面上真沒有標準教程。我建議按三層遞進的方式補。第一層掌握 Prompt 工程和 Function Calling能用官方 SDK 寫一個會調工具的原型。這一步篩掉一半人因為很多人只會聊天模板不會讓模型結構化輸出工具參數(shù)。第二層理解 ReAct、Plan-and-Execute、Reflexion 這些推理范式并且能在代碼里實現(xiàn)一個最小循環(huán)思考、調用、觀察、再思考。這一步驗證的是你是否有工程手感而不只是懂概念。第三層動手部署一個帶記憶、帶沙箱、帶評測的完整系統(tǒng)把權限控制、超時、限流、觀測這些工程細節(jié)全部踩一遍。能走到第三層的人面試基本不用慌。面試被問如何設計一個 Agent 系統(tǒng)時不要上來背框架而是講方法論。你可以先講任務閉環(huán)拆解再講目標、規(guī)劃、記憶、工具、執(zhí)行這五要素的分層取舍最后拋出一個真實案例的失敗與修正。面試官最想聽的不是框架 API 名稱而是你在踩坑中形成的判斷力比如為什么給工具加白名單、為什么摘要要保留結構化字段、為什么評測要做回放式分析。這些細節(jié)才區(qū)分了用過 Agent和做強過 Agent。回到我自己這個項目上我越來越覺得 Agent 系統(tǒng)的上限由模型決定下限由工程決定。模型決定它能多聰明工程決定它在混亂真實世界里多穩(wěn)定。所謂混亂包括亂寫的工具描述、超時的外部接口、丟字段的記憶摘要、缺失的審計日志。把這些細節(jié)一個一個磨平一個夠用且穩(wěn)定的 Agent 并不遙遠。如果你讀完能少踩幾個坑這篇就算沒白寫。