前一段時間在調(diào)一個“多步驟自主任務(wù)”的系統(tǒng)時遇到了一個特別典型的困境提示詞本身看起來沒問題工具調(diào)用鏈也拆得足夠細(xì)可一旦讓 Agent 自主跑完整個長周期流程最后的結(jié)果仍然會在中途某個環(huán)節(jié)悄悄偏掉。單獨看每一步都對連起來卻經(jīng)常返工而且每次失敗的原因都不同。后來把注意力從“模型指令”上挪開轉(zhuǎn)向設(shè)計層的優(yōu)化方式整個問題才逐漸清晰起來。這篇文章會圍繞 Long-Horizon Agentic Design 的工程實現(xiàn)展開講解如何用 Meta-Harness 的思路去系統(tǒng)化地優(yōu)化長周期 Agent 任務(wù)編排并給出一個可運行的閉環(huán)優(yōu)化案例。適合閱讀本文的讀者包括正在做 Agent 工作流編排的算法工程師、想給 LLM 應(yīng)用引入自評價與回滾機制的開發(fā)者以及研究 Agent 系統(tǒng)評測與自動優(yōu)化的同學(xué)。讀完你會理解 Agentic Design 的復(fù)雜度來源掌握 Harness 層與 Meta 層的分工并能動手實現(xiàn)一個最簡單的“采樣—評估—修正”優(yōu)化閉環(huán)。1. 背景為什么“長周期 Agent”這么難設(shè)計1.1 先理解 Long-Horizon 任務(wù)的問題本質(zhì)我們平時調(diào)用一次模型接口通常只需要一輪問題與回答模型直接輸出一個答案即可。但在很多真實業(yè)務(wù)里任務(wù)并不是“問一句就結(jié)束”而是需要多個工具、多次推理、多次結(jié)果確認(rèn)才能完成整個流程。比如讓 Agent 從一份線上配置中心拉取規(guī)則再根據(jù)規(guī)則去數(shù)據(jù)庫查詢多個維度的指標(biāo)最后生成一段修復(fù)建議。讓 Agent 自主完成測試代碼生成、本地執(zhí)行、失敗日志分析、再修復(fù)、再回歸的完整循環(huán)。讓 Agent 從幾十份文檔中提取數(shù)據(jù)再按統(tǒng)一模板生成結(jié)構(gòu)化報表并完成校驗。這類任務(wù)就是 Long-Horizon Task。它的持續(xù)時間長、中間步驟多、狀態(tài)空間大而且每一輪的輸出都會影響后續(xù)步驟的輸入。一個形象的比喻是寫一句帶 Prompt 的對話像是打一桿臺球目標(biāo)明確、距離短而讓 Agent 跑通一個長周期任務(wù)則像布置一條自動化流水線任何一環(huán)的設(shè)計不合理都會在后面的環(huán)節(jié)放大成不可控的問題。1.2 Agentic Design 不是一個“寫提示詞”的問題很多同學(xué)第一次接觸 Agentic Design 時會下意識把它等價成“如何寫出一個好 Prompt”。這種理解不能算錯但遠(yuǎn)遠(yuǎn)不夠完整。真正落地的 Agent 系統(tǒng)里設(shè)計對象包含至少四塊系統(tǒng)提示詞給模型定義角色、目標(biāo)、約束的輸出文本。工具接口定義模型能看到哪些工具、工具參數(shù)如何描述、哪些信息不能暴露。任務(wù)編排邏輯模型在什么條件下調(diào)用工具、什么條件下停止、什么條件下進行反思。結(jié)果評估機制如何判斷當(dāng)前狀態(tài)是成功、失敗、還是需要繼續(xù)做。這四塊合在一起才是 Agent 的“行為空間”。AutoDesign 這種思路本質(zhì)上就是把 Agentic Design 視作一個可以被優(yōu)化的連續(xù)過程——它不滿足于“人工寫一版提示詞”而是希望能在多次任務(wù)執(zhí)行過程中自動發(fā)現(xiàn)更優(yōu)的行為編排方案。1.3 Agent、Harness、Meta 三層各自的角色初次看到 “Meta-Harness Optimization” 這個詞很容易被術(shù)語嚇住。我們把英文直接拆開看Harness 在工程領(lǐng)域通常指“裝配、編排、約束裝置”放在 Agent 語境下可以理解為一套用來控制 Agent 運行方式的支架Meta 表示“關(guān)于自身”的層面。所以 Meta-Harness Optimization 的含義是不直接去調(diào)整大模型內(nèi)部的權(quán)重而是在運行層之上再去設(shè)計一套機制用于持續(xù)優(yōu)化 Agent 任務(wù)背后的控制策略。為了方便理解可以畫下面這個粗糙的分層表層級解決問題典型可控對象模型層單次輸入能生成多好的文本預(yù)訓(xùn)練權(quán)重、微調(diào)數(shù)據(jù)、推理參數(shù)Harness 層多個步驟之間能否穩(wěn)定完成編排提示詞模板、工具 Schema、狀態(tài)回調(diào)邏輯、斷點機制Meta 層如何根據(jù)歷史效果反推并修改 Harness 層配置自動評估器、候選生成器、策略更新邏輯核心結(jié)論是如果你想讓長周期 Agent 在無人看守的情況下保持穩(wěn)定光在模型層使勁是不夠的真正需要持續(xù)迭代的是 Harness 層而驅(qū)動迭代的正是 Meta 層。AutoDesign 研究中提到的 Meta-Harness Optimization就是希望把這一整套流程形式化讓原來靠直覺試錯的編排方式變成可采樣、可比較、可自動收斂的方法。2. 核心方法剖析Meta-Harness Optimization 的四個維度2.1 把完整流程拆成可觀測的“狀態(tài)片段”為什么人工設(shè)計長周期任務(wù)這么困難因為 Long-Horizon 任務(wù)的反饋信號非常稀疏。很多時候Agent 在前 30 步做得都很好最后一步才失敗或者前 20 步里面有一個隱形偏差直到第 40 步才徹底暴露。這種長鏈路很難定位問題。Harness 設(shè)計的前提就是讓 Agent 的執(zhí)行過程具備“可觀測性”。具體做法是在每一步之間都建立一個結(jié)構(gòu)化的狀態(tài)封裝。比如工具調(diào)用返回后Agent 先不直接繼續(xù)生成而是先進入一個狀態(tài)更新器把當(dāng)前回合的目標(biāo)、執(zhí)行結(jié)果摘要、已有結(jié)論、尚未解決的問題保存成一個快照。正是這個快照讓后續(xù)的 Meta 層能夠拿到大量軌跡樣本來做分析。否則拿到的只是零散的日志文本很難進行統(tǒng)一化比較。2.2 三種 Harness 可調(diào)參數(shù)形態(tài)Meta 層要優(yōu)化的是 Agent 的執(zhí)行配置下文統(tǒng)一稱這些配置為 Harness 配置。在工程落地時常見的可調(diào)對象可以按類型分成三類第一類是離散型選擇參數(shù)。例如 Agent 最大迭代輪數(shù)、工具超時時間、完成后是否執(zhí)行總結(jié)、錯誤時是否自動重試。這類參數(shù)不連續(xù)適合用網(wǎng)格搜索或離散差分處理。第二類是模板型參數(shù)。例如系統(tǒng)提示詞里的某段任務(wù)分解引導(dǎo)語可能會存在多個候選版本。我們無法直接對自然語言求梯度但可以通過采樣和效果評估來選出更優(yōu)的候選。第三類是數(shù)值型參數(shù)。例如“當(dāng)工具結(jié)果置信度低于多少時觸發(fā)人工確認(rèn)”“每一步最多允許失敗幾次”等。這類參數(shù)可以通過隨機搜索或貝葉斯優(yōu)化來逼近更優(yōu)區(qū)間。Harness 優(yōu)化的目標(biāo)函數(shù)不一定是單一指標(biāo)。對于不同的業(yè)務(wù)場景可能是完成率、平均輪數(shù)、成本開銷、用戶滿意度等。通常需要把多個指標(biāo)加權(quán)成一個回報函數(shù)作為 meta 層決策的依據(jù)。2.3 Meta-Harness 優(yōu)化的通用閉環(huán)一個通用性很強的優(yōu)化閉環(huán)可以概括成四步。第一步初始化候選池第二部并行執(zhí)行長周期任務(wù)采樣并記錄過程軌跡第三步用離線評估器給結(jié)果打分第四步根據(jù)分?jǐn)?shù)決定下一輪配置候選。以下是這個閉環(huán)的流程描述準(zhǔn)備一組初始 Harness 配置。每個配置在多個測試任務(wù)上獨立運行得到任務(wù)軌跡。對軌跡統(tǒng)一執(zhí)行步驟級和結(jié)果級評估。根據(jù)評估反饋對配置執(zhí)行參數(shù)修改、模板重組或隨機變異。進入下一輪直到效果收斂或預(yù)算耗盡。2.4 長周期任務(wù)中最需要避免的問題在實際跑過幾個長周期案例之后會發(fā)現(xiàn)有幾類問題是長周期任務(wù)特有的也是設(shè)計階段必須想清楚的。第一個很常見的問題是累積偏差。單步執(zhí)行準(zhǔn)確率是 98%連續(xù)十步真的成功率只有 82% 左右如果關(guān)鍵判斷缺乏校驗鏈條越長越容易斷。要解決這個問題除了提高每步的提示質(zhì)量更重要的是設(shè)計檢查點。檢查點不是讓人去看日志而是讓 Agent 在執(zhí)行關(guān)鍵動作前主動核對上中游結(jié)果的一致性。第二個問題是上下文污染。任務(wù)進行到中期時上下文里可能堆積大量中間輸出。這些輸出里可能包含相互矛盾的舊假設(shè)模型很容易被干擾。好的設(shè)計應(yīng)該裁剪歷史避免把垃圾信息一直帶到最后。第三個問題是獎勵信號模糊。長周期任務(wù)很難在每個步驟都獲得高質(zhì)量標(biāo)記如果只拿最終結(jié)果來反饋容易導(dǎo)致優(yōu)化策略只能看見最后一步的問題。因此實踐中必須引入過程評估機制或結(jié)構(gòu)約束把稀疏反饋折算成密反饋。3. 環(huán)境準(zhǔn)備與實驗樣例設(shè)計3.1 從論文概念轉(zhuǎn)向可實現(xiàn)的最小系統(tǒng)既然標(biāo)題中有 AutoDesign我們自然會思考它能否落地成一個實際的工程組件。本文接下來的實戰(zhàn)部分并不打算復(fù)現(xiàn)某個具體研究團隊的完整系統(tǒng)因為那需要大量算力和生產(chǎn)數(shù)據(jù)。這里會把關(guān)鍵思想提取出來實現(xiàn)一個極簡但是可以充分理解原理的“Meta-Harness 優(yōu)化演示環(huán)境”。這個演示環(huán)境里我們會用一個模擬函數(shù)扮演 LLM工具鏈的長周期執(zhí)行器。雖然調(diào)用關(guān)系是模擬的但你會清楚看到配置參數(shù)如何影響軌跡、如何采樣多輪結(jié)果、如何對軌跡打分、如何根據(jù)歷史反饋生成下一輪改進。把這個框子替換成真實模型調(diào)用后核心邏輯可以無縫遷移。3.2 運行環(huán)境與依賴說明建議使用 Python 3.9 或以上版本直接使用標(biāo)準(zhǔn)庫加 PyYAML不需要任何重量級機器學(xué)習(xí)框架。python -m venv venv source venv/bin/activate pip install pyyaml如果你的環(huán)境中尚未安裝 PyYAML執(zhí)行上面的最后一行即可。也可以采用最簡模式直接用 JSON 文件保存配置不安裝任何第三方庫但為了配置可讀性這里統(tǒng)一采用 YAML。3.3 項目目錄設(shè)計以下目錄結(jié)構(gòu)適合作為工程起點meta_harness_demo/ ├── configs/ │ ├── base_config.yaml │ └── candidate_pool.yaml ├── meta_harness/ │ ├── __init__.py │ ├── executor.py │ ├── evaluator.py │ ├── optimizer.py │ └── utils.py ├── run_experiment.py └── README.md其中有幾個文件需要特別說明executor.py執(zhí)行一個 Harness 配置在單個任務(wù)上的完整軌跡。evaluator.py把執(zhí)行軌跡轉(zhuǎn)成量化分?jǐn)?shù)。optimizer.py根據(jù)歷史采樣結(jié)果生成下一輪候選配置。run_experiment.py編排整個閉環(huán)循環(huán)。4. 完整實戰(zhàn)一個最小化的 AutoDesign 閉環(huán)4.1 用配置定義 Harness 的可調(diào)區(qū)間先創(chuàng)建基礎(chǔ)配置。這個文件描述的是一個長周期邏輯任務(wù)的基礎(chǔ)狀態(tài)包括執(zhí)行路徑、超時輪次、反思開關(guān)、隨機種子范圍。# 文件路徑configs/base_config.yaml harness: max_steps: 12 timeout_seconds: 8 enable_reflection: true context_trim_threshold: 4000 tool_call_retry: 2 optimization: population_size: 6 num_rounds: 3 replicate_per_config: 2 evaluation: success_weight: 1.0 step_penalty: 0.1 consistency_weight: 0.5下面解釋一下這些配置項的含義max_steps單個任務(wù)最多允許 Agent 執(zhí)行多少步超過直接判定失敗。enable_reflection是否在每兩步后要求模型進行一次自我校驗。context_trim_threshold上下文超過這個字符量時進行歷史裁剪。tool_call_retry工具調(diào)用失敗時允許重試的次數(shù)。population_size每輪并行評估多少組配置。replicate_per_config同樣的配置跑幾次取平均分用來降低隨機性。success_weight、step_penalty、consistency_weight評分函數(shù)里的三項權(quán)重讀者在真實項目里要根據(jù)業(yè)務(wù)目標(biāo)改動。這里要注意評分權(quán)重本身就是 Harness 空間的一個維度。如果你希望 Agent 更節(jié)省成本可以把 step_penalty 調(diào)高如果只在意最終成功那么 success_weight 占比可以更大。4.2 執(zhí)行器模擬帶噪聲的長周期任務(wù)軌跡executor.py 是整個項目里的核心執(zhí)行模塊。為了避開真實第三方依賴我們用一組內(nèi)置函數(shù)模擬“任務(wù)步驟”。每個模擬步驟的代碼邏輯固定但由于引入隨機噪聲和配置影響同一配置跑多次會得到不同結(jié)果。# 文件路徑meta_harness/executor.py import random import time from dataclasses import dataclass, field dataclass class StepRecord: step_index: int status: str info: str score: float 0.0 dataclass class Trajectory: config: dict task_id: str steps: list field(default_factorylist) total_reward: float 0.0 success: bool False step_count: int 0這里定義了兩個基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)。StepRecord 記錄單步狀態(tài)Trajectory 則記錄一整個配置在一次任務(wù)上的執(zhí)行軌跡。下面實現(xiàn)一個模擬執(zhí)行核心函數(shù)。# 文件路徑meta_harness/executor.py追加 def _simulate_step(task_id: str, step_index: int, config: dict) - StepRecord: 模擬執(zhí)行一個任務(wù)步驟。 實際項目中這一步往往是一次 LLM 調(diào)用可能會調(diào)用外部工具。 這里用一個隨機噪聲模型代替執(zhí)行效果。 max_steps config[harness][max_steps] reflection_on config[harness][enable_reflection] retry_times config[harness][tool_call_retry] # 隨著步數(shù)增加任務(wù)難度逐漸上升 difficulty (step_index 1) / max_steps base_success_prob 0.93 - difficulty * 0.12 # 開啟反思會增加微小的時間開銷但能提升步驟成功率 if reflection_on: base_success_prob 0.03 # 隨機噪聲 p random.random() if p base_success_prob: if p 0.96 and retry_times 1: return StepRecord( step_indexstep_index, statusretry, info首次失敗觸發(fā)重試機制, score0.4, ) return StepRecord( step_indexstep_index, statusfailed, info步驟執(zhí)行失敗, score0.0, ) # 模擬一部分中間狀態(tài)不一致的情況 consistency_penalty 0.0 if random.random() 0.08: consistency_penalty 0.2 return StepRecord( step_indexstep_index, statussuccess, info步驟執(zhí)行成功, score1.0 - consistency_penalty, )這段模擬函數(shù)雖然很簡單但它真實反映了長周期任務(wù)的幾個典型特點越往后越難也就是 difficulty 逐漸上升。失敗可能觸發(fā)重試但與直接失敗相比有代價。成功不是二元狀態(tài)可能包含中間一致性損耗。接下來實現(xiàn) execute_trajectory 函數(shù)# 文件路徑meta_harness/executor.py追加 def execute_trajectory(config: dict, task_id: str, seed: int 0) - Trajectory: 執(zhí)行一次完整的長周期軌跡。 random.seed(seed) max_steps config[harness][max_steps] timeout config[harness][timeout_seconds] trajectory Trajectory(configconfig, task_idtask_id) reflection_on config[harness][enable_reflection] start_time time.time() for step_idx in range(1, max_steps 1): # 模擬每次調(diào)用的耗時 time.sleep(0.005) elapsed time.time() - start_time if elapsed timeout: trajectory.steps.append( StepRecord(step_indexstep_idx, statustimeout, info步驟超時) ) break record _simulate_step(task_id, step_idx, config) trajectory.steps.append(record) # 反思機制會額外產(chǎn)生一步校驗這里用狀態(tài)標(biāo)記體現(xiàn) if reflection_on and step_idx % 2 0 and record.status ! failed: trajectory.steps.append( StepRecord( step_indexstep_idx 100, statusreflection, infoAgent 進行自我校驗, score0.15 if random.random() 0.85 else 0.0, ) ) if record.status success: trajectory.success True elif record.status failed: trajectory.success False break trajectory.step_count len(trajectory.steps) return trajectory這個函數(shù)有幾個細(xì)節(jié)值得展開講。timeout 是模擬網(wǎng)絡(luò)調(diào)用超時在實際系統(tǒng)中經(jīng)常被忽略但一旦任務(wù)鏈變長單步超時就會導(dǎo)致整體失敗。反思機制被表示成每隔兩步插入一條 reflection 記錄這些記錄也會被算入總分中開啟后會讓軌跡步驟變長但可能帶來更高的成功概率。4.3 評估器把軌跡轉(zhuǎn)換為可比較得分executor 只產(chǎn)生原始軌跡真正驅(qū)動優(yōu)化的是評估器。評分規(guī)則設(shè)計如下成功結(jié)果給予 success_weight 對應(yīng)的正向得分。每執(zhí)行一步扣除 step_penalty體現(xiàn)成本與延遲損失。軌跡中出現(xiàn) retry 扣分failed 或 timeout 則直接判負(fù)并記錄失敗原因。reflection 記錄若被判定為校驗失敗則計入一致性損失。把評估邏輯封裝成函數(shù)# 文件路徑meta_harness/evaluator.py from meta_harness.executor import Trajectory def evaluate_trajectory(weight_config: dict, trajectory: Trajectory) - dict: 對一條軌跡進行量化評分。 success_weight weight_config[evaluation][success_weight] step_penalty weight_config[evaluation][step_penalty] consistency_weight weight_config[evaluation][consistency_weight] final_score 0.0 success trajectory.success consistency_loss 0.0 if success: final_score success_weight for step in trajectory.steps: final_score - step_penalty if step.status retry: final_score - 0.2 elif step.status timeout: final_score - 0.5 elif step.status reflection: final_score 0.02 * step.score if step.score 0.5: consistency_loss consistency_weight * 0.1 elif step.status success: final_score 0.05 * step.score final_score - consistency_loss return { task_id: trajectory.task_id, success: success, step_count: trajectory.step_count, score: round(final_score, 4), success_weight_used: success, }很多剛做 Agent 評估的同學(xué)會習(xí)慣只用 success 字段做 0/1 判斷這是不夠的。Long-Horizon 任務(wù)里一個任務(wù)跑了 8 步成功和一個任務(wù)跑了 30 步但最終成功用戶體驗差異巨大前者顯著更穩(wěn)、成本更低。所以評估一定要納入步驟成本。真實系統(tǒng)如果要更細(xì)還建議記錄 token 消耗、工具調(diào)用成功率、平均單步延遲。為了避免單次隨機性影響判斷實現(xiàn)一個批量評估函數(shù)# 文件路徑meta_harness/evaluator.py追加 def evaluate_config_with_replicates( weight_config: dict, trajectory_list: list, ) - dict: 對某個配置多次執(zhí)行結(jié)果做聚合平均。 total_score 0.0 success_count 0 total_steps 0 for traj in trajectory_list: result evaluate_trajectory(weight_config, traj) total_score result[score] total_steps result[step_count] if result[success]: success_count 1 n len(trajectory_list) return { avg_score: round(total_score / n, 4), success_rate: round(success_count / n, 4), avg_step_count: round(total_steps / n, 2), trajectory_count: n, }4.4 優(yōu)化器實現(xiàn)最簡單的變異—選擇策略Meta-Harness Optimization 的算法不唯一。本文演示最簡單且有效的離散優(yōu)化方式隨機變異 精英保留。這種策略在配置搜索空間不大、單輪采樣成本較高時非常實用。# 文件路徑meta_harness/optimizer.py import random def mutate_config(config: dict, mutation_rate: float 0.3) - dict: 對配置進行隨機變異產(chǎn)生新候選。 new_config { harness: dict(config[harness]), optimization: dict(config[optimization]), evaluation: dict(config[evaluation]), } if random.random() mutation_rate: new_config[harness][max_steps] max(5, new_config[harness][max_steps] random.choice([-2, -1, 1, 2])) if random.random() mutation_rate: new_config[harness][enable_reflection] not new_config[harness][enable_reflection] if random.random() mutation_rate: new_config[harness][tool_call_retry] max(0, new_config[harness][tool_call_retry] random.choice([-1, 1])) if random.random() mutation_rate: new_config[harness][timeout_seconds] max( 1, new_config[harness][timeout_seconds] random.choice([-2, -1, 1, 2]) ) return new_config def select_top_configs(evaluated_pool: list, top_n: int 3) - list: 按平均分排序并返回排名靠前的配置。 sorted_pool sorted(evaluated_pool, keylambda x: x[avg_score], reverseTrue) return sorted_pool[:top_n]可以看到這其實就是一條經(jīng)典的優(yōu)化鏈路評估完所有候選后把得分最高的幾組配置保留下來再通過變異生成新一組候選進入下一輪。這種方法不會保證達(dá)到全局最優(yōu)但工程上可解釋性強且實現(xiàn)簡單。如果你希望進一步增強優(yōu)化能力可以引入交叉操作把兩個精英配置的部分字段交換。比如將“開啟反思”的字段從配置 A 遷移到配置 B形成更符合預(yù)期的下一代候選。這和進化算法的思路很接近。4.5 跑通完整實驗閉環(huán)現(xiàn)在實現(xiàn) run_experiment.py 來串聯(lián)整個流程。# 文件路徑run_experiment.py import copy import random from collections import defaultdict import yaml from meta_harness.executor import execute_trajectory from meta_harness.evaluator import evaluate_config_with_replicates from meta_harness.optimizer import mutate_config, select_top_configs def load_config(path: str) - dict: with open(path, r, encodingutf-8) as f: return yaml.safe_load(f) def build_initial_pool(base_config: dict, population_size: int) - list: 以基礎(chǔ)配置為中心創(chuàng)建少量變異候選。 pool [base_config] while len(pool) population_size: candidate mutate_config(copy.deepcopy(base_config), mutation_rate0.6) if candidate not in pool: pool.append(candidate) return pool def run_one_round(base_config: dict, config_pool: list, round_index: int): 執(zhí)行一輪評估。 replicate base_config[optimization][replicate_per_config] seed_base round_index * 100 # 分組評估 group_results [] for idx, cfg in enumerate(config_pool): traj_list [] for rep in range(replicate): seed seed_base idx * 10 rep traj execute_trajectory(cfg, task_idftask_{idx}_{rep}, seedseed) traj_list.append(traj) agg evaluate_config_with_replicates(base_config, traj_list) group_results.append({**agg, config: cfg}) group_results.sort(keylambda x: x[avg_score], reverseTrue) return group_results下面加一段打印結(jié)果邏輯并執(zhí)行def main(): base_config load_config(configs/base_config.yaml) pool_size base_config[optimization][population_size] num_rounds base_config[optimization][num_rounds] config_pool build_initial_pool(base_config, pool_size) for round_idx in range(num_rounds): print(f Round {round_idx 1} ) round_results run_one_round(base_config, config_pool, round_idx) for i, item in enumerate(round_results): config_snapshot { max_steps: item[config][harness][max_steps], enable_reflection: item[config][harness][enable_reflection], tool_call_retry: item[config][harness][tool_call_retry], } print( fRank {i 1} | avg_score{item[avg_score]} | fsuccess_rate{item[success_rate]} | favg_steps{item[avg_step_count]} | fconfig{config_snapshot} ) top_configs select_top_configs(round_results, top_n3) new_pool [] for top_cfg in top_configs: top_value top_cfg[config] new_pool.append(top_value) new_pool.append(mutate_config(copy.deepcopy(top_value))) new_pool.append(mutate_config(copy.deepcopy(top_value), mutation_rate0.8)) config_pool new_pool[:pool_size] print() if __name__ __main__: main()啟動實驗python run_experiment.py由于隨機種子是固定的每次完整運行的結(jié)果會保持一致便于學(xué)習(xí)者對照。但這個實驗的核心目的不在于唯一次數(shù)跑出多高分而在于觀察不同配置在不同輪次中的變化趨勢開啟反思的配置是不是更容易在更少步驟內(nèi)達(dá)到穩(wěn)定重試次數(shù)多的配置是否拉高了耗時正常情況下我們會看到第一輪中配置之間差異很大經(jīng)過幾輪篩選后avg_score 會緩慢上升。如果某組配置的 success_rate 上升但 avg_step_count 也上升就需要重新審視 step_penalty 的權(quán)重是否合理。5. Meta 層設(shè)計容易被忽略的關(guān)鍵細(xì)節(jié)5.1 評測集不能只覆蓋成功路徑做工程優(yōu)化和做研究實驗最大的不同在于研究可以只挑少量高質(zhì)量測試集但工程上線要面對的是大量真實任務(wù)分布。很多 Agent 優(yōu)化剛開始都很美好換了一批任務(wù)就崩潰。原因在于評測樣本單一。建議在實驗階段把評測任務(wù)分成至少三類簡單短期任務(wù)時長 3 至 5 步用來驗證基礎(chǔ)流程是否正常。中等復(fù)雜任務(wù)時長 8 至 15 步用來調(diào)節(jié)反思頻率和上下文管理策略。困難長周期任務(wù)時長 20 步以上用來暴露累積偏差、上下文污染等核心問題。如果全部用簡單任務(wù)做優(yōu)化Meta 層很容易學(xué)到“直接關(guān)閉反思、增加重試次數(shù)”這種過度自信的策略但這種策略一旦遷移到困難任務(wù)就會變成災(zāi)難。5.2 過程軌跡比結(jié)果日志更重要傳統(tǒng)監(jiān)控手段通常只打印每步日志比如“步驟 3 調(diào)用了 search 工具”“步驟 4 返回了結(jié)果”。這樣對我們發(fā)現(xiàn)問題用處不大。要想驅(qū)動 Meta-Harness 優(yōu)化至少要存儲每步執(zhí)行時的結(jié)構(gòu)化狀態(tài)包括當(dāng)前步驟的目標(biāo)。當(dāng)前步驟是否偏離主任務(wù)。關(guān)鍵中間結(jié)果的摘要。工具調(diào)用時的完整入?yún)⑴c出參。模型在步驟間的反思內(nèi)容。這些軌跡數(shù)據(jù)是后續(xù)分析的長周期反饋信號。我們可以在沒有人工標(biāo)注的情況下通過規(guī)則自動計算相似度或一致性發(fā)現(xiàn)哪些配置容易出現(xiàn)“重復(fù)調(diào)用同一個工具”“輸出自相矛盾”“忘記最初指令”等問題。5.3 不要為了對齊自動評估而犧牲真實目標(biāo)設(shè)計評估函數(shù)時最怕出現(xiàn)“評估器與業(yè)務(wù)目標(biāo)不一致”的情況。假如你給 Agent 的核心目標(biāo)設(shè)定為“獲取準(zhǔn)確數(shù)據(jù)并按模板生成報告”但評估函數(shù)主要獎勵“快速收斂到成功狀態(tài)”和“減少中斷”就可能導(dǎo)致 Agent 學(xué)到取巧的路徑遇到數(shù)據(jù)缺失就自己編一條合理值而不是觸發(fā)人工確認(rèn)?，F(xiàn)實世界中這一點尤其重要。長周期任務(wù)成功率的定義要盡量貼近業(yè)務(wù)結(jié)果而不是讓評測函數(shù)變成游戲規(guī)則的設(shè)計漏洞。想要安全可以加入一致性校驗邏輯把“自動補全的結(jié)果必須由評審節(jié)點確認(rèn)”作為一個強約束寫入 Harness。6. 常見問題與排查思路問題現(xiàn)象常見原因解決思路放開反思后回合數(shù)大幅上升反思觸發(fā)過于頻繁模型陷入形式化自檢僅在高風(fēng)險步驟后觸發(fā)或采用按步驟間隔觸發(fā)提高最大步數(shù)后成功率不升反降A(chǔ)gent 在后續(xù)步驟中遇到上下文污染或幻覺啟用裁剪機制定期壓縮中間日志摘要重試次數(shù)高但任務(wù)仍失敗重試只是重復(fù)同一錯誤沒有變更方法對比兩次執(zhí)行差異要求 Agent 在重試前輸出原因分析評測分?jǐn)?shù)穩(wěn)定但線上效果差測試任務(wù)與真實分布不一致擴充多樣測試集加入線上采樣任務(wù)自動評估器給出錯誤反饋規(guī)則評估器對語義理解不足引入大模型裁判或混合評估模式關(guān)鍵步驟人工抽檢針對第一類問題如果想精細(xì)調(diào)整可以在反思步驟的提示詞中增加約束“僅當(dāng)存在不確定結(jié)論、潛在沖突或高風(fēng)險決策時進行反思”這比簡單設(shè)置開關(guān)更有效。第二類問題在 Long-Horizon 場景里極為高頻。上下文裁剪的實現(xiàn)可以在每次步驟結(jié)束后把舊日志壓縮成一條摘要記錄只保留最近三到五條原始日志。這樣既能保留信息又不會讓模型注意力被垃圾字段稀釋。7. 工程落地的建議與風(fēng)險清單7.1 設(shè)計上先做輕量級 Harness再做 Meta 層很多團隊在第 1 天就想搭建極其復(fù)雜的自動優(yōu)化平臺這是個典型誤區(qū)。Meta-Harness Optimization 真正運轉(zhuǎn)的前提是 Harness 本身已經(jīng)具備穩(wěn)定的執(zhí)行、日志和可回滾能力。如果當(dāng)前任務(wù)在固定配置下本身就經(jīng)常失敗盲目引入自動優(yōu)化只會放大噪聲甚至讓配置搜索往錯誤方向收斂。建議按以下步驟進行落地先手工固定一套較優(yōu)配置跑通至少 100 條真實任務(wù)軌跡。分析失敗任務(wù)軌跡檢查是否存在重復(fù)失敗原因。將修復(fù)經(jīng)驗沉淀為規(guī)則校驗節(jié)點或提示詞約束。之后再引入配置池與自動評估器。上線自動優(yōu)化時先用影子模式并行比對推薦配置與當(dāng)前線上的表現(xiàn)。7.2 配置版本管理必須納入代碼倉庫Harness 配置在優(yōu)化過程中可能每輪都會變化。如果像改普通業(yè)務(wù)配置一樣直接修改運行參數(shù)很容易失去審計能力。推薦把所有候選配置統(tǒng)一存儲在 Git 倉庫或配置中心中候選名遵循清晰的命名規(guī)范例如 reflective_v3_low_penalty方便回滾。Autodesign 的精神在于“自動發(fā)現(xiàn)更好的 Harness”但這并不意味著可以繞過工程標(biāo)準(zhǔn)。任何自動生成的候選都應(yīng)該經(jīng)過變更評審流程至少要在測試環(huán)境跑通回歸樣本。7.3 給每個軌跡增加可復(fù)現(xiàn)標(biāo)識長周期任務(wù)具有不小的隨機性因此排查問題時需要精確定位到底是在哪一次執(zhí)行中出了問題。建議每一次 Trajectory 都保存以下元信息配置版本號。模型版本號。隨機種子。時間戳。工具調(diào)用的實際入?yún)⒄?。?dāng)前環(huán)境變量標(biāo)簽。當(dāng)后續(xù)發(fā)現(xiàn)線上效果出現(xiàn)抖動時這組元信息能幫助快速鎖定問題源頭是來自配置變化還是模型版本變化。7.4 安全邊界與人工兜底自動化優(yōu)化經(jīng)常在困境中得出一些看起來聰明的配置。例如為了降低失敗率Agent 可能會把工具異常吞掉、只報成功也可能為了讓用戶滿意而編造不存在的數(shù)據(jù)。這種問題不能完全依靠評測函數(shù)去預(yù)防。一個務(wù)實的做法是為所有 Agent 工具調(diào)用加入“結(jié)果可回滾”和“高危操作二次確認(rèn)”護欄。凡涉及數(shù)據(jù)庫刪除、外部接口寫入、線上配置變更等敏感操作強制要求經(jīng)過獨立評審鏈或人工確認(rèn)。Harness 優(yōu)化過程同樣不得繞過這條安全邊界。8. 從演示到生產(chǎn)你還差哪幾步如果你希望把這個最小演示遷移到真實的 LLM Agent 環(huán)境中可以按下面的順序替換模塊。首先把 execute_trajectory 中模擬單步執(zhí)行的函數(shù)替換成真實的模型調(diào)用邏輯保持與外部工具的交互方式不變?nèi)缓蟀衍壽E記錄中增加模型輸入輸出的 token 消耗最后把評估函數(shù)從規(guī)則計算改為“規(guī)則計算 大模型裁判加權(quán)”的混合評估。在此之上還可以從一次性采樣升級為流式采樣也就是不等待本輪所有配置全部跑完而是實時評估已完成的軌跡并動態(tài)淘汰明顯劣勢的配置。不過這種策略只適合測試任務(wù)量大、單條成本較高的場景否則會引入額外復(fù)雜度。如果你的任務(wù)中存在多種差異很大的業(yè)務(wù)類型建議為每種類型單獨維護一套 Harness 配置池與評估權(quán)重而不是追求單一萬能配置。很多團隊在最開始會試圖設(shè)計一套“通用 Agent”結(jié)果在長周期任務(wù)上發(fā)現(xiàn)不同場景的最優(yōu)節(jié)奏差異巨大強行統(tǒng)一配置后所有任務(wù)的表現(xiàn)都退化成平均水平。本文從設(shè)計理念到一個小型閉環(huán)實現(xiàn)覆蓋了長周期 Agent 任務(wù)中“配置定義—軌跡執(zhí)行—過程評估—自動優(yōu)化—安全落地”這條完整鏈路。真實項目里大家不必立刻追求復(fù)雜的強化學(xué)習(xí)或大規(guī)模搜索算法先把手里的 Harness 配置管理好、評測指標(biāo)定義好、軌跡可觀測性做好再逐步引入 Meta 層自動優(yōu)化效果會遠(yuǎn)比空談概念更扎實。如果想繼續(xù)深入可以進一步學(xué)習(xí)過程獎勵模型、開放式軌跡搜索、以及基于人工偏好對齊的評估函數(shù)設(shè)計。這些都是 Meta-Harness Optimization 后續(xù)演進中非常有價值的方向。