Anthropic 這篇《Writing effective tools for AI agents — with agents》把給智能體寫工具從零散經(jīng)驗(yàn)上升為可復(fù)現(xiàn)的方法論：強(qiáng)調(diào)以評(píng)估驅(qū)動(dòng)的迭代流程、以Agents為中心的工具設(shè)計(jì)原則（namespacing、簡潔響應(yīng)、token 效率等），并展示用 Claude 自身去分析/優(yōu)化工具的實(shí)戰(zhàn)路徑——這對(duì)工程落地、產(chǎn)品設(shè)計(jì)和行業(yè)標(biāo)準(zhǔn)化都具有立刻可用的價(jià)值

過去我們把 API 當(dāng)成給程序員用的契約，現(xiàn)在要把接口重新設(shè)計(jì)成能被會(huì)思考的模型理解的工具。Anthropic 這篇工程帖子，把這件事從經(jīng)驗(yàn)總結(jié)，推演成一套可執(zhí)行的工程流程——從原型、評(píng)估、到讓 Claude 自己參與改進(jìn)工具。讀完它，你會(huì)發(fā)現(xiàn)：未來的后端接口設(shè)計(jì)，不再只為了機(jī)器——而是為了會(huì)推理的機(jī)器

Agent的效能取決于提供給它們的工具。本文將分享如何編寫高質(zhì)量的工具和評(píng)估方法，以及如何利用 Claude 來為它自己優(yōu)化工具，從而提升性能

模型上下文協(xié)議（Model Context Protocol, MCP）可以為大語言模型代理賦予數(shù)百種工具來解決現(xiàn)實(shí)世界的任務(wù)。但如何使這些工具的效能最大化呢？

本文將介紹在多種代理 AI 系統(tǒng)中提升性能最有效的技巧

首先，本文將涵蓋如何：

1.構(gòu)建和測試工具的原型

2.創(chuàng)建并運(yùn)行針對(duì)代理使用工具的全面評(píng)估

3.與像 Claude Code 這樣的代理協(xié)作，自動(dòng)提升工具的性能

最后，本文將總結(jié)在此過程中總結(jié)出的編寫高質(zhì)量工具的關(guān)鍵原則：

選擇正確的工具進(jìn)行實(shí)現(xiàn)（以及不實(shí)現(xiàn)）

通過命名空間為工具定義清晰的功能邊界

從工具向代理返回有意義的上下文

優(yōu)化工具響應(yīng)的詞元（token）效率

通過提示工程優(yōu)化工具描述和規(guī)范

什么是工具？

在計(jì)算領(lǐng)域，確定性系統(tǒng)在給定相同輸入時(shí)總是產(chǎn)生相同的輸出，而非確定性系統(tǒng)——比如代理——即使在起始條件相同的情況下也可能生成不同的響應(yīng)。

在傳統(tǒng)軟件編寫中，是在確定性系統(tǒng)之間建立一種契約。例如，像 getWeather("NYC") 這樣的函數(shù)調(diào)用，每次執(zhí)行時(shí)都會(huì)以完全相同的方式獲取紐約市的天氣。

工具是一種新型軟件，它反映了確定性系統(tǒng)與非確定性代理之間的契約。當(dāng)用戶問“我今天需要帶傘嗎？”，代理可能會(huì)調(diào)用天氣工具，也可能根據(jù)常識(shí)回答，甚至可能先詢問地點(diǎn)等澄清性問題。偶爾，代理可能會(huì)產(chǎn)生幻覺，或者無法理解如何使用某個(gè)工具。

這意味著在為代理編寫軟件時(shí)，需要從根本上反思方法：不能像為其他開發(fā)者或系統(tǒng)編寫函數(shù)和 API 那樣來編寫工具和 MCP 服務(wù)器，而是需要為代理進(jìn)行設(shè)計(jì)。

目標(biāo)是通過使用工具來追求各種成功的策略，從而擴(kuò)大代理能夠有效解決各類任務(wù)的范圍。幸運(yùn)的是，根據(jù)經(jīng)驗(yàn)，那些對(duì)代理而言最“易于使用”的工具，最終對(duì)人類來說也出乎意料地直觀易懂。

如何編寫工具

本節(jié)將介紹如何與代理協(xié)作來編寫并改進(jìn)提供給它們的工具。首先，快速搭建一個(gè)工具原型并在本地進(jìn)行測試。接著，運(yùn)行一次全面的評(píng)估來衡量后續(xù)的改動(dòng)效果。通過與代理協(xié)同工作，可以重復(fù)評(píng)估和改進(jìn)工具的流程，直到代理在真實(shí)世界任務(wù)上取得優(yōu)異的性能。

構(gòu)建原型

在沒有親身實(shí)踐的情況下，很難預(yù)見哪些工具對(duì)代理來說是易于使用的，哪些不是。首先應(yīng)快速搭建一個(gè)工具原型。如果使用 Claude Code 編寫工具（可能是一次性生成），向 Claude 提供工具所依賴的任何軟件庫、API 或 SDK（可能包括 MCP SDK）的文檔會(huì)很有幫助。大語言模型友好的文檔通常可以在官方文檔網(wǎng)站的扁平化 llms.txt 文件中找到。

將工具包裝在本地 MCP 服務(wù)器或桌面擴(kuò)展（DXT）中，就可以在 Claude Code 或 Claude 桌面應(yīng)用中連接并測試工具。

要將本地 MCP 服務(wù)器連接到 Claude Code，運(yùn)行 claude mcp add [args...]

要將本地 MCP 服務(wù)器或 DXT 連接到 Claude 桌面應(yīng)用，分別導(dǎo)航至“設(shè)置 > 開發(fā)者”或“設(shè)置 > 擴(kuò)展”

工具也可以直接傳遞到 Anthropic API 調(diào)用中進(jìn)行編程化測試

親自測試這些工具，找出任何不順手的地方。收集用戶的反饋，以便對(duì)工具所要支持的用例和提示建立直觀的理解。

運(yùn)行評(píng)估

接下來，需要通過運(yùn)行評(píng)估來衡量 Claude 使用工具的效果。首先，基于真實(shí)世界用例生成大量的評(píng)估任務(wù)。建議與代理協(xié)作，幫助分析結(jié)果并確定如何改進(jìn)工具

生成評(píng)估任務(wù)

利用早期原型，Claude Code 可以快速探索工具并創(chuàng)建數(shù)十個(gè)提示和響應(yīng)對(duì)。提示應(yīng)受到真實(shí)世界用例的啟發(fā)，并基于現(xiàn)實(shí)的數(shù)據(jù)源和服務(wù)（例如，內(nèi)部知識(shí)庫和微服務(wù)）。建議避免使用過于簡單或膚淺的“沙盒”環(huán)境，因?yàn)樗鼈儫o法以足夠的復(fù)雜性對(duì)工具進(jìn)行壓力測試。一個(gè)好的評(píng)估任務(wù)可能需要多次工具調(diào)用——甚至可能多達(dá)數(shù)十次

以下是一些好的任務(wù)示例：

安排下周與 Jane 開會(huì)，討論最新的 Acme 公司項(xiàng)目。附上我們上次項(xiàng)目規(guī)劃會(huì)議的紀(jì)要，并預(yù)訂一間會(huì)議室

客戶 ID 9182 報(bào)告稱，他們的一次購買嘗試被收取了三次費(fèi)用。找出所有相關(guān)的日志條目，并確定是否有其他客戶受到同樣問題的影響

客戶 Sarah Chen 剛剛提交了取消請(qǐng)求。準(zhǔn)備一份挽留方案。確定：(1) 他們離開的原因，(2) 哪種挽留方案最具吸引力，以及 (3) 在提出方案前需要注意的任何風(fēng)險(xiǎn)因素。

以下是一些較弱的任務(wù)示例：

安排下周與 jane@acme.corp 開會(huì)

在支付日志中搜索 purchase_complete 和 customer_id=9182

根據(jù)客戶 ID 45892 查找取消請(qǐng)求

每個(gè)評(píng)估提示都應(yīng)配有一個(gè)可驗(yàn)證的響應(yīng)或結(jié)果。驗(yàn)證器可以像基準(zhǔn)真相與采樣響應(yīng)之間的精確字符串比較一樣簡單，也可以像讓 Claude 來評(píng)判響應(yīng)一樣高級(jí)。避免使用過于嚴(yán)格的驗(yàn)證器，它們可能會(huì)因?yàn)楦袷?、?biāo)點(diǎn)或有效的替代表述等無關(guān)緊要的差異而拒絕正確的響應(yīng)。

對(duì)于每個(gè)提示-響應(yīng)對(duì)，可以選擇性地指定期望代理在解決任務(wù)時(shí)調(diào)用的工具，以衡量代理在評(píng)估過程中是否成功掌握了每個(gè)工具的用途。然而，由于解決任務(wù)可能存在多種有效路徑，應(yīng)盡量避免過度指定或?qū)μ囟ú呗赃^擬合。

運(yùn)行評(píng)估

建議通過直接調(diào)用 LLM API 以編程方式運(yùn)行評(píng)估。使用簡單的代理循環(huán)（包裹著交替的 LLM API 和工具調(diào)用的 while 循環(huán)）：每個(gè)評(píng)估任務(wù)一個(gè)循環(huán)。每個(gè)評(píng)估代理都應(yīng)被賦予一個(gè)任務(wù)提示和相應(yīng)的工具。

在評(píng)估代理的系統(tǒng)提示中，建議不僅指示代理輸出結(jié)構(gòu)化的響應(yīng)塊（用于驗(yàn)證），還要輸出推理和反饋塊。指示代理在工具調(diào)用和響應(yīng)塊之前輸出這些內(nèi)容，可能會(huì)觸發(fā)思維鏈（CoT）行為，從而提高大語言模型的有效智能

如果使用 Claude 運(yùn)行評(píng)估，可以開啟“交錯(cuò)思考”（interleaved thinking）功能以獲得類似的效果。這將有助于探查代理調(diào)用或不調(diào)用某些工具的原因，并突出工具描述和規(guī)范中需要改進(jìn)的具體方面。

除了頂層準(zhǔn)確率外，還建議收集其他指標(biāo)，如單個(gè)工具調(diào)用和任務(wù)的總運(yùn)行時(shí)間、總工具調(diào)用次數(shù)、總詞元消耗量和工具錯(cuò)誤。跟蹤工具調(diào)用可以揭示代理常用的工作流程，并為工具的整合提供一些機(jī)會(huì)

分析結(jié)果

代理是發(fā)現(xiàn)問題和提供反饋的得力助手，它們能就從矛盾的工具描述到低效的工具實(shí)現(xiàn)和令人困惑的工具模式等一切問題提供反饋。但請(qǐng)記住，代理在反饋和響應(yīng)中遺漏的內(nèi)容往往比它們包含的內(nèi)容更重要。大語言模型并不總能言如其意。

觀察代理在何處遇到困難或感到困惑。通讀評(píng)估代理的推理和反饋（或思維鏈），以找出不順手的地方。審查原始交互記錄（包括工具調(diào)用和工具響應(yīng)），以捕捉代理思維鏈中未明確描述的任何行為。要讀懂言外之意；記住，評(píng)估代理不一定知道正確的答案和策略。

分析工具調(diào)用指標(biāo)。大量的冗余工具調(diào)用可能表明需要調(diào)整分頁或詞元限制參數(shù)；大量因參數(shù)無效導(dǎo)致的工具錯(cuò)誤可能表明工具需要更清晰的描述或更好的示例。在推出 Claude 的網(wǎng)絡(luò)搜索工具時(shí)，發(fā)現(xiàn) Claude 會(huì)不必要地將“2025”附加到工具的查詢參數(shù)中，這導(dǎo)致搜索結(jié)果出現(xiàn)偏差并降低了性能（通過改進(jìn)工具描述引導(dǎo) Claude 回到了正確的方向）。

與代理協(xié)作

甚至可以讓代理來分析結(jié)果并改進(jìn)工具。只需將評(píng)估代理的交互記錄拼接起來，然后粘貼到 Claude Code 中。Claude 是分析交互記錄和一次性重構(gòu)大量工具的專家——例如，在進(jìn)行新更改時(shí)，確保工具的實(shí)現(xiàn)和描述保持自洽。

實(shí)際上，本文中的大部分建議都來自于反復(fù)使用 Claude Code 優(yōu)化內(nèi)部工具實(shí)現(xiàn)的過程。這些評(píng)估建立在內(nèi)部工作空間之上，反映了內(nèi)部工作流程的復(fù)雜性，包括真實(shí)的項(xiàng)目、文檔和消息。

通過使用獨(dú)立的測試集來確保沒有對(duì)“訓(xùn)練”用的評(píng)估集過擬合。這些測試集表明，即使是基于“專家”編寫的工具實(shí)現(xiàn)——無論是研究員手動(dòng)編寫的還是由 Claude 自己生成的——也仍然可以獲得額外的性能提升。

編寫高效工具的原則

本節(jié)將把所學(xué)到的經(jīng)驗(yàn)提煉為幾個(gè)編寫高效工具的指導(dǎo)原則。

為代理選擇正確的工具

更多的工具并不總能帶來更好的結(jié)果。一個(gè)常見的錯(cuò)誤是，工具僅僅是對(duì)現(xiàn)有軟件功能或 API 端點(diǎn)的簡單包裝——而不管這些工具是否適合代理。這是因?yàn)榇硐鄬?duì)于傳統(tǒng)軟件有不同的“功能可見性”（affordances）——也就是說，它們感知其可以采取的潛在行動(dòng)的方式不同。

大語言模型代理的“上下文”（即它們一次能處理的信息量）是有限的，而計(jì)算機(jī)內(nèi)存則廉價(jià)且充足?？紤]在地址簿中搜索聯(lián)系人的任務(wù)。傳統(tǒng)軟件程序可以高效地存儲(chǔ)和逐個(gè)處理聯(lián)系人列表，檢查完一個(gè)再移至下一個(gè)。

然而，如果一個(gè)大語言模型代理使用的工具返回了所有聯(lián)系人，然后它必須逐個(gè)詞元地閱讀每個(gè)聯(lián)系人，那么它就是在不相關(guān)的信息上浪費(fèi)其有限的上下文空間（想象一下通過從頭到尾閱讀每一頁來在地址簿中查找聯(lián)系人——也就是通過暴力搜索）。更好、更自然的方法（對(duì)代理和人類都一樣）是先跳到相關(guān)的頁面（也許是按字母順序查找）。

建議先構(gòu)建少數(shù)幾個(gè)經(jīng)過深思熟慮的工具，針對(duì)特定的高影響力工作流程，這些工作流程應(yīng)與評(píng)估任務(wù)相匹配，然后在此基礎(chǔ)上逐步擴(kuò)展。在地址簿的例子中，可以選擇實(shí)現(xiàn)一個(gè) search_contacts 或 message_contact 工具，而不是一個(gè) list_contacts 工具。

工具可以整合功能，在底層處理可能多個(gè)離散的操作（或 API 調(diào)用）。例如，工具可以用相關(guān)的元數(shù)據(jù)豐富工具響應(yīng)，或者在一個(gè)工具調(diào)用中處理頻繁鏈?zhǔn)秸{(diào)用的多步任務(wù)。

以下是一些示例：

與其實(shí)現(xiàn) list_users、list_events 和 create_event 工具，不如考慮實(shí)現(xiàn)一個(gè) schedule_event 工具，該工具可以查找空閑時(shí)間并安排事件

與其實(shí)現(xiàn)一個(gè) read_logs 工具，不如考慮實(shí)現(xiàn)一個(gè) search_logs 工具，它只返回相關(guān)的日志行和一些上下文

與其實(shí)現(xiàn) get_customer_by_id、list_transactions 和 list_notes 工具，不如實(shí)現(xiàn)一個(gè) get_customer_context 工具，該工具一次性匯編客戶所有近期和相關(guān)的信息。

確保構(gòu)建的每個(gè)工具都有一個(gè)清晰、獨(dú)特的目的。工具應(yīng)能讓代理像人類在擁有相同底層資源的情況下那樣，對(duì)任務(wù)進(jìn)行細(xì)分和解決，并同時(shí)減少本應(yīng)被中間輸出消耗的上下文。

過多的工具或功能重疊的工具也可能分散代理的注意力，使其無法采取高效的策略。謹(jǐn)慎、有選擇地規(guī)劃要構(gòu)建（或不構(gòu)建）的工具，可以帶來巨大的回報(bào)。

為工具使用命名空間

AI 代理可能會(huì)接觸到數(shù)十個(gè) MCP 服務(wù)器和數(shù)百個(gè)不同的工具——包括其他開發(fā)者開發(fā)的工具。當(dāng)工具功能重疊或目的模糊時(shí)，代理可能會(huì)混淆該使用哪個(gè)。

命名空間（將相關(guān)工具按共同的前綴分組）有助于在眾多工具之間劃定界限；MCP 客戶端有時(shí)會(huì)默認(rèn)這樣做。例如，按服務(wù)（如 asana_search、jira_search）和按資源（如 asana_projects_search、asana_users_search）對(duì)工具進(jìn)行命名空間劃分，可以幫助代理在正確的時(shí)間選擇正確的工具。

實(shí)踐發(fā)現(xiàn)，選擇基于前綴還是后綴的命名空間方案，對(duì)工具使用評(píng)估有不可忽視的影響。這種影響因大語言模型而異，建議根據(jù)自己的評(píng)估選擇命名方案。

代理可能會(huì)調(diào)用錯(cuò)誤的工具，用錯(cuò)誤的參數(shù)調(diào)用正確的工具，調(diào)用過少的工具，或錯(cuò)誤地處理工具響應(yīng)。通過有選擇地實(shí)現(xiàn)其名稱能反映任務(wù)自然劃分的工具，可以同時(shí)減少加載到代理上下文中的工具和工具描述的數(shù)量，并將代理計(jì)算從代理的上下文中轉(zhuǎn)移回工具調(diào)用本身。這降低了代理犯錯(cuò)的總體風(fēng)險(xiǎn)。

從工具中返回有意義的上下文

同樣地，工具的實(shí)現(xiàn)應(yīng)注意只向代理返回高信息量的信號(hào)。它們應(yīng)優(yōu)先考慮上下文相關(guān)性而非靈活性，并避免使用低級(jí)別的技術(shù)標(biāo)識(shí)符（例如：uuid、256px_image_url、mime_type）。像 name、image_url 和 file_type 這樣的字段更有可能直接為代理的后續(xù)行動(dòng)和響應(yīng)提供信息。

代理處理自然語言名稱、術(shù)語或標(biāo)識(shí)符時(shí)，也比處理晦澀的標(biāo)識(shí)符要成功得多。實(shí)踐發(fā)現(xiàn)，僅僅將任意的字母數(shù)字 UUID 解析為更具語義意義和可解釋性的語言（甚至是 0 索引的 ID 方案），就能通過減少幻覺顯著提高 Claude 在檢索任務(wù)中的精確度。

在某些情況下，代理可能需要靈活地與自然語言和技術(shù)標(biāo)識(shí)符輸出進(jìn)行交互，哪怕只是為了觸發(fā)后續(xù)的工具調(diào)用（例如，search_user(name=’jane’) → send_message(id=12345)）?？梢酝ㄟ^在工具中暴露一個(gè)簡單的 response_format 枚舉參數(shù)來實(shí)現(xiàn)這一點(diǎn)，讓代理控制工具是返回“簡潔”還是“詳細(xì)”的響應(yīng)。

可以添加更多格式以獲得更大的靈活性，類似于 GraphQL，可以選擇確切地想要接收哪些信息。以下是一個(gè)用于控制工具響應(yīng)詳細(xì)程度的 ResponseFormat 枚舉示例：

enum ResponseFormat { DETAILED ="detailed", CONCISE ="concise" }

這是一個(gè)詳細(xì)工具響應(yīng)的示例（206 個(gè)詞元）：

這是一個(gè)簡潔工具響應(yīng)的示例（72 個(gè)詞元）：

即使是工具的響應(yīng)結(jié)構(gòu)——例如 XML、JSON 或 Markdown——也可能對(duì)評(píng)估性能產(chǎn)生影響：沒有一種萬能的解決方案。這是因?yàn)榇笳Z言模型是基于下一個(gè)詞元預(yù)測進(jìn)行訓(xùn)練的，它們往往在處理與其訓(xùn)練數(shù)據(jù)格式相匹配的格式時(shí)表現(xiàn)更好。最佳的響應(yīng)結(jié)構(gòu)會(huì)因任務(wù)和代理的不同而有很大差異。建議根據(jù)自己的評(píng)估選擇最佳的響應(yīng)結(jié)構(gòu)。

優(yōu)化工具響應(yīng)的詞元效率

優(yōu)化上下文的質(zhì)量很重要，但優(yōu)化工具響應(yīng)中返回給代理的上下文數(shù)量也同樣重要。

建議為任何可能消耗大量上下文的工具響應(yīng)，實(shí)施分頁、范圍選擇、過濾和/或截?cái)嗟慕M合，并設(shè)置合理的默認(rèn)參數(shù)值。對(duì)于 Claude Code，工具響應(yīng)默認(rèn)限制在 25,000 個(gè)詞元。預(yù)計(jì)代理的有效上下文長度會(huì)隨著時(shí)間的推移而增長，但對(duì)上下文高效的工具的需求將持續(xù)存在。

如果選擇截?cái)囗憫?yīng)，請(qǐng)務(wù)必用有用的指令來引導(dǎo)代理。可以直接鼓勵(lì)代理采取更節(jié)省詞元的策略，例如在知識(shí)檢索任務(wù)中進(jìn)行多次小范圍、有針對(duì)性的搜索，而不是一次大范圍的搜索。同樣，如果工具調(diào)用引發(fā)錯(cuò)誤（例如，在輸入驗(yàn)證期間），可以通過提示工程優(yōu)化錯(cuò)誤響應(yīng)，以清晰地傳達(dá)具體且可操作的改進(jìn)建議，而不是返回不透明的錯(cuò)誤代碼或追溯信息。

這是一個(gè)截?cái)喙ぞ唔憫?yīng)的示例：

這是一個(gè)無益的錯(cuò)誤響應(yīng)示例：

這是一個(gè)有益的錯(cuò)誤響應(yīng)示例：

通過提示工程優(yōu)化工具描述

現(xiàn)在介紹一種最有效的工具改進(jìn)方法：通過提示工程優(yōu)化工具的描述和規(guī)范。因?yàn)檫@些內(nèi)容會(huì)被加載到代理的上下文中，它們可以共同引導(dǎo)代理采取有效的工具調(diào)用行為。

在編寫工具描述和規(guī)范時(shí)，可以想象一下如何向團(tuán)隊(duì)中的新成員描述這個(gè)工具。考慮那些可能隱含的背景信息——專門的查詢格式、小眾術(shù)語的定義、底層資源之間的關(guān)系——并將它們明確化。通過清晰地描述（并用嚴(yán)格的數(shù)據(jù)模型強(qiáng)制執(zhí)行）預(yù)期的輸入和輸出來避免歧義。特別是，輸入?yún)?shù)應(yīng)被明確命名：與其使用名為 user 的參數(shù)，不如嘗試使用名為 user_id 的參數(shù)。

通過評(píng)估，可以更有信心地衡量提示工程帶來的影響。即使是對(duì)工具描述進(jìn)行微小的改進(jìn)，也可能帶來顯著的性能提升。在對(duì)工具描述進(jìn)行精確優(yōu)化后，Claude Sonnet 3.5 在 SWE-bench Verified 評(píng)估中取得了業(yè)界領(lǐng)先的性能，錯(cuò)誤率大幅降低，任務(wù)完成率顯著提高。

可以在開發(fā)者指南中找到有關(guān)工具定義的其他最佳實(shí)踐。如果正在為 Claude 構(gòu)建工具，也建議閱讀關(guān)于工具如何動(dòng)態(tài)加載到 Claude 系統(tǒng)提示中的內(nèi)容。最后，如果正在為 MCP 服務(wù)器編寫工具，工具注解有助于說明哪些工具需要訪問開放世界或會(huì)進(jìn)行破壞性更改。

展望未來

要為代理構(gòu)建有效的工具，需要將軟件開發(fā)實(shí)踐從可預(yù)測的、確定性的模式轉(zhuǎn)向非確定性的模式。

通過本文描述的迭代、評(píng)估驅(qū)動(dòng)的流程，已經(jīng)識(shí)別出成功工具的一致模式：有效的工具目標(biāo)明確、定義清晰，能明智地使用代理上下文，可以組合成多樣化的工作流程，并能讓代理直觀地解決真實(shí)世界的任務(wù)。

未來，預(yù)計(jì)代理與世界交互的具體機(jī)制將會(huì)演變——從 MCP 協(xié)議的更新到基礎(chǔ)大語言模型本身的升級(jí)。通過系統(tǒng)化、評(píng)估驅(qū)動(dòng)的方法來改進(jìn)代理工具，可以確保隨著代理能力的增強(qiáng)，它們使用的工具也將與之共同進(jìn)化

參考：

https://www.anthropic.com/engineering/writing-tools-for-agents