1. 從 Harness 到數(shù)據(jù)分析這套智能體方案到底在解決什么問題第一次看到“OpenCode 智能體教程從 Harness 核心架構到數(shù)據(jù)分析全流程實操”這個標題我腦子里冒出來的第一個念頭是又是一個把幾個熱詞拼在一起的縫合怪。但仔細拆開看Harness、智能體、數(shù)據(jù)分析、架構這四個詞放在一起其實指向了一個非常具體的工程場景——用一套可編排的智能體框架把數(shù)據(jù)分析從“人寫代碼跑結果”變成“智能體自動規(guī)劃、執(zhí)行、校驗、輸出”的流水線。我自己在過去一年里陸續(xù)接觸過不少智能體框架從早期的 LangChain 到后來的 LangGraph再到各種垂直領域的 Agent 平臺踩過的坑比跑通的流程多得多。OpenCode 這個方向之所以值得單獨拿出來講是因為它把 Harness 這個概念放在了核心位置。Harness 在智能體語境下你可以把它理解成“馬具”或者“挽具”——它不是馬本身也不是馬車而是把馬和車連接起來、控制方向、傳遞動力的那套裝置。放到智能體系統(tǒng)里Harness 就是連接大模型能力與具體任務執(zhí)行之間的那層編排邏輯。很多人做智能體開發(fā)一上來就急著調 API、寫 prompt、接工具結果做到一半發(fā)現(xiàn)整個流程亂成一鍋粥模型不知道什么時候該調工具工具返回的結果不知道怎么塞回上下文多輪對話之后狀態(tài)全丟了。這個問題的根源就在于缺少一個清晰的 Harness 層。Harness 要解決的問題不是“模型能不能做”而是“模型做完之后下一步該誰接手、狀態(tài)怎么流轉、異常怎么兜底”。這篇文章適合三類人看第一類是想從零搭建智能體但不知道從哪下手的開發(fā)者第二類是在數(shù)據(jù)分析場景里被重復勞動折磨、想用智能體提效的從業(yè)者第三類是對 Harness 架構感興趣、想搞清楚它和普通 Agent 框架區(qū)別的技術人。我會從架構拆解講到實操落地把 OpenCode 這套東西的來龍去脈、核心機制、配置細節(jié)、避坑經驗全部攤開來講。你不需要有很深的 AI 背景但最好對 Python 和基本的數(shù)據(jù)分析流程有概念這樣看實操部分會更順暢。2. Harness 核心架構拆解它和普通 Agent 框架到底差在哪2.1 Harness 的本質不是模型是控制平面很多人第一次聽到 Harness 這個詞會懵因為它不像“Agent”或者“Tool”那么直觀。我剛開始也花了不少時間才理清楚。簡單來說Harness 在智能體系統(tǒng)里扮演的是控制平面的角色。如果把大模型比作發(fā)動機工具比作車輪那 Harness 就是方向盤、變速箱和儀表盤的集合體。它不直接產生動力但決定了動力往哪走、走多快、什么時候換擋。在 OpenCode 的架構里Harness 層主要承擔四個職責。第一是任務分解與規(guī)劃把用戶的一句“幫我分析一下這個銷售數(shù)據(jù)”拆成可執(zhí)行的步驟序列。第二是狀態(tài)管理記錄每一步執(zhí)行的結果、中間變量、上下文信息確保多輪交互不會斷片。第三是工具調度決定什么時候調用哪個工具、傳什么參數(shù)、拿到結果后怎么處理。第四是異常處理與回退當某個步驟失敗時是重試、換路徑還是直接報錯都由 Harness 層決策。這和 LangChain 那種鏈式調用有本質區(qū)別。LangChain 的 Chain 更像是一條流水線你預先定義好 A 到 B 到 C 的順序數(shù)據(jù)沿著鏈條往下流。但 Harness 是動態(tài)的它可以根據(jù)中間結果決定下一步走哪條分支。舉個例子數(shù)據(jù)分析任務里如果初步統(tǒng)計發(fā)現(xiàn)數(shù)據(jù)缺失率超過 30%Harness 可以自動切換到數(shù)據(jù)清洗分支而不是傻乎乎地繼續(xù)跑分析。這種動態(tài)決策能力是 Harness 架構最核心的價值。2.2 OpenCode 的 Harness 分層設計OpenCode 的 Harness 架構我拆下來大概分成三層。最底層是執(zhí)行引擎層負責實際調用模型和工具處理 token 管理、并發(fā)控制、超時重試這些臟活累活。中間層是編排邏輯層也就是 Harness 的核心包含任務圖構建、狀態(tài)機管理、條件分支判斷。最上層是接口適配層對外暴露統(tǒng)一的 API讓上層應用不用關心底層用的是哪個模型、哪個工具。這種分層的好處在于解耦。我試過把底層模型從某個免費模型換成另一個付費模型只要接口適配層不改上面的編排邏輯完全不用動。同樣新增一個數(shù)據(jù)分析工具只需要在執(zhí)行引擎層注冊Harness 層通過工具描述自動發(fā)現(xiàn)并調度。這種設計在需要頻繁切換模型或擴展工具的場景下特別省心。注意分層設計雖然靈活但也帶來了調試復雜度。當流程跑不通時你需要先判斷是執(zhí)行引擎的問題、編排邏輯的問題還是接口適配的問題。我的經驗是先在執(zhí)行引擎層打開詳細日志確認模型和工具調用本身沒問題再往上排查。2.3 Harness 與 Agent 的關系馬具和馬熱詞里有個“harness和agent區(qū)別”這個問題問得很好。Agent 是“能感知環(huán)境并采取行動以達成目標的實體”Harness 是“約束和引導 Agent 行為的框架”。用馬術打比方Agent 是馬Harness 是馬具。沒有馬具馬也能跑但方向不可控、速度不穩(wěn)定、遇到障礙不知道停。有了馬具騎手才能精確控制。在 OpenCode 里一個 Agent 可以理解為一個配置了特定模型、特定工具集、特定提示詞的執(zhí)行單元。而 Harness 是管理這些 Agent 如何協(xié)作、如何切換、如何傳遞狀態(tài)的調度器。你可以有多個 Agent比如一個負責數(shù)據(jù)讀取、一個負責統(tǒng)計分析、一個負責可視化Harness 決定它們按什么順序上場、什么時候交接。這種多 Agent 協(xié)作模式在數(shù)據(jù)分析場景里特別實用。我做過一個銷售數(shù)據(jù)分析的項目流程是這樣的數(shù)據(jù)讀取 Agent 先從數(shù)據(jù)庫拉數(shù)據(jù)Harness 檢查數(shù)據(jù)質量后決定是否交給清洗 Agent清洗完再交給分析 Agent 跑統(tǒng)計最后交給可視化 Agent 出圖。每個 Agent 只專注自己的事Harness 負責串起來。這樣比用一個萬能 Agent 硬扛所有任務要穩(wěn)定得多因為每個 Agent 的提示詞和工具集都可以針對性優(yōu)化。3. OpenCode 環(huán)境搭建與核心配置實操3.1 安裝與初始化避開依賴沖突的坑OpenCode 的安裝本身不復雜但依賴管理是個容易翻車的地方。我建議用虛擬環(huán)境隔離不要直接裝在系統(tǒng) Python 里。具體操作如下python -m venv opencode-env source opencode-env/bin/activate # Windows 用 opencode-env\Scripts\activate pip install opencode-harness如果你用的是 ARM 架構的機器比如某些開發(fā)板或者新款筆記本需要注意部分依賴包可能沒有預編譯的 ARM 版本。我遇到過在 ARM 上裝某個科學計算庫時編譯失敗的情況解決辦法是先裝系統(tǒng)級的開發(fā)工具鏈再手動編譯。具體來說Ubuntu 系可以先跑sudo apt install build-essential python3-dev然后再 pip install。安裝完成后用opencode init初始化項目目錄。這個命令會生成一個標準的項目結構包含配置文件、工具注冊目錄、Agent 定義目錄和日志目錄。我建議不要跳過這一步手動建目錄因為 OpenCode 的很多默認路徑是約定好的手動建容易漏掉某些隱藏配置。初始化后的目錄結構大概長這樣opencode-project/ ├── config/ │ ├── harness.yaml # Harness 核心配置 │ ├── models.yaml # 模型接入配置 │ └── tools.yaml # 工具注冊配置 ├── agents/ │ ├── data_reader.yaml │ ├── analyzer.yaml │ └── visualizer.yaml ├── tools/ │ └── custom_tools.py └── logs/3.2 模型接入配置免費額度和付費方案的取舍OpenCode 支持多種模型接入方式。熱詞里提到的“opencode免費模型”和“opencode go套餐”我都試過。免費額度適合做原型驗證和輕量任務但有幾個限制需要提前知道。免費額度的調用頻率有限制而且某些高級功能比如長上下文、函數(shù)調用可能不可用。如果你要做完整的數(shù)據(jù)分析流程涉及多輪工具調用和大量 token 消耗免費額度很快就會用完。配置模型接入在config/models.yaml里完成。一個典型的配置長這樣models: default: provider: opencode model_name: opencode-base api_key: ${OPENCODE_API_KEY} max_tokens: 4096 temperature: 0.1 fallback: provider: deepseek model_name: deepseek-chat api_key: ${DEEPSEEK_API_KEY} max_tokens: 8192 temperature: 0.2這里有個實用技巧配置 fallback 模型。當主模型調用失敗或者額度用完時Harness 會自動切換到備用模型。我在跑批量數(shù)據(jù)分析任務時經常遇到主模型限流的情況有了 fallback 就不會整個流程卡死。temperature 參數(shù)在數(shù)據(jù)分析場景建議設低一點0.1 到 0.3 之間比較合適因為分析任務需要的是穩(wěn)定和準確不需要創(chuàng)意發(fā)揮。提示API Key 不要硬編碼在配置文件里用環(huán)境變量引用。OpenCode 支持${VAR_NAME}的語法這樣配置文件可以安全地提交到版本控制。3.3 Harness 核心參數(shù)調優(yōu)config/harness.yaml是 Harness 層的核心配置里面有幾個參數(shù)直接影響智能體的行為。我挑幾個關鍵的講。max_iterations控制單個任務的最大迭代次數(shù)。設太小復雜任務跑不完就中斷設太大遇到死循環(huán)會浪費大量 token。我的經驗值是 15 到 25 之間具體看任務復雜度。數(shù)據(jù)分析類任務一般 20 次迭代夠用如果經常觸頂說明任務分解粒度太粗需要調整 Agent 的規(guī)劃提示詞。timeout_per_step是單步超時時間單位秒。工具調用特別是數(shù)據(jù)庫查詢可能很慢這個值要設得合理。我一般設 60 秒如果某個查詢經常超時說明需要優(yōu)化查詢本身或者加索引而不是一味調大超時。retry_policy定義失敗重試策略。我建議配置成指數(shù)退避第一次失敗等 1 秒重試第二次等 2 秒第三次等 4 秒。這樣在遇到臨時性網(wǎng)絡抖動時能自動恢復又不會在真正出錯時瘋狂重試浪費資源。state_persistence決定狀態(tài)是否持久化。對于長時間運行的數(shù)據(jù)分析任務建議開啟這樣即使進程重啟也能從上次中斷的地方繼續(xù)。持久化后端可以選本地文件或者數(shù)據(jù)庫本地文件適合單機開發(fā)數(shù)據(jù)庫適合生產環(huán)境。4. 數(shù)據(jù)分析全流程實操從原始數(shù)據(jù)到可視化報告4.1 數(shù)據(jù)讀取 Agent 的配置與工具注冊數(shù)據(jù)分析的第一步是拿到數(shù)據(jù)。在 OpenCode 里我習慣單獨配一個數(shù)據(jù)讀取 Agent而不是讓分析 Agent 自己去讀文件。這樣做的好處是職責清晰讀取 Agent 可以專門處理各種數(shù)據(jù)源格式分析 Agent 只關心拿到干凈的數(shù)據(jù)框。數(shù)據(jù)讀取 Agent 的配置文件agents/data_reader.yaml大概這樣寫name: data_reader model: default system_prompt: | 你是一個數(shù)據(jù)讀取專家。你的任務是從指定數(shù)據(jù)源讀取數(shù)據(jù) 并返回一個標準化的數(shù)據(jù)框。如果數(shù)據(jù)源不可用返回明確的錯誤信息。 tools: - read_csv - read_excel - query_database - read_json max_iterations: 5工具注冊在config/tools.yaml里完成。OpenCode 內置了一些常用工具但數(shù)據(jù)分析場景往往需要自定義。比如從業(yè)務數(shù)據(jù)庫讀取數(shù)據(jù)你需要注冊一個數(shù)據(jù)庫查詢工具。自定義工具用 Python 寫放在tools/custom_tools.py里然后用裝飾器注冊from opencode.tools import tool tool(namequery_database, description執(zhí)行 SQL 查詢并返回結果) def query_database(sql: str, connection_string: str) - dict: import sqlalchemy engine sqlalchemy.create_engine(connection_string) with engine.connect() as conn: result conn.execute(sqlalchemy.text(sql)) columns result.keys() rows result.fetchall() return { columns: list(columns), rows: [list(row) for row in rows], row_count: len(rows) }這里有個細節(jié)要注意工具函數(shù)的返回值必須是可序列化的因為 Harness 需要把結果塞回上下文傳給模型。如果你返回的是 pandas DataFrame模型看不懂需要轉成字典或者 JSON 格式。我一般返回列名、行數(shù)據(jù)和行數(shù)三個字段模型拿到之后能理解數(shù)據(jù)結構也能判斷數(shù)據(jù)量級。4.2 分析 Agent 的任務規(guī)劃與執(zhí)行分析 Agent 是整個流程的核心。它的 system prompt 設計直接決定了分析質量。我試過很多版本最后穩(wěn)定下來的寫法是這樣的name: analyzer model: default system_prompt: | 你是一個資深數(shù)據(jù)分析師。你會收到一個數(shù)據(jù)框和用戶的分析需求。 你的工作流程是 1. 先理解數(shù)據(jù)框的結構列名、類型、行數(shù) 2. 根據(jù)用戶需求制定分析計劃 3. 逐步執(zhí)行分析每一步都輸出中間結果 4. 最后匯總分析結論 你可以使用以下工具 - describe_data: 輸出數(shù)據(jù)的基本統(tǒng)計信息 - group_by_aggregate: 分組聚合 - correlation_analysis: 相關性分析 - trend_analysis: 趨勢分析 - hypothesis_test: 假設檢驗 注意每次調用工具前先說明你為什么需要這個工具 以及你期望得到什么結果。如果工具返回的結果不符合預期 分析原因并調整策略。 tools: - describe_data - group_by_aggregate - correlation_analysis - trend_analysis - hypothesis_test max_iterations: 20這個 prompt 的關鍵在于“先說明為什么再調用”這一條。我加上這句話之后Agent 的分析過程變得可追溯多了。以前它悶頭調工具出了問題我不知道是哪一步的假設錯了?，F(xiàn)在它會先輸出“我需要做分組聚合來比較不同區(qū)域的銷售差異”然后才調工具排查起來方便很多。工具的實現(xiàn)我舉一個例子分組聚合工具tool(namegroup_by_aggregate, description按指定列分組并聚合數(shù)值列) def group_by_aggregate(df: dict, group_col: str, agg_col: str, agg_func: str sum) - dict: import pandas as pd dataframe pd.DataFrame(df[rows], columnsdf[columns]) if group_col not in dataframe.columns: return {error: f分組列 {group_col} 不存在} if agg_col not in dataframe.columns: return {error: f聚合列 {agg_col} 不存在} result dataframe.groupby(group_col)[agg_col].agg(agg_func).reset_index() return { columns: list(result.columns), rows: result.values.tolist(), row_count: len(result) }注意這里接收的 df 參數(shù)是字典格式因為從上一個工具傳過來的是序列化后的數(shù)據(jù)。每次工具調用都要做一次 DataFrame 和字典之間的轉換雖然有點繁瑣但保證了狀態(tài)在 Harness 層可以正確序列化和持久化。4.3 可視化 Agent 與報告生成分析做完之后最后一步是出報告?？梢暬?Agent 的職責是把分析結果轉成圖表和文字報告。這里有個坑模型本身不能直接畫圖它只能生成畫圖的代碼或者配置。所以可視化 Agent 的工具集里需要包含一個“執(zhí)行繪圖代碼”的工具。我的做法是讓可視化 Agent 生成 matplotlib 或 plotly 的代碼然后通過一個沙箱工具執(zhí)行。沙箱工具的實現(xiàn)要小心不能直接 exec 任意代碼需要做白名單限制。我一般只允許導入 matplotlib、plotly、pandas 這幾個庫禁止文件寫入和網(wǎng)絡訪問。tool(namerender_chart, description執(zhí)行繪圖代碼并保存圖片) def render_chart(code: str, output_path: str) - dict: allowed_imports [matplotlib, plotly, pandas, numpy] # 簡單的安全檢查 for line in code.split(\n): if line.strip().startswith(import) or line.strip().startswith(from): module line.split()[1].split(.)[0] if module not in allowed_imports: return {error: f不允許導入 {module}} try: exec_globals {} exec(code, exec_globals) return {status: success, output_path: output_path} except Exception as e: return {error: str(e)}注意exec 執(zhí)行代碼始終有安全風險生產環(huán)境建議用更嚴格的沙箱方案比如 Docker 容器隔離或者專門的代碼執(zhí)行服務。我這里展示的是開發(fā)環(huán)境的簡化版本。報告生成部分我讓可視化 Agent 輸出 Markdown 格式的文字報告包含分析結論、關鍵數(shù)據(jù)點和圖表引用。這樣最終產物是一份可以直接發(fā)給業(yè)務方的文檔而不是一堆散落的圖片和數(shù)字。5. 常見問題與排查技巧實錄5.1 模型調用失敗與額度管理熱詞里有個“error from provider (console): opencodes free tier can only be used from wi”這個報錯我遇到過。免費額度通常有使用場景限制比如只能在特定環(huán)境或特定 IP 段使用。解決辦法要么是升級到付費套餐要么是在合規(guī)的網(wǎng)絡環(huán)境下使用。我不建議在這上面花太多時間折騰如果免費額度不夠用直接上付費方案是最省事的。另一個常見問題是模型返回格式不符合預期。比如你期望 JSON它返回了一段帶解釋的文字。這種情況在 prompt 里加一句“只返回 JSON不要包含任何其他文字”通常能解決。如果還是不行可以在 Harness 層加一個輸出解析器用正則提取 JSON 部分。5.2 工具調用死循環(huán)的排查死循環(huán)是智能體開發(fā)里最煩人的問題之一。表現(xiàn)是 Agent 反復調用同一個工具每次都得到相似的結果但就是不往下走。我排查下來主要有三個原因。第一個原因是工具返回的結果模型理解不了。比如工具返回了一個嵌套很深的字典模型在上下文里看到一堆括號和冒號不知道關鍵信息在哪。解決辦法是簡化工具返回值只返回模型需要的最小信息集。第二個原因是 prompt 里沒有明確的終止條件。模型不知道什么情況下應該停止調用工具、開始輸出結論。我在 analyzer 的 prompt 里加了一句“當你已經收集到足夠的信息來回答用戶問題時停止調用工具并輸出分析結論”死循環(huán)概率大幅下降。第三個原因是狀態(tài)沒有正確傳遞。每一步的結果應該累積到上下文里但如果 Harness 配置有問題模型可能看不到之前的步驟結果導致它以為任務還沒開始反復從頭執(zhí)行。檢查state_persistence配置和上下文窗口大小確保歷史信息沒有丟失。5.3 數(shù)據(jù)分析場景的專屬避坑指南數(shù)據(jù)分析有一些特殊坑和通用智能體開發(fā)不太一樣。我整理了一個速查表問題現(xiàn)象可能原因解決辦法數(shù)據(jù)讀取后列名亂碼編碼格式不匹配讀取時指定 encoding 參數(shù)常見的有 utf-8、gbk、latin-1數(shù)值列被識別為字符串數(shù)據(jù)中有特殊符號讀取后做類型轉換用 pd.to_numeric 加 errorscoerce分組聚合結果為空分組列有缺失值先 dropna 或者 fillna 再分組相關性分析報錯列中包含非數(shù)值類型只選數(shù)值列做相關性分析圖表中文顯示為方塊matplotlib 字體問題設置 rcParams[font.sans-serif] 為中文字體大文件讀取內存溢出一次性加載太多數(shù)據(jù)用 chunksize 分塊讀取或者只讀需要的列還有一個經驗數(shù)據(jù)分析任務里讓 Agent 先做數(shù)據(jù)質量檢查再開始分析。我加了一個check_data_quality工具輸出缺失率、重復率、異常值比例。Agent 拿到這些信息后會自己決定是先清洗還是直接分析。這個改動讓分析結果的可靠性提升了不少因為很多錯誤其實源于臟數(shù)據(jù)而不是分析方法本身。6. 多 Agent 協(xié)作與分布式擴展思路6.1 多 Agent 協(xié)作的編排模式單 Agent 能做的事有限復雜數(shù)據(jù)分析往往需要多個 Agent 接力。OpenCode 的 Harness 支持幾種編排模式我常用的有兩種流水線模式和主管模式。流水線模式就是前面說的數(shù)據(jù)讀取、分析、可視化依次執(zhí)行適合步驟固定的場景。主管模式是有一個“主管 Agent”負責拆解任務、分配給下面的“工人 Agent”適合任務不確定、需要動態(tài)調度的場景。比如用戶說“幫我看看銷售數(shù)據(jù)有什么問題”主管 Agent 可能先派一個 Agent 做數(shù)據(jù)質量檢查根據(jù)檢查結果再決定派誰做后續(xù)分析。配置主管模式需要在 Harness 里定義一個 routing 規(guī)則routing: supervisor: supervisor_agent workers: - data_reader - analyzer - visualizer routing_prompt: | 根據(jù)當前任務狀態(tài)選擇下一個應該執(zhí)行的 Agent。 如果數(shù)據(jù)還沒讀取選 data_reader。 如果數(shù)據(jù)已讀取但未分析選 analyzer。 如果分析完成但未出圖選 visualizer。 如果全部完成返回 FINISH。6.2 分布式部署的考量當數(shù)據(jù)分析任務量大了之后單機跑不過來需要考慮分布式。OpenCode 的 Harness 層設計上支持分布式擴展核心思路是把執(zhí)行引擎層做成無狀態(tài)的服務多個實例可以并行處理任務。狀態(tài)管理抽到獨立的存儲服務里比如 Redis 或者數(shù)據(jù)庫。我做過一個簡單的分布式部署用三臺機器分別跑數(shù)據(jù)讀取、分析、可視化。Harness 作為調度中心把任務分發(fā)給空閑的 worker。這種架構的瓶頸通常在狀態(tài)存儲上因為每次工具調用都要讀寫狀態(tài)。優(yōu)化方法是減少狀態(tài)讀寫頻率把多個小步驟合并成一個事務。提示分布式部署不是必須的。我建議先把單機流程跑通、跑穩(wěn)確認瓶頸確實在計算資源上再考慮分布式。很多情況下優(yōu)化 prompt 和工具實現(xiàn)比加機器更有效。6.3 從數(shù)據(jù)分析擴展到其他場景這套 Harness 加多 Agent 的架構其實不只能做數(shù)據(jù)分析。我把同樣的模式套用到過自動化報告生成、競品監(jiān)控、用戶反饋分類等場景核心邏輯是一樣的讀取數(shù)據(jù)、處理數(shù)據(jù)、輸出結果。區(qū)別只在于 Agent 的 prompt 和工具集不同。比如做用戶反饋分類數(shù)據(jù)讀取 Agent 從工單系統(tǒng)拉數(shù)據(jù)分析 Agent 用文本分類工具打標簽可視化 Agent 出分類分布圖。Harness 配置幾乎不用改只換 Agent 定義就行。這種可復用性是 Harness 架構最大的優(yōu)勢也是我為什么愿意花時間把它吃透的原因。7. 一些實操后的個人體會這套東西我斷斷續(xù)續(xù)折騰了幾個月最大的感受是智能體系統(tǒng)的瓶頸往往不在模型能力上而在工程細節(jié)上。模型能不能做某件事和你能不能讓它穩(wěn)定地做某件事中間隔了無數(shù)個配置項、異常處理和狀態(tài)管理。Harness 層的價值在于它把這些工程細節(jié)收斂到了一個可控的范圍內。你不用在每個 Agent 里重復處理超時、重試、狀態(tài)傳遞這些都由 Harness 統(tǒng)一負責。Agent 只需要專注自己的任務邏輯。這種關注點分離的設計在系統(tǒng)復雜度上升之后優(yōu)勢特別明顯。另外一點體會是關于 prompt 的。我一開始總想把 prompt 寫得特別詳細恨不得把每一步都規(guī)定死。后來發(fā)現(xiàn)給 Agent 留出一定的自主決策空間效果反而更好。關鍵是定義清楚邊界條件——什么情況下必須停止、什么情況下必須報錯、什么情況下可以自行判斷。邊界清晰之后Agent 的自主性就是助力而不是風險。最后分享一個小技巧在開發(fā)階段把 Harness 的日志級別調到 DEBUG每一步的輸入輸出都打出來。雖然日志量大但排查問題時能省很多時間。等流程穩(wěn)定了再調回 INFO 級別。這個習慣幫我定位過好幾次隱蔽的狀態(tài)傳遞 bug值得養(yǎng)成。