做了一年多 AI Agent 開發(fā)我越來越認同一個判斷Agent 的真正差異不在模型多強而在它“夠得著”多少東西。模型再聰明如果連瀏覽器都沒法打開、文件沒法讀寫、外部服務(wù)沒法調(diào)用那它充其量是個高級聊天框。我最近在做的這個項目代號就叫 Agent-Reach核心理念很簡單——把 Agent 從對話里解放出來讓它通過工具、技能、記憶和安全邊界真正觸達外部世界并完成任務(wù)。這個項目做下來我把 Agent 開發(fā)里踩過的坑幾乎都重新踩了一遍架構(gòu)選型、工具調(diào)用、上下文管理、安全控制、評測閉環(huán)。這篇文章就圍繞 Agent-Reach 的記錄展開講清楚我在設(shè)計 Agent 架構(gòu)、搭建 Agent 框架、處理 Agent 記憶和 Agent 安全時的具體做法。不管你是剛準備入門 Agent 開發(fā)還是已經(jīng)在用 LangChain、Dify、CrewAI 這類框架搭過原型都應(yīng)該能從這篇文章里找到一些能直接抄作業(yè)的東西。1. 為什么是 Agent-Reach這個項目的起點和它想解決的問題1.1 一個容易被低估的問題Agent 到底“夠得著”什么在做 Agent-Reach 之前我做過一個內(nèi)部知識庫問答機器人效果不錯但它不是 Agent因為它只會“答”不會“做”。后來業(yè)務(wù)方提了個需求能不能讓機器人幫忙查詢訂單、導出報表、跟進異常流程這就從 RAG 走到了 Agent 開發(fā)。我這才意識到真正的分水嶺不是對話能力而是“觸達能力”?！坝|達”是個很具體的工程問題Agent 要調(diào)用哪些外部能力參數(shù)怎么傳結(jié)果怎么回中間出錯怎么辦操作會不會有危險模型沒有手工具就是它的手而 Agent-Reach 的全部工作就是給模型配好這套手并且保證每一只手伸出去之后都能安全收回來。這也是項目名 Reach 的由來——不是“搜索”不是“回答”而是“到達”。一個任務(wù)無論多復雜最終都要落到某個具體動作上讀寫文件、請求接口、生成圖片、更新數(shù)據(jù)庫。Agent 能不能到達那個動作、完成那個動作決定了它到底是玩具還是生產(chǎn)力工具。1.2 Agent-Reach 的項目定位與功能范圍Agent-Reach 不是一個從零自研框架的大工程而是一個以“任務(wù)可達”為目標的 Agent 開發(fā)項目。它的目標很樸素給定一個自然語言任務(wù)Agent 能自主完成規(guī)劃、執(zhí)行、驗證、匯報四步閉環(huán)。這里我把功能范圍劃成五條主線工具與技能層Agent 能通過注冊機制調(diào)用外部工具每個工具都有清晰的名稱、描述、參數(shù)結(jié)構(gòu)和權(quán)限等級。任務(wù)編排層拆解復雜任務(wù)串聯(lián)多個步驟支持單 Agent 和多 Agent 協(xié)作。記憶層區(qū)分短期工作記憶和長期記憶避免上下文無限膨脹。安全與沙箱關(guān)鍵操作受限執(zhí)行超時、失敗、越權(quán)都有兜底。評測與觀測有可復跑的任務(wù)評測集有全鏈路日志能判斷每次改動是變好還是變壞。這五條主線基本就是各大 Agent 框架都在解決的核心問題。我說得直白一點如果你能自己動手實現(xiàn)一遍這五條主線再用某個框架重新組織一遍你對 Agent 架構(gòu)的理解會比只看文檔深得多。Agent-Reach 就是我做這件事的載體。這個項目適合誰我按自己的經(jīng)驗說兩類人最合適一種是已經(jīng)用現(xiàn)成框架搭過 Chatbot、想進一步理解 Agent 原理的開發(fā)另一種是在做“Agent 應(yīng)用落地”時頻繁遇到工具調(diào)用、記憶、安全問題的工程師。至于零基礎(chǔ)的同學建議先把 Python 基礎(chǔ)和大模型 API 調(diào)用學明白再來看 Agent 架構(gòu)門檻會更低。2. Agent-Reach 的架構(gòu)取舍單Agent、多Agent和框架選擇背后的邏輯2.1 架構(gòu)設(shè)計的第一刀先想清楚任務(wù)邊界我見過很多 Agent 項目死于“一開始就搞多 Agent”。一上來就把一個任務(wù)拆成“主管 Agent 多個專家 Agent”聽起來很高端實際跑起來光協(xié)調(diào)消息就要占掉大量 token角色之間互相“踢皮球”的情況也時有發(fā)生。Agent-Reach 的第一版我堅持用單 Agent 工具編排。單 Agent 的意思是一個大模型實例承擔整個任務(wù)的規(guī)劃與執(zhí)行它自己決定調(diào)用哪個工具、怎么處理工具返回的結(jié)果。這樣做的好處非常直接——調(diào)試路徑最短。一個任務(wù)就是“模型思考 - 調(diào)用工具 - 獲得結(jié)果 - 繼續(xù)思考”的循環(huán)任何一環(huán)出問題看 trace 就能定位。當任務(wù)真正復雜到需要并行處理時我才會把它拆成多 Agent。比如“同時調(diào)研三個競爭對手的產(chǎn)品動態(tài)”單 Agent 串行做太慢這時可以讓一個協(xié)調(diào)者 Agent 把任務(wù)廣播給三個執(zhí)行者 Agent等結(jié)果匯總后再由協(xié)調(diào)者統(tǒng)一輸出。多 Agent 適合的是“物理上可以并行”的任務(wù)而不是“聽起來很復雜”的任務(wù)這個判斷標準是我在這次項目里最重要的收獲之一。2.2 主流Agent框架橫向?qū)Ρ扰c我的選型結(jié)論做架構(gòu)選型時我把搜索熱度最高的幾個方案都試了一遍LangChain、Dify、CrewAI外加一個基于 Rust 的輕量 Agent 運行時。說實話框架沒有絕對的好壞只有適不適合當前階段。我整理了一張對比表框架擅長場景我實際踩到的問題LangChain代碼深度定制、鏈式編排、生態(tài)齊全抽象層太多對新手不友好Debug 時容易陷入“把源碼翻穿”的困境Dify低代碼可視化、快速出 Demo、自帶 API 服務(wù)靈活度受限復雜條件分支不如代碼直觀定位更偏向運營而非研發(fā)CrewAI多 Agent 角色扮演、協(xié)作任務(wù)、文檔清晰多 Agent 協(xié)調(diào)開銷大小任務(wù)用它是殺雞用牛刀Rust Agent性能敏感、端側(cè)部署、低資源占用生態(tài)仍在早期LLM 相關(guān)的 Python 庫用不了迭代效率低最終我的選型結(jié)論是Agent-Reach 的核心編排寫了一個輕量自研層同時保留 LangChain 的 Prompt 和模型封裝習慣并借鑒 CrewAI 的角色設(shè)計。說實話這個選擇也是被“逼”出來的。用現(xiàn)成框架時一旦遇到“工具返回格式不對導致模型反復調(diào)用”“上下文被塞滿后行為漂移”這類問題你很難在框架的抽象層里找到答案反而要自己去讀源碼、改回調(diào)。自研一個極簡編排層雖然代碼量多一點但每個環(huán)節(jié)都長在自己腦子里排錯效率反而更高?？蚣軕?yīng)當是你的工具箱而不是你的天花板。2.3 為什么我把 Rust 放進了備選方案“基于 Rust 語言 AI Agent”能進入熱搜說明關(guān)注端側(cè) Agent 的人越來越多了。我也認真調(diào)研過 Rust 路線Rust 的運行時穩(wěn)定、內(nèi)存安全、部署方便在低資源設(shè)備上跑 Agent 有天然優(yōu)勢。如果 Agent-Reach 要往端側(cè)靠Rust 確實是一個值得押注的方向。但我最終沒有把核心 Agent 用 Rust 來寫原因很現(xiàn)實Agent 開發(fā)是典型的高速迭代場景今天的工具可能是文生圖明天可能是瀏覽器自動化后天可能是訪問企業(yè)內(nèi)部系統(tǒng)。Python 生態(tài)里對應(yīng)的庫幾乎現(xiàn)成而 Rust 這邊很多能力要自己用 FFI 去綁綁一輪下來別家 Agent 已經(jīng)迭代了三個版本。所以我的處理方式是把 Rust 放在邊緣模塊做一些對性能敏感但又不需要頻繁改動的公共組件比如大響應(yīng)內(nèi)容的解析、文件格式轉(zhuǎn)換、正則匹配這類活。核心的思考循環(huán)用 Python底層的“體力活”用 Rust 加速兩邊各取所長。如果你從頭開始做 Agent我的建議也是先用最快的方式跑通閉環(huán)再回頭看性能不要第一步就糾結(jié)語言。3. 工具調(diào)用與Skill機制讓Agent的手真正伸出去3.1 Skill系統(tǒng)設(shè)計的核心原則Agent 開發(fā)的第一個分水嶺是工具調(diào)用能不能做穩(wěn)。我在 Agent-Reach 里把“工具”封裝成“Skill”每個 Skill 就是一個可復用的能力包。設(shè)計 Skill 時我給自己定了三條硬原則名稱和描述必須讓模型一眼看懂什么時候該用。命名要具體描述要寫清楚輸入輸出和邊界條件。比如webpage_to_markdown比fetch_page好因為模型看到后者會困惑“fetch 回來之后呢是給我原文還是給我摘要”參數(shù)結(jié)構(gòu)必須嚴格校驗。Agent 調(diào)用 Skill 時傳的參數(shù)來自模型生成經(jīng)常會出現(xiàn)缺字段、多了字段、類型不對的情況。Skill 入口必須做一層參數(shù)校驗不合格就直接返回可讀的錯誤信息而不是拋異常。執(zhí)行結(jié)果必須結(jié)構(gòu)化。我統(tǒng)一用“狀態(tài) 數(shù)據(jù) 錯誤信息”三件套返回比如{status: ok, data: ...}或{status: error, message: timeout after 10s}。模型拿到結(jié)構(gòu)化的結(jié)果之后才能準確判斷下一步該繼續(xù)還是該換個思路。這三條原則說起來簡單但每一步都有代價。寫完 Skill 注冊表之后我才感受到為什么很多框架把工具調(diào)用單獨做成一塊模型對工具的選擇本質(zhì)上是在做“模式匹配”你的工具描述寫得越像用戶真實需求模型選得越準。描述不清晰后面一切優(yōu)化都是白搭。3.2 一個完整Skill示例網(wǎng)頁保存為MarkdownAgent-Reach 里我最常用的一個 Skill 是把網(wǎng)頁保存成 Markdown。這個能力在文檔整理、競品調(diào)研、資料歸檔里都很實用。實現(xiàn)上我把它拆成四步抓取 HTML、解析主內(nèi)容、轉(zhuǎn)換 Markdown、保存到本地或上傳到知識庫。Skill 的注冊信息長這樣{ name: webpage_to_markdown, description: 抓取指定網(wǎng)頁并轉(zhuǎn)換為Markdown格式適用于保存網(wǎng)頁正文、整理資料、生成文檔, parameters: { type: object, properties: { url: { type: string, description: 需要轉(zhuǎn)換的網(wǎng)頁地址必須是 http/https 開頭的完整URL }, output_dir: { type: string, description: 保存目錄默認使用當前工作目錄下的 downloads 文件夾, default: downloads } }, required: [url] } }真正執(zhí)行時我要做三個額外保護第一只允許抓取白名單域名內(nèi)的頁面避免模型被誘導去訪問內(nèi)網(wǎng)地址第二控制單個頁面大小上限超過 2MB 就拒絕第三設(shè)置十秒超時避免一個壞 URL 卡住整個任務(wù)。這里有個細節(jié)輸出目錄這個參數(shù)我一開始沒加模型每次都會把結(jié)果放到當前目錄導致文件滿天飛。后來我加了個默認值并讓 Skill 返回包含完整路徑的結(jié)果問題立刻解決。別小看這些細節(jié)Agent 跑十幾個步驟時一個“文件去哪了”的小問題就可能讓整個任務(wù)失敗。3.3 沙箱與權(quán)限控制給Agent的“手”戴上手套工具調(diào)用一直是 Agent 安全的重災區(qū)所以 Agent-Reach 從第一天起就把沙箱視為基礎(chǔ)設(shè)施而不是事后補丁。我的分層思路如下第一層是域名白名單和命令白名單。抓網(wǎng)頁只允許白名單域名執(zhí)行 shell 只允許注冊過的命令其它一律拒絕。第二層是環(huán)境隔離。凡是可能產(chǎn)生副作用的代碼比如安裝依賴、執(zhí)行腳本、讀寫系統(tǒng)目錄統(tǒng)一丟到子進程或容器里跑宿主環(huán)境不暴露給模型。第三層是人工審批。對刪除操作、支付操作、外發(fā)消息這類高影響動作Agent 不會直接執(zhí)行而是先生成一個“待確認任務(wù)”等人在控制臺點確認后才放行。這個“三明治”結(jié)構(gòu)看起來繁瑣但在真實場景里非常必要。我見過不少 Agent 項目在演示時很驚艷一上生產(chǎn)就把權(quán)限全部放開結(jié)果模型因為一次 Prompt 注入跑去調(diào)用了不該調(diào)用的接口。沙箱不是限制 Agent 的手腳而是讓它在可控范圍內(nèi)發(fā)揮能力。關(guān)于 Agent 安全我的態(tài)度一貫是寧可讓 Agent 少做一步也不能讓它多做錯一步。4. 記憶與上下文Agent-Reach 的短期工作臺和長期倉庫4.1 三層記憶架構(gòu)Agent 記憶是 Agent 開發(fā)繞不開的話題。模型本身沒有記憶每次調(diào)用開始都是“失憶”狀態(tài)。Agent-Reach 里我設(shè)計了三層記憶對應(yīng)不同的讀寫頻次和數(shù)據(jù)量工作臺記憶當前任務(wù)內(nèi)的關(guān)鍵信息。比如用戶剛說“幫我查一下上海到北京的航班”那出發(fā)地、目的地、日期就應(yīng)該在工作臺里后續(xù)每輪調(diào)用都能引用。摘要記憶當對話太長時把前面的執(zhí)行過程壓縮成一段摘要取代原始對話原文保持上下文不無限膨脹。長期記憶跨任務(wù)的知識沉淀。比如用戶偏好、歷史任務(wù)結(jié)果、常用賬號信息這些會寫入向量庫或結(jié)構(gòu)化數(shù)據(jù)庫供后續(xù)任務(wù)檢索。這個分層最核心的價值是讓 Agent 分得清“哪些信息馬上要用”和“哪些信息以后可能有用”。工作臺里放太多垃圾模型會被噪聲干擾長期記憶里放太多臨時狀態(tài)檢索時又會命中一堆無關(guān)內(nèi)容。我的經(jīng)驗是寧可在摘要記憶階段多花一次模型調(diào)用去整理也不要讓所有原始信息都堆在上下文里。4.2 Token預算與上下文管理實測Token 是 Agent 開發(fā)繞不開的成本指標。很多初學者問“AI Agent token 是什么意思”簡單說Token 就是模型處理文本的最小單位中文通常一個字對應(yīng)一到兩個 Token。Agent 每做一輪思考、每調(diào)用一次工具都要把歷史上下文重新發(fā)給模型所以 Token 消耗是呈“滾雪球”式增長的。我在 Agent-Reach 里跑過一次實際統(tǒng)計一個“調(diào)研三家競品并輸出報告”的任務(wù)原始輸入 1000 Token任務(wù)完成后累計消耗 28000 Token。其中模型思考占 40%工具返回結(jié)果占 45%系統(tǒng)提示詞和框架固定開銷占 15%。也就是說你看到的一小段網(wǎng)頁正文可能吃掉一大半成本。所以控制 Token 不是摳門而是 Agent 能不能持續(xù)跑下去的前提。我的具體做法有三個一是工具返回結(jié)果要做截斷和摘要網(wǎng)頁抓下來先取前 500 字必要時再讓模型針對性讀取二是歷史對話超過一定輪數(shù)后用一次模型調(diào)用把舊內(nèi)容壓成摘要三是為每個任務(wù)設(shè) Token 上限超了就主動終止避免“無限燒錢”式執(zhí)行。按這個配置跑下來單任務(wù)成本大概能省三成而且響應(yīng)速度也快了一圈。5. 安全護欄和穩(wěn)定性自主運行的底線設(shè)計5.1 Agent安全最容易忽略的三個點我常說Agent 安全不是網(wǎng)絡(luò)安全課上的名詞而是每個 Agent 開發(fā)者的日常手感。我自己在 Agent-Reach 里踩過三個典型坑第一個坑是“讀”和“寫”權(quán)限不分。很多 Demo 里工具能讀文件也能寫文件看起來方便但模型只要輸出一個錯誤的路徑就可能覆蓋生產(chǎn)配置。我在權(quán)限模型里強制區(qū)分只讀和讀寫除非任務(wù)明確需要否則絕大多數(shù)工具默認只讀。第二個坑是外部數(shù)據(jù)不可信。Agent 抓到的網(wǎng)頁、收到的郵件、讀到的文檔本質(zhì)上都是不可信輸入。如果這些輸入里包含惡意指令模型可能被“越獄”去執(zhí)行危險操作。所以凡是外部文本要進入 Prompt我都會做一道標記和隔離比如在內(nèi)容前后加上“外部內(nèi)容開始/結(jié)束”的邊界提示并讓模型對這部分內(nèi)容保持懷疑。第三個坑是并發(fā)副作用。多 Agent 同時跑如果兩個 Agent 同時寫同一個文件、調(diào)同一個接口會出現(xiàn)臟寫和請求錯亂。我在任務(wù)執(zhí)行器里給每個寫操作加了鎖和版本號沖突時直接讓其中一個任務(wù)重試。這些設(shè)計不復雜但沒有的話Agent 越自主翻車方式就越五花八門。5.2 運行錯誤處理從終止異常到優(yōu)雅降級熱搜詞里有一條很扎眼“agent execution terminated due to error”翻譯過來就是“Agent 執(zhí)行因錯誤被終止”。這不是什么神秘報錯而是我的 Agent 在超時、接口返回異常、模型連續(xù)輸出無效操作時最常見的結(jié)局。我?guī)缀趺看味紩谌罩纠锟吹剿栴}在于默認處理方式是“直接終止”這等于把失敗完全甩給用戶。Agent-Reach 里我做了一個“三級降級”機制第一步遇到單步錯誤先重試一次可能是網(wǎng)絡(luò)抖動第二步重試還失敗就換一個思路比如從“抓取網(wǎng)頁”降級為“調(diào)用搜索 API 獲取摘要”第三步所有方案都失效才停止并生成一份“失敗報告”說明卡在哪個 Skill、錯誤是什么、可能的修復方向。這套機制讓 Agent-Reach 的“表面失敗”少了很多。我統(tǒng)計過加入三級降級后測試任務(wù)從“遇到錯誤就終止”變?yōu)椤白罱K給出結(jié)果或明確診斷”的比例提高了約 35%。記住一個原則自主 Agent 的價值就在于碰到意外時能自己繞路而不是把每次異常都拋回給人類。6. 評測集與迭代如何證明Agent-Reach真的“到達”了目標6.1 為什么通用評測集救不了你Agent 開發(fā)做到一定階段一定會遇到一個問題怎么判斷它變好了如果只看幾個手工測試的案例你根本分不清這次改動是修復了一個 bug 還是引入了三個新 bug。這也是為什么我堅持為 Agent-Reach 建自己的評測集。市面上的通用 Agent 評測集可以作為參考但不能直接拿來用。原因是 Agent 任務(wù)高度依賴具體環(huán)境和工具你的 Agent 能調(diào)你公司的內(nèi)部系統(tǒng)別家的評測集里沒有這個環(huán)境你的任務(wù)是“整理會議紀要并發(fā)送郵件”評測集可能只會測“從網(wǎng)頁提取信息”。通用評測集的分數(shù)高不代表你的業(yè)務(wù)場景里能跑通。我建議的做法是從真實需求里挑出 30 到 50 條代表性任務(wù)組成一個“個人評測集”。不用多但要覆蓋工具調(diào)用、多步規(guī)劃、信息提取、異常處理幾條主線。每次改代碼之后把這個評測集完整跑一遍看成功率變化這就是你的 Agent 專屬“回歸測試”。6.2 我的評測集構(gòu)建方法與指標Agent-Reach 的評測集分四類任務(wù)信息獲取類查天氣、搜新聞、抓網(wǎng)頁、文件操作類格式轉(zhuǎn)換、批量重命名、內(nèi)容歸檔、編排類跨多個工具完成的復合任務(wù)、安全類遇到危險操作時是否正確拒絕。每類 10 條左右總共 40 條。打分我不用“感覺”用四個硬指標成功率最終結(jié)果是否滿足預期人工判定 0/1。成本單位任務(wù)消耗 Token 數(shù)和模型調(diào)用次數(shù)。延遲從任務(wù)開始到結(jié)束的總時長。穩(wěn)定性同一任務(wù)連跑五次成功次數(shù)是否穩(wěn)定。我會用“LLM as Judge”做初步評分即讓另一個模型按規(guī)則打分再抽一部分由人工復核。這里有個經(jīng)驗LLM Judge 適合做初篩不適合當唯一標準因為它在語義判斷上容易給出“看著有道理但其實沒完成”的評分。關(guān)鍵是要把任務(wù)的成功標準寫進評分規(guī)則里而不是讓它自由發(fā)揮。評測集跑定期之后Agent 開發(fā)就從一個“改完不知道結(jié)果”的盲盒變成了一條可迭代的流水線?，F(xiàn)在我的習慣是任何改動先過評測集再看人工抽查最后才把改動合入主線。這個過程可能讓每次迭代變慢但長期看它的效率遠高于“改一行代碼跑五個隨機任務(wù)憑感覺判斷好壞”。7. Agent-Reach 開發(fā)過程中的踩坑清單7.1 工具描述寫不好Agent就變“瞎”這是我在 Agent 開發(fā)里最先遇到的坑。早期我在注冊 Skill 時描述寫得很隨意比如“獲取網(wǎng)頁內(nèi)容”結(jié)果模型在用戶說“把這個頁面保存下來”時死活不選這個 Skill反而去猜別的能力。后來我把描述改成“抓取指定網(wǎng)頁并轉(zhuǎn)換為Markdown格式適用于保存網(wǎng)頁正文、整理資料、生成文檔”模型的調(diào)用準確率肉眼可見上升。寫工具描述時可以想象自己在給一個從不認識這些函數(shù)的新同事寫說明文檔把它的用途、輸入、輸出、典型場景全部寫清楚。一個好的描述比你在 Prompt 里反復強調(diào)“請正確調(diào)用工具”有效得多。這也是為什么我在每個新 Skill 上線前都會要求先寫描述再寫代碼。7.2 長對話變慢、變貴、變笨的應(yīng)對第二個坑是長對話失控。Agent 在跑長任務(wù)時歷史上下文會越堆越長模型響應(yīng)變慢、成本飆升、行為漂移。我記得有一次 Agent 在第五步之后開始反復輸出“讓我回顧一下之前的操作”其實上下文里已經(jīng)擠滿了沒用的中間結(jié)果。解決辦法我在記憶那一節(jié)已經(jīng)提到截斷工具返回、做歷史摘要、控制上下文窗口。這里再補充一個“上下文預算”的技巧每一步開始前先檢查當前長度如果超過預算就先執(zhí)行一次摘要壓縮再讓模型繼續(xù)。這個檢查看起來多了一次模型調(diào)用但實際上減少了后續(xù)大量的重復思考和無效輸出整體成本反而更低。7.3 調(diào)試自主Agent的正確方式最后一個坑也是最容易被忽視的怎么調(diào)試一個“每一步都是模型自由發(fā)揮”的 Agent。傳統(tǒng)的 print 調(diào)試和斷點調(diào)試在這里基本失效因為你沒法預知模型會走哪條路。我的做法是給 Agent-Reach 加了一個“全鏈路追蹤”模塊每次模型調(diào)用、每次 Skill 調(diào)用、每次工具返回都記錄成結(jié)構(gòu)化日志包括輸入、輸出、耗時、成本。調(diào)試時把一次任務(wù)完整回放就像給 Agent 拍紀錄片一樣。一旦某一步的結(jié)果不對你就能順著 trace 找到是模型理解錯了、工具傳參錯了還是返回解析錯了。這大概是整個項目里投入產(chǎn)出比最高的一件事。以前處理一個詭異 bug 可能要半天現(xiàn)在打開 trace 看五分鐘就能定位。如果你準備自己搞 Agent 項目我強烈建議第一版就把日志和追蹤做進去否則后面補的成本會是現(xiàn)在的三倍?；氐介_頭那句話Agent 的核心是“到達”。Agent-Reach 這個項目做到現(xiàn)在我最大的體會是能不能到達取決于你把工具、記憶、安全和評測這幾塊地基打得有多扎實。每一步都是笨功夫但沒有這些笨功夫再聰明的模型也只會原地打轉(zhuǎn)。如果你也有一個想做的 Agent 項目別急著堆新功能先從把“到達”練扎實開始。