很多人第一次接觸 OpenClaw Agents 的時候注意力都放在模型對話、Skill 調用這些看得見的功能上很少有人去關注執(zhí)行引擎。但我把src/agents/pi-embedded-runner/這個目錄從頭到尾過了一遍之后我的結論很直接整個 Agent 能不能穩(wěn)定干活靠的全是這一層。模型負責想Runner 負責轉工具負責做而 pi-embedded-runner 就是中間那個承上啟下的傳動軸。如果你正在嘗試部署 OpenClaw、自己寫 Skill或者被各種AI 聊天正常但一執(zhí)行任務就翻車的問題困擾這篇文章就是你排查問題的路線圖。我會從設計邏輯拆到實際部署把我自己跑通和踩坑的過程一起放進來。1. 為什么說執(zhí)行引擎是 Agent 的大腦中樞1.1 從能聊天到能干活的關鍵一躍你可以把純粹的 LLM 聊天想象成一個特別能說的朋友——你問他任何問題他都能給你一個語法正確、邏輯自洽的回答但他不會幫你關燈、不會幫你查數(shù)據(jù)庫、不會幫你把文件從 A 目錄挪到 B 目錄。Agent 要做的恰恰是這最后一步讓 AI 的想法變成真實的動作。在這個轉變里執(zhí)行引擎Runner承擔的角色非常像操作系統(tǒng)里的進程調度器。聊天場景下模型輸出一段文本就結束了但 Agent 場景下模型的輸出會被解析成調用哪個工具、傳什么參數(shù)、期望什么返回的結構化指令。Runner 拿到這個指令之后要去查工具注冊表、做參數(shù)校驗、執(zhí)行真實調用、把結果重新塞回上下文然后再交給模型進行下一輪判斷。我見過不少剛上手的朋友有個誤區(qū)以為只要把模型 API Key 配好Agent 就能自動聰明起來。實際完全不是這樣。你給模型再強如果執(zhí)行引擎不會解析工具調用、不會管理多輪上下文、不會處理工具異常那 Agent 就只是一個看起來很忙的聊天機器人任務稍微復雜一點就開始空轉。1.2 一個典型的思考-行動循環(huán)長什么樣為了把執(zhí)行引擎的作用說清楚我先拋出一個最小閉環(huán)。一個普通的多步任務在 Agent 內部通常是這樣流轉的接收用戶目標比如幫我查一下當前目錄里所有文檔中提到了哪些 API 配置項整理成表格。模型規(guī)劃LLM 把這個大目標拆成子步驟比如第一步列出當前目錄文件第二步逐個讀取文檔內容第三步篩選 API 配置項第四步生成表格。生成工具調用指令模型不直接執(zhí)行操作而是輸出一段結構化的調用意圖例如list_files(directory.)。執(zhí)行引擎調度Runner 解析這個意圖找到注冊表中對應的工具函數(shù)做參數(shù)校驗然后真正調用。結果回填工具返回的文件列表被寫入上下文模型看到真實結果后決定下一步動作。循環(huán)直到目標完成或達到上限整個過程可能經歷很多輪每輪都是模型輸出調用意圖 → Runner 執(zhí)行 → 結果回填 → 模型再輸出。你有沒有發(fā)現(xiàn)這套流程里最容易出問題的環(huán)節(jié)恰恰不是模型而是第 4 步和第 5 步。工具調用意圖解析錯了、參數(shù)類型不匹配、返回值太長把上下文撐爆、工具拋異常沒有捕獲任何一個環(huán)節(jié)出問題整個任務鏈條就斷了。pi-embedded-runner 存在的意義就是把這套流程做成一個穩(wěn)定、可控、可觀測的基礎設施。1.3 pi-embedded-runner 在 OpenClaw 里的定位從名字可以拆出三層信息。pi在 OpenClaw 的語境里通常指代 Personal Intelligence也就是面向個人助理場景的智能核心embedded表示它是進程內嵌入運行的不是獨立部署的微服務runner則是執(zhí)行調度器的意思。合起來它的職責很清楚作為嵌入式執(zhí)行引擎直接跑在你的應用進程里負責把模型輸出翻譯成真實動作。這個定位帶來兩個非常實際的好處。第一是低延遲工具調用不需要跨網絡請求Runner 和工具函數(shù)在同一個進程內省掉了大量序列化和網絡開銷。第二是便于本地化控制Skill 的執(zhí)行權限、文件訪問范圍、網絡請求白名單都可以直接在 Runner 層做約束不用依賴外部網關。對個人 Agent 這種既要靈活又要可控的場景嵌入式設計其實比微服務架構更合適。2. 拆解 pi-embedded-runner嵌入式 Runner 的設計邏輯2.1 embedded不是一句口號而是架構選擇很多 Agent 框架會把規(guī)劃器和執(zhí)行器拆成兩個獨立服務中間用消息隊列通信。OpenClaw 的 pi-embedded-runner 偏偏反著來它把自己做成一個庫直接嵌入到宿主進程里。我第一次看到這個設計時也有些疑惑但真正跑起來才明白它的用意。嵌入式架構的核心優(yōu)勢在于工具調用變成了純函數(shù)調用不再需要為每個工具定義一套網絡協(xié)議。以我接入的一個自定義 Skill 為例函數(shù)內部需要讀取本地 Sqlite 數(shù)據(jù)庫、調用一個內部 HTTP 接口、再寫日志文件。如果是微服務架構我得為這個 Skill 單獨封裝一個服務接口然后處理認證、超時、序列化但在 embedded runner 的設計下它就是一個普通的異步函數(shù)Runner 直接 await 它就可以了。代價也很明顯——宿主進程的內存和事件循環(huán)會決定 Agent 的性能上限。如果你在同一進程里又跑模型推理又跑大量文件 IO就可能出現(xiàn)事件循環(huán)阻塞。所以 OpenClaw 的 Runner 在設計上把模型交互和工具執(zhí)行基本都做成了異步流程盡量不在關鍵路徑上放同步阻塞操作。你在實踐里如果發(fā)現(xiàn) Agent 卡頓可以先檢查自己寫的 Skill 里有沒有同步的文件讀操作把它改成異步往往立竿見影。2.2 Runner 如何對接模型層、工具層和記憶層執(zhí)行引擎不可能孤立工作它必須同時面對三個方向向上對接模型、向下對接工具、側向對接記憶。pi-embedded-runner 的設計里這三條通道是明確分離的。模型層接口Runner 不關心你底層用的是 OpenAI 兼容接口、Ollama 本地模型還是 Anthropic 的 API它只面向統(tǒng)一的 Completion 接口。這里面有一個很重要的抽象模型輸出既可以是純文本也可以是結構化的工具調用意圖。Runner 要做的是把這兩種輸出都統(tǒng)一成內部消息格式再送給下一步處理。我實際接 Ollama 上的 qwen2.5-3b 時發(fā)現(xiàn)小模型對工具調用這種格式的支持不太穩(wěn)定經常輸出一段 Markdown 而不是嚴格的 JSON優(yōu)化辦法是在系統(tǒng)提示詞里明確給例子而不是只描述規(guī)則。工具層接口工具在 OpenClaw 里通常以 Skill 的形式存在每個 Skill 對外暴露一個描述清單包含名稱、用途說明、參數(shù) Schema。Runner 維護一張工具注冊表當模型說要調用某個工具時Runner 會先做語法層面的匹配和參數(shù)校驗校驗通過才真正執(zhí)行。有一次我寫 Skill 時把參數(shù)名從keyword改成了query結果模型連續(xù)三輪都在用舊參數(shù)名調用Runner 每輪都返回參數(shù)校驗錯誤。排查了半天才發(fā)現(xiàn)是描述信息沒有同步更新模型看到的注冊表還是舊的。這個教訓說明工具參數(shù) Schema 一旦變更必須同步更新工具描述否則模型不會自動知道新參數(shù)。記憶層接口執(zhí)行引擎的第三個連接對象是記憶模塊。每一輪工具調用的產物比如讀取的文件內容、查詢到的記錄不屬于長期記憶只屬于當前會話的短期上下文只有用戶明確要求記住或者到達某個重要節(jié)點時Runner 才會調用記憶接口做持久化。理解這一點你才能解釋為什么很多 Agent 在會話中表現(xiàn)很好但新開一個會話就失憶——因為執(zhí)行引擎默認只做短期上下文管理長期記憶需要顯式觸發(fā)。2.3 會話槽位與串并行調度pi-embedded-runner 里還有一個容易忽略但很重要的概念會話槽位slot。一個 Runner 實例可以同時管理多個 Agent 會話每個會話擁有獨立的上下文緩沖區(qū)和狀態(tài)棧。這有點像數(shù)據(jù)庫連接池——每個連接都是隔離的互不干擾。由于底層模型調用通常是串行的尤其本地模型Runner 需要一個調度策略來決定多個會話之間如何搶占模型資源。我跑下來的感受是OpenClaw 默認更偏向一個主任務占住模型的調度方式并行能力有限。如果你在同一個進程里同時跑多個 Agent 任務可能會出現(xiàn)一個任務的長工具調用堵住了另一個任務的模型請求。解決方案通常是把不同任務拆到不同的 Runner 實例不同的 Node 進程而不是在同一個實例里硬塞高并發(fā)。下面是我整理的一份調度參數(shù)對照表幫助你在調優(yōu)時有一個直觀的參照參數(shù)作用建議值/做法maxIterations單個任務最多循環(huán)多少輪簡單任務 8 輪復雜任務 15~20 輪maxTokens單輪模型輸出最大 token 數(shù)根據(jù)模型上下文留足工具結果的空間slotCountRunner 同時可承載的會話數(shù)本地模型建議 1~2云端 API 可到 5timeout單次工具調用超時網絡類 30s本地文件類 10stoolRetries工具失敗重試次數(shù)冪等工具 2 次非冪等工具 0 次這張表的每一條都來自真實調參經歷。比如timeout這條我開始沒設置結果某個網絡工具在目標站點無響應時直接掛起整個任務卡了快 10 分鐘。后來給工具加上 30 秒超時Runner 會在超時后把錯誤信息返回給模型模型自己決定是重試還是換方案整個系統(tǒng)立刻靈活了很多。3. 核心循環(huán)深入從意圖到動作的每一步3.1 意圖識別與任務分解LLM 如何輸出結構化指令執(zhí)行引擎的第一道工序是把自然語言目標變成可執(zhí)行的指令序列。這一步通常不在 Runner 里而是在模型層但 Runner 必須能正確解讀模型的輸出?，F(xiàn)在主流的做法有兩種一種是讓模型輸出function_call格式的原生工具調用另一種是讓模型輸出嚴格的 JSON再由 Runner 里的解析器讀取。我的經驗是不要過度相信模型會嚴格遵守 JSON 格式。哪怕是表現(xiàn)很好的模型在長上下文和工具結果干擾下也可能輸出多余的解釋文字。我處理過一個很典型的情況模型明明應該輸出{tool: read_file, params: {path: xxx}}結果在 JSON 前面加了一句好的我來幫你讀取這個文件如果 Runner 沒有做從文本中提取 JSON 片段的兜底這個調用就直接失敗了。所以一個健壯的執(zhí)行引擎必須內置容錯解析先嘗試嚴格解析失敗后再做提取再失敗才把錯誤返回給模型。3.2 工具調度的決策規(guī)則選哪個工具、傳什么參數(shù)當模型提出多個可能的工具調用時Runner 不能全盤照收它需要基于規(guī)則做決策。這里主要看三件事工具是否在當前注冊表中、參數(shù)是否符合 Schema、是否有足夠的執(zhí)行權限。工具描述的質量會直接決定模型的選擇準確性。你在寫 Skill 時描述不能只寫讀取文件要寫清楚這個工具適合什么場景、有哪些邊界、參數(shù)的含義。讀取文件內容支持普通 UTF-8 文本文件不適合二進制文件返回文件前 200 行——這種描述能極大減少模型誤調用的概率。參數(shù)校驗是另一道關鍵防線。模型可能從上下文里提取了一個并不存在的文件名或者把數(shù)字類型的參數(shù)傳成了字符串。Runner 在調用真實工具之前做一次 Schema 校驗能攔截大部分低級錯誤。有一次模型連續(xù)三次調我的analyze_logs工具參數(shù)里傳的次數(shù)都是負數(shù)如果 Runner 不攔截工具就會返回一堆沒意義的統(tǒng)計攔截之后把校驗錯誤給模型模型自己就意識到傳參數(shù)錯了重新傳了正數(shù)。3.3 結果反饋與上下文更新失敗信號如何進入下一輪工具執(zhí)行完之后返回結果不會直接丟給用戶它會先進入 Runner 的結果處理器。處理器要做三件事把結果格式化成緊湊的消息、把結果注入上下文、判斷結果是否包含失敗信號。結果格式化這一點特別重要。工具可能返回一個巨大的 JSON全量塞進上下文會浪費 token 占用。Runner 通常會做截斷或摘要只保留前 N 個字符。我在做日志分析類 Skill 時工具動輒返回上萬行日志一開始全量回填上下文很快就爆了后來在工具側先做了聚合統(tǒng)計只返回 Top 10 錯誤和統(tǒng)計匯總模型處理起來又快又準。失敗信號的處理同樣關鍵。工具調用失敗超時、權限不足、參數(shù)錯誤不能簡單結束任務Runner 要把失敗原因轉換成模型可理解的自然語言放進上下文讓模型自己決定下一步。比如文件讀取失敗路徑不存在這個信號模型讀完會嘗試列出目錄看看有哪些文件存在而不是直接放棄。這種失敗即反饋的機制是 Agent 能自我糾錯的核心。3.4 迭代剎車的安全邊界設置沒有剎車的 Agent 是危險的。如果模型在一個錯誤分支上打轉或者工具不停地返回同樣的結果任務可能會無限循環(huán)。pi-embedded-runner 提供了多層剎車機制。第一層是maxIterations也就是最多允許的思考-行動輪數(shù)。我一般給普通任務設 10 輪復雜任務 20 輪。超過這個數(shù) Runner 會強制終止并返回已達到最大迭代次數(shù)的提示。第二層是相鄰輪次的相似度檢測如果連續(xù)兩輪模型的工具調用意圖完全相同Runner 會給模型一個警告你剛剛已經做過同樣操作請確認是否需要繼續(xù)。第三層是 token 預算上下文接近模型上限時 Runner 會主動觸發(fā)滑窗把最舊的消息摘要掉而不是盲目擴充。這里我想多說一句安全邊界本質上是給模型一次認錯機會的設計。你不需要把每一條路徑都堵死只需要在失控時軟性打斷然后讓模型意識到自己在重復。實測下來相似度檢測這一條能解決八成左右的循環(huán)問題比硬性中斷體驗好很多。4. 實戰(zhàn)環(huán)境準備與第一個多步任務跑通4.1 處理 WSL 環(huán)境異常與準備 Node 運行時我最初是在 Windows 上嘗試部署 OpenClaw 的結果啟動階段就遇到了社區(qū)里出現(xiàn)頻率很高的那個提示openclaw 無法安全驗證 wsl 環(huán)境。請在 powershell 中運行 wsl -- status。上網一查遇到的人不少這個提示的意思是系統(tǒng)還沒有正確啟用 WSL 2或者默認版本不對。排查思路不復雜。先打開 PowerShell執(zhí)行wsl --status看返回的信息里 WSL 版本是不是 2。如果系統(tǒng)提示適用于 Linux 的 Windows 子系統(tǒng)未安裝就需要先安裝wsl --install。安裝完成后重啟再執(zhí)行wsl --set-default-version 2確保用的是 WSL 2而不是舊版的 WSL 1。還有一個常見問題是在 BIOS 里未開啟虛擬化功能這個用systeminfo檢查虛擬化: 已啟用就能確認。OpenClaw 本身的安裝路徑我建議直接走 Node.js 生態(tài)。先到官網安裝 LTS 版本的 Node.js我用的 20.x然后全局安裝 OpenClaw 就可以。這里有一個比較隱蔽的坑安裝完 Node 之后要重開終端否則 npm 全局路徑不會加載。我第一次就是沒重開終端直接執(zhí)行命令行提示找不到命令折騰了好一會兒。4.2 配置模型通道本地 Ollama 還是云端 API執(zhí)行引擎本身不帶模型它需要連接一個能輸出工具調用意圖的模型后端。兩種主流方式我都試過。本地模型社區(qū)里很多人嘗試用 Ollama 跑 qwen2.5-3b 關聯(lián)到 OpenClaw。好處是免費、本地數(shù)據(jù)不出機器壞處是小模型的工具調用能力比較弱經常不按 JSON 格式輸出。我在跑通之前做了兩個優(yōu)化一是把溫度調到 0 或接近 0減少隨機性二是在配置里給模型填了詳細的工具調用示例。這里要說句公道話3b 這種小模型做簡單問答可以做復雜的多步任務真的比較吃力建議至少 7b 起步有條件直接 14b。云端 API如果你配置了 OpenAI 兼容接口支持 OpenAI、或國內可直連的兼容服務Runner 連接會順利很多。云端模型對工具調用的原生支持更好跑復雜任務的穩(wěn)定性明顯高于本地小模型。缺點是需要考慮 API 費用和隱私問題。我的建議是開發(fā)調試階段用云端 API 把邏輯跑通之后換成本地模型做隱私敏感的任務兩者配合最舒服。配置模型通道時核心是把模型的輸入輸出格式對齊 Runner 的預期。我貼一段我使用的配置思路以 Ollama 為例{ llm: { provider: ollama, baseUrl: http://localhost:11434, model: qwen2.5:7b, temperature: 0, maxTokens: 4096 }, runner: { maxIterations: 15, toolTimeout: 30000, toolRetries: 1 } }你不需要照抄這段重點是注意temperature和maxTokens這兩個值。溫度太高模型就愛自由發(fā)揮格式容易亂maxTokens太低會導致模型輸出到一半就被截斷工具調用意圖不完整。4.3 編寫一個自定義 Skill 并注冊到 Runner光會配置還不夠真正讓執(zhí)行引擎活起來的是自定義 Skill。我以讀取本地文檔并提取配置項為例演示一個最簡 Skill 的寫法。在 OpenClaw 里一個 Skill 通常包含一個描述文件和一個執(zhí)行函數(shù)執(zhí)行函數(shù)用 JavaScript 寫Runner 通過描述文件知道這個工具的名稱和參數(shù)要求。// skill: doc-config-extractor.js export default async function extractConfigItems({ filePath, keyword }) { const fs await import(node:fs); const content await fs.promises.readFile(filePath, utf-8); const lines content.split(\n); const results lines .filter(line line.includes(keyword)) .slice(0, 50); return { lineCount: results.length, matchedLines: results, }; }對應的描述信息需要為這個 Skill 寫明名稱、用途、參數(shù) Schema。描述越具體模型越不容易誤用{ name: extract_config_items, description: 讀取文本文件中包含指定關鍵字的行適合從配置文檔、日志、代碼文件中提取配置項。不適合二進制文件。返回匹配行列表與前 50 行。, parameters: { type: object, properties: { filePath: { type: string, description: 文件絕對路徑或相對路徑 }, keyword: { type: string, description: 搜索關鍵字大小寫敏感 } }, required: [filePath, keyword] } }把這兩個文件放到 OpenClaw 的 skills 目錄后重啟 Runner執(zhí)行引擎就會自動把新 Skill 注冊進工具表。驗證注冊成功的方法是直接給 Agent 發(fā)一條使用該工具的任務然后看 Runner 的日志里是否有該 Skill 的加載記錄。4.4 跑通檢索整理輸出的三步任務環(huán)境就緒后我做的第一個完整測試是一個三步任務讀取項目文檔里所有包含API_KEY的行去重后按文件名分組生成一個匯總表格。Agent 的實際執(zhí)行路徑可能和我預想的不完全一樣但大體會是先列目錄 → 讀取文檔 → 調用extract_config_items→ 匯總 → 生成表格。整個過程經歷了大概 6 輪思考-行動循環(huán)每輪我都盯著 Runner 日志看確認工具調用意圖被正確解析和執(zhí)行。第一次跑的時候并沒有一次成功。問題出在模型調用了extract_config_items之后返回結果里有 200 多行匹配數(shù)據(jù)我把這些全塞進了下一輪上下文模型很快就暈了最后的表格殘缺不全。后來我給工具返回結果加了截斷只保留前 30 行匹配并且在工具側先做了簡單的去重統(tǒng)計問題才消失。這個例子再次印證了我在第 3 章說的工具返回結果必須在進入上下文之前做瘦身否則模型再強也處理不了海量明細。5. 運行中的坑與調優(yōu)工具返回格式、上下文與超時5.1 工具返回值不規(guī)范導致的LLM 發(fā)瘋這是執(zhí)行引擎實戰(zhàn)里我遇到最多的一類問題。工具函數(shù)為了自己方便返回的是無格式的純文本、或者嵌套很深的 JSON模型拿到這種結果后很容易產生幻覺開始腦補不存在的信息。一個非常典型的場景我寫了一個查詢服務器狀態(tài)的工具返回值里有一段純文本日志連接正常 200 OK。結果模型下一輪直接宣稱服務器連接完全正常延遲 5ms丟包率 0%?？晌业墓ぞ吒緵]返回延遲和丟包率。這就是典型的模型腦補——它根據(jù)上下文風格順嘴編了細節(jié)。解決方案分兩層。工具側返回值盡量結構化用簡單扁平的 JSONkey 命名清晰并明確注明以下數(shù)據(jù)為原始結果未加工Runner 側在工具描述里加一條約定工具返回的是原始數(shù)據(jù)只能基于返回字段做分析不得推斷字段之外的信息。加了這條約束后模型腦補的現(xiàn)象明顯減少了但說實話無法百分百消除所以關鍵數(shù)據(jù)你一定要在工具側做好驗證和統(tǒng)計不要指望模型忠實轉述。5.2 上下文窗口逼近限制時的處理策略執(zhí)行引擎是個上下文貪吃鬼每輪模型輸出、每輪工具結果、每輪狀態(tài)記錄都在累積 token。當你的任務超過 10 輪、工具又返回大段數(shù)據(jù)時上下文很容易逼近模型窗口上限。我在 pi-embedded-runner 里驗證過的策略有三個按優(yōu)先級排序截斷優(yōu)先、摘要其次、滑窗兜底。工具返回結果在進入上下文前先截斷這是最廉價也最有效的方案如果截斷后仍接近上限Runner 會把最早幾輪思考-行動記錄進行摘要壓縮換成一行簡短的第 1 輪完成了文件列表獲取最后一道是滑窗直接把最早的對話內容丟棄。三種策略的取舍值得注意。截斷有丟失信息的風險但工具結果的重復度通常不高丟失尾部明細影響較小摘要有信息失真風險適合處理歷史過程而不是關鍵數(shù)據(jù)滑窗則會讓模型失去記憶導致后半程任務可能遺漏早期的約束條件。我的建議是盡量讓每個工具在源頭就返回精簡結果別依賴 Runner 做售后處理。5.3 超時、重試與冪等設計執(zhí)行引擎在真實環(huán)境中工具調用失敗是常態(tài)不是異常。網絡抖動、文件鎖定、外部服務無響應任何一項都能讓工具調用失敗。Runner 如何處理失敗直接決定了 Agent 的穩(wěn)定性。超時設置是第一道防線。不給超時的工具調用是定時炸彈。我給網絡類工具統(tǒng)一設 30 秒超時本地文件類工具 10 秒超過就拋異常并把異常轉成自然語言錯誤返回給模型。重試策略要區(qū)分工具是否冪等。冪等工具只讀操作可以重試非冪等工具寫操作、發(fā)消息重試要格外小心。有一次我寫的通知類 Skill 沒做冪等控制Runner 自動重試了兩次結果用戶收到了三條重復通知。后來在代碼里加了請求去重 ID才解決問題。5.4 觀察軌跡如何用日志審查 Agent 的思考過程執(zhí)行引擎比純聊天模型強的地方就是它可以復盤。Runner 只要開啟軌跡日志每一輪的模型輸出、工具調用意圖、參數(shù)校驗結果、工具返回摘要都會被記錄下來。遇到 Agent 行為異常時你完全可以像回放監(jiān)控錄像一樣看到它在哪一輪跑偏了。我強烈建議在調試階段開啟詳細日志線上運行階段至少保留錯誤級日志。有一次我的 Agent 莫名其妙總是漏掉任務里的一項要求怎么調 prompt 都沒用后來翻軌跡日志發(fā)現(xiàn)模型在第三輪就已經忘記了原始目標自顧自地推進到了下一步。找到原因后我改了系統(tǒng)提示詞要求模型在每輪開始前先復述一次原始目標——問題立即解決。這種問題沒有軌跡日志基本不可能定位。6. 我的一點實操體會6.1 對執(zhí)行引擎選型與配置的建議如果你準備在自己的項目里接 OpenClaw我的建議是先別急著堆功能花一天時間把pi-embedded-runner的配置和日志機制摸清楚。這個時間絕對值得因為后面你調試任何 Skill、處理任何Agent 不聽話的問題都會回到執(zhí)行引擎這個層面。具體來說一是把工具返回值瘦身變成你寫 Skill 的默認習慣不要指望模型和 Runner 處理你隨手丟回去的海量數(shù)據(jù)二是重視工具描述的質量你花在寫描述上的時間會在模型調用準確率上成倍賺回來三是建立軌跡日志的復盤習慣Agent 不是黑盒它每一步都有痕跡善用痕跡能省掉大量猜謎時間。6.2 這個執(zhí)行引擎未來還能怎么擴展往大了說pi-embedded-runner 這種嵌入式 Runner 的設計思路很適合往多 Agent 協(xié)作方向延伸。每個 Runner 是一個迷你執(zhí)行單元多個 Runner 之間可以通過消息傳遞協(xié)作——這正好呼應了社區(qū)里討論的 agents anywhere 和多 AI 協(xié)作的方向。我個人的下一步計劃是嘗試在同一個進程里跑多個 Runner 實例分別負責規(guī)劃者和執(zhí)行者角色并探索更精細的權限隔離方案。如果你想更進一步還可以研究怎么把 Runner 的事件流接入外部監(jiān)控系統(tǒng)做可視化回放。無論如何執(zhí)行引擎這個層面你理解得越深玩 Agent 的上限就越高。