指南：從狀態(tài)管理到工具調用的完整閉環(huán))
1. 先把概念講清楚Loop Engineering 到底在解決什么問題1.1 Agent 不是“一次問答”而是“一個閉環(huán)”今年做 AI Agent 相關的項目有一個詞幾乎繞不開——Loop Engineering。我第一次聽到這個詞時正在調試一個翻來覆去調用同一個搜索工具、就是不往下走的 Agent那一刻我才真正意識到把大模型接進一個循環(huán)里比讓大模型輸出一段好看的 JSON 難多了。簡單來說Loop Engineering 就是把“思考—行動—觀察—再思考”做成一個顯式的循環(huán)大模型先判斷自己要做什么調用一個工具把工具返回的結果當作新輸入繼續(xù)推理直到達成目標。過去我們習慣把 LLM 當成一個“搜索框”問一句答一句但真實任務里比如整理一份競品分析、抓取一個網站并提煉要點根本不是一次對話能完成的它需要連續(xù)的決策和多個工具的協(xié)作。這就像開導航去一個陌生地方不是出發(fā)前看一次地圖就能到而是每個路口都要看一眼當前路況、重新規(guī)劃路線再開一段再看一次直到抵達終點。Loop Engineering 就是把這種“邊走邊看邊修正”的過程顯式地寫進代碼里讓模型不再是一次性推理而是在閉環(huán)里持續(xù)迭代。那么為什么這個方向在最近一段時間突然被大家反復提起原因不難找一是模型本身的推理能力夠用了二是工具調用的協(xié)議成熟了三是大家發(fā)現光靠 Prompt 很難約束長期任務的執(zhí)行過程必須在代碼層面對“循環(huán)”做工程化管理?？梢哉fLoop Engineering 的本質是把 Agent 的執(zhí)行過程從“黑盒”變成“結構化的可控制流程”。1.2 為什么這個思路“現在”才被集中討論很多人誤以為 Loop Engineering 是個新概念其實“Agent 循環(huán)”早在 ReAct、Toolformer 那批論文里就有了只是當時的模型工具調用能力太弱循環(huán)跑兩三輪就開始胡說八道工程上很難落地。真正讓這個方向爆發(fā)的是兩個變化。一個是模型端現在的模型在 function calling 上越來越穩(wěn)給定工具文檔和參數結構它基本能正確生成調用請求也能理解工具返回的 JSON。另一個是框架端OpenAI 推出 tool calls 結構以后模型輸出已經不再只是“一段文字”而是一份結構化的動作指令代碼里可以做分支判斷——是返回最終答案還是繼續(xù)執(zhí)行工具。這樣的協(xié)議層支持讓“循環(huán)”變成一個標準的工程模式而不是 hack。還有一個容易被忽略的原因應用場景倒逼。RAG 解決的是“知識不足”的問題但很多真實任務根本不是“缺知識”而是“缺流程”。比如讓 Agent 做一份競品分析它要先去搜索品牌信息看完結果決定補搜某個維度再整理對比表格再寫結論——這一步一步的行為序列沒法靠一次生成搞定。當越來越多團隊把 Agent 往真實業(yè)務里推的時候循環(huán)能力就直接決定了系統(tǒng)能不能用。所以你會看到 LangGraph、AutoGen、CrewAI 這些框架核心賣點全是“圖結構”“多輪狀態(tài)流轉”“可暫?？苫謴汀闭f白了都是在幫開發(fā)者管理循環(huán)。Loop Engineering 不是某個人的發(fā)明而是 Agent 工程化過程中繞不開的基礎設施。1.3 和 Prompt Engineering 的分工別混淆我經?？吹接腥税阉袉栴}都丟給 Prompt結果系統(tǒng) prompt 寫了兩千字模型還是崩。這里需要明確一個分工Prompt Engineering 負責的是“讓模型理解要做什么”而 Loop Engineering 負責的是“讓系統(tǒng)確保它真的做完了”。換句話說Prompt 是給模型看的說明書Loop 是給代碼看的執(zhí)行框架。模型說“我要調用 search”靠的是 Prompt 和工具定義但模型調用了五次 search 仍然沒有產出這個問題只能靠循環(huán)層來解決——比如輪數上限、重復行為檢測、中間結果評估。舉個我踩過的例子早期我做一個客服工單自動分類的 Agent系統(tǒng) prompt 里寫了“如果信息不足繼續(xù)追問”結果模型每次都在兜圈子反復問同一個問題因為它在文本層面不知道自己已經問過了。后來我在循環(huán)層加了歷史記錄去重判斷發(fā)現同一問題出現三次就直接中斷轉入人工流程問題立刻緩解。這就是典型的兩層分工Prompt 負責表達意圖Loop 負責兜底控制。搞清楚這個邊界之后你再去看那些 Loop Engineering 的項目思路會清晰很多它不是在和 Prompt 搶工作而是在補 Prompt 夠不著的那部分系統(tǒng)級控制。2. 一個健壯循環(huán)的四個核心組成部分2.1 狀態(tài)管理消息歷史與狀態(tài)機整個循環(huán)最核心的數據結構就是消息歷史。不是簡單的列表而是需要嚴格維護的上下文上下文系統(tǒng)消息、用戶任務、模型決策文本、工具調用請求、工具返回結果。每一步都必須把這個歷史完整地拼好再遞給模型。我見過很多新手翻車都是因為歷史維護不完整。最常見的錯誤是工具調用結果拿出來之后沒有把它的關聯 id 和 tool_call_id 對應好模型下一步就不知道這個結果是誰返回的。在 OpenAI 的協(xié)議里tool reply 必須回填 tool_call_id否則校驗直接報錯。這還不是最坑的更隱蔽的是模型在一步里發(fā)起了多個工具調用代碼只處理了第一個剩下的被靜默丟棄——歷史就缺了一塊后續(xù)推理必然亂套。好消息是狀態(tài)管理不需要一上來就上復雜的狀態(tài)機庫一個字典加幾個字段就夠了。我自己在手工實現階段習慣用一個 Session 類來存當前狀態(tài)class Session: def __init__(self, task: str, max_steps: int 15): self.task task self.history [] self.steps 0 self.max_steps max_steps self.seen_tool_calls set() def append(self, message: dict): self.history.append(message) self.steps 1 def is_exhausted(self) - bool: return self.steps self.max_steps這個類看起來簡單但字段設計都是有講究的task 記錄最原始的目標防止模型后面跑偏了沒人知道seen_tool_calls 用來做重復檢測max_steps 是硬安全閥。等循環(huán)邏輯復雜到需要分支、暫停、恢復的時候再遷移到狀態(tài)機框架也不遲。狀態(tài)機思維是另一個關鍵。每輪循環(huán)其實對應一個狀態(tài)遷移初始狀態(tài) → 工具決策狀態(tài) → 工具執(zhí)行狀態(tài) → 觀察狀態(tài) → 再決策狀態(tài)。把這一步顯式寫出來你能在代碼里看得非常清楚一旦邏輯出問題直接定位到具體環(huán)節(jié)。老實說大多數簡單 Agent 用 if-else 就夠了但你必須心里有一張狀態(tài)遷移圖。2.2 工具層可調用、可觀測、可中斷工具層是循環(huán)的另一半。很多教程只教你定義幾個函數然后丟給模型但工程化的工具層需要三個能力可調用、可觀測、可中斷?？烧{用是基礎——工具的簽名要清晰參數結構要穩(wěn)定返回結果最好統(tǒng)一成 JSON這樣循環(huán)層才能統(tǒng)一處理。我習慣所有工具都返回同一個包一層的結果def safe_call(tool_name: str, args: dict): try: result TOOL_REGISTRY[tool_name](**args) return {ok: True, result: result} except Exception as exc: return {ok: False, error: str(exc)}可觀測的意思是工具的每次調用都要留下日志誰調用的、參數是什么、耗時多少、返回什么。這一點將在下一個項目中體現得淋漓盡致——你會需要這些日志去還原模型那一整套“腦回路”。沒有日志你可能只知道模型在死循環(huán)卻不知道它在循環(huán)里看到了什么?？芍袛喔匾?。不是每個工具調用都必須在循環(huán)里跑完一個搜索 API 可能卡了 30 秒一個爬蟲可能永遠拿不到結果。我在實踐里會給每個工具調用加超時import signal class TimeoutError(Exception): pass def timeout_handler(signum, frame): raise TimeoutError(tool call timeout) def call_with_timeout(func, timeout_seconds10): signal.signal(signal.SIGALRM, timeout_handler) signal.alarm(timeout_seconds) try: return func() finally: signal.alarm(0)超時后返回的錯誤信息本身也算一種觀察結果喂給模型讓它自己決定是重試還是換方案。這一步看起來臺階低卻解決了我遇到過的很多線上問題搜索 API 偶爾超時、第三方接口抽風、被反爬限制……如果沒有超時中斷循環(huán)會卡在那里白白燒錢。2.3 終止條件與安全閥防止模型“永遠不結束”想讓循環(huán)正確地結束遠比想象中難。模型經常出現兩種情況任務明明完成了還在繼續(xù)調用工具或者任務沒完成就提前說“搞定”。所以終止條件不能只靠模型自覺必須從多個維度同時設防。第一個維度是顯式完成信號。我通常會告訴模型如果任務完成回復的內容里必須包含 END。代碼在每輪循環(huán)檢查模型輸出里有沒有這個標記。它不能作為唯一判據因為模型有時候會忘掉但它是最直接的信號。第二個維度是輪數上限。這是最硬的約束也是無論如何都要有的安全閥。15 輪也好、30 輪也好一旦超過就強制截斷寧可任務沒完成也不讓它無限跑下去。成本失控的 Agent 事故絕大多數就是沒有設置這個上限。第三個維度是重復行為檢測。模型會反復用相同的參數調用同一個工具這是無限循環(huán)最常見的標志。我實現的時候很簡單每個工具調用都生成一個簽名“工具名 參數哈希”放進集合里如果連續(xù)出現三次相同簽名就判定為陷入重復主動中斷并把這個判斷結果告訴模型。第四個維度我最近才加上是“低置信度早?！?。如果模型連續(xù)幾輪都在說“我再確認一下”但又沒有新的進展我就把它導到人工處理流程。這個有點玄學但實際項目里真會遇到模型自我懷疑式的循環(huán)輪數沒超工具換了就是沒進展。這種問題靠代碼判斷比較困難我更建議配合日志去人工 review別指望自動化全包。2.4 錯誤反饋與自我糾錯把失敗變成信息循環(huán) Agent 和普通腳本最大的區(qū)別是它能“看見”自己的失敗并調整。這個能力完全建立在錯誤反饋機制上。工具返回了錯誤不能只打印在控制臺必須作為工具結果的一部分完整地塞回消息歷史里讓模型在下一次推理時看到。我做一個爬蟲任務的時候模型調用爬取工具頁面結構變了返回的數據是空的。如果沒有錯誤反饋模型會繼續(xù)以為自己成功了然后基于空數據寫報告但我在返回里加了一段“數據為空可能是頁面結構變化請嘗試備用接口”模型立刻換了一條路線第二次就拿到了數據。具體實現上工具返回的 JSON 里我會包含三個字段ok 表示成功與否result 是真正的數據debug 是給模型看的額外提示。這比只返回一行報錯更有用因為 debug 字段是我根據該工具的業(yè)務背景寫的診斷信息。自我糾錯的另一層是“反思”。如果循環(huán)里檢測到重復行為或者連續(xù)兩次同樣的錯誤我會往歷史里插入一條虛擬助手消息“你剛才連續(xù)兩次調用了同一個工具但結果異常請停下來評估當前策略是否有效?！边@種顯式的反思指令比讓模型自己憑空反思有效得多。因為模型的注意力分配有限你不主動提醒它它很可能忽略掉那些矛盾的歷史記錄。3. 保姆級項目實戰(zhàn)從零搭一個“調研報告生成 Agent”3.1 場景定義與需求拆解理論講完上一段真實代碼。我最近做了一個小項目調研報告生成 Agent。輸入一個主題Agent 自動完成“搜索資料 → 篩選有效信息 → 補充缺口 → 整理成結構化報告”的完整流程。為什么選這個場景因為它天然需要循環(huán)。第一步搜索結果往往是不夠的模型需要根據已找到的信息決定下一步搜什么信息收集到一定程度還要判斷有沒有缺口決定是繼續(xù)搜還是開始寫。整個過程是典型的“決策—行動—觀察”閉環(huán)非常適合用來演示 Loop Engineering。技術棧選擇上我沒有直接用 LangGraph而是手寫了不到兩百行的 Python 循環(huán)。原因很簡單手寫循環(huán)能讓你把狀態(tài)流轉、終止條件、錯誤反饋這些細節(jié)吃透之后再遷移到框架你會更容易理解框架設計者為什么那么做。API 我用的 OpenAI 兼容接口這里不限制具體廠商只要是支持 function calling 的模型都行。需求先拆成三條核心邏輯第一工具層面至少要有搜索和文本整理兩個工具搜索用來拿信息文本整理用來生成章節(jié)初稿第二循環(huán)必須在信息收集充分后自動切換到寫作階段不能一直搜下去第三必須有輪數上限防止模型在查資料上無限折騰。3.2 核心代碼實現與逐步拆解先定義工具層。我給 Agent 準備了兩個工具一個是搜索工具實際項目里可以對接搜索 API這里用一個模擬函數代替重點看循環(huán)結構另一個是 write_section 工具把文本片段寫入報告草稿。import json from typing import Dict, List, Callable, Any TOOL_REGISTRY: Dict[str, Callable] {} def register_tool(name: str): def decorator(func: Callable): TOOL_REGISTRY[name] func return func return decorator register_tool(web_search) def web_search(query: str) - Dict[str, Any]: # 真實項目中這里會請求搜索 API屬于 I/O 操作 return {ok: True, result: f關于「{query}」的搜索摘要包含若干相關鏈接和要點。} register_tool(write_section) def write_section(title: str, content: str) - Dict[str, Any]: # 真實項目中會寫入文件或數據庫 return {ok: True, result: f章節(jié)「{title}」已寫入共 {len(content)} 字。}工具返回統(tǒng)一 JSON 結構是后續(xù)所有判斷的基礎。接下來是核心的循環(huán)邏輯def build_system_prompt(): prompt 你是一個調研報告助手。請按以下流程完成調研任務 1. 先使用 web_search 收集資料每次搜索只查一個關鍵詞。 2. 如果信息不夠繼續(xù)搜索但不要重復相同的關鍵詞。 3. 當信息足夠時使用 write_section 寫入報告章節(jié)然后輸出最終報告。 4. 所有工具調用必須包含合法的 arguments JSON。 如果你的分析已經完成請直接輸出最終報告并在開頭包含「REPORT_END」標記。 return prompt.strip() def run_research_agent(task: str, llm, max_steps: int 20): system_prompt build_system_prompt() history: List[Dict] [ {role: system, content: system_prompt}, {role: user, content: task}, ] completed_tool_keys set() for step in range(max_steps): response llm(history) # 情況一模型輸出最終報告 content response.get(content, ) if content: if REPORT_END in content: return content, step 1 history.append({role: assistant, content: content}) # 情況二模型請求調用工具 tool_calls response.get(tool_calls, []) if not tool_calls: # 模型既沒給內容也沒給工具調用只能強制終止 return content or 模型未正確終止強制結束, step 1 for call in tool_calls: tool_name call[function][name] raw_args call[function][arguments] try: args json.loads(raw_args) if isinstance(raw_args, str) else raw_args except json.JSONDecodeError: history.append({ role: tool, content: json.dumps({ok: False, error: f參數不是合法 JSON請修復你的 arguments 字符串}), tool_call_id: call[id], }) continue tool_key f{tool_name}:{json.dumps(args, sort_keysTrue)} # 重復檢測同一工具同一參數出現兩次以上給模型提示 if tool_key in completed_tool_keys: history.append({ role: tool, content: json.dumps({ok: False, error: 你剛剛已經用相同的參數調用過相同工具請更換策略或停止}), tool_call_id: call[id], }) continue completed_tool_keys.add(tool_key) func TOOL_REGISTRY.get(tool_name) if func is None: result {ok: False, error: f未知工具: {tool_name}} else: try: result func(**args) except Exception as exc: result {ok: False, error: str(exc)} history.append({ role: tool, content: json.dumps(result, ensure_asciiFalse), tool_call_id: call[id], }) return (未在限制輪次內完成), max_steps這段代碼把前面講的核心設計全部落實了歷史消息持續(xù)累積工具調用結果回填歷史重復調用被檢測并反饋給模型JSON 解析錯誤也沒有直接崩潰而是轉給了模型自我修正。它還隱含了終止策略有 REPORT_END 就給最終結果沒給就強制返回不讓循環(huán)無限跑下去。這里有個細節(jié)值得展開說當模型調用工具后代碼里我并沒有立刻結束循環(huán)而是把工具結果追加到歷史后讓循環(huán)繼續(xù)執(zhí)行下一次推理。換句話說tool reply 不是一棵樹的終點而是下一次決策的起點。很多新手的誤區(qū)就是工具調用完就不知道如何“把球踢回給模型”導致整個流程只能走一步。3.3 可觀測性與調試技巧讓每一個決策可回放手寫循環(huán)最大的好處是調試透明前提是你留下了足夠的日志。我在這套代碼里一向會在幾個關鍵節(jié)點打日志第幾輪、模型輸出了什么、調用了哪個工具、參數是什么、返回是什么、當前處于哪個階段。我把日志格式固定下來方便事后用文本工具分析。import logging logging.basicConfig( levellogging.INFO, format%(asctime)s [step %(step)s] %(message)s, )實踐中我發(fā)現打印每一步的完整對話歷史最有價值而不是只打印最后結果。模型在循環(huán)中的每一步判斷都受前面所有歷史的影響只看尾部你永遠不知道它是被哪條歷史帶偏的。我常用的調試手法是把 history 完整 dump 成一個 JSON 文件再在本地開個聊天窗口去“復現”模型的視角。如果你覺得純日志不夠直觀可以做一個極簡的可視化每輪用“step → 工具名 → 結果說明”的方式打印一行20 輪以內的 Agent 都能一眼看完全程。這種日志在定位死循環(huán)時非常實用——你會立刻看見模型一直在搜同一個關鍵詞或者一直在寫同一節(jié)內容。3.4 成本與性能控制別讓循環(huán)燒掉你的錢包Loop Engineering 一個繞不開的問題每一次循環(huán)都需要一次完整的 LLM 調用輪數越多token 消耗越大。一個 15 輪的調研任務如果每輪都要把幾萬字的工具結果塞進上下文單次任務的成本可能高到離譜。控制成本有幾個非常實用的手段都是我在實際項目里驗證過效果的。第一工具結果截斷。搜索工具返回的長文本在塞進歷史之前先截斷到 2000 字以內。真實場景下搜索摘要里 90% 的內容是廢話保留最前面的關鍵部分是夠用的。我建議在工具層就做截斷不要在循環(huán)層做因為工具最清楚自己返回的信息哪些要緊。第二歷史摘要化。如果歷史超過一定長度把前面的工具結果用一個“摘要消息”替換掉。寫一個 summarize 工具也行直接調用模型壓縮也行。這個操作對長任務特別有效能大幅延長可執(zhí)行輪數。第三緩存重復調用。如果模型在多個輪次內提出了相同的問題直接復用第一次的工具結果不要再真實請求一次。我在上一小節(jié)的重復檢測里已經覆蓋了這個邏輯它不僅防止死循環(huán)也避免了重復的 API 消耗。第四讓模型更克制的調用工具。在 system prompt 里明確告訴它“每次搜索必須基于已有信息提出新的增量關鍵詞不得重復搜索”。好的 prompt 能把輪數壓縮掉 30% 到 50%這在批跑任務時是巨大的節(jié)省。我實際跑過一輪對比同一個調研任務不做任何控制時模型燒了約 4 萬 token加了截斷和重復檢測之后不到 1.6 萬 token。差距主要就是循環(huán)控制帶來的。4. 真實踩坑記錄循環(huán) Agent 的典型問題與排查思路4.1 模型陷入“工具調用死循環(huán)”這是新手遇到最多的問題癥狀很典型日志里全是同一對工具來回調用比如 web_search 和 write_section 反復交替或者一模一樣的關鍵詞被搜了七八次。原因通常有兩個一是模型確實忘了自己之前搜過什么這屬于上下文注意力不足只能靠外部記憶來補二是工具返回的結果沒有提供“下一步依據”模型沒有足夠信息判斷該結束了。排查的時候我會先把完整的工具調用序列打出來看模式是不是同一個“工具名參數”組合在重復如果是就是重復檢測沒生效如果工具參數每次都在變但整體沒有進展那就是模型在無意義探索需要給反饋信息加更明確的目標指引。我的解決方案就是在循環(huán)層加重復目標檢測并且把提示寫得具體到“你剛才已經用相同參數搜索過請基于已有結果提出新的搜索關鍵詞或者直接進入報告寫作階段”。好模型的自我修正能力遠超想象很多時候只是缺一句“有人盯著它”的提醒。4.2 上下文爆炸token 被歷史消息吃光循環(huán)跑多了最直接的問題就是歷史消息越來越長。模型每輪都要讀完全部歷史token 消耗隨輪數指數增長而且一旦超出上下文窗口就會報錯。我踩過一次比較嚴重的坑做一個網頁抓取 Agent每輪都把整頁 HTML 塞進歷史跑到第五輪時上下文直接爆了前面的搜索結果全被截斷模型完全失憶。解決辦法是在工具層就做清洗和截斷HTML 轉純文本然后限制最長長度。上下文爆炸不僅僅是技術問題也是成本問題。我建議對工具返回設置一個硬長度上限超過部分直接切掉同時在 System Prompt 里說明“工具結果可能被截斷需要完整信息時請重新搜索更有針對性的關鍵詞”。這樣模型不會因為信息不全而反復抓瞎。4.3 工具輸出格式導致解析失敗模型返回的 tool_calls 不一定永遠規(guī)范尤其在一些開源模型上function arguments 經常不是合法 JSON或者參數名跟工具定義不完全一致。如果放任不管循環(huán)就會在這里卡死。處理方式是在循環(huán)層做一個容錯解析先嘗試標準 json.loads失敗時用一個寬松的解析函數把 key 和 value 用正則提取出來。如果還是失敗不要直接報錯而是把“參數解析失敗”作為工具結果返回給模型讓它自己修復。更隱蔽的問題在于模型把工具名寫錯比如定義的是 web_search它寫成 search_web。發(fā)生這種情況我會在錯誤反饋里附上可用工具列表讓模型自己讀一遍再重新生成。實測下來大部分模型看到自己手里的“菜單”后會立刻糾正。4.4 任務沒完成就提前收尾有些模型在信息明顯不足的情況下寧可輸出一份泛泛而談的報告也不繼續(xù)搜索。這通常是懶惰不是能力不足。我遇到過一個任務讓 Agent 調研某一垂直領域的市場規(guī)模它搜了一次數據來源就寫完了結果報告里全是定性描述一個具體數字都沒有。要解決“提前收尾”我嘗試過幾種辦法。最有效的有兩個一是要求模型在最終報告里包含完整的數據來源如果沒有來源就不允許輸出 REPORT_END 標記二是在循環(huán)層增加一個“完成度校驗”的子模型專門評估最終報告的質量不合格就把評估意見塞回歷史讓模型補做。完成度校驗增加了額外的 LLM 調用但值得。尤其在生產場景里與其讓一份爛報告直接交付給用戶不如多花幾百 token 把質量兜住。當然它對 Prompt 的要求也更高你需要很明確地告訴評估子模型“什么樣的報告算合格”否則它會跟主要模型互相拍馬屁兩人都覺得寫得不錯。下面是幾個高頻問題的速查表我直接把它貼進代碼注釋里遇到問題先對照一遍。癥狀常見原因排查方法處理建議連續(xù)調用同一工具缺重復檢測打印歷史中的工具調用簽名添加重復簽名檢測并反饋給模型上下文越來越長無窗口控制監(jiān)控每輪 token 消耗工具結果截斷 歷史摘要化參數 JSON 解析報錯模型輸出格式不穩(wěn)定打印原始 arguments 字符串容錯解析 向模型回傳錯誤信息未完成就輸出報告缺少完成度標準人工抽查最終報告質量加入完成度校驗子模型輪數超限仍不停止安全閥缺失檢查循環(huán)代碼的 break 條件強制 max_steps 硬上限工具超時導致卡死外部 API 不穩(wěn)定檢查耗時日志給工具調用加超時和異常捕獲4.5 思考式排查法當模型不按規(guī)則出牌怎么辦最后分享一個偏“玄學”但很實用的排查思路當你無法從代碼層面判斷模型行為是否合理時把歷史導出來自己扮演一次模型——也就是所謂的“角色扮演回放”。具體做法是這樣的把某一輪的完整歷史里模型消息和工具返回打印出來人工去看模型在最后一步的選擇假設你是這個模型你會如何決策如果連你自己都覺得信息足夠、應該進入下一階段那說明模型的判斷是合理的問題可能出在終止條件上如果連你自己都覺得信息不足那問題出在工具的數據質量上模型確實沒法從垃圾數據里推理出有價值的東西。這個方法幫我定位過很多詭異的問題比如模型在一輪里突然調用了一個跟任務完全無關的工具回看一下才發(fā)現是前面某條工具結果里的字符誤導了它。紙面上的日志永遠比腦子里模糊的印象可靠。5. 繼續(xù)加碼從單循環(huán)到多循環(huán)的擴展方向前面這套調研報告 Agent 用的還是單循環(huán)結構一個主模型驅動所有決策。但真實世界里的復雜任務往往需要多個循環(huán)配合這也是 Loop Engineering 的核心進階方向。第一個常見的擴展是“規(guī)劃器—執(zhí)行器”雙層循環(huán)。規(guī)劃器模型負責拆解任務、生成執(zhí)行計劃執(zhí)行器模型負責跑具體的工具每完成一個子步驟規(guī)劃器收到結果后重新評估剩余規(guī)劃直到全部結束。這個結構能顯著提升復雜任務的穩(wěn)定性因為規(guī)劃器有全局視角執(zhí)行器可以專心做局部操作。第二個擴展是“子 Agent 循環(huán)”。當工具調用需要上下文隔離時我會為每個子任務單獨開一個循環(huán)讓它們各自維護自己的歷史最后匯總到主循環(huán)。比如調研任務里每個細分領域開一個子 Agent 循環(huán)分別去收集資料主循環(huán)負責合并結果和寫報告。隔離的上下文不僅降低了彼此的干擾也大幅減少了主循環(huán)的 token 消耗。第三個擴展是“記憶循環(huán)”。如果讓 Agent 在多輪任務中記住用戶偏好或歷史決策就需要一個專門的管理循環(huán)來維護長期記憶。每輪決策結束后主循環(huán)把關鍵信息抽取出來寫入記憶庫下一次循環(huán)開始時把記憶加載進來。這個本質上是在循環(huán)外面套了一層“記憶維護循環(huán)”兩者同步運轉。如果你已經有了一定的基礎我特別建議自己先手寫兩三個不同場景的單循環(huán) Agent把狀態(tài)維護和終止條件玩明白然后再去用 LangGraph 這樣的框架?？蚣軒湍闶〉袅舜罅繕影宕a但它也隱藏了循環(huán)內部的很多細節(jié)。做過一遍手寫循環(huán)之后你看到 LangGraph 的 StateGraph 和 conditional edges就會有一種“這不就是我把 if-else 整理成配置”的感覺理解成本瞬間歸零。說到最后聊聊我做 Loop Engineering 的個人體會。它不是一個你調一晚上就能學會的 API而是一種工程思維的轉變別再想著靠某一次完美的 Prompt 讓模型一步到位而是接受“模型會犯錯、會繞路、會自我懷疑”這個事實然后用循環(huán)把這些錯誤變成可修正的中間狀態(tài)。每給循環(huán)加一道“護欄”你其實就在慢慢把一個演示用的 Agent 變成能穩(wěn)定跑業(yè)務的系統(tǒng)。這個過程中最值得投入的地方不是復雜的狀態(tài)機理論而是對真實任務的拆解能力和對日志的敏感度。數據永遠能告訴你答案前提是你讓它在循環(huán)里流動起來。 Loop Engineering 實戰(zhàn)指南：從狀態(tài)管理到工具調用的完整閉環(huán)
1. 先把概念講清楚Loop Engineering 到底在解決什么問題1.1 Agent 不是“一次問答”而是“一個閉環(huán)”今年做 AI Agent 相關的項目有一個詞幾乎繞不開——Loop Engineering。我第一次聽到這個詞時正在調試一個翻來覆去調用同一個搜索工具、就是不往下走的 Agent那一刻我才真正意識到把大模型接進一個循環(huán)里比讓大模型輸出一段好看的 JSON 難多了。簡單來說Loop Engineering 就是把“思考—行動—觀察—再思考”做成一個顯式的循環(huán)大模型先判斷自己要做什么調用一個工具把工具返回的結果當作新輸入繼續(xù)推理直到達成目標。過去我們習慣把 LLM 當成一個“搜索框”問一句答一句但真實任務里比如整理一份競品分析、抓取一個網站并提煉要點根本不是一次對話能完成的它需要連續(xù)的決策和多個工具的協(xié)作。這就像開導航去一個陌生地方不是出發(fā)前看一次地圖就能到而是每個路口都要看一眼當前路況、重新規(guī)劃路線再開一段再看一次直到抵達終點。Loop Engineering 就是把這種“邊走邊看邊修正”的過程顯式地寫進代碼里讓模型不再是一次性推理而是在閉環(huán)里持續(xù)迭代。那么為什么這個方向在最近一段時間突然被大家反復提起原因不難找一是模型本身的推理能力夠用了二是工具調用的協(xié)議成熟了三是大家發(fā)現光靠 Prompt 很難約束長期任務的執(zhí)行過程必須在代碼層面對“循環(huán)”做工程化管理?？梢哉fLoop Engineering 的本質是把 Agent 的執(zhí)行過程從“黑盒”變成“結構化的可控制流程”。1.2 為什么這個思路“現在”才被集中討論很多人誤以為 Loop Engineering 是個新概念其實“Agent 循環(huán)”早在 ReAct、Toolformer 那批論文里就有了只是當時的模型工具調用能力太弱循環(huán)跑兩三輪就開始胡說八道工程上很難落地。真正讓這個方向爆發(fā)的是兩個變化。一個是模型端現在的模型在 function calling 上越來越穩(wěn)給定工具文檔和參數結構它基本能正確生成調用請求也能理解工具返回的 JSON。另一個是框架端OpenAI 推出 tool calls 結構以后模型輸出已經不再只是“一段文字”而是一份結構化的動作指令代碼里可以做分支判斷——是返回最終答案還是繼續(xù)執(zhí)行工具。這樣的協(xié)議層支持讓“循環(huán)”變成一個標準的工程模式而不是 hack。還有一個容易被忽略的原因應用場景倒逼。RAG 解決的是“知識不足”的問題但很多真實任務根本不是“缺知識”而是“缺流程”。比如讓 Agent 做一份競品分析它要先去搜索品牌信息看完結果決定補搜某個維度再整理對比表格再寫結論——這一步一步的行為序列沒法靠一次生成搞定。當越來越多團隊把 Agent 往真實業(yè)務里推的時候循環(huán)能力就直接決定了系統(tǒng)能不能用。所以你會看到 LangGraph、AutoGen、CrewAI 這些框架核心賣點全是“圖結構”“多輪狀態(tài)流轉”“可暫?？苫謴汀闭f白了都是在幫開發(fā)者管理循環(huán)。Loop Engineering 不是某個人的發(fā)明而是 Agent 工程化過程中繞不開的基礎設施。1.3 和 Prompt Engineering 的分工別混淆我經?？吹接腥税阉袉栴}都丟給 Prompt結果系統(tǒng) prompt 寫了兩千字模型還是崩。這里需要明確一個分工Prompt Engineering 負責的是“讓模型理解要做什么”而 Loop Engineering 負責的是“讓系統(tǒng)確保它真的做完了”。換句話說Prompt 是給模型看的說明書Loop 是給代碼看的執(zhí)行框架。模型說“我要調用 search”靠的是 Prompt 和工具定義但模型調用了五次 search 仍然沒有產出這個問題只能靠循環(huán)層來解決——比如輪數上限、重復行為檢測、中間結果評估。舉個我踩過的例子早期我做一個客服工單自動分類的 Agent系統(tǒng) prompt 里寫了“如果信息不足繼續(xù)追問”結果模型每次都在兜圈子反復問同一個問題因為它在文本層面不知道自己已經問過了。后來我在循環(huán)層加了歷史記錄去重判斷發(fā)現同一問題出現三次就直接中斷轉入人工流程問題立刻緩解。這就是典型的兩層分工Prompt 負責表達意圖Loop 負責兜底控制。搞清楚這個邊界之后你再去看那些 Loop Engineering 的項目思路會清晰很多它不是在和 Prompt 搶工作而是在補 Prompt 夠不著的那部分系統(tǒng)級控制。2. 一個健壯循環(huán)的四個核心組成部分2.1 狀態(tài)管理消息歷史與狀態(tài)機整個循環(huán)最核心的數據結構就是消息歷史。不是簡單的列表而是需要嚴格維護的上下文上下文系統(tǒng)消息、用戶任務、模型決策文本、工具調用請求、工具返回結果。每一步都必須把這個歷史完整地拼好再遞給模型。我見過很多新手翻車都是因為歷史維護不完整。最常見的錯誤是工具調用結果拿出來之后沒有把它的關聯 id 和 tool_call_id 對應好模型下一步就不知道這個結果是誰返回的。在 OpenAI 的協(xié)議里tool reply 必須回填 tool_call_id否則校驗直接報錯。這還不是最坑的更隱蔽的是模型在一步里發(fā)起了多個工具調用代碼只處理了第一個剩下的被靜默丟棄——歷史就缺了一塊后續(xù)推理必然亂套。好消息是狀態(tài)管理不需要一上來就上復雜的狀態(tài)機庫一個字典加幾個字段就夠了。我自己在手工實現階段習慣用一個 Session 類來存當前狀態(tài)class Session: def __init__(self, task: str, max_steps: int 15): self.task task self.history [] self.steps 0 self.max_steps max_steps self.seen_tool_calls set() def append(self, message: dict): self.history.append(message) self.steps 1 def is_exhausted(self) - bool: return self.steps self.max_steps這個類看起來簡單但字段設計都是有講究的task 記錄最原始的目標防止模型后面跑偏了沒人知道seen_tool_calls 用來做重復檢測max_steps 是硬安全閥。等循環(huán)邏輯復雜到需要分支、暫停、恢復的時候再遷移到狀態(tài)機框架也不遲。狀態(tài)機思維是另一個關鍵。每輪循環(huán)其實對應一個狀態(tài)遷移初始狀態(tài) → 工具決策狀態(tài) → 工具執(zhí)行狀態(tài) → 觀察狀態(tài) → 再決策狀態(tài)。把這一步顯式寫出來你能在代碼里看得非常清楚一旦邏輯出問題直接定位到具體環(huán)節(jié)。老實說大多數簡單 Agent 用 if-else 就夠了但你必須心里有一張狀態(tài)遷移圖。2.2 工具層可調用、可觀測、可中斷工具層是循環(huán)的另一半。很多教程只教你定義幾個函數然后丟給模型但工程化的工具層需要三個能力可調用、可觀測、可中斷?？烧{用是基礎——工具的簽名要清晰參數結構要穩(wěn)定返回結果最好統(tǒng)一成 JSON這樣循環(huán)層才能統(tǒng)一處理。我習慣所有工具都返回同一個包一層的結果def safe_call(tool_name: str, args: dict): try: result TOOL_REGISTRY[tool_name](**args) return {ok: True, result: result} except Exception as exc: return {ok: False, error: str(exc)}可觀測的意思是工具的每次調用都要留下日志誰調用的、參數是什么、耗時多少、返回什么。這一點將在下一個項目中體現得淋漓盡致——你會需要這些日志去還原模型那一整套“腦回路”。沒有日志你可能只知道模型在死循環(huán)卻不知道它在循環(huán)里看到了什么?？芍袛喔匾?。不是每個工具調用都必須在循環(huán)里跑完一個搜索 API 可能卡了 30 秒一個爬蟲可能永遠拿不到結果。我在實踐里會給每個工具調用加超時import signal class TimeoutError(Exception): pass def timeout_handler(signum, frame): raise TimeoutError(tool call timeout) def call_with_timeout(func, timeout_seconds10): signal.signal(signal.SIGALRM, timeout_handler) signal.alarm(timeout_seconds) try: return func() finally: signal.alarm(0)超時后返回的錯誤信息本身也算一種觀察結果喂給模型讓它自己決定是重試還是換方案。這一步看起來臺階低卻解決了我遇到過的很多線上問題搜索 API 偶爾超時、第三方接口抽風、被反爬限制……如果沒有超時中斷循環(huán)會卡在那里白白燒錢。2.3 終止條件與安全閥防止模型“永遠不結束”想讓循環(huán)正確地結束遠比想象中難。模型經常出現兩種情況任務明明完成了還在繼續(xù)調用工具或者任務沒完成就提前說“搞定”。所以終止條件不能只靠模型自覺必須從多個維度同時設防。第一個維度是顯式完成信號。我通常會告訴模型如果任務完成回復的內容里必須包含 END。代碼在每輪循環(huán)檢查模型輸出里有沒有這個標記。它不能作為唯一判據因為模型有時候會忘掉但它是最直接的信號。第二個維度是輪數上限。這是最硬的約束也是無論如何都要有的安全閥。15 輪也好、30 輪也好一旦超過就強制截斷寧可任務沒完成也不讓它無限跑下去。成本失控的 Agent 事故絕大多數就是沒有設置這個上限。第三個維度是重復行為檢測。模型會反復用相同的參數調用同一個工具這是無限循環(huán)最常見的標志。我實現的時候很簡單每個工具調用都生成一個簽名“工具名 參數哈希”放進集合里如果連續(xù)出現三次相同簽名就判定為陷入重復主動中斷并把這個判斷結果告訴模型。第四個維度我最近才加上是“低置信度早?！?。如果模型連續(xù)幾輪都在說“我再確認一下”但又沒有新的進展我就把它導到人工處理流程。這個有點玄學但實際項目里真會遇到模型自我懷疑式的循環(huán)輪數沒超工具換了就是沒進展。這種問題靠代碼判斷比較困難我更建議配合日志去人工 review別指望自動化全包。2.4 錯誤反饋與自我糾錯把失敗變成信息循環(huán) Agent 和普通腳本最大的區(qū)別是它能“看見”自己的失敗并調整。這個能力完全建立在錯誤反饋機制上。工具返回了錯誤不能只打印在控制臺必須作為工具結果的一部分完整地塞回消息歷史里讓模型在下一次推理時看到。我做一個爬蟲任務的時候模型調用爬取工具頁面結構變了返回的數據是空的。如果沒有錯誤反饋模型會繼續(xù)以為自己成功了然后基于空數據寫報告但我在返回里加了一段“數據為空可能是頁面結構變化請嘗試備用接口”模型立刻換了一條路線第二次就拿到了數據。具體實現上工具返回的 JSON 里我會包含三個字段ok 表示成功與否result 是真正的數據debug 是給模型看的額外提示。這比只返回一行報錯更有用因為 debug 字段是我根據該工具的業(yè)務背景寫的診斷信息。自我糾錯的另一層是“反思”。如果循環(huán)里檢測到重復行為或者連續(xù)兩次同樣的錯誤我會往歷史里插入一條虛擬助手消息“你剛才連續(xù)兩次調用了同一個工具但結果異常請停下來評估當前策略是否有效?！边@種顯式的反思指令比讓模型自己憑空反思有效得多。因為模型的注意力分配有限你不主動提醒它它很可能忽略掉那些矛盾的歷史記錄。3. 保姆級項目實戰(zhàn)從零搭一個“調研報告生成 Agent”3.1 場景定義與需求拆解理論講完上一段真實代碼。我最近做了一個小項目調研報告生成 Agent。輸入一個主題Agent 自動完成“搜索資料 → 篩選有效信息 → 補充缺口 → 整理成結構化報告”的完整流程。為什么選這個場景因為它天然需要循環(huán)。第一步搜索結果往往是不夠的模型需要根據已找到的信息決定下一步搜什么信息收集到一定程度還要判斷有沒有缺口決定是繼續(xù)搜還是開始寫。整個過程是典型的“決策—行動—觀察”閉環(huán)非常適合用來演示 Loop Engineering。技術棧選擇上我沒有直接用 LangGraph而是手寫了不到兩百行的 Python 循環(huán)。原因很簡單手寫循環(huán)能讓你把狀態(tài)流轉、終止條件、錯誤反饋這些細節(jié)吃透之后再遷移到框架你會更容易理解框架設計者為什么那么做。API 我用的 OpenAI 兼容接口這里不限制具體廠商只要是支持 function calling 的模型都行。需求先拆成三條核心邏輯第一工具層面至少要有搜索和文本整理兩個工具搜索用來拿信息文本整理用來生成章節(jié)初稿第二循環(huán)必須在信息收集充分后自動切換到寫作階段不能一直搜下去第三必須有輪數上限防止模型在查資料上無限折騰。3.2 核心代碼實現與逐步拆解先定義工具層。我給 Agent 準備了兩個工具一個是搜索工具實際項目里可以對接搜索 API這里用一個模擬函數代替重點看循環(huán)結構另一個是 write_section 工具把文本片段寫入報告草稿。import json from typing import Dict, List, Callable, Any TOOL_REGISTRY: Dict[str, Callable] {} def register_tool(name: str): def decorator(func: Callable): TOOL_REGISTRY[name] func return func return decorator register_tool(web_search) def web_search(query: str) - Dict[str, Any]: # 真實項目中這里會請求搜索 API屬于 I/O 操作 return {ok: True, result: f關于「{query}」的搜索摘要包含若干相關鏈接和要點。} register_tool(write_section) def write_section(title: str, content: str) - Dict[str, Any]: # 真實項目中會寫入文件或數據庫 return {ok: True, result: f章節(jié)「{title}」已寫入共 {len(content)} 字。}工具返回統(tǒng)一 JSON 結構是后續(xù)所有判斷的基礎。接下來是核心的循環(huán)邏輯def build_system_prompt(): prompt 你是一個調研報告助手。請按以下流程完成調研任務 1. 先使用 web_search 收集資料每次搜索只查一個關鍵詞。 2. 如果信息不夠繼續(xù)搜索但不要重復相同的關鍵詞。 3. 當信息足夠時使用 write_section 寫入報告章節(jié)然后輸出最終報告。 4. 所有工具調用必須包含合法的 arguments JSON。 如果你的分析已經完成請直接輸出最終報告并在開頭包含「REPORT_END」標記。 return prompt.strip() def run_research_agent(task: str, llm, max_steps: int 20): system_prompt build_system_prompt() history: List[Dict] [ {role: system, content: system_prompt}, {role: user, content: task}, ] completed_tool_keys set() for step in range(max_steps): response llm(history) # 情況一模型輸出最終報告 content response.get(content, ) if content: if REPORT_END in content: return content, step 1 history.append({role: assistant, content: content}) # 情況二模型請求調用工具 tool_calls response.get(tool_calls, []) if not tool_calls: # 模型既沒給內容也沒給工具調用只能強制終止 return content or 模型未正確終止強制結束, step 1 for call in tool_calls: tool_name call[function][name] raw_args call[function][arguments] try: args json.loads(raw_args) if isinstance(raw_args, str) else raw_args except json.JSONDecodeError: history.append({ role: tool, content: json.dumps({ok: False, error: f參數不是合法 JSON請修復你的 arguments 字符串}), tool_call_id: call[id], }) continue tool_key f{tool_name}:{json.dumps(args, sort_keysTrue)} # 重復檢測同一工具同一參數出現兩次以上給模型提示 if tool_key in completed_tool_keys: history.append({ role: tool, content: json.dumps({ok: False, error: 你剛剛已經用相同的參數調用過相同工具請更換策略或停止}), tool_call_id: call[id], }) continue completed_tool_keys.add(tool_key) func TOOL_REGISTRY.get(tool_name) if func is None: result {ok: False, error: f未知工具: {tool_name}} else: try: result func(**args) except Exception as exc: result {ok: False, error: str(exc)} history.append({ role: tool, content: json.dumps(result, ensure_asciiFalse), tool_call_id: call[id], }) return (未在限制輪次內完成), max_steps這段代碼把前面講的核心設計全部落實了歷史消息持續(xù)累積工具調用結果回填歷史重復調用被檢測并反饋給模型JSON 解析錯誤也沒有直接崩潰而是轉給了模型自我修正。它還隱含了終止策略有 REPORT_END 就給最終結果沒給就強制返回不讓循環(huán)無限跑下去。這里有個細節(jié)值得展開說當模型調用工具后代碼里我并沒有立刻結束循環(huán)而是把工具結果追加到歷史后讓循環(huán)繼續(xù)執(zhí)行下一次推理。換句話說tool reply 不是一棵樹的終點而是下一次決策的起點。很多新手的誤區(qū)就是工具調用完就不知道如何“把球踢回給模型”導致整個流程只能走一步。3.3 可觀測性與調試技巧讓每一個決策可回放手寫循環(huán)最大的好處是調試透明前提是你留下了足夠的日志。我在這套代碼里一向會在幾個關鍵節(jié)點打日志第幾輪、模型輸出了什么、調用了哪個工具、參數是什么、返回是什么、當前處于哪個階段。我把日志格式固定下來方便事后用文本工具分析。import logging logging.basicConfig( levellogging.INFO, format%(asctime)s [step %(step)s] %(message)s, )實踐中我發(fā)現打印每一步的完整對話歷史最有價值而不是只打印最后結果。模型在循環(huán)中的每一步判斷都受前面所有歷史的影響只看尾部你永遠不知道它是被哪條歷史帶偏的。我常用的調試手法是把 history 完整 dump 成一個 JSON 文件再在本地開個聊天窗口去“復現”模型的視角。如果你覺得純日志不夠直觀可以做一個極簡的可視化每輪用“step → 工具名 → 結果說明”的方式打印一行20 輪以內的 Agent 都能一眼看完全程。這種日志在定位死循環(huán)時非常實用——你會立刻看見模型一直在搜同一個關鍵詞或者一直在寫同一節(jié)內容。3.4 成本與性能控制別讓循環(huán)燒掉你的錢包Loop Engineering 一個繞不開的問題每一次循環(huán)都需要一次完整的 LLM 調用輪數越多token 消耗越大。一個 15 輪的調研任務如果每輪都要把幾萬字的工具結果塞進上下文單次任務的成本可能高到離譜。控制成本有幾個非常實用的手段都是我在實際項目里驗證過效果的。第一工具結果截斷。搜索工具返回的長文本在塞進歷史之前先截斷到 2000 字以內。真實場景下搜索摘要里 90% 的內容是廢話保留最前面的關鍵部分是夠用的。我建議在工具層就做截斷不要在循環(huán)層做因為工具最清楚自己返回的信息哪些要緊。第二歷史摘要化。如果歷史超過一定長度把前面的工具結果用一個“摘要消息”替換掉。寫一個 summarize 工具也行直接調用模型壓縮也行。這個操作對長任務特別有效能大幅延長可執(zhí)行輪數。第三緩存重復調用。如果模型在多個輪次內提出了相同的問題直接復用第一次的工具結果不要再真實請求一次。我在上一小節(jié)的重復檢測里已經覆蓋了這個邏輯它不僅防止死循環(huán)也避免了重復的 API 消耗。第四讓模型更克制的調用工具。在 system prompt 里明確告訴它“每次搜索必須基于已有信息提出新的增量關鍵詞不得重復搜索”。好的 prompt 能把輪數壓縮掉 30% 到 50%這在批跑任務時是巨大的節(jié)省。我實際跑過一輪對比同一個調研任務不做任何控制時模型燒了約 4 萬 token加了截斷和重復檢測之后不到 1.6 萬 token。差距主要就是循環(huán)控制帶來的。4. 真實踩坑記錄循環(huán) Agent 的典型問題與排查思路4.1 模型陷入“工具調用死循環(huán)”這是新手遇到最多的問題癥狀很典型日志里全是同一對工具來回調用比如 web_search 和 write_section 反復交替或者一模一樣的關鍵詞被搜了七八次。原因通常有兩個一是模型確實忘了自己之前搜過什么這屬于上下文注意力不足只能靠外部記憶來補二是工具返回的結果沒有提供“下一步依據”模型沒有足夠信息判斷該結束了。排查的時候我會先把完整的工具調用序列打出來看模式是不是同一個“工具名參數”組合在重復如果是就是重復檢測沒生效如果工具參數每次都在變但整體沒有進展那就是模型在無意義探索需要給反饋信息加更明確的目標指引。我的解決方案就是在循環(huán)層加重復目標檢測并且把提示寫得具體到“你剛才已經用相同參數搜索過請基于已有結果提出新的搜索關鍵詞或者直接進入報告寫作階段”。好模型的自我修正能力遠超想象很多時候只是缺一句“有人盯著它”的提醒。4.2 上下文爆炸token 被歷史消息吃光循環(huán)跑多了最直接的問題就是歷史消息越來越長。模型每輪都要讀完全部歷史token 消耗隨輪數指數增長而且一旦超出上下文窗口就會報錯。我踩過一次比較嚴重的坑做一個網頁抓取 Agent每輪都把整頁 HTML 塞進歷史跑到第五輪時上下文直接爆了前面的搜索結果全被截斷模型完全失憶。解決辦法是在工具層就做清洗和截斷HTML 轉純文本然后限制最長長度。上下文爆炸不僅僅是技術問題也是成本問題。我建議對工具返回設置一個硬長度上限超過部分直接切掉同時在 System Prompt 里說明“工具結果可能被截斷需要完整信息時請重新搜索更有針對性的關鍵詞”。這樣模型不會因為信息不全而反復抓瞎。4.3 工具輸出格式導致解析失敗模型返回的 tool_calls 不一定永遠規(guī)范尤其在一些開源模型上function arguments 經常不是合法 JSON或者參數名跟工具定義不完全一致。如果放任不管循環(huán)就會在這里卡死。處理方式是在循環(huán)層做一個容錯解析先嘗試標準 json.loads失敗時用一個寬松的解析函數把 key 和 value 用正則提取出來。如果還是失敗不要直接報錯而是把“參數解析失敗”作為工具結果返回給模型讓它自己修復。更隱蔽的問題在于模型把工具名寫錯比如定義的是 web_search它寫成 search_web。發(fā)生這種情況我會在錯誤反饋里附上可用工具列表讓模型自己讀一遍再重新生成。實測下來大部分模型看到自己手里的“菜單”后會立刻糾正。4.4 任務沒完成就提前收尾有些模型在信息明顯不足的情況下寧可輸出一份泛泛而談的報告也不繼續(xù)搜索。這通常是懶惰不是能力不足。我遇到過一個任務讓 Agent 調研某一垂直領域的市場規(guī)模它搜了一次數據來源就寫完了結果報告里全是定性描述一個具體數字都沒有。要解決“提前收尾”我嘗試過幾種辦法。最有效的有兩個一是要求模型在最終報告里包含完整的數據來源如果沒有來源就不允許輸出 REPORT_END 標記二是在循環(huán)層增加一個“完成度校驗”的子模型專門評估最終報告的質量不合格就把評估意見塞回歷史讓模型補做。完成度校驗增加了額外的 LLM 調用但值得。尤其在生產場景里與其讓一份爛報告直接交付給用戶不如多花幾百 token 把質量兜住。當然它對 Prompt 的要求也更高你需要很明確地告訴評估子模型“什么樣的報告算合格”否則它會跟主要模型互相拍馬屁兩人都覺得寫得不錯。下面是幾個高頻問題的速查表我直接把它貼進代碼注釋里遇到問題先對照一遍。癥狀常見原因排查方法處理建議連續(xù)調用同一工具缺重復檢測打印歷史中的工具調用簽名添加重復簽名檢測并反饋給模型上下文越來越長無窗口控制監(jiān)控每輪 token 消耗工具結果截斷 歷史摘要化參數 JSON 解析報錯模型輸出格式不穩(wěn)定打印原始 arguments 字符串容錯解析 向模型回傳錯誤信息未完成就輸出報告缺少完成度標準人工抽查最終報告質量加入完成度校驗子模型輪數超限仍不停止安全閥缺失檢查循環(huán)代碼的 break 條件強制 max_steps 硬上限工具超時導致卡死外部 API 不穩(wěn)定檢查耗時日志給工具調用加超時和異常捕獲4.5 思考式排查法當模型不按規(guī)則出牌怎么辦最后分享一個偏“玄學”但很實用的排查思路當你無法從代碼層面判斷模型行為是否合理時把歷史導出來自己扮演一次模型——也就是所謂的“角色扮演回放”。具體做法是這樣的把某一輪的完整歷史里模型消息和工具返回打印出來人工去看模型在最后一步的選擇假設你是這個模型你會如何決策如果連你自己都覺得信息足夠、應該進入下一階段那說明模型的判斷是合理的問題可能出在終止條件上如果連你自己都覺得信息不足那問題出在工具的數據質量上模型確實沒法從垃圾數據里推理出有價值的東西。這個方法幫我定位過很多詭異的問題比如模型在一輪里突然調用了一個跟任務完全無關的工具回看一下才發(fā)現是前面某條工具結果里的字符誤導了它。紙面上的日志永遠比腦子里模糊的印象可靠。5. 繼續(xù)加碼從單循環(huán)到多循環(huán)的擴展方向前面這套調研報告 Agent 用的還是單循環(huán)結構一個主模型驅動所有決策。但真實世界里的復雜任務往往需要多個循環(huán)配合這也是 Loop Engineering 的核心進階方向。第一個常見的擴展是“規(guī)劃器—執(zhí)行器”雙層循環(huán)。規(guī)劃器模型負責拆解任務、生成執(zhí)行計劃執(zhí)行器模型負責跑具體的工具每完成一個子步驟規(guī)劃器收到結果后重新評估剩余規(guī)劃直到全部結束。這個結構能顯著提升復雜任務的穩(wěn)定性因為規(guī)劃器有全局視角執(zhí)行器可以專心做局部操作。第二個擴展是“子 Agent 循環(huán)”。當工具調用需要上下文隔離時我會為每個子任務單獨開一個循環(huán)讓它們各自維護自己的歷史最后匯總到主循環(huán)。比如調研任務里每個細分領域開一個子 Agent 循環(huán)分別去收集資料主循環(huán)負責合并結果和寫報告。隔離的上下文不僅降低了彼此的干擾也大幅減少了主循環(huán)的 token 消耗。第三個擴展是“記憶循環(huán)”。如果讓 Agent 在多輪任務中記住用戶偏好或歷史決策就需要一個專門的管理循環(huán)來維護長期記憶。每輪決策結束后主循環(huán)把關鍵信息抽取出來寫入記憶庫下一次循環(huán)開始時把記憶加載進來。這個本質上是在循環(huán)外面套了一層“記憶維護循環(huán)”兩者同步運轉。如果你已經有了一定的基礎我特別建議自己先手寫兩三個不同場景的單循環(huán) Agent把狀態(tài)維護和終止條件玩明白然后再去用 LangGraph 這樣的框架?？蚣軒湍闶〉袅舜罅繕影宕a但它也隱藏了循環(huán)內部的很多細節(jié)。做過一遍手寫循環(huán)之后你看到 LangGraph 的 StateGraph 和 conditional edges就會有一種“這不就是我把 if-else 整理成配置”的感覺理解成本瞬間歸零。說到最后聊聊我做 Loop Engineering 的個人體會。它不是一個你調一晚上就能學會的 API而是一種工程思維的轉變別再想著靠某一次完美的 Prompt 讓模型一步到位而是接受“模型會犯錯、會繞路、會自我懷疑”這個事實然后用循環(huán)把這些錯誤變成可修正的中間狀態(tài)。每給循環(huán)加一道“護欄”你其實就在慢慢把一個演示用的 Agent 變成能穩(wěn)定跑業(yè)務的系統(tǒng)。這個過程中最值得投入的地方不是復雜的狀態(tài)機理論而是對真實任務的拆解能力和對日志的敏感度。數據永遠能告訴你答案前提是你讓它在循環(huán)里流動起來。