1. 從命令行到智能體Agent-Reach 到底想解決什么問題第一次看到 Agent-Reach 這個名字我下意識把它歸類成又一個套殼 CLI 工具。畢竟這兩年命令行里冒出來的 AI 工具太多了從各種 codex cli、zcode cli 到 minimax cli、trae cli名字一個比一個花哨裝完之后真正能留在日常工具鏈里的沒幾個。但把 Agent-Reach 拆開看它的定位其實比命令行聊天框要重得多——它想干的事情是讓一個 AI Agent 真正夠得著外部世界也就是 Reach 這個詞的字面意思觸達。傳統(tǒng) CLI 工具的邊界很清楚你敲一條命令它執(zhí)行一個動作返回一個結(jié)果結(jié)束。而 Agent-Reach 這類工具的核心變化在于它把 CLI 從執(zhí)行入口升級成了Agent 的調(diào)度中樞。你在終端里輸入的不再是一條條孤立的指令而是一個目標Agent 自己去拆解任務(wù)、調(diào)用工具、讀取文件、訪問接口、驗證結(jié)果最后把成品交回給你。這中間涉及的關(guān)鍵詞——CLI、AI Agent、ai agent 搭建、ai agent 部署、ai agent 主流架構(gòu)——基本都指向同一個問題怎么讓 Agent 從能聊天變成能干活。我之所以愿意花時間研究它是因為踩過一個很典型的坑。早些年我用某個 CLI 工具做批量文件處理腳本寫到一半發(fā)現(xiàn)它只能處理單一目錄跨目錄就得手動改路徑改到最后腳本比手動操作還慢。那時候我就在想如果有一個 Agent 能理解把這三個目錄里所有符合規(guī)則的日志合并、去重、按時間排序、導出成一份報告這種復合意圖并且自己決定先干什么后干什么那才是真正省事。Agent-Reach 瞄準的就是這個場景它把意圖理解 任務(wù)編排 工具調(diào)用 結(jié)果校驗這條鏈路收進了一個命令行入口。適合看這篇內(nèi)容的人我大致分三類。第一類是已經(jīng)用過 codex cli、gitlab cli 這類工具想進一步搞清楚 Agent 化 CLI 怎么搭、怎么部署的開發(fā)者第二類是在做 ai agent 項目、需要一套可復用的命令行交互層和工具調(diào)用規(guī)范的人第三類是對 ai agent 學習路線感興趣想找一個具體項目當抓手而不是停留在看架構(gòu)圖階段的入門者。不管你是哪一類下面我會把 Agent-Reach 這類工具的設(shè)計思路、核心細節(jié)、實操流程和踩坑經(jīng)驗完整拆一遍盡量做到你看完能自己動手復現(xiàn)一個最小可用版本。2. 整體設(shè)計與思路拆解為什么是 CLI 而不是 Web 界面2.1 CLI 作為 Agent 入口的天然優(yōu)勢很多人第一反應(yīng)是Agent 不是應(yīng)該配個漂亮的 Web 界面嗎為什么非要做成 CLI這個問題我在實際項目里反復權(quán)衡過結(jié)論是 CLI 在 Agent 場景下有幾個 Web 界面替代不了的優(yōu)勢。第一是管道能力。命令行天然支持 stdin/stdout 的流式傳遞Agent 的輸出可以直接喂給下一個命令比如把 Agent 生成的報告直接 pipe 給 grep 做過濾或者重定向到文件。Web 界面要做到這一點得額外寫導出、下載、再導入的邏輯鏈路長且容易斷。第二是可腳本化。CLI 工具可以被 shell 腳本、CI 流水線、定時任務(wù)直接調(diào)用這意味著 Agent 能嵌進現(xiàn)有的自動化體系里而不是另起一套。第三是低交互成本。對于熟練用戶敲一條命令比點五次鼠標快得多尤其是在需要反復調(diào)試 Agent 行為的階段CLI 的反饋循環(huán)更短。Agent-Reach 選擇 CLI 作為主入口本質(zhì)上是在賭一件事Agent 的高頻使用場景是開發(fā)者和運維人員的日常工作流而不是普通消費者的閑聊。這個判斷我認為是對的因為目前 ai agent 真正產(chǎn)生穩(wěn)定價值的場景集中在代碼生成、日志分析、數(shù)據(jù)處理、部署編排這些偏工程的方向而這些方向的人本來就活在終端里。2.2 Agent 架構(gòu)選型ReAct 還是 Plan-and-Execute拆到架構(gòu)層面Agent-Reach 這類工具繞不開一個核心選擇用 ReAct 模式還是 Plan-and-Execute 模式。這兩個詞在 ai agent 主流架構(gòu)的討論里出現(xiàn)頻率極高我用大白話解釋一下區(qū)別。ReAct 是邊想邊做Agent 每一步都先推理一下當前該干什么然后執(zhí)行一個動作觀察結(jié)果再推理下一步。它的優(yōu)點是靈活遇到意外情況能及時調(diào)整缺點是容易迷路任務(wù)一長就可能陷入循環(huán)或者偏離目標。Plan-and-Execute 是先規(guī)劃再執(zhí)行Agent 先把整個任務(wù)拆成步驟清單然后按順序執(zhí)行執(zhí)行中如果發(fā)現(xiàn)計劃有問題再回頭改計劃。它的優(yōu)點是全局感強適合多步驟復雜任務(wù)缺點是前期規(guī)劃如果錯了后面全盤皆輸而且規(guī)劃本身也要消耗不少 token。Agent-Reach 在實際實現(xiàn)里我觀察到它更偏向一種混合模式對于短任務(wù)用 ReAct 快速響應(yīng)對于長任務(wù)先做一次輕量規(guī)劃把任務(wù)拆成若干子目標每個子目標內(nèi)部再用 ReAct 執(zhí)行。這種設(shè)計的好處是兼顧了靈活性和全局性代價是實現(xiàn)復雜度上升。如果你自己要搭一個類似的 Agent我建議先從純 ReAct 起步跑通之后再引入規(guī)劃層不要一上來就搞混合否則調(diào)試起來會很痛苦。2.3 工具調(diào)用層Agent 的手怎么設(shè)計Agent 再聰明沒有工具調(diào)用能力就是個嘴炮。Agent-Reach 的工具調(diào)用層設(shè)計我認為是它最值得借鑒的部分。它把工具分成幾類文件系統(tǒng)操作、命令執(zhí)行、網(wǎng)絡(luò)請求、以及外部服務(wù)集成。每一類工具都有明確的輸入輸出 schemaAgent 只能通過這些 schema 調(diào)用不能隨意發(fā)揮。這樣做的好處是可控。你想想如果 Agent 能隨意執(zhí)行任意 shell 命令那風險就太大了一條 rm -rf 就能讓你哭。通過 schema 約束Agent 只能調(diào)用你預先定義好的工具每個工具的行為邊界是清晰的。這也是為什么很多 ai agent 項目在部署階段會強調(diào)工具白名單機制本質(zhì)上就是把 Agent 的能力關(guān)進籠子里讓它在你允許的范圍內(nèi)活動。提示設(shè)計工具 schema 時輸入?yún)?shù)盡量用結(jié)構(gòu)化格式如 JSON Schema不要用自然語言描述參數(shù)。自然語言描述會讓 Agent 產(chǎn)生歧義理解導致調(diào)用失敗率飆升。2.4 為什么用 Rust 而不是 Python熱詞里出現(xiàn)了基于 rust 語言 ai agent這其實是個很有意思的選型問題。Python 在 AI 生態(tài)里是絕對主流langchain、langgraph 這些框架都是 Python 的為什么還要用 Rust 寫 Agent我的理解是Rust 的優(yōu)勢在于性能和部署。CLI 工具如果啟動一次要等兩三秒Python 解釋器加載 依賴導入用戶體驗會很差。Rust 編譯出的二進制文件啟動幾乎是瞬時的而且不依賴運行時環(huán)境扔到任何機器上都能跑。對于需要頻繁調(diào)用的 CLI Agent 來說這個差異很關(guān)鍵。另外 Rust 的并發(fā)模型在處理ai agent 怎么扛并發(fā)這個問題上有天然優(yōu)勢多個 Agent 任務(wù)并行執(zhí)行時Rust 的異步運行時能更高效地調(diào)度。但代價也很明顯Rust 的 AI 生態(tài)遠不如 Python 成熟很多模型 SDK、向量庫、工具鏈都得自己造輪子。所以現(xiàn)實中更常見的做法是混合架構(gòu)核心調(diào)度和 CLI 層用 Rust 保證性能和部署體驗AI 推理和復雜邏輯用 Python 服務(wù)承載兩者通過本地接口通信。Agent-Reach 如果要在生產(chǎn)環(huán)境扛并發(fā)大概率也是走這條路。3. 核心細節(jié)解析與實操要點3.1 環(huán)境準備與依賴安裝動手之前先把環(huán)境理清楚。Agent-Reach 這類工具通常需要以下幾類依賴我按優(yōu)先級列一下。依賴類型具體項作用是否必需運行時Rust 工具鏈cargo編譯和運行核心程序是模型接口大模型 API KeyAgent 的推理能力來源是通信層本地 HTTP 服務(wù)Rust 與 Python 邏輯通信視架構(gòu)而定工具依賴git、ripgrep 等Agent 調(diào)用的外部工具按需配置管理環(huán)境變量或配置文件存放密鑰和參數(shù)是安裝 Rust 工具鏈這一步如果你用的是 Linux 或 macOS官方腳本一行搞定curl --proto https --tlsv1.2 -sSf https://sh.rustup.rs | sh裝完之后記得 source 一下環(huán)境變量或者重開終端。驗證是否成功cargo --version rustc --versionWindows 用戶我建議用 WSL原生 Windows 下編譯 Rust 項目偶爾會遇到鏈接器問題WSL 里體驗順暢得多。這一步看著簡單但我見過不少人卡在這里尤其是公司內(nèi)網(wǎng)環(huán)境下rustup 的下載源可能被限制需要提前配置鏡像。3.2 配置文件的結(jié)構(gòu)設(shè)計Agent-Reach 的配置文件通常分三塊模型配置、工具配置、行為配置。我拿一個典型的結(jié)構(gòu)舉例[model] provider openai-compatible base_url https://your-endpoint/v1 api_key_env AGENT_REACH_API_KEY model_name your-model max_tokens 4096 temperature 0.2 [tools] enabled [file_read, file_write, shell_exec, http_request] shell_whitelist [ls, cat, grep, find, git] [behavior] max_iterations 15 planning_mode hybrid timeout_seconds 120這里有幾個參數(shù)值得展開說。temperature 設(shè)成 0.2而不是默認的 0.7是因為 Agent 任務(wù)需要穩(wěn)定和可復現(xiàn)太高的隨機性會讓同樣的輸入產(chǎn)生不同的執(zhí)行路徑調(diào)試時你會瘋掉。max_iterations 設(shè)成 15是防止 Agent 陷入死循環(huán)的保險絲超過這個步數(shù)就強制終止并返回當前結(jié)果。shell_whitelist是安全底線只允許 Agent 執(zhí)行白名單里的命令這個列表越短越安全。注意api_key 千萬不要直接寫在配置文件里然后提交到 git。用環(huán)境變量引用如上面的 api_key_env配置文件本身可以進版本庫密鑰留在本地環(huán)境。3.3 工具調(diào)用的實現(xiàn)細節(jié)工具調(diào)用是 Agent 的手實現(xiàn)質(zhì)量直接決定 Agent 好不好用。我以 file_read 這個最基礎(chǔ)的工具為例講一下實現(xiàn)要點。一個合格的 file_read 工具輸入應(yīng)該是文件路徑輸出是文件內(nèi)容但中間要處理很多邊界情況文件不存在怎么辦、文件太大怎么辦、編碼不是 UTF-8 怎么辦、路徑是相對路徑怎么解析。這些細節(jié)如果不在工具層處理就會變成 Agent 的意外導致它反復重試或者報錯退出。def file_read(path: str, max_bytes: int 100000) - dict: import os abs_path os.path.abspath(path) if not os.path.exists(abs_path): return {status: error, message: ffile not found: {abs_path}} size os.path.getsize(abs_path) if size max_bytes: return {status: error, message: ffile too large: {size} bytes, limit {max_bytes}} try: with open(abs_path, r, encodingutf-8) as f: content f.read() return {status: ok, content: content, size: size} except UnicodeDecodeError: return {status: error, message: file is not valid utf-8 text}注意這里返回的是結(jié)構(gòu)化的 dict而不是直接拋異常。為什么因為 Agent 需要理解發(fā)生了什么而不是被一個異常打斷。返回結(jié)構(gòu)化的錯誤信息Agent 就能根據(jù)錯誤類型決定下一步文件不存在就換個路徑文件太大就分段讀取編碼不對就換工具。這種錯誤也是信息的設(shè)計思路是 Agent 工具層和普通函數(shù)庫最大的區(qū)別。3.4 提示詞工程讓 Agent 知道自己的邊界Agent 的行為很大程度上由系統(tǒng)提示詞決定。Agent-Reach 這類工具的系統(tǒng)提示詞通常包含幾塊內(nèi)容角色定義、可用工具清單、行為約束、輸出格式要求。角色定義要具體不要寫你是一個有用的助手這種廢話。寫你是一個命令行環(huán)境下的任務(wù)執(zhí)行 Agent你的職責是把用戶的自然語言目標拆解成可執(zhí)行的步驟并通過調(diào)用工具完成它。工具清單要準確列出每個工具的名字、用途、參數(shù)格式。行為約束要明確告訴它什么不能做比如不要執(zhí)行白名單之外的命令、不要修改用戶沒有明確要求修改的文件。輸出格式要求則規(guī)定它每一步的思考過程怎么呈現(xiàn)方便你調(diào)試。我踩過的一個坑是提示詞寫得太客氣用了大量請、盡量、如果可以這類詞結(jié)果 Agent 遇到模糊情況就傾向于詢問用戶而不是自己決策導致交互輪次暴增。后來我把措辭改成明確的指令式比如當信息不足時優(yōu)先使用工具獲取信息而不是詢問用戶Agent 的自主性明顯提升。提示詞的語氣會直接影響 Agent 的行為風格這一點很多人沒意識到。4. 實操過程與核心環(huán)節(jié)實現(xiàn)4.1 從零搭建一個最小可用 Agent下面我?guī)阕咭槐樽钚】捎?Agent 的搭建流程。目標很簡單讓 Agent 接收一個自然語言任務(wù)比如統(tǒng)計當前目錄下所有 Python 文件的代碼行數(shù)然后自己完成它。第一步定義工具集。這個任務(wù)至少需要兩個工具列目錄和讀文件。列目錄工具返回指定目錄下的文件列表讀文件工具返回文件內(nèi)容。def list_dir(path: str .) - dict: import os try: entries os.listdir(path) return {status: ok, entries: entries} except Exception as e: return {status: error, message: str(e)} def count_lines(path: str) - dict: try: with open(path, r, encodingutf-8) as f: lines f.readlines() return {status: ok, lines: len(lines)} except Exception as e: return {status: error, message: str(e)}第二步構(gòu)造 Agent 循環(huán)。核心邏輯是把任務(wù)和工具清單發(fā)給模型模型返回一個工具調(diào)用請求執(zhí)行工具把結(jié)果發(fā)回模型模型再決定下一步直到模型返回最終答案。def run_agent(task: str, max_steps: int 10): messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: task} ] for step in range(max_steps): response call_model(messages, toolsTOOL_SCHEMAS) if response.is_final: return response.content tool_name response.tool_name tool_args response.tool_args result dispatch_tool(tool_name, tool_args) messages.append({role: assistant, content: response.raw}) messages.append({role: tool, content: json.dumps(result)}) return 達到最大步數(shù)限制任務(wù)未完成第三步跑起來測試。輸入統(tǒng)計當前目錄下所有 Python 文件的代碼行數(shù)觀察 Agent 的執(zhí)行路徑。正常情況下它應(yīng)該先調(diào)用 list_dir 拿到文件列表篩選出 .py 文件然后逐個調(diào)用 count_lines最后匯總結(jié)果。4.2 參數(shù)計算max_iterations 到底設(shè)多少合適max_iterations 這個參數(shù)很多人隨手設(shè)一個其實它應(yīng)該根據(jù)任務(wù)復雜度估算。我的經(jīng)驗公式是max_iterations ≈ 任務(wù)子步驟數(shù) × 2 3。乘以 2 是因為每個子步驟可能需要執(zhí)行 驗證兩步加 3 是留給意外情況的緩沖。以剛才的統(tǒng)計任務(wù)為例假設(shè)目錄下有 5 個 Python 文件子步驟是列目錄1步 逐個讀文件5步 匯總1步 7 步那么 max_iterations 設(shè)成 7×2317 比較穩(wěn)妥。設(shè)太小任務(wù)做不完設(shè)太大又失去了防死循環(huán)的意義。這個公式不是絕對的但比拍腦袋強。4.3 并發(fā)處理多個 Agent 任務(wù)同時跑ai agent 怎么扛并發(fā)是個高頻問題。單機跑一個 Agent 任務(wù)很簡單但同時跑十個、一百個就是另一回事了。核心矛盾在于模型 API 調(diào)用是網(wǎng)絡(luò) IO等待時間長工具執(zhí)行可能是 CPU 密集或 IO 密集多個任務(wù)之間可能爭搶同一份資源。我的處理思路是分層。第一層是任務(wù)隊列所有任務(wù)先進隊列由調(diào)度器分配執(zhí)行槽位。第二層是異步執(zhí)行模型調(diào)用和工具調(diào)用都用異步 IO避免線程阻塞。第三層是資源隔離每個 Agent 任務(wù)有獨立的工作目錄和上下文避免互相干擾。import asyncio async def run_task(task_id: str, task: str, semaphore: asyncio.Semaphore): async with semaphore: result await run_agent_async(task) return {task_id: task_id, result: result} async def main(tasks: list): semaphore asyncio.Semaphore(10) # 最多同時跑10個 coros [run_task(t[id], t[content], semaphore) for t in tasks] results await asyncio.gather(*coros) return results這里的 semaphore 是關(guān)鍵它限制了同時進行的任務(wù)數(shù)防止把模型 API 打爆或者把本地資源耗盡。10 這個數(shù)字要根據(jù)你的 API 配額和機器性能調(diào)整我一般從 5 開始試穩(wěn)定后再往上加。4.4 部署從本地腳本到常駐服務(wù)本地跑通之后下一步是部署成常駐服務(wù)。Agent-Reach 這類工具常見的部署形態(tài)有兩種一種是 CLI 常駐進程通過本地 socket 接收請求另一種是 HTTP 服務(wù)通過端口接收請求。CLI 常駐進程的好處是啟動快、資源占用低適合個人使用。HTTP 服務(wù)的好處是能被其他程序調(diào)用適合團隊協(xié)作。我個人的選擇是兩者都留日常自己用走 CLI需要集成到其他系統(tǒng)時走 HTTP。部署時要注意幾個點。日志要分級Agent 的思考過程、工具調(diào)用、錯誤信息分開記錄方便排查。配置要外置不同環(huán)境用不同配置不要把配置寫死在代碼里。健康檢查要有服務(wù)掛了要能自動重啟。資源限制要設(shè)單個任務(wù)的內(nèi)存和 CPU 使用要有上限防止一個失控的任務(wù)拖垮整個服務(wù)。5. 常見問題與排查技巧實錄5.1 Agent 陷入循環(huán)怎么辦這是最常見的問題表現(xiàn)是 Agent 反復調(diào)用同一個工具或者在不同工具之間來回橫跳就是不給最終答案。原因通常有三個工具返回的信息不足以讓 Agent 做決策、提示詞沒有明確何時停止、任務(wù)本身描述有歧義。排查思路先看日志確認 Agent 在循環(huán)的哪一步卡住。如果是工具返回信息不足就補充工具的返回內(nèi)容如果是提示詞問題就在系統(tǒng)提示詞里加一句當你已經(jīng)獲得足夠信息時立即給出最終答案不要重復調(diào)用工具如果是任務(wù)歧義就在任務(wù)描述里補充約束條件。我遇到過一個典型案例Agent 反復讀取同一個文件因為它不確定文件內(nèi)容是否完整。后來我在 file_read 的返回里加了一個 total_lines 字段Agent 看到這個字段就知道文件讀完了循環(huán)立刻停止。給 Agent 提供明確的完成信號比讓它自己判斷要可靠得多。5.2 工具調(diào)用失敗率高的排查工具調(diào)用失敗通常表現(xiàn)為參數(shù)格式錯誤、工具名拼寫錯誤、或者參數(shù)值超出范圍。排查時先看模型返回的原始 tool_call 內(nèi)容確認參數(shù)格式是否符合 schema。問題現(xiàn)象可能原因解決方法工具名不存在提示詞里工具清單和實際注冊的不一致統(tǒng)一工具注冊表從同一來源生成提示詞參數(shù)類型錯誤schema 定義不清晰用 JSON Schema 嚴格定義參數(shù)類型參數(shù)值越界缺少范圍校驗在工具實現(xiàn)里加參數(shù)校驗和友好錯誤提示調(diào)用超時工具執(zhí)行時間過長加超時機制超時返回錯誤讓 Agent 決策一個實用技巧是在工具返回里帶上建議下一步。比如文件不存在時返回里附帶當前目錄下的文件列表Agent 看到這個就能直接選一個正確的路徑而不是盲目重試。5.3 模型輸出不穩(wěn)定的處理同樣的任務(wù)有時候 Agent 一次就做對有時候要折騰半天。這種不穩(wěn)定性主要來自模型的隨機性。降低隨機性的手段有幾個temperature 調(diào)低、提示詞更明確、給 few-shot 示例、限制輸出格式。我實測下來給一兩個 few-shot 示例對穩(wěn)定性的提升最明顯。比如在系統(tǒng)提示詞里放一個任務(wù)→執(zhí)行步驟→最終答案的完整示例Agent 就會模仿這個模式輸出結(jié)構(gòu)穩(wěn)定很多。代價是提示詞變長消耗更多 token但換來的是可靠性這筆賬劃算。5.4 安全相關(guān)的坑Agent 能執(zhí)行命令、讀寫文件安全風險是實打?qū)嵉?。我總結(jié)了幾條底線命令白名單必須要有不能讓 Agent 執(zhí)行任意 shell文件寫入要限制目錄不能讓 Agent 寫到系統(tǒng)目錄網(wǎng)絡(luò)請求要限制域名不能讓 Agent 訪問任意地址敏感操作要二次確認比如刪除文件、修改配置。注意不要因為方便就放開這些限制。我見過有人為了調(diào)試方便把白名單關(guān)了結(jié)果 Agent 在一次任務(wù)里誤刪了重要文件。安全限制不是障礙是保險。5.5 常見問題速查表癥狀優(yōu)先排查方向快速驗證方法Agent 不調(diào)用工具提示詞是否包含工具清單打印發(fā)給模型的完整 promptAgent 調(diào)用工具但結(jié)果不對工具實現(xiàn)是否有 bug單獨測試工具函數(shù)任務(wù)執(zhí)行到一半中斷是否觸發(fā) max_iterations查看日志步數(shù)響應(yīng)特別慢模型 API 延遲或工具阻塞分別計時模型調(diào)用和工具調(diào)用并發(fā)時任務(wù)互相干擾上下文是否隔離檢查工作目錄和變量作用域6. 從 Agent-Reach 延伸出去的幾個方向把 Agent-Reach 這類工具跑通之后你會發(fā)現(xiàn)它能延伸的場景比想象中多。我分享幾個自己試過或者正在試的方向。第一個方向是把它接進 CI 流水線。比如每次提交代碼后讓 Agent 自動檢查代碼風格、跑測試、生成變更摘要。這比寫死板的腳本靈活因為 Agent 能處理這次改動比較特殊的情況。第二個方向是做數(shù)據(jù)處理管道。日志清洗、格式轉(zhuǎn)換、異常檢測這些任務(wù)用 Agent 編排比寫一堆膠水腳本可維護性高。第三個方向是個人知識管理。讓 Agent 定期整理筆記、提取待辦、生成周報把零散信息變成結(jié)構(gòu)化輸出。但我要潑一盆冷水不是所有任務(wù)都適合 Agent。如果一個任務(wù)步驟固定、邏輯清晰、沒有歧義那寫個腳本比用 Agent 快得多也穩(wěn)得多。Agent 的價值在于處理需要判斷的場景而不是替代所有自動化。我見過有人硬要把簡單的文件重命名任務(wù)做成 Agent結(jié)果又慢又不穩(wěn)定純屬自找麻煩。判斷一個任務(wù)適不適合 Agent我的標準是如果這個任務(wù)交給一個新人你需要跟他解釋很多看情況的規(guī)則那它就適合 Agent如果三句話能說清楚那就寫腳本。最后分享一個我在調(diào)試 Agent 時的小習慣把每次任務(wù)的完整執(zhí)行軌跡存下來包括輸入、每一步的模型輸出、工具調(diào)用和返回、最終結(jié)果。攢夠幾十條之后你會發(fā)現(xiàn)失敗案例有明顯的模式針對這些模式改提示詞或者改工具比盲目調(diào)參有效得多。這個習慣幫我省了大量時間也讓我對 Agent 的行為有了更直觀的理解。