1. 從桌面工作臺到 MCP 工具這個項目到底在解決什么問題第一次看到“把桌面工作臺變成 MCP 工具”這個說法我腦子里冒出來的第一個念頭是終于有人把這件事系統(tǒng)化地做了。過去大半年我一直在折騰各種 Agent 與本地環(huán)境的對接最頭疼的從來不是模型本身的能力而是怎么讓 Agent 安全、穩(wěn)定、結(jié)構(gòu)化地操作我桌面上的那些工具。你讓模型去跑一條命令、讀一個文件、查一下系統(tǒng)狀態(tài)聽起來簡單真做起來全是坑路徑怎么傳、輸出怎么解析、權(quán)限怎么控制、異常怎么兜底每一個環(huán)節(jié)都能讓整個流程崩掉。Termexo 這個項目做的事情本質(zhì)上是把一臺桌面工作臺里那些零散的、需要手動敲命令才能完成的操作封裝成19 個標(biāo)準(zhǔn)化的 MCP 工具然后讓 Agent 通過 MCP 協(xié)議自動接入。MCP 是 Model Context Protocol 的縮寫你可以把它理解成一套“Agent 和外部工具之間的通用插座標(biāo)準(zhǔn)”。以前每個 Agent 想調(diào)用外部能力都得自己寫一套適配層A 框架一套、B 框架又一套重復(fù)勞動不說還特別容易出錯。MCP 出現(xiàn)之后只要工具端按協(xié)議暴露能力任何支持 MCP 的 Agent 都能直接接上省掉了大量膠水代碼。這個項目適合誰來參考我梳理了一下大概三類人收益最大。第一類是做 Agent 應(yīng)用開發(fā)的工程師你手里有 Agent但苦于沒有一套現(xiàn)成的、覆蓋桌面常用操作的工具體系Termexo 的 19 個工具可以直接當(dāng)參考模板。第二類是自動化運(yùn)維和效率工具愛好者你可能不寫 Agent但你想把日常重復(fù)的桌面操作標(biāo)準(zhǔn)化這套工具劃分思路本身就很有借鑒價值。第三類是想理解 MCP 協(xié)議落地方式的人光看協(xié)議文檔容易云里霧里看一個真實項目怎么把 19 個工具接進(jìn)去比讀十遍規(guī)范都管用。我特別想強(qiáng)調(diào)一點(diǎn)這個項目的價值不在于“19”這個數(shù)字本身而在于它示范了一種把非結(jié)構(gòu)化操作轉(zhuǎn)化為結(jié)構(gòu)化工具的方法論。桌面工作臺上能做的事太多了但并不是每一件都適合做成工具。哪些該封裝、怎么切分粒度、參數(shù)怎么設(shè)計、返回值怎么規(guī)范這些決策背后的邏輯才是真正值得學(xué)的東西。接下來我會把這 19 個工具的分類邏輯、MCP 接入的完整流程、以及我在實操中踩過的坑一層層拆開講清楚。2. 核心設(shè)計思路為什么是 19 個工具而不是 5 個或 50 個2.1 工具粒度劃分的底層邏輯很多人做工具封裝時最容易犯的錯就是粒度失控。要么太粗一個工具干十件事參數(shù)一大堆Agent 根本不知道該傳什么要么太細(xì)把每個小動作都拆成一個工具結(jié)果工具列表長到模型看不過來選擇成本極高。Termexo 選擇 19 個這個數(shù)量我認(rèn)為是經(jīng)過權(quán)衡的它背后有一條很清晰的劃分原則按“操作意圖”而不是“底層命令”來切分。舉個例子桌面上“查看某個目錄下有哪些文件”和“查看某個文件的詳細(xì)信息”底層可能都調(diào)用了類似的系統(tǒng)調(diào)用但它們是兩個不同的操作意圖所以應(yīng)該拆成兩個工具。反過來“列出文件”和“列出文件并按大小排序”如果排序只是加一個參數(shù)就能實現(xiàn)那就沒必要拆成兩個工具合并成一個帶可選參數(shù)的更合理。這種“意圖驅(qū)動”的劃分方式讓每個工具都有明確的語義邊界Agent 在決策時更容易匹配。我實測下來19 個工具大概覆蓋了桌面工作臺的幾個核心域文件與目錄操作、進(jìn)程與系統(tǒng)狀態(tài)查詢、文本處理與檢索、命令執(zhí)行與結(jié)果捕獲、環(huán)境信息讀取。每個域下面 3 到 5 個工具分布相當(dāng)均衡。這種均衡不是巧合而是刻意為之——如果某個域工具特別多說明劃分可能過細(xì)了如果某個域一個工具都沒有說明覆蓋有盲區(qū)。2.2 為什么選擇 MCP 而不是自定義接口這里要回答一個關(guān)鍵問題既然要暴露工具給 Agent為什么不直接寫一套 REST API 或者自定義的 function calling 格式非要用 MCP我的理解是三個層面的考量。第一是標(biāo)準(zhǔn)化帶來的復(fù)用性。自定義接口的問題是你為 A 框架寫的適配換到 B 框架就得重寫。MCP 作為一套開放協(xié)議工具端只需要實現(xiàn)一次所有支持 MCP 的客戶端都能接入。這意味著 Termexo 的 19 個工具不是綁定在某一個 Agent 上的而是變成了一個通用的能力池。第二是協(xié)議層已經(jīng)處理好了很多臟活。比如工具的 schema 描述、參數(shù)的 JSON Schema 校驗、調(diào)用的請求響應(yīng)格式、錯誤碼的規(guī)范這些如果自己寫每個項目都要重復(fù)實現(xiàn)一遍還容易實現(xiàn)得不一致。MCP 把這些都標(biāo)準(zhǔn)化了工具開發(fā)者只需要關(guān)心“我的工具做什么”而不用操心“怎么把這件事描述給 Agent 聽”。第三是生態(tài)兼容性?，F(xiàn)在越來越多的 Agent 框架和桌面客戶端開始支持 MCP這意味著你基于 MCP 做的工具天然就能被這些生態(tài)里的產(chǎn)品消費(fèi)。這個杠桿效應(yīng)是自定義接口給不了的。提示如果你現(xiàn)在還在用自定義 function calling 格式對接 Agent我建議認(rèn)真評估一下遷移到 MCP 的成本。短期看是多了學(xué)習(xí)成本長期看省下的是每個新 Agent 接入時的重復(fù)適配工作。2.3 自動接入機(jī)制的設(shè)計考量標(biāo)題里“Agent 自動接入”這幾個字很關(guān)鍵。手動接入和自動接入體驗差距是巨大的。手動接入意味著每換一個 Agent你都要重新配置一遍工具列表、重新填參數(shù)、重新測試連通性。自動接入則是 Agent 啟動時通過 MCP 的服務(wù)發(fā)現(xiàn)機(jī)制自動拉取到可用的工具清單直接就能用。Termexo 的自動接入我理解核心在于它把工具服務(wù)做成了一個常駐的、可被發(fā)現(xiàn)的 MCP Server。Agent 端只需要知道這個 Server 的接入點(diǎn)剩下的工具枚舉、schema 獲取、調(diào)用路由全部由協(xié)議自動完成。這帶來的一個直接好處是你新增或修改工具時Agent 端不需要做任何改動下次連接時自動就能看到最新的工具集。這種“工具端演進(jìn)、Agent 端無感”的特性在快速迭代階段特別有價值。不過自動接入也有它的代價就是安全邊界需要額外設(shè)計。工具自動暴露給 Agent意味著 Agent 理論上可以調(diào)用所有工具。如果某個工具涉及敏感操作就必須在工具端做權(quán)限控制而不能指望 Agent 端來把關(guān)。這一點(diǎn)我在后面的實操部分會詳細(xì)講。3. 19 個工具的分類拆解與參數(shù)設(shè)計要點(diǎn)3.1 文件與目錄操作類工具這一類大概是桌面工作臺上使用頻率最高的。我梳理了一下Termexo 在這塊大概有 5 個左右的工具覆蓋了列目錄、讀文件、寫文件、查文件信息、搜文件內(nèi)容這幾個核心意圖?？雌饋砗唵蔚珔?shù)設(shè)計上有不少講究。以“列目錄”這個工具為例最基礎(chǔ)的參數(shù)是路徑但實際使用中你很快會發(fā)現(xiàn)還需要是否遞歸、是否包含隱藏文件、結(jié)果數(shù)量上限、排序方式。這些參數(shù)如果全都做成必填A(yù)gent 每次調(diào)用都要糾結(jié)如果全都做成可選又容易出現(xiàn) Agent 不知道該傳什么的尷尬。我的經(jīng)驗是把最符合直覺的默認(rèn)值設(shè)好只把真正影響語義的參數(shù)暴露出來。比如遞歸默認(rèn)關(guān)閉、隱藏文件默認(rèn)不包含、數(shù)量上限默認(rèn)給一個合理值比如 200這樣 Agent 在大多數(shù)場景下只需要傳一個路徑就能拿到想要的結(jié)果。“讀文件”這個工具的參數(shù)設(shè)計更微妙。除了路徑你還需要考慮讀多少行、從第幾行開始讀、是否帶行號、超大文件怎么處理。這里有個我踩過的坑早期我沒設(shè)讀取上限結(jié)果 Agent 讀了一個幾百 MB 的日志文件直接把上下文撐爆了。后來我加了一個默認(rèn)的行數(shù)上限并且在返回值里明確告訴 Agent“還有多少行沒讀”讓它自己決定要不要繼續(xù)讀。這個設(shè)計思路很值得借鑒——工具不應(yīng)該默默截斷而應(yīng)該把截斷的事實和剩余量告訴調(diào)用方。3.2 進(jìn)程與系統(tǒng)狀態(tài)查詢類工具這一類工具有個特點(diǎn)它們大多是只讀的、冪等的所以安全風(fēng)險相對低但返回值的結(jié)構(gòu)化程度要求很高。比如“查進(jìn)程列表”如果你直接返回系統(tǒng)命令的原始文本輸出Agent 解析起來會很痛苦如果你返回結(jié)構(gòu)化的 JSON 數(shù)組每個進(jìn)程包含 PID、名稱、CPU 占用、內(nèi)存占用Agent 就能直接做篩選和判斷。我在實操中發(fā)現(xiàn)進(jìn)程類工具的過濾參數(shù)特別重要。桌面上的進(jìn)程動輒上百個全量返回既浪費(fèi)上下文又干擾判斷。所以好的設(shè)計應(yīng)該支持按名稱模糊匹配、按資源占用閾值過濾、按數(shù)量上限截斷。這幾個參數(shù)組合起來Agent 就能精準(zhǔn)地拿到它關(guān)心的那幾個進(jìn)程。系統(tǒng)狀態(tài)查詢類工具比如查 CPU、內(nèi)存、磁盤使用率參數(shù)通常很簡單但返回值的單位要統(tǒng)一。我見過有的工具返回百分比有的返回絕對值有的返回字節(jié)有的返回 KBAgent 拿到之后還得做單位換算很容易出錯。統(tǒng)一用百分比或者統(tǒng)一用字節(jié)并且在 schema 描述里寫清楚能省掉很多麻煩。3.3 文本處理與檢索類工具這一類是我個人覺得最有價值的因為它把很多“需要寫腳本才能完成”的操作變成了一個工具調(diào)用。比如在目錄下按關(guān)鍵詞搜索文件內(nèi)容這個操作如果讓 Agent 自己拼 grep 命令參數(shù)轉(zhuǎn)義、路徑處理、結(jié)果解析全是坑封裝成工具之后Agent 只需要傳目錄、關(guān)鍵詞、文件類型過濾就能拿到結(jié)構(gòu)化的匹配結(jié)果。文本處理類工具的參數(shù)設(shè)計核心是正則與字面量的區(qū)分。有些場景用戶想搜的是字面字符串有些場景想用正則。如果工具只支持一種就會有一半場景不好用。我的做法是加一個mode參數(shù)明確區(qū)分literal和regex并且在 schema 里寫清楚兩種模式的行為差異。這樣 Agent 在調(diào)用時能做出明確選擇而不是靠猜。還有一個細(xì)節(jié)是結(jié)果的數(shù)量控制。搜索類操作很容易返回海量結(jié)果如果不做限制上下文瞬間就滿了。所以除了數(shù)量上限我還會加一個“是否只返回匹配的文件列表”和“是否返回匹配的具體行”的開關(guān)。很多時候 Agent 只想知道“哪些文件包含這個關(guān)鍵詞”并不需要看到每一行的內(nèi)容這個開關(guān)能大幅節(jié)省上下文。3.4 命令執(zhí)行與結(jié)果捕獲類工具這是整個工具集里最強(qiáng)大也最危險的一類。強(qiáng)大在于它幾乎能完成任何操作危險也在于此。Termexo 在這塊的參數(shù)設(shè)計我推測會包含命令內(nèi)容、工作目錄、超時時間、環(huán)境變量、輸出上限。其中超時時間和輸出上限是兩個必須有的保護(hù)參數(shù)。超時時間的重要性不用多說一條卡住的命令如果沒超時整個 Agent 流程就掛在那里了。我一般會設(shè)一個默認(rèn)超時比如 30 秒同時允許 Agent 在明確知道命令耗時較長時手動調(diào)大。輸出上限則是防止命令輸出把上下文撐爆超出部分應(yīng)該被截斷并明確標(biāo)記。注意命令執(zhí)行類工具一定要在工具端做危險命令攔截不能完全依賴 Agent 的自覺。像刪除、格式化、權(quán)限修改這類操作要么直接禁止要么要求額外的確認(rèn)參數(shù)。我見過太多因為 Agent 誤判而執(zhí)行了破壞性命令的案例這個防線必須建在工具端。3.5 環(huán)境信息讀取類工具這一類工具看起來最不起眼但在實際使用中出場率很高。Agent 在做任何操作之前往往需要先了解當(dāng)前環(huán)境操作系統(tǒng)是什么、當(dāng)前工作目錄在哪、有哪些環(huán)境變量、可用的命令有哪些。這些信息如果每次都要 Agent 自己拼命令去查既慢又容易出錯。環(huán)境信息類工具的設(shè)計要點(diǎn)是緩存與實時性的平衡。有些信息比如操作系統(tǒng)類型在會話期間基本不變可以緩存有些信息比如當(dāng)前目錄可能隨時變化必須實時讀取。我的做法是把這兩類分開不變的用緩存工具會變的用實時工具避免 Agent 拿到過期信息做出錯誤判斷。4. MCP 接入的完整實操流程4.1 工具端的 MCP Server 搭建要讓 19 個工具能被 Agent 自動接入第一步是把它們包裝成一個符合 MCP 規(guī)范的 Server。這個過程我拆成幾個關(guān)鍵步驟來講。首先是工具注冊。每個工具都需要提供三樣?xùn)|西工具名稱、工具描述、參數(shù)的 JSON Schema。工具名稱要簡潔且語義明確比如list_directory、read_file、search_content這種避免用do_stuff這種含糊的命名。工具描述是給 Agent 看的要寫清楚這個工具做什么、什么時候該用、有什么限制這段文字的質(zhì)量直接影響 Agent 的選擇準(zhǔn)確率。參數(shù) Schema 是重頭戲。MCP 用的是 JSON Schema 標(biāo)準(zhǔn)你需要為每個參數(shù)定義類型、描述、是否必填、默認(rèn)值、取值范圍。我特別建議在描述里多花點(diǎn)心思把參數(shù)的實際影響寫清楚。比如一個max_results參數(shù)不要只寫“最大結(jié)果數(shù)”而要寫“超過此數(shù)量的結(jié)果會被截斷建議根據(jù)實際需要設(shè)置過大會占用大量上下文”。這種描述能幫 Agent 做出更合理的參數(shù)選擇。{ name: search_content, description: 在指定目錄下按關(guān)鍵詞搜索文件內(nèi)容返回匹配的文件和行, inputSchema: { type: object, properties: { directory: { type: string, description: 要搜索的目錄路徑必須是絕對路徑 }, keyword: { type: string, description: 搜索關(guān)鍵詞 }, mode: { type: string, enum: [literal, regex], default: literal, description: 匹配模式literal 為字面匹配regex 為正則匹配 }, max_results: { type: integer, default: 50, description: 最大返回結(jié)果數(shù)超過會被截斷 } }, required: [directory, keyword] } }其次是調(diào)用路由。MCP Server 收到調(diào)用請求后需要根據(jù)工具名稱路由到對應(yīng)的處理函數(shù)。這部分邏輯本身不復(fù)雜但要注意錯誤處理的一致性。不管哪個工具出錯返回的錯誤格式都應(yīng)該統(tǒng)一包含錯誤類型、錯誤信息、可能的修復(fù)建議。這樣 Agent 拿到錯誤后能做出合理的反應(yīng)而不是一臉茫然。最后是服務(wù)啟動與發(fā)現(xiàn)。MCP Server 需要以一種 Agent 能找到的方式運(yùn)行。常見的方式是作為本地進(jìn)程啟動通過標(biāo)準(zhǔn)輸入輸出或者本地端口通信。具體用哪種取決于你的 Agent 端支持哪種傳輸方式。我實測下來標(biāo)準(zhǔn)輸入輸出的方式最簡單不需要處理端口占用和網(wǎng)絡(luò)配置適合本地桌面場景。4.2 Agent 端的自動接入配置工具端準(zhǔn)備好之后Agent 端的接入其實相當(dāng)輕量。核心就是告訴 Agent有一個 MCP Server 在某個位置你去連它。配置通常是一個 JSON 文件包含 Server 的啟動命令或者連接地址。{ mcpServers: { termexo: { command: termexo-server, args: [--tools, all], env: { TERMEXO_WORKSPACE: /home/user/workspace } } } }這段配置的意思是啟動一個叫 termexo 的 MCP Server用termexo-server命令加載全部工具工作目錄限定在指定的 workspace 下。Agent 啟動時會自動執(zhí)行這個命令建立連接然后拉取工具列表。整個過程不需要手動干預(yù)這就是“自動接入”的含義。我特別想說的是env里那個 workspace 變量。把工具的操作范圍限定在一個工作目錄內(nèi)是一個非常重要的安全設(shè)計。這樣即使 Agent 調(diào)用了文件操作工具也只能在這個目錄內(nèi)活動不會誤傷系統(tǒng)其他文件。這個邊界一定要在工具端強(qiáng)制執(zhí)行不能只是配置上的約定。4.3 接入后的驗證與調(diào)試配置好之后怎么確認(rèn)接入成功我的做法是分三步驗證。第一步工具枚舉驗證。讓 Agent 列出它當(dāng)前可用的工具看看是不是 19 個都在名稱和描述是否正確。這一步能發(fā)現(xiàn)配置錯誤或者 Server 啟動失敗的問題。第二步單工具調(diào)用驗證。挑幾個只讀的、安全的工具比如列目錄、查系統(tǒng)信息讓 Agent 實際調(diào)用一下看看返回值是否符合預(yù)期。這一步能發(fā)現(xiàn)參數(shù)傳遞、結(jié)果解析的問題。第三步組合場景驗證。設(shè)計一個需要連續(xù)調(diào)用多個工具的任務(wù)比如“找到某個目錄下最近修改的文件讀取它的內(nèi)容然后總結(jié)”看看 Agent 能不能正確地串聯(lián)多個工具。這一步能發(fā)現(xiàn)工具之間協(xié)作的問題。調(diào)試過程中日志是關(guān)鍵。MCP Server 端要記錄每一次調(diào)用的工具名、參數(shù)、返回值、耗時Agent 端要記錄它為什么選擇這個工具、怎么解析的返回值。兩邊日志對照著看大部分問題都能快速定位。5. 實操中踩過的坑與排查技巧5.1 工具描述寫不好導(dǎo)致 Agent 選錯工具這是我早期遇到的最頻繁的問題。有段時間我做了兩個工具一個叫find_files一個叫search_files描述也寫得很接近結(jié)果 Agent 經(jīng)常在該用find_files的時候用了search_files。后來我把它們的描述徹底區(qū)分開find_files明確寫“按文件名查找”search_files明確寫“按文件內(nèi)容查找”并且在描述里加了“如果你要找的是文件名用 find_files如果你要找的是文件里的內(nèi)容用 search_files”這樣的引導(dǎo)語。改完之后選擇準(zhǔn)確率明顯提升。這個經(jīng)驗告訴我工具描述不是寫給人類看的文檔而是寫給模型看的決策依據(jù)。要站在模型的角度想它在什么場景下會面臨選擇困難然后提前把區(qū)分點(diǎn)寫清楚。5.2 返回值過大撐爆上下文前面提過讀大文件的坑其實不止讀文件列目錄、搜索內(nèi)容、查進(jìn)程任何一個返回列表的工具都有這個問題。我的解決方案是三層防護(hù)工具端設(shè)默認(rèn)上限、返回值里明確標(biāo)記截斷、提供分頁或續(xù)讀參數(shù)。具體來說工具端默認(rèn)返回不超過 N 條如果實際結(jié)果超過 N 條返回值里加一個字段說明“共 M 條已返回 N 條可使用 offset 參數(shù)獲取更多”。這樣 Agent 既不會被撐爆又知道還有數(shù)據(jù)可以拿需要的時候能主動續(xù)讀。這個設(shè)計比簡單粗暴地截斷要友好得多。5.3 超時與長任務(wù)的平衡命令執(zhí)行類工具的超時設(shè)置是個兩難。設(shè)短了正常的耗時命令會被誤殺設(shè)長了卡住的命令會拖垮整個流程。我的做法是默認(rèn)超時 顯式覆蓋 后臺執(zhí)行三管齊下。默認(rèn)超時設(shè)一個保守值比如 30 秒覆蓋大多數(shù)快速命令。對于明確知道會耗時的命令A(yù)gent 可以顯式傳一個更大的超時值。對于真正長時間運(yùn)行的任務(wù)提供一個“后臺執(zhí)行”模式工具立即返回一個任務(wù) IDAgent 后續(xù)可以用另一個工具查詢?nèi)蝿?wù)狀態(tài)。這樣既不會卡住又能處理長任務(wù)。5.4 常見問題速查表問題現(xiàn)象可能原因排查方向解決方法Agent 看不到任何工具Server 未啟動或配置錯誤檢查 Server 進(jìn)程和配置文件手動啟動 Server 驗證核對配置路徑工具調(diào)用報參數(shù)錯誤Schema 定義與實際不符對比 schema 和實際接收的參數(shù)修正 schema確保類型和必填項一致返回值解析失敗返回格式不符合預(yù)期查看原始返回值統(tǒng)一返回格式增加格式校驗調(diào)用超時無響應(yīng)命令卡住或超時設(shè)置過長查看 Server 日志縮短默認(rèn)超時增加后臺執(zhí)行模式Agent 選錯工具工具描述區(qū)分度不夠分析 Agent 的決策日志強(qiáng)化描述中的區(qū)分點(diǎn)和引導(dǎo)語上下文被撐爆返回值過大檢查返回結(jié)果大小加默認(rèn)上限標(biāo)記截斷提供分頁5.5 權(quán)限與安全的實操心得最后聊聊安全。工具自動接入 Agent 之后安全邊界的設(shè)計就成了重中之重。我的核心原則是最小權(quán)限 顯式確認(rèn) 操作審計。最小權(quán)限是指每個工具只能訪問它必須訪問的資源。文件操作工具限定在 workspace 內(nèi)命令執(zhí)行工具限制可執(zhí)行的命令白名單系統(tǒng)查詢工具只讀不寫。顯式確認(rèn)是指對于有副作用的操作寫文件、執(zhí)行命令要么在工具端做二次確認(rèn)要么要求 Agent 傳入一個明確的確認(rèn)參數(shù)。操作審計是指所有工具調(diào)用都要記錄日志包括誰調(diào)的、調(diào)了什么、結(jié)果如何出問題的時候能追溯。提示不要指望 Agent 端來做安全控制。Agent 的決策是不確定的今天它不調(diào)用危險工具不代表明天不會。安全防線必須建在工具端這是唯一可靠的地方。6. 工具集后續(xù)擴(kuò)展的思路19 個工具覆蓋了桌面工作臺的核心操作但肯定不是終點(diǎn)。我在實操中總結(jié)出幾個擴(kuò)展方向供參考。第一個方向是增加組合工具?，F(xiàn)在很多任務(wù)是靠 Agent 串聯(lián)多個基礎(chǔ)工具完成的如果某些組合特別高頻可以考慮封裝成一個組合工具減少調(diào)用輪次。比如“查找并讀取最近修改的配置文件”這種就可以做成一個工具。第二個方向是增加領(lǐng)域?qū)Ｓ霉ぞ?。通用的文件、進(jìn)程、命令操作之外不同用戶還有各自的領(lǐng)域需求。比如做數(shù)據(jù)處理的可能需要 CSV 解析工具做前端的可能需要依賴檢查工具。這些可以按需擴(kuò)展不必強(qiáng)求統(tǒng)一。第三個方向是增強(qiáng)工具的可觀測性?，F(xiàn)在工具調(diào)用基本是黑盒Agent 調(diào)了什么、花了多久、成功失敗缺乏細(xì)粒度的監(jiān)控。后續(xù)可以增加調(diào)用統(tǒng)計、性能分析、異常告警這些能力讓工具集從“能用”進(jìn)化到“好用且可管理”。我個人在實際操作中的體會是工具集的價值不在于數(shù)量多而在于每個工具都經(jīng)過真實場景的打磨。與其急著堆到 50 個工具不如把現(xiàn)有的 19 個用透把參數(shù)設(shè)計、錯誤處理、安全邊界都做到位。一個設(shè)計精良的工具勝過十個粗糙的工具。這個項目最值得學(xué)的地方恰恰是它在工具劃分和參數(shù)設(shè)計上的克制與考究而不是工具數(shù)量本身。