從“能跑通”到“能自愈”智能體開發(fā)真正的分水嶺在哪最近和不少做 Agent 項目的團隊交流大家普遍有一個同感做一個能在演示環(huán)境里跑通的智能體很容易做一個能在生產(chǎn)環(huán)境里穩(wěn)定工作的智能體很難。難的不是調(diào)用大模型也不是寫幾個工具函數(shù)而是讓系統(tǒng)在沒有人盯著的情況下持續(xù)輸出正確結(jié)果并在出錯時自動修正。很多人把問題歸結(jié)為“模型不夠聰明”于是不斷換更強的底座模型。但更常見的原因藏在工程側(cè)你的 Agent 本質(zhì)上是“一次性問答腳本”而不是一個“自主驅(qū)動的閉環(huán)系統(tǒng)”。它沒有對自身輸出的評價能力沒有失敗后的重試策略也沒有把業(yè)務(wù)反饋回流到下一輪決策的通道。換句話說它缺少的是一個貫穿感知、決策、行動、反饋的循環(huán)回路。這正是我想在這篇文章里展開的核心概念循環(huán)工程。它不是某個工具的某個功能而是智能體從 demo 走向生產(chǎn)時需要重新建立的工程思維方式。我會先用通俗的語言講清楚循環(huán)工程和閉環(huán)系統(tǒng)的設(shè)計要點再給出一套可直接運行的 Python 示例演示一個帶自動評估和自動修正的 Agent 閉環(huán)流程最后補充常見坑位和生產(chǎn)落地的工程建議。1. 這篇文章真正要解決的問題如果用一個問題概括這篇文章的主題那就是為什么很多 Agent 只跑一次效果好跑一百次就崩以及怎么把“穩(wěn)定性”設(shè)計進系統(tǒng)里。傳統(tǒng)開發(fā)里我們習慣用“輸入 → 處理 → 輸出”的線性模型思考問題。大多數(shù) Agent demo 也是這樣用戶提問LLM 推理工具返回結(jié)果LLM 匯總輸出。整條鏈路沒有反饋回路系統(tǒng)無法判斷自己“做得好不好”更無法在下一次做得更好。這會導致三類典型問題錯誤會被放大而不是被修正。LLM 第一次調(diào)用生成了一段不夠準確的 SQL系統(tǒng)直接把 SQL 丟給數(shù)據(jù)庫去執(zhí)行報錯了也不重試或者重試時用同一個錯誤上下文繼續(xù)生成大概率還是同樣錯。沒有量化評估手段。你只能說“感覺這個 Agent 還行”但說不清它在 1000 條測試數(shù)據(jù)上的準確率、召回率、失敗率和平均修正次數(shù)。沒有度量就沒有優(yōu)化方向。業(yè)務(wù)反饋無法回流。Agent 在線上建議了錯誤的庫存調(diào)撥業(yè)務(wù)人員手工糾正之后系統(tǒng)毫無感知明天還會犯同樣的錯。循環(huán)工程要解決的就是把單向的“輸入 → 輸出”變成雙向的“輸出 → 評估 → 反饋 → 再輸出”。這聽起來像控制論里的老話題但放到大模型驅(qū)動的智能體時代它有了新的實現(xiàn)方式和新的工程難點。這篇文章最適合三類讀者閱讀正在做 Agent 應(yīng)用開發(fā)但發(fā)現(xiàn)系統(tǒng)在真實場景中不穩(wěn)定的人想從可視化平臺如 Dify、Coze 等轉(zhuǎn)向代碼級控制或想理解平臺內(nèi)部閉環(huán)原理的人負責 AI 應(yīng)用架構(gòu)設(shè)計需要為團隊制定 Agent 工程規(guī)范的工程師。讀完這篇文章你會得到一套判斷標準和一套可落地的代碼骨架而不是一堆浮在表面的趨勢名詞。2. 循環(huán)工程概念、本質(zhì)與定位2.1 什么是循環(huán)工程循環(huán)工程的英文直譯是 Iterative Engineering或者更貼近本文語境的說法是 Loop Engineering。它強調(diào)的不是“寫一個循環(huán)”而是圍繞智能體生命周期建立持續(xù)反饋與自我修正機制的設(shè)計方法。和傳統(tǒng)軟件工程相比循環(huán)工程的核心差異在于傳統(tǒng)軟件的行為是可預期的代碼寫死邏輯測試斷言輸入輸出而智能體的行為是概率性的同樣的提示詞可能產(chǎn)出不完全一樣的結(jié)果同一個工具可能在不同語境下被調(diào)用得對錯不一。因此我們不能再只依賴“上線前測試”必須在運行時建立持續(xù)校準機制。可以把智能體想象成一個剛?cè)肼毜膯T工。傳統(tǒng)軟件是一臺設(shè)定好程序的生產(chǎn)機器而智能體更像一個需要帶教、反饋和復盤的新人。你要給他工作目標觀察他的產(chǎn)出指出問題再讓他重做。循環(huán)工程就是為智能體設(shè)計這套“帶教機制”。2.2 循環(huán)工程、提示詞工程與 Agent 工程的區(qū)別很多人容易把循環(huán)工程和提示詞工程混為一談這里用一個表格做區(qū)分工程類型關(guān)注核心主要手段典型產(chǎn)出提示詞工程讓模型更準確地理解指令編寫和優(yōu)化提示詞更好的單次輸出Agent 工程讓模型學會調(diào)用工具、拆解任務(wù)工具注冊、任務(wù)編排、上下文管理能完成多步任務(wù)的智能體循環(huán)工程讓智能體具備自我評估和自我修正能力評估器、反饋通道、重試策略、記憶更新穩(wěn)定、可演進的生產(chǎn)級智能體提示詞工程解決的是“把話說清楚”Agent 工程解決的是“把任務(wù)拆明白”循環(huán)工程解決的是“把系統(tǒng)做穩(wěn)定”。三者層層遞進缺一不可。很多項目在提示詞工程上下足了功夫也順利接上了工具調(diào)用卻依然不穩(wěn)定大概率是缺了循環(huán)工程這一層。2.3 為什么現(xiàn)在才強調(diào)循環(huán)工程過去兩輪 AI 浪潮里基于規(guī)則的客服機器人也有反饋機制比如用戶點了“不滿意”就轉(zhuǎn)人工。但那時規(guī)則是人工編寫的語義理解能力弱反饋只能做到按鈕級別。大模型出現(xiàn)后智能體擁有了開放式的語言理解和生成能力工具調(diào)用的邊界被大大擴展——它可以寫代碼、查數(shù)據(jù)庫、操作 API、生成文檔。這意味著一個出錯動作的影響范圍遠大于傳統(tǒng)規(guī)則機器人。與此同時模型的概率性輸出特征沒有消失。能力越強可以做錯的事就越多。所以不是循環(huán)工程突然出現(xiàn)了而是智能體的能力邊界擴大之后沒有循環(huán)工程的項目開始大面積失控循環(huán)工程才被迫成為顯性話題。市面上主流的智能體開發(fā)平臺無論是開源的 Dify還是國內(nèi)開發(fā)者常用的 Coze扣子、AgentScope 等本質(zhì)上都在幫開發(fā)者把“模型調(diào)用、工具編排、流程控制”這層做簡單。但平臺越簡單越容易讓人忽略底層其實仍需要“評估與反饋”的設(shè)計。如果不在工作流中顯式加入評測和糾錯節(jié)點可視化拖拽出來的 Agent 同樣會在復雜場景里翻車。3. 自主驅(qū)動閉環(huán)系統(tǒng)的核心模塊理解了循環(huán)工程的概念下面把“自主驅(qū)動的 AI 閉環(huán)系統(tǒng)”拆開看它到底由哪些模塊組成。一個經(jīng)典的閉環(huán)智能體通常包含四個核心模塊3.1 狀態(tài)感知模塊系統(tǒng)要能感知當前環(huán)境的狀態(tài)包括用戶輸入、工具返回結(jié)果、外部系統(tǒng)狀態(tài)、歷史對話記錄等。沒有感知后面的一切決策都是盲目的。實際工程中狀態(tài)感知往往不是簡單地把全部上下文塞進提示詞而是要做篩選和結(jié)構(gòu)化。比如一個客服智能體需要從用戶消息中提取意圖、槽位、情緒傾向一個數(shù)據(jù)分析智能體需要了解當前數(shù)據(jù)庫里有哪些表、表結(jié)構(gòu)是什么、用戶權(quán)限到什么級別。這里容易被忽視的是工具返回狀態(tài)的感知。很多 Agent 調(diào)用外部 API 后完全不檢查 HTTP 狀態(tài)碼和返回體中的錯誤信息直接把結(jié)果扔給 LLM。結(jié)果就是 LLM 一本正經(jīng)地根據(jù)錯誤頁面“編”出一個答案。狀態(tài)感知模塊必須把工具調(diào)用的成功、失敗、超時、部分成功等狀態(tài)顯式地暴露給決策模塊。3.2 決策與行動模塊這是 Agent 的主體負責根據(jù)當前狀態(tài)決定下一步動作。它可能是單次 LLM 調(diào)用也可能是一個多輪任務(wù)規(guī)劃器。在多智能體場景中還涉及任務(wù)的分配與協(xié)作。決策模塊的設(shè)計重點是“動作空間的定義”。所謂動作空間就是系統(tǒng)允許智能體執(zhí)行的所有原子操作比如生成回復、執(zhí)行 SQL、調(diào)用外部 API、讀取本地文件等。動作空間定義得越清晰模型越不容易行為越界。3.3 自動評估模塊評估模塊是閉環(huán)系統(tǒng)和普通 Agent 的最大區(qū)別。它在每次行動完成后對行動結(jié)果進行量化打分并生成修正建議。評估器的實現(xiàn)方式有很多種規(guī)則評估器檢查輸出是否包含某個關(guān)鍵字段、是否超過長度限制、是否通過正則校驗。適合有客觀標準的結(jié)果如 JSON 格式是否正確。模型評估器用一個 LLM 扮演評估者根據(jù)評分標準給輸出打分。適合主觀質(zhì)量評估如文案是否符合品牌語氣。工具評估器通過實際執(zhí)行來驗證結(jié)果。比如生成的 SQL 是否能在測試庫跑通生成的代碼是否通過單測生成的回答是否能被檢索到證據(jù)。人工評估器把結(jié)果推送給人類審核人工裁決。適合高風險場景不追求全自動閉環(huán)。3.4 反饋演進模塊評估產(chǎn)生分數(shù)和修正意見之后系統(tǒng)需要把這些信號回流到?jīng)Q策模塊或記憶模塊。修正意見用于當前這一輪的自我糾錯而長期信號比如某個任務(wù)反復失敗、某類用戶的投訴率升高則需要沉淀到長時記憶或離線訓練數(shù)據(jù)中讓 Agent 在未來的會話中也表現(xiàn)得更好。反饋演進是很多項目做得最薄弱的一環(huán)。大家愿意花錢做實時反饋卻很少沉淀下來形成評測集和樣例庫。而恰恰是這些被沉淀下來的數(shù)據(jù)才是智能體持續(xù)進化的燃料。4. 自主驅(qū)動閉環(huán)系統(tǒng)的架構(gòu)設(shè)計與技術(shù)選型下面從架構(gòu)層面看一個可實現(xiàn)的閉環(huán)系統(tǒng)。我不會綁定某個具體平臺而是給出一個通用分層你在 Dify、Coze 上配置 Agent或者從零用代碼寫 Agent都可以按這個層次來思考。4.1 分層架構(gòu)一個閉環(huán)智能體系統(tǒng)我習慣分為五層接入層負責接收用戶請求處理對話上下文做基礎(chǔ)的輸入校驗和敏感信息過濾。決策層調(diào)用 LLM 進行任務(wù)規(guī)劃決定調(diào)用哪個工具、生成什么內(nèi)容。行動層實際執(zhí)行工具調(diào)用包括函數(shù)插件、API 調(diào)用、數(shù)據(jù)庫操作、代碼執(zhí)行。評估層對行動結(jié)果進行評估輸出質(zhì)量分數(shù)與修正建議。記憶層負責短期上下文、長期記憶、向量檢索庫的讀寫與更新。閉環(huán)的關(guān)鍵在于評估層的輸出要能返回給決策層驅(qū)動下一輪決策。如果評估層只輸出一個分數(shù)卻沒有任何動作那不叫閉環(huán)只叫“監(jiān)控”。4.2 技術(shù)選型的幾個關(guān)鍵選擇工作流編排純代碼Python/TypeScript適合復雜邏輯和高定制需求可視化平臺適合快速驗證和輕量業(yè)務(wù)。兩者并不沖突很多團隊先用可視化平臺搭原型再把核心鏈路遷移到代碼。記憶存儲短上下文直接拼進提示詞長期記憶通常用向量數(shù)據(jù)庫保存每次檢索相關(guān)片段注入上下文。選擇向量庫時除了檢索質(zhì)量還要關(guān)注權(quán)限隔離和元數(shù)據(jù)過濾能力。評估器實現(xiàn)規(guī)則優(yōu)先模型兜底。能用規(guī)則判斷的就不要用模型成本和穩(wěn)定性都更優(yōu)。異步與重試閉環(huán)系統(tǒng)天然需要重試機制。要注意設(shè)置最大重試次數(shù)和超時時間避免在錯誤路徑上無限循環(huán)。4.3 單 Agent 與多 Agent 的閉環(huán)差異單 Agent 閉環(huán)相對簡單一個 LLM 承擔決策一個評估器校驗輸出循環(huán)往復直到滿意或多輪失敗。多 Agent 場景下閉環(huán)邏輯更復雜。每個子 Agent 有自己的輸入輸出子 Agent 之間可能有依賴關(guān)系。此時評估層既要評估每個子 Agent 的產(chǎn)出還要評估整體任務(wù)的完成度。A2AAgent to Agent協(xié)議、消息隊列等基礎(chǔ)設(shè)施會變得更加重要。不過我建議剛開始做閉環(huán)的團隊不要直接上多 Agent先在一個單 Agent 上把閉環(huán)跑通再逐步擴展。5. 完整示例一個帶自動評估與自我修正的閉環(huán)智能體下面進入實踐環(huán)節(jié)。我會用一個最小但完整的 Python 示例演示循環(huán)工程的核心邏輯。場景設(shè)計假設(shè)我們要做一個“周報生成智能體”輸入幾條工作內(nèi)容智能體輸出一段結(jié)構(gòu)化周報。這個場景不復雜但足以展示閉環(huán)的四個模塊。為方便讀者直接運行示例中不依賴真實大模型 API而是用模擬 LLM 和模擬評估器。如果你有 OpenAI 兼容的模型 API可以把對應(yīng)函數(shù)替換為真實調(diào)用。5.1 整體結(jié)構(gòu)loop_engineering_demo/ ├── main.py # 主流程閉環(huán)控制邏輯 ├── evaluator.py # 評估器 ├── llm.py # LLM 接口默認 Mock 實現(xiàn) └── memory.py # 簡單記憶存儲5.2 模擬 LLM 接口# 文件路徑loop_engineering_demo/llm.py class LLMClient: 統(tǒng)一的 LLM 調(diào)用接口。 真實場景中把 generate 方法替換為對 OpenAI / 國內(nèi)大模型 API 的 HTTP 調(diào)用即可。 def __init__(self, max_calls: int 100): self.max_calls max_calls self.call_count 0 def generate(self, system_prompt: str, user_prompt: str) - str: 模擬模型生成。第一次生成缺少關(guān)鍵指標第二次開始會參考評估反饋。 真實接入時這里應(yīng)調(diào)用模型 API response openai.ChatCompletion.create( modelyour-model-name, messages[ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ], ) return response[choices][0][message][content] self.call_count 1 if 看到反饋 in user_prompt: # 模擬模型根據(jù)反饋修正補充缺少的指標 return ( 周報\n 1. 數(shù)據(jù)看板開發(fā)完成用戶活躍度看板包括 DAU 趨勢、留存漏斗。\n 2. 智能體評估模塊完成自動評分器準確率達到 92%。\n 關(guān)鍵指標本周迭代完成度 85%線上問題 0 個。\n ) # 第一次生成缺少關(guān)鍵指標 return ( 周報\n 1. 數(shù)據(jù)看板開發(fā)完成用戶活躍度看板包括 DAU 趨勢、留存漏斗。\n 2. 智能體評估模塊完成自動評分器準確率達到 92%。\n )這個 Mock 實現(xiàn)的關(guān)鍵是第一次生成不包含“關(guān)鍵指標”評估器會判定不合格并把修正建議拼入下一次調(diào)用的 user_prompt 中第二次調(diào)用看到反饋后生成了包含關(guān)鍵指標的完整周報。這樣閉環(huán)流程就能演示出來。5.3 評估器# 文件路徑loop_engineering_demo/evaluator.py from typing import Tuple class Evaluator: 評估器檢查輸出質(zhì)量返回是否通過、分數(shù)、修正建議。 這是閉環(huán)系統(tǒng)里最重要的裁判角色。 REQUIRED_KEYWORDS [關(guān)鍵指標, 周報] MAX_LINES 8 def evaluate(self, output: str) - Tuple[bool, float, str]: score 100.0 suggestions [] # 規(guī)則1必須包含標題“周報” if 周報 not in output: score - 30 suggestions.append(請以“周報”作為標題。) # 規(guī)則2必須包含關(guān)鍵指標 if 關(guān)鍵指標 not in output: score - 40 suggestions.append(請補充本周關(guān)鍵指標例如迭代完成度、線上問題數(shù)、性能數(shù)據(jù)。) # 規(guī)則3行數(shù)不能過長 lines output.strip().splitlines() if len(lines) self.MAX_LINES: score - 10 suggestions.append(f請精簡內(nèi)容控制在 {self.MAX_LINES} 行以內(nèi)。) passed score 80 correction ; .join(suggestions) if suggestions else return passed, score, correction評估器用了最簡單的規(guī)則邏輯包含三個硬性檢查項。真實場景中這里的規(guī)則可以換成模型評估器讓 LLM 按 5 個維度打分并輸出 json 格式的修正建議。5.4 閉環(huán)主流程# 文件路徑loop_engineering_demo/main.py from evaluator import Evaluator from llm import LLMClient def run_closed_loop(max_attempts: int 3): 閉環(huán)主流程 1. 根據(jù)原始輸入生成內(nèi)容 2. 評估器打分 3. 不達標則把修正建議反饋給模型重新生成 4. 達到最大嘗試次數(shù)后停止返回最終結(jié)果 client LLMClient() evaluator Evaluator() system_prompt 你是一名研發(fā)團隊負責人請根據(jù)工作內(nèi)容生成一段簡潔的周報。 user_prompt ( 本周完成的工作有\(zhòng)n - 數(shù)據(jù)看板開發(fā)\n - 智能體評估模塊\n ) attempts [] final_output final_passed False for attempt in range(1, max_attempts 1): print(f 第 {attempt} 次生成 ) output client.generate(system_prompt, user_prompt) passed, score, correction evaluator.evaluate(output) record { attempt: attempt, output: output, score: score, passed: passed, correction: correction, } attempts.append(record) print(f輸出內(nèi)容\n{output}) print(f評估得分{score}) print(f是否通過{passed}) if correction: print(f修正建議{correction}) if passed: final_output output final_passed True print(評估通過閉環(huán)結(jié)束。) break # 不通過把修正建議拼入下一輪生成指令形成閉環(huán) user_prompt ( user_prompt f\n\n上一版本的評估結(jié)果得分 {score}修正建議{correction}\n 看到反饋后請重新生成一版周報。 ) else: final_output attempts[-1][output] final_passed False print(f已嘗試 {max_attempts} 次仍未通過結(jié)束閉環(huán)。) return { final_output: final_output, final_passed: final_passed, attempts: attempts, model_call_count: client.call_count, } if __name__ __main__: result run_closed_loop(max_attempts3) print(\n########## 閉環(huán)運行摘要 ##########) print(f模型總調(diào)用次數(shù){result[model_call_count]}) print(f最終是否通過評估{result[final_passed]}) for record in result[attempts]: print(f第 {record[attempt]} 次得分{record[score]})5.5 真實模型接入片段上面的 Mock 實現(xiàn)用于本地演示邏輯。真實場景中你需要把LLMClient.generate替換為模型 API 調(diào)用。下面是一個兼容 OpenAI 接口的調(diào)用示例注意這里只是片段完整代碼屬于你的項目# 文件路徑你的項目中替換 llm.py 的 generate 方法 import os import openai client openai.OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL), # 例如國內(nèi)模型服務(wù)商提供的 OpenAI 兼容地址 ) def generate(self, system_prompt: str, user_prompt: str) - str: resp client.chat.completions.create( modelos.getenv(LLM_MODEL_NAME), messages[ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ], temperature0.7, ) return resp.choices[0].message.content6. 運行結(jié)果與效果驗證6.1 運行方式在loop_engineering_demo目錄下執(zhí)行python main.py6.2 預期輸出正常情況下你會看到類似下面的日志 第 1 次生成 輸出內(nèi)容 周報 1. 數(shù)據(jù)看板開發(fā)完成用戶活躍度看板包括 DAU 趨勢、留存漏斗。 2. 智能體評估模塊完成自動評分器準確率達到 92%。 評估得分60.0 是否通過False 修正建議請補充本周關(guān)鍵指標例如迭代完成度、線上問題數(shù)、性能數(shù)據(jù)。 第 2 次生成 輸出內(nèi)容 周報 1. 數(shù)據(jù)看板開發(fā)完成用戶活躍度看板包括 DAU 趨勢、留存漏斗。 2. 智能體評估模塊完成自動評分器準確率達到 92%。 關(guān)鍵指標本周迭代完成度 85%線上問題 0 個。 評估得分100.0 是否通過True 評估通過閉環(huán)結(jié)束。 ########## 閉環(huán)運行摘要 ########## 模型總調(diào)用次數(shù)2 最終是否通過評估True 第 1 次得分60.0 第 2 次得分100.06.3 如何判斷閉環(huán)生效判斷閉環(huán)系統(tǒng)是否真正工作有三個標準第一次失敗后是否產(chǎn)生了有效的修正指令。修正指令必須具體、可執(zhí)行而不是“請優(yōu)化一下”。示例中“請補充本周關(guān)鍵指標”是具體的第二次生成的輸出是否解決了修正指令提出的問題。如果模型看到反饋后仍輸出同樣內(nèi)容說明反饋鏈路斷了運行摘要里的軌跡信息是否完整。每輪嘗試的得分、修正建議、最終結(jié)果都應(yīng)被記錄方便事后分析。如果你把示例中evaluator.py里的score 80改成score 100并且把max_attempts調(diào)成 1會看到閉環(huán)在第一次失敗后直接停止。這個對比能幫你直觀理解“重試次數(shù)”和“評估門檻”對閉環(huán)效果的影響。7. 常見問題與排查方法閉環(huán)系統(tǒng)雖然原理不復雜但在實際項目中踩坑的點非常多。下面列幾個最典型的問題。問題現(xiàn)象可能原因排查方式解決方案模型反復重試卻一直在同一個問題上失敗修正建議不夠具體或評估器在鉆規(guī)則空子打印每一輪的修正建議看是否每次都一樣細化修正建議增加示例性反饋如果同一問題出現(xiàn) 2 次以上考慮切換到人工介入評估器給模型打分很高但人工看質(zhì)量很差評估器規(guī)則過于簡單或模型評估器被“自圓其說”帶偏隨機抽 20 條高分輸出做人工復核統(tǒng)計偏差增加規(guī)則檢查項模型評估器采用獨立提示詞并要求先引用原文再打分工具調(diào)用報錯但 Agent 沒感知繼續(xù)胡說工具異常信息沒有結(jié)構(gòu)化回傳給 LLM查看工具調(diào)用日志確認錯誤信息是否進入 prompts在工具調(diào)用層捕獲異常統(tǒng)一改寫為“工具失敗 原因摘要 可選重試”閉環(huán)日志太長根本無法定位問題每輪都把完整上下文塞給模型日志沒有分層檢查日志記錄結(jié)構(gòu)按 attempt_id 記錄輸入、輸出、評估結(jié)果輸出關(guān)鍵指標用結(jié)構(gòu)化字段而非純文本重試次數(shù)多導致成本飆升沒有控制最大重試次數(shù)且每次重試都全量調(diào)用大模型查看模型調(diào)用計費和調(diào)用日志設(shè)置max_attempts對簡單校驗流程使用規(guī)則評估器不必每次都調(diào)大模型系統(tǒng)在評估器認為成功后仍然產(chǎn)生劣質(zhì)業(yè)務(wù)結(jié)果評估器只評“文本質(zhì)量”沒有評“業(yè)務(wù)效果”檢查線上指標與評估分數(shù)的相關(guān)性引入業(yè)務(wù)結(jié)果反饋例如用戶點擊率、人工糾錯率、工單是否解決這里要特別強調(diào)一個問題評估器和模型用同一個大模型容易產(chǎn)生“自己評自己”的偏差。如果主模型和評估模型是同一個主模型生成的錯誤會被評估模型以同樣的知識偏見放過。更穩(wěn)妥的做法是使用不同的模型做評估或者使用“規(guī)則 模型”混合評估器。8. 最佳實踐與工程建議8.1 先定義成功標準再寫 Agent 邏輯很多團隊先寫代碼后補評估這是本末倒置。正確順序是明確 Agent 在什么場景下算是“完成得好”把好結(jié)果量化成可檢查的指標再開始寫 Agent 的決策邏輯。以周報生成為例好結(jié)果的定義是包含本周工作、包含關(guān)鍵指標、不超長、語氣簡潔。把這個定義翻譯成規(guī)則就是示例中evaluator.py里的三個檢查項。8.2 規(guī)則優(yōu)先模型兜底能用規(guī)則判斷的不要用模型。規(guī)則的優(yōu)點是穩(wěn)定、便宜、可解釋。只有當規(guī)則無法覆蓋開放性問題時才引入模型評估器。比如 SQL 是否正確直接去測試庫執(zhí)行最可靠回答是否專業(yè)才需要模型評估。8.3 設(shè)置控制參數(shù)避免閉環(huán)失控自主驅(qū)動不等于無限循環(huán)。生產(chǎn)環(huán)境中必須設(shè)置硬性邊界# 文件路徑config.yaml loop: max_attempts: 3 # 最大生成嘗試次數(shù) timeout_seconds: 60 # 單次循環(huán)超時 escalation_after_fail: true # 失敗后是否轉(zhuǎn)人工這樣即使模型一直不達標系統(tǒng)也會在規(guī)定次數(shù)后停止并把任務(wù)轉(zhuǎn)交給人工處理而不是無限燒錢。8.4 為每一步留下溯源日志閉環(huán)系統(tǒng)的可觀測性比傳統(tǒng)系統(tǒng)更重要因為每一次輸出都疊加了模型的不確定性。建議為每輪嘗試記錄以下字段attempt_id、task_idprompt 版本號模型名稱和參數(shù)生成內(nèi)容摘要評估器類型、評估分數(shù)、修正建議循環(huán)終止原因通過、超時或達到最大次數(shù)記錄這些日志不僅用于排錯也是后續(xù)建設(shè)評測集的素材。8.5 沉淀評測集與回歸測試和傳統(tǒng)軟件有單元測試一樣智能體也需要回歸測試。每次修復一個 bug都應(yīng)該往評測集里加入一條對應(yīng)的用例。評測集應(yīng)該包含正常輸入happy path邊界輸入空輸入、超長輸入、多語言混合對抗輸入誘導性提示、越權(quán)請求歷史失敗用例每次修改 Agent 邏輯后跑一遍評測集對比綜合通過率和平均修正次數(shù)以此量化“改進是否帶來了真正的提升”。8.6 關(guān)于可視化平臺與代碼實現(xiàn)的取舍Dify、Coze 等平臺可以幫助你快速搭建帶工具調(diào)用和工作流節(jié)點的 Agent它們內(nèi)置了一些循環(huán)能力比如條件分支、重試節(jié)點。對于驗證業(yè)務(wù)邏輯平臺足夠高效。但平臺上對評估器的定制能力、對循環(huán)控制細粒度的掌控通常不如代碼靈活。我的建議是分階段走先用可視化平臺把業(yè)務(wù)閉環(huán)跑通驗證“循環(huán)設(shè)計是否合理”再根據(jù)業(yè)務(wù)復雜度決定是否遷移到代碼實現(xiàn)。關(guān)鍵是無論用什么平臺你都要清楚自己的評估器是什么、反饋信號是什么、終止條件是什么。這些是平臺給不了你的。8.7 安全與權(quán)限邊界閉環(huán)系統(tǒng)擁有“自主行動”和“反復重試”的能力這意味著它造成錯誤影響的可能性比普通 Agent 更大。生產(chǎn)環(huán)境必須遵循最小權(quán)限原則數(shù)據(jù)庫賬號只授予所需表的 SELECT 權(quán)限必要時單獨為 Agent 建立只讀賬號涉及寫操作、刪除操作、資金操作等高風險行為必須設(shè)置為人工審批后再執(zhí)行工具調(diào)用全部要記錄操作人、操作內(nèi)容、時間戳便于審計追蹤。如果 Agent 的閉環(huán)過程中包含數(shù)據(jù)庫寫操作強烈建議先在測試環(huán)境驗證、配置自動備份與回滾方案再考慮灰度上線。不要一開始就讓生產(chǎn)庫暴露在自主循環(huán)的決策空間里。9. 總結(jié)與后續(xù)學習方向這篇文章想傳達的核心判斷是智能體的生產(chǎn)級能力不只看模型有多聰明更看系統(tǒng)有沒有建立“輸出 → 評估 → 反饋 → 調(diào)整”的循環(huán)回路。你可以將其視為“循環(huán)工程”。它和提示詞工程、Agent 工程不是替代關(guān)系而是在它們之上補上了“穩(wěn)定性和演進能力”這一層。值得記住的三個要點閉環(huán)的設(shè)計從評估器開始而不是從模型調(diào)用開始。先想清楚什么算“好”再討論怎么生成閉環(huán)必須設(shè)置邊界。最大重試次數(shù)、超時、人工介入、權(quán)限隔離是生產(chǎn)級系統(tǒng)的標配閉環(huán)產(chǎn)生的數(shù)據(jù)要沉淀下來它們是評測集和記憶系統(tǒng)的源頭。下一步你可以沿著這幾個方向繼續(xù)深入把示例中的規(guī)則評估器替換成模型評估器實現(xiàn)一個基于評分標準的多維度打分器在閉環(huán)流程中加入向量記憶讓 Agent 在做同類任務(wù)時參考歷史成功案例嘗試多智能體協(xié)作使用 A2A 協(xié)議或消息隊列組織多個子 Agent并為整體任務(wù)增加評估層建設(shè)一個智能體評測集把線上失敗樣例持續(xù)回流形成 Agent 的回歸測試體系。如果這篇文章對你有所啟發(fā)建議先花一晚上把這個最小閉環(huán)示例跑通再修改評估規(guī)則換成你自己的業(yè)務(wù)場景。親手調(diào)一遍理解會遠比讀文章深刻。技術(shù)上真正重要的事往往不是某個炫酷模型而是把系統(tǒng)做得穩(wěn)定、可觀測、可演進的那部分工程。