做 Agent 項目的朋友估計都被 Agent Harness 和 Agent Runtime 這兩個詞繞暈過同樣是“Agent 相關的東西”為什么有人天天問“你基于哪個 Runtime”有人卻在說“我自己寫了個 Harness”更麻煩的是不同框架文檔里的用法還不一樣有的把 Harness 說成 Agent 執(zhí)行器有的把 Runtime 直接當成模型調用客戶端。這篇文章不繞概念直接站在工程落地角度把兩者的邊界、職責、代碼形態(tài)、排查方式一次說清楚。先說結論Agent Runtime 是 Agent 代碼真正執(zhí)行的環(huán)境和基礎設施負責模型通信、工具調用、記憶讀寫、生命周期內的進程與資源管理Agent Harness 則是跑在 Runtime 之上、控制 Agent 行為節(jié)奏的編排層它決定 Agent“下一步該推斷還是該調用工具、什么時候算完成、異常了怎么糾正”。你可以把 Runtime 理解成攝影棚里的燈光、攝像機和場地把 Harness 理解成導演手里的分鏡本——兩部戲可以共用一個攝影棚但分鏡本完全不同。1. 先把定義釘死兩個詞到底在解決什么問題1.1 一個馬上能記住的類比電影棚和導演我給人講這個概念時最喜歡用拍電影來比。Runtime 是整個拍攝現(xiàn)場的基礎設施攝影機、燈光、錄音設備、場務調度它們保證“只要演員站在那里就能被拍下來”。Harness 則是導演手上的劇本分鏡、走位要求和喊停規(guī)則它決定演員先說哪句臺詞、走到哪個機位、什么情況下這場戲可以收工。落到 Agent 工程里Runtime 負責“能跑”。模型接口是否可用、工具函數(shù)能否在安全容器里執(zhí)行、上一步的對話歷史能不能被讀出、運行時的指標和日志能不能被采集這些都是 Runtime 的活。Harness 負責“怎么跑”。先讓模型生成一段推理還是先調用檢索接口拿到工具返回后要不要再讓模型分析一輪已經重復三次還沒結果時是否要強行結束這些都是 Harness 的活。這個區(qū)分并不是某些框架發(fā)明的而是軟件工程里“基礎設施”和“業(yè)務流程”分層思想在 Agent 領域的自然延伸。只要你寫過異步任務應該能感受到類似的邏輯消息隊列是 Runtime任務編排狀態(tài)機是 Harness數(shù)據(jù)庫是 Runtime事務腳本是 Harness。1.2 為什么那么多教程把這兩個詞混著用說句公道話這不能全怪初學者因為不同框架對術語的處理確實不同。有的框架把 Agent Runtime 做成了一個很薄的服務端只處理模型調用和工具執(zhí)行有的框架則把 Harness 封裝成完整的 Agent 類內置了 ReAct 循環(huán)、策略注入和記憶壓縮文檔甚至不出現(xiàn) Harness 這個詞。正因為框架層面的抽象層級不統(tǒng)一才導致“同樣的詞在不同人嘴里根本不是同一個東西”。更大的混淆來源是早期很多 Agent Demo 是單體腳本運行時環(huán)境和控制循環(huán)寫在同一份代碼里。比如 AutoGPT 早期的實現(xiàn)主循環(huán)、提示詞拼接、文件操作全在一個進程里跑后來社區(qū)才逐漸把它拆成不同的組件。在這種“先能用、后分層”的歷史背景下你當然很難說清哪個部分屬于 Harness、哪個部分屬于 Runtime。但從工程化角度分層遲早要做。原因很簡單如果你只是想展示一個 Agent Demo單體代碼無所謂如果要做多租戶、灰度發(fā)布、穩(wěn)定觀察和權限隔離你就必須知道哪部分能力應該下沉為公共運行環(huán)境哪部分策略應該保留為每個業(yè)務可控的編排層。后面所有內容都圍繞這個“分層必要性”展開。2. Agent RuntimeAgent 真正“跑”起來的底座2.1 Runtime 不等于“模型 API 封裝”它的范圍更寬很多人第一反應是Runtime 不就是那個調用 GPT 接口的客戶端嗎這理解太窄了。模型調用只是 Runtime 的一個子能力完整的 Agent Runtime 至少應該提供四類能力。第一是模型訪問抽象。你的業(yè)務代碼不該寫死“openai.ChatCompletion.create”而應該面向一個統(tǒng)一接口能隨時從某通義模型切到某個開源私有化模型。第二是工具執(zhí)行能力。模型輸出一個call_search_engine(query...)的指令后Runtime 需要真正把這個指令落到可信環(huán)境里執(zhí)行并且拿到結構化結果返回給上層。第三是狀態(tài)與記憶能力。Agent 每一輪的消息歷史、內部狀態(tài)、外部記憶向量都需要 Runtime 管理讀寫和過期策略。第四是可觀測性和容錯。調用模型失敗要重試工具執(zhí)行超時要熔斷每步的 token 和耗時要有 trace這些都是 Runtime 該提供的基礎設施能力。你可以回憶一下自己寫單體 Agent 時最煩的事切換模型供應商要動業(yè)務代碼某個工具有毛病把整個進程打掛多輪內存一長上下文爆掉沒人處理。這些問題全部指向同一個根源——你把業(yè)務控制邏輯和底層執(zhí)行能力耦合在一起了。引入 Runtime 這一層之后業(yè)務控制邏輯只用關心“要什么”不用關心“去哪里取、怎么取更穩(wěn)”。2.2 Runtime 接口設計的重要原則用名詞定義能力不要用流程定義能力我在看開源項目 Runtime 接口時會特別留意一個細節(jié)它暴露出來的方法到底是穩(wěn)定能力還是臨時流程。穩(wěn)定能力比如chat(messages, tools)、run_tool(name, args)、save_recall(text)、retrieve_recall(query)這些可以作為 Runtime 接口。而execute_step(observation)這種帶狀態(tài)推進語義的接口通常更適合放在 Harness 里因為“執(zhí)行一步”本身就是一種控制策略。用名詞定義能力還有個好處可替換性更強。比如今天底層模型不支持 Tool Calling只要模型訪問抽象層能把用戶指令改寫為“請輸出JSON格式工具調用”上層 Harness 就不必大改今天工具執(zhí)行環(huán)境從本地 subprocess 改成遠端容器只要run_tool接口的入參和返回值不變Harness 也無感知。這就是“底座”該有的樣貌。下面給一個最小 Python 接口示意幫助你感受 Runtime 抽象# runtime.py class AgentRuntime: def __init__(self, model_client, tool_registry, memory_store): self.model_client model_client self.tool_registry tool_registry self.memory_store memory_store def chat(self, messages, toolsNone, **kwargs): 調用底層模型并返回完整響應不做決策 return self.model_client.complete(messages, toolstools, **kwargs) def run_tool(self, name, args, timeout10): 在受控環(huán)境執(zhí)行工具并返回結構化結果 executor self.tool_registry.get(name) return executor.run(args, timeouttimeout) def save_memory(self, text): return self.memory_store.save(text) def retrieve_memory(self, query, top_k5): return self.memory_store.search(query, top_ktop_k)看到這里你可能會說這不就是普通函數(shù)封裝嗎對其實就是這么簡單。真正復雜的 Runtime 當然還有調度隊列、容器隔離、限流和密鑰管理但在邏輯上它對外只承諾“我能穩(wěn)定執(zhí)行這些原子能力”。原子能力之上如何組合不是 Runtime 的職責。2.3 什么時候該從框架 Runtime 遷到自研 Runtime如果你是剛開始做 Agent 原型的個人開發(fā)者建議直接用現(xiàn)成的 Runtime。Python 里可以用 LangChain 的 LCEL 和工具抽象也可以直接用輕量函數(shù)實現(xiàn)底層的調用封裝端側可用 Ollama 這類模型運行時它們已經幫你把模型請求標準化了。真正需要自研 Runtime 的信號通常是下面幾類你需要對工具執(zhí)行做更強的安全隔離比如 Agent 生成的要執(zhí)行的代碼不能直接subprocess跑在業(yè)務容器里而要進入沙箱容器你需要把 Agent 的調用能力開放給多個業(yè)務方每個業(yè)務方的模型流量、密鑰、限流規(guī)則各不相同你需要把記憶存儲從“簡單的列表保存”升級成多租戶隔離向量庫并且要求底層存儲可運維、可備份、可審計你需要極致的可觀測性每次模型調用和工具調用都必須有完整 tracetoken 成本要按客戶維度拆分。這些需求出現(xiàn)時如果你依然在 Harness 代碼里到處調用模型 SDK、直接操作工具函數(shù)那架構基本是一盤散沙。先把 Runtime 能力抽出來再談上層編排才有的放矢。3. Agent Harness真正控制“智能化行為”的編排層3.1 Harness 的核心是那個循環(huán)不是模型本身大模型本身只是一個“單步推理器”給它一段上下文它返回一段文本或一個工具調用。真正讓 Agent 持續(xù)工作、能分多步完成任務的那個機制是 Harness 里的循環(huán)邏輯。經典的 ReAct 循環(huán)可以概括為觀察當前問題 - 讓模型思考 - 如果模型要調用工具就執(zhí)行 - 把工具結果返回給模型 - 再觀察 - 直到模型給出最終答案。Harness 就是這段循環(huán)的載體。循環(huán)不是越高深越好但必須滿足工程要求最大步數(shù)、終止條件、異?；謴?、歷史裁剪。我見過不少項目把 Agent 寫得神乎其神最后跑崩的原因卻特別低級沒有限制最大步數(shù)工具調用結果異常后沒有讓模型感知到或者模型已經連續(xù)三次給出同一種錯誤工具調用卻沒有打斷機制。這些都不是模型能力問題而是 Harness 沒有把“套路”寫扎實。一個健壯 Harness 的控制偽代碼# harness.py class Harness: def __init__(self, runtime, policy, max_steps10): self.runtime runtime self.policy policy self.max_steps max_steps def run(self, task): history [] observation task for step in range(self.max_steps): # 策略層先判斷是否可以收手 if self.policy.should_stop(observation, history): return self.policy.build_final_answer(observation, history) # Runtime 負責讓模型“想一步” response self.runtime.chat( messagesself.policy.build_messages(observation, history), toolsself.policy.get_tools() ) if response.has_tool_call(): # 執(zhí)行工具這一步走 Runtime result self.runtime.run_tool( response.tool_call.name, response.tool_call.args ) observation {tool_result: result} else: # 沒有工具調用說明模型想直接給答案 if self.policy.is_final(response.text): return response.text observation {agent_message: response.text} history.append({ step: step, response: response, observation: observation, }) raise HarnessTimeoutError(f超過 {self.max_steps} 步仍未得出最終答案)注意這個偽代碼里runtime.chat和runtime.run_tool幾乎沒有業(yè)務語義它們只是被動執(zhí)行而循環(huán)次數(shù)、什么時候停止、歷史怎么傳給模型、要不要把上一步的工具結果轉成一句話全是 Harness 在管。這就是兩者各自的位置。3.2 Harness 同時裝著提示詞策略和人類規(guī)則Harness 不只是寫循環(huán)它還承載了很多“規(guī)則”。同一個 Runtime接不同 Harness可以做出完全不同的 Agent 性格和行為。比如客服 Agent 的 Harness 里會內置“先查訂單再安撫用戶實在解決不了就轉人工”的策略代碼助手 Agent 的 Harness 會內置“修改文件前先展示 diff確認后才寫入”的審批動作數(shù)據(jù)分析 Agent 的 Harness 會在模型生成 SQL 之后強制執(zhí)行“只讀檢查”禁止DELETE和UPDATE開頭。這些策略放不到 Runtime 里因為 Runtime 不知道上層業(yè)務目標。但它們非常適合放在 Harness 里通過顯式的 Policy 類注入。我在上面代碼里寫了self.policy就是這個意思。Policy 可以封裝系統(tǒng)提示詞、工具列表、停止規(guī)則、結果校驗甚至人工審批回調。把策略從循環(huán)代碼里拆出來之后測試和復用都方便很多。還有一點容易被忽略錯誤處理策略也屬于 Harness。比如工具調用返回了“權限不足”Harness 要決定是直接反饋給模型讓它換個方式還是終止任務并通知管理員。Runtime 只能告訴你工具拋了異常不能替你決定下一步怎么辦。這是“編排放控制層”和“執(zhí)行層”最本質的區(qū)別。3.3 開源框架里的 Harness 長什么樣為了讓你能對號入座我列幾個常見框架里“Harness 角色”的具象化框架典型類型對應內容LangGraph圖狀態(tài)機Agent 節(jié)點、工具節(jié)點、條件邊、循環(huán)限制CrewAICrew / Agent / Task任務編排、Agent 角色提示詞、流程模式AutoGenGroupChatManager對話調度、發(fā)言順序、終止條件Semantic KernelKernel / Planner規(guī)劃器與函數(shù)調用循環(huán)自研系統(tǒng)Harness / Controller主循環(huán)、策略注入、中斷恢復拿 LangGraph 來說StateGraph里的add_node、add_edge本身就是 Harness 邏輯的高度抽象而實際執(zhí)行invoke model或call tool的是 Runtime 層。很多人誤以為 LangGraph 等于 Runtime其實它更偏 Harness真正的底層模型調用還是由 LangChain 的 ChatModel 或者獨立 SDK 完成。當你理解了“LangGraph 更像 Harness”之后就不會再犯一個典型錯誤試圖在 LangGraph 里塞過多底層連接池、超時重試等基礎設施邏輯。那些邏輯應該在節(jié)點內部封裝的 Runtime 客戶端里否則整個圖會變成一張又大又脆的蜘蛛網。4. 兩者邊界一圖流按職責對照與協(xié)作流程拆解4.1 高頻對比速查表下面這張表可以保存下來當速查卡每次邊界模糊時就拿出來對一遍對比維度Agent RuntimeAgent Harness定位執(zhí)行基礎設施控制編排層回答的問題“能不能跑、穩(wěn)不穩(wěn)”“下一步做什么、什么時候?！敝饕庋b模型客戶端、工具執(zhí)行器、記憶存儲主循環(huán)、Policy、提示詞策略、終止條件典型載體獨立服務、函數(shù)庫、沙箱進程Agent 類、狀態(tài)圖、編排器對模型影響通過 system 和 tools 傳入但不會“替模型決策”決定 model 看到什么、能看到幾步歷史故障影響崩潰會導致所有 Agent 不可用出 bug 會導致當前任務走偏或死循環(huán)可觀測對象token 數(shù)、調用耗時、工具執(zhí)行時延決策軌跡、工具選擇原因、循環(huán)步數(shù)測試重點接口穩(wěn)定性、超時和隔離不同策略下的任務成功率、終止率這不是二選一的關系而是分層依賴關系Harness 依賴 Runtime 提供的原子能力Runtime 不依賴任何 Harness 的業(yè)務策略。如果哪天你發(fā)現(xiàn)自己的 Runtime 代碼里塞了大量“如果用戶問了天氣就優(yōu)先調用天氣工具”這種邏輯那說明 Harness 里的策略漏到了 Runtime。4.2 一次真實查詢的完整路徑假設你正在做一個企業(yè)內部知識庫問答 Agent用戶問“幫我總結昨天項目周報并找出風險項?！?我按一次完整執(zhí)行拆給你看。第一步HTTP 網關收到請求創(chuàng)建 Session初始化 Harness 和綁定給該 Session 的 Runtime。第二步Harness 調 Policy 構造系統(tǒng)提示詞把“你是項目經理助理”這類人設和工具說明帶進去然后調用 Runtime.chat 把用戶問題發(fā)給模型。第三步模型返回的不是最終答案而是一個工具調用比如search_docs(query項目周報 2025-04-10, date2025-04-10)。Harness 看到有 tool_call于是轉到工具執(zhí)行階段調用Runtime.run_toolRuntime 去向量庫檢索并把文本片段返回。第四步Harness 拿到檢索結果后把工具結果拼進 messages再調用 Runtime.chat。模型這次根據(jù)檢索內容生成了總結和風險點。Harness 判斷文本不是最終答案而是“需要再調一次 calendar 工具獲取成員日程”的新請求于是再次執(zhí)行工具。第五步直到模型輸出滿足 Policy 的終止條件Harness 把結果回給 HTTP 網關。如果第五步發(fā)生了工具調用異常Harness 會決定是重試、換工具還是把異常信息返回給模型繼續(xù)推理。從這五個步驟你應該能感覺到用戶感知到的“智能”其實就是 Harness 對 Runtime 多次調用后形成的結果。Runtime 每次執(zhí)行都很快難的是如何編排這些步驟讓模型在正確時機看到正確信息。4.3 邊界模糊時用四個問題做判斷如果你在代碼評審時拿不準某個函數(shù)應該屬于哪一層可以直接問下面四個問題。第一個問題這段邏輯去掉之后Agent 還能用同一個底層模型和工具嗎如果能它多半屬于 Harness 策略。第二個問題這段邏輯和具體模型供應商強相關嗎比如某個 API 的 tools 參數(shù)格式轉換這屬于 Runtime。第三個問題這段邏輯需要所有 Agent 類型共用嗎比如統(tǒng)一的限流、鑒權它是 Runtime 基礎設施如果只有財務分析 Agent 需要審批流程那是 Harness。第四個問題如果業(yè)務要新接入一個完全不同的 Agent 場景你是否希望復用這段代碼希望復用的底層資源和穩(wěn)定性邏輯放 Runtime不希望復用的場景策略放 Harness。這四句話基本能解決 90% 的歸屬爭論。剩下的 10% 可能屬于長期演進產生的中間層比如“會話路由”到底歸誰取決于你的產品形態(tài)但至少你們討論時能有一個統(tǒng)一的判斷框架而不是靠感覺。5. 日常開發(fā)中的高頻坑位與排查實錄5.1 現(xiàn)象一工具調用一直執(zhí)行但 Agent 每次都說“沒找到結果”這個坑我見得太多了。表面上看 Runtime 日志里工具執(zhí)行成功了返回內容也打印出來了但模型還是說沒找到。排查時先別懷疑模型重點看 Harness 把工具結果回傳給模型時是怎么拼裝的。常見的錯誤是Harness 把工具結果保存在了一個局部變量里但下一次調用模型時忘了把這條消息加到 messages或者加了但消息角色寫成了user而不是tool對應的角色。工具結果回傳屬于 Agent 編排的核心細節(jié)。模型廠商對工具結果的格式要求可能不同OpenAI 要求用 roletool 的消息并要求提供 tool_call_id其他模型可能只要求在 user 內容里塞結果。這個差異通常在 Runtime 層做適配但 Harness 要保證“每條 tool_call 都有對應結果”。如果你發(fā)現(xiàn)工具執(zhí)行成功但 Agent “失憶”建議在 Harness 插入一步檢查統(tǒng)計 messages 里 tool_call 數(shù)量和 tool_result 數(shù)量是否一致。5.2 現(xiàn)象二Agent 永久不終止費用飆高這大概率不是 Runtime 問題而是 Harness 的終止條件寫得太寬松。最常見的情況是 Policy 里只判斷“模型輸出是否包含 final 標記”但模型在復雜任務里就是不輸出這個標記于是一直循環(huán)調用工具。我的建議是任何 Harness 都必須同時具備“正向終止”和“強制終止”正向終止由 Policy 判斷任務目標是否完成強制終止由兜底步數(shù)、時間閾值和 Token 閾值共同實現(xiàn)。上面代碼里的max_steps就是強制終止。真實項目里我還會加一個熔斷器如果連續(xù)三次工具調用都返回相同錯誤Harness 直接停止并把上下文發(fā)給人工處理。這一步能省下大量調試成本。5.3 現(xiàn)象三問題定位時日志到底去 Harness 找還是 Runtime 找很多團隊日志混亂就是因為沒有按職責劃分。我的經驗是Harness 日志記錄的是“決策軌跡”比如第幾步、模型回復了哪段思考、為什么調用某個工具、終止原因是什么Runtime 日志記錄的是“執(zhí)行指標”比如模型接口耗時、Token 消耗、工具執(zhí)行超時、網絡重試次數(shù)。如果任務結果不符合預期先查 Harness 的決策軌跡比如“它到底有沒有理解用戶意圖”如果系統(tǒng)整體卡頓或偶發(fā)失敗再查 Runtime 指標比如“是不是模型 API 超時率變高了”。我把排查順序整理成了一個速查表現(xiàn)象優(yōu)先排查層典型原因結論不對Harness提示詞策略缺失、上下文裁剪過度、工具信息未回傳某一步工具偶發(fā)失敗Runtime工具超時、服務不可用、鑒權過期任務中途停止Harness異常未處理、終止條件誤判整個服務不可用Runtime資源耗盡、下游模型限流未處理響應慢但結果OKRuntime模型調用串行、工具執(zhí)行慢同一問題多次回答漂移Harness缺少固定的 few-shot、溫度未調低這里的重點是不要一出現(xiàn)問題就瘋狂打日志定位到每一行而是先判斷“是這一層壞了還是上一層用錯了”。層與層之間的語義障礙是最大的排查暗礁。5.4 我的一個壓箱底調試技巧給 Harness 裝“步進器”不知道你會不會遇到這種情況Agent 跑了 20 步之后終于飛了但你想知道它在第 7 步為什么突然檢索了一個毫不相關的文檔。看完整日志太累直接調模型接口又脫離真實場景。我的建議是給 Harness 設計一個可插拔的 StepListener在每一輪循環(huán)開始、模型返回、工具調用前后觸發(fā)回調把關鍵信息渲染成可讀的 JSONL。這樣你可以在本地把一次完整運行保存下來再用腳本按 step 編號逐層查看。實際上這也是一種“Harness 與 Runtime 分離”帶來的紅利Runtime 只記錄底層請求Harness 記錄決策鏈條。把決策鏈條回放一遍你會瞬間看清是哪條 Prompt 誤導了模型而不是在 Runtime 的幾百條原始請求日志里大海撈針。這個技巧我?guī)缀踉诿總€生產級 Agent 項目里都會用。6. 架構決策順序與我的個人心得6.1 小項目可以先不拆服務但邏輯必須拆看到這你可能會緊張是不是必須上容器、上獨立 Runtime 服務才算完成了分層大可不必。個人項目或者五個以內的 Agent 場景完全可以跑在同一個 Python 進程里但代碼結構上要拆。我推薦的目錄結構很簡單app/ runtime/ model_client.py tool_executor.py memory_store.py harness/ base_harness.py policies/ customer_service.py analyst.py loop_listeners.py agents/ customer_service_agent.pyruntime下的模塊不 importharness下的任何內容harness只通過 Runtime 對外暴露的接口方法使用能力agents負責把某個 Harness 和 Runtime 組合起來注冊工具、綁定模型賬號。這樣就實現(xiàn)了邏輯邊界。將來如果某個 Runtime 模塊需要獨立成服務把它抽出來補一個網絡接口層即可不會牽連 Harness。6.2 演進路徑通常從“Harness 吃胖”開始要主動給 Runtime 補位在實際項目里還有一個很普遍的趨勢一開始 Harness 和 Runtime 確實分了層但隨著業(yè)務迭代大家圖省事開始把“其他模型供應商的適配”“工具執(zhí)行的沙箱參數(shù)”“歷史消息的向量化存儲”都寫進了 Harness。于是 Harness 越來越胖Runtime 變成了空殼所謂架構分層名存實亡。我的建議是每兩周做一次代碼評審時按第 4.3 節(jié)的判斷標準重新檢查如果同一段“穩(wěn)定執(zhí)行能力”被多個 Harness 復制粘貼了就把它下沉到 Runtime如果 Runtime 里出現(xiàn)了業(yè)務相關的策略 if-else就把它上提到 Harness。這個動作要持續(xù)做而不是只在架構設計時做一次。分層不是一錘子買賣它更像廚房里“灶臺”和“菜單”的關系灶臺性能穩(wěn)定菜單卻每周都在換。6.3 最后一個選型建議先寫壞掉的 Harness再談框架很多朋友在選擇 LangGraph、CrewAI 還是自研時猶豫很久。我的觀點是如果你連一個最樸素的while循環(huán) Harness 都沒寫過直接上抽象框架很容易被框架帶著走。先把你想要的一個場景用最原始的 Runtime Policy 循環(huán)寫出來跑通一次再去看框架內部怎么表達這些概念你才能判斷它是在替你做決策還是在限制你的表達。我自己做過兩個核心 Agent 系統(tǒng)一個早期重度依賴編排框架后續(xù)為了加“人工審批暫停與恢復”花了大半個月改造另一個一開始就用很樸素的 Runtime 接口 Harness 控制循環(huán)加新策略反而很快。不是框架不好而是框架自帶的那套 Harness 假設未必匹配你的業(yè)務狀態(tài)機。這里沒有銀彈理解分層邏輯比背出任何一家 API 文檔都管用。我個人最后一次分享一個真實體會Agent 項目的復雜度從來不是“模型不夠聰明”而是“環(huán)境不可控、步驟不可回放、策略不可解釋”。把 Runtime 做好解決的是環(huán)境穩(wěn)定性問題把 Harness 做好解決的是步驟可控和策略可解釋問題。兩者都有價值但如果你今天只打算改一處優(yōu)先把 Harness 的循環(huán)、終止、Policy 和回放日志寫得像樣因為這是你和“玄學 Agent”之間最重要的一道閘門。