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