• 如何建立有效的智能體？來(lái)自anthropic的官方AI Agent構(gòu)建指南
• 一文了解大模型廠商眼中的智能體，來(lái)自anthropic的AI Agent年度性總結(jié)
• 到底什么是智能體？一篇anthropic官方AI Agent綜述看明白
• 工作流和Agent有何區(qū)別？應(yīng)該什么時(shí)候用工作流和Agent？Anthropic官方指南來(lái)了
• 構(gòu)建AI Agent用框架還是用工作流？Anthropic年度綜述智能體構(gòu)建指北
• 大模型廠商視角的AI Agent綜述，Anthropic圖文并茂多個(gè)案例教你構(gòu)建有效智能體

最近兩個(gè)月，全球大語(yǔ)言模型廠商都在關(guān)注和學(xué)習(xí)的OpenAI和anthropic，都迭代了最新產(chǎn)品和解決方案。

OpenAI的12場(chǎng)直播前11場(chǎng)平平無(wú)奇，倒是最后一場(chǎng)壓軸的高性能AI推理模型o3又讓人眼前一亮。是的，最新發(fā)布的o系列模型不叫o2而是取名o3，不知道是不是為了應(yīng)景OpenAI處于其AGI五級(jí)量化表中的第三階段。當(dāng)然，還有個(gè)說(shuō)法是o2這個(gè)名字被搶注了。

名字不過(guò)是一個(gè)代號(hào)，關(guān)鍵是o3的能力還是給了大家很多震撼。其在一項(xiàng)推理基準(zhǔn)測(cè)試ARC AGI 中表現(xiàn)優(yōu)異，得分從之前模型的32% 躍升至87%，在解決復(fù)雜邏輯和數(shù)學(xué)問(wèn)題上的能力有了顯著提升。

隨之而來(lái)的便是“AI取代程序員”的聲量再次被放大，也讓更多人又開始相信大模型是實(shí)現(xiàn)AGI的曙光。

雖然o3成功引起了熱議，但GPT-5還是被曝光研發(fā)受阻。在為期18個(gè)月的開發(fā)過(guò)程中，OpenAI 已完成至少兩輪大規(guī)模訓(xùn)練。只是初始訓(xùn)練速度低于預(yù)期，導(dǎo)致后續(xù)大規(guī)模訓(xùn)練既耗時(shí)又成本高昂，該項(xiàng)目正面臨重大挑戰(zhàn)。

所以對(duì)于“AGI橋梁”這樣的愿景詞匯，大家已經(jīng)越來(lái)越不感冒了。

OpenAI用12場(chǎng)直播讓大家記住了o3模型與AGI愿景，卻帶有一些未來(lái)主義宏大敘事色彩。倒是anthropic在11月發(fā)布的可操控電腦的模型Claude 3.5 sonnet升級(jí)版 ，到現(xiàn)在還為大家所津津樂(lè)道。

Claude3.5 sonnet升級(jí)版實(shí)則已是一個(gè)AI Agent，而能夠操控電腦也就意味著能夠執(zhí)行復(fù)雜業(yè)務(wù)。Anthropic發(fā)布這個(gè)模型，也意味著全球大語(yǔ)言模型的Agent化已經(jīng)徹底開啟。甚至，它還在二級(jí)市場(chǎng)催生了類似“電腦使用（Computer Use）”這樣的概念股。

不只如此，Anthropic還推出了一種模型上下文協(xié)議和架構(gòu)（MCP Architecture），用于為語(yǔ)言模型提供從外部系統(tǒng)獲取的必要上下文。顧名思義，模型上下文協(xié)議定義了如何將現(xiàn)有數(shù)據(jù)源（如文件系統(tǒng)、關(guān)系數(shù)據(jù)庫(kù)、代碼存儲(chǔ)庫(kù)和幾乎所有其他內(nèi)容）連接到 LLM 和Agent。

相關(guān)介紹：https://www.anthropic.com/news/model-context-protocol

                                               ANTHROPIC MCP架構(gòu)

模型上下文協(xié)議代表了AI集成向前邁出的重要一步，提供了一個(gè)通用標(biāo)準(zhǔn)，簡(jiǎn)化了AI系統(tǒng)和各種數(shù)據(jù)源之間的連接。這種開源協(xié)議解決了碎片化數(shù)據(jù)訪問(wèn)的挑戰(zhàn)，允許更高效和上下文感知的 AI 應(yīng)用程序。通過(guò)更輕松地與不同的數(shù)據(jù)源進(jìn)行交互而不會(huì)出現(xiàn)任何問(wèn)題，MCP 提高了 AI 生成的響應(yīng)的相關(guān)性和準(zhǔn)確性。

所以，它被認(rèn)為是AI Agent或者AI能力發(fā)展的重要一步。

從Computer Use到MCP再到改進(jìn)的工具使用，Anthropic所做這些都是在推進(jìn)AI Agent的落地與應(yīng)用。這個(gè)時(shí)間不到2個(gè)月，卻讓其AI Agent已經(jīng)大放異彩。能夠這么快速地推出AI Agent應(yīng)用生態(tài)，可以見得Anthropic對(duì)于智能體這一領(lǐng)域的深度探索與積累。

在這些產(chǎn)品與解決方案的背后，是在過(guò)去一年里，Anthropic與數(shù)十個(gè)團(tuán)隊(duì)的合作、交流以及構(gòu)建的數(shù)十個(gè)跨行業(yè)大型語(yǔ)言模型Agent。

正是基于這些探索與經(jīng)驗(yàn)，12月20日Anthropic發(fā)布了一篇名為《Building effective agents（構(gòu)建有效智能體）》的年度總結(jié)性文章。

原文鏈接：https://www.anthropic.com/research/building-effective-agents

這是一篇對(duì)智能體的總結(jié)性文章，也是一篇大語(yǔ)言模型廠商視角的AI Agent綜述。它介紹了如何構(gòu)建高效的基于大型語(yǔ)言模型(LLM)的智能體，比較了工作流和智能體兩種系統(tǒng)架構(gòu)，詳細(xì)闡述了多種工作流模式（如提示鏈、路由、并行化等），并強(qiáng)調(diào)了構(gòu)建簡(jiǎn)單、透明、易于測(cè)試的智能體的重要性，以客戶支持和編碼智能體為例說(shuō)明了實(shí)際應(yīng)用。還提供了工具提示工程的建議，以提高智能體與工具交互的效率。

重點(diǎn)講述了Agent和工作流的定義、何時(shí)使用Agent、何時(shí)使用框架、構(gòu)建Agent的基塊和工作流模式，以及Agent的實(shí)踐應(yīng)用。

這篇綜述，對(duì)于理清一些AI Agent相關(guān)的概念有很大的幫助。對(duì)于一些似是而非的概念，比如當(dāng)前大家很容易把工作流和Agent混淆，這篇文章也有相應(yīng)的敘述。

文章講了不少，當(dāng)然重點(diǎn)還是告訴大家如何構(gòu)建有效的智能體。畢竟當(dāng)前市面上很多平臺(tái)都存在大量智能體，但對(duì)用戶個(gè)性化需求而言真正可用的可能并不多。所以，從體驗(yàn)通用智能體到嘗試構(gòu)建適應(yīng)自己的個(gè)性化智能體才是最佳選擇。

文章建議從簡(jiǎn)單的LLM API開始，并在必要時(shí)增加復(fù)雜性，以構(gòu)建有效且可靠的Agent系統(tǒng)。這一點(diǎn)很重要，對(duì)于大家在什么需求應(yīng)該怎樣構(gòu)建一個(gè)面向自身業(yè)務(wù)需求的Agent有很強(qiáng)的指導(dǎo)意義。

這篇綜述有助于大家更簡(jiǎn)單地搞懂當(dāng)前階段的AI Agent形態(tài)，這里貼上原文供大家研讀。

在過(guò)去的一年中，我們與數(shù)十個(gè)團(tuán)隊(duì)合作，跨行業(yè)構(gòu)建大型語(yǔ)言模型（LLM）Agent。始終，最成功的實(shí)現(xiàn)不是使用復(fù)雜的框架或?qū)ｉT的庫(kù)，而是使用簡(jiǎn)單、可組合的模式構(gòu)建。

在這篇文章中，我們分享了我們從與客戶和建筑Agent合作中學(xué)到的經(jīng)驗(yàn)，并為開發(fā)人員提供了關(guān)于構(gòu)建有效Agent的實(shí)用建議。

什么是Agent？

“Agent”可以通過(guò)多種方式定義。一些客戶將Agent定義為完全自主的系統(tǒng)，可以在較長(zhǎng)時(shí)間內(nèi)獨(dú)立運(yùn)行，使用各種工具來(lái)完成復(fù)雜的任務(wù)。其他人使用該術(shù)語(yǔ)來(lái)描述遵循預(yù)定義工作流的更具規(guī)范性的實(shí)現(xiàn)。

在Anthropic，我們將所有這些變體歸類為Agent系統(tǒng)，但在工作流和Agent之間進(jìn)行了重要的架構(gòu)區(qū)分：

• 工作流是通過(guò)預(yù)定義的代碼路徑編排LLM和工具的系統(tǒng)。
• Agent是LLM動(dòng)態(tài)指導(dǎo)自己的流程和工具使用的系統(tǒng)，保持對(duì)如何完成任務(wù)的控制。

下面，我們將詳細(xì)探討這兩種類型的Agent系統(tǒng)。在附錄1（“實(shí)踐中的Agent”）中，我們描述了兩個(gè)領(lǐng)域，客戶在使用這些類型的系統(tǒng)時(shí)發(fā)現(xiàn)了特別的價(jià)值。

何時(shí)（以及何時(shí)不）使用Agent

在使用LLM構(gòu)建應(yīng)用程序時(shí)，我們建議找到最簡(jiǎn)單的解決方案，并在需要時(shí)僅增加復(fù)雜性。這可能意味著根本不構(gòu)建Agent系統(tǒng)。Agent系統(tǒng)通常會(huì)為了更好的任務(wù)性能而犧牲延遲和成本，您應(yīng)該考慮何時(shí)這種權(quán)衡是有意義的。

當(dāng)需要更多的復(fù)雜性時(shí)，工作流為明確定義的任務(wù)提供可預(yù)測(cè)性和一致性，而當(dāng)需要大規(guī)模的靈活性和模型驅(qū)動(dòng)決策時(shí)，Agent是更好的選擇。然而，對(duì)于許多應(yīng)用程序，通過(guò)檢索和上下文示例優(yōu)化單個(gè)LLM調(diào)用通常就足夠了。

何時(shí)以及如何使用框架

有許多框架可以使Agent系統(tǒng)更容易實(shí)現(xiàn)，包括：

• 來(lái)自 LangChain 的 LangGraph；
• Amazon Bedrock的AI Agent框架；
• Rivet，一個(gè)拖放GUILLM工作流生成器；
• Vellum，另一個(gè)用于構(gòu)建和測(cè)試復(fù)雜工作流的GUI工具。

相關(guān)鏈接：

LangGraph：https://langchain-ai.github.io/langgraph/

Amazon Bedrock：https://aws.amazon.com/bedrock/agents/

Rivet：https://rivet.ironcladapp.com/

Vellum：https://www.vellum.ai/

這些框架通過(guò)簡(jiǎn)化標(biāo)準(zhǔn)的低級(jí)任務(wù)，如調(diào)用LLM、定義和解析工具以及將調(diào)用鏈接在一起，使入門變得容易。然而，它們通常會(huì)創(chuàng)建額外的抽象層，這可能會(huì)掩蓋底層提示和響應(yīng)，使它們更難調(diào)試。當(dāng)更簡(jiǎn)單的設(shè)置就足夠時(shí)，它們還可能會(huì)使增加復(fù)雜性變得誘人。

我們建議開發(fā)人員直接使用LLM API：許多模式可以在幾行代碼中實(shí)現(xiàn)。如果您使用框架，請(qǐng)確保您理解底層代碼。對(duì)底層代碼的錯(cuò)誤假設(shè)是客戶錯(cuò)誤的常見來(lái)源。

有關(guān)一些示例實(shí)現(xiàn)，請(qǐng)參閱我們的食譜（Building Effective Agents Cookbook）。

食譜鏈接：https://github.com/anthropics/anthropic-cookbook/tree/main/patterns/agents

構(gòu)建塊、工作流和Agent

在本節(jié)中，我們將探討我們?cè)谏a(chǎn)中看到的Agent系統(tǒng)的常見模式。我們將從我們的基礎(chǔ)構(gòu)建塊——增強(qiáng)型LLM開始，逐步增加復(fù)雜性，從簡(jiǎn)單的組合工作流程到自主Agent。

  構(gòu)建塊：增強(qiáng)型LLM

Agent系統(tǒng)的基本構(gòu)建塊是通過(guò)檢索、工具和內(nèi)存等增強(qiáng)功能增強(qiáng)的LLM。我們當(dāng)前的模型可以積極使用這些功能——生成自己的搜索查詢、選擇適當(dāng)?shù)墓ぞ卟⒋_定要保留哪些信息。

增強(qiáng)的 LLM

我們建議關(guān)注實(shí)現(xiàn)的兩個(gè)關(guān)鍵方面：根據(jù)您的特定用例定制這些功能，并確保它們?yōu)槟腖LM提供一個(gè)簡(jiǎn)單、文檔齊全的界面。雖然有很多方法可以實(shí)現(xiàn)這些增強(qiáng)，但一種方法是通過(guò)我們最近發(fā)布的模型上下文協(xié)議，它允許開發(fā)人員通過(guò)簡(jiǎn)單的客戶端實(shí)現(xiàn)與不斷增長(zhǎng)的第三方工具生態(tài)系統(tǒng)集成。

參考鏈接：

模型上下文協(xié)議：???https://www.anthropic.com/news/model-context-protocol??

客戶端實(shí)現(xiàn)：https://modelcontextprotocol.io/tutorials/building-a-client#building-mcp-clients?

對(duì)于本文的其余部分，我們將假設(shè)每個(gè)LLM調(diào)用都可以訪問(wèn)這些增強(qiáng)功能。

  工作流：提示鏈接 Workflow: Prompt chaining

提示鏈接將任務(wù)分解為一系列步驟，其中每個(gè)LLM調(diào)用處理前一個(gè)的輸出。您可以在任何中間步驟上添加編程檢查（參見下圖中的“門”），以確保流程仍在正軌上。

提示鏈接工作流

何時(shí)使用此工作流：此工作流非常適合任務(wù)可以輕松干凈地分解為固定子任務(wù)的情況。主要目標(biāo)是通過(guò)使每個(gè)LLM調(diào)用成為更容易的任務(wù)來(lái)權(quán)衡延遲以獲得更高的準(zhǔn)確性。

提示鏈接有用的示例：

• 生成營(yíng)銷文案，然后將其翻譯成不同的語(yǔ)言。
• 編寫文檔大綱，檢查大綱是否符合某些標(biāo)準(zhǔn)，然后根據(jù)大綱編寫文檔。

  工作流：路由 Workflow: Routing

路由對(duì)輸入進(jìn)行分類并將其定向到專門的跟進(jìn)任務(wù)。此工作流程允許分離關(guān)注點(diǎn)并構(gòu)建更專門的提示。如果沒(méi)有此工作流程，針對(duì)一種輸入進(jìn)行優(yōu)化可能會(huì)損害其他輸入的性能。

路由工作流

何時(shí)使用此工作流：路由適用于復(fù)雜任務(wù)，其中有更好地單獨(dú)處理的不同類別，并且可以通過(guò)LLM或更傳統(tǒng)的分類模型/算法準(zhǔn)確處理分類。

路由有用的示例：

• 將不同類型的客服查詢（普通問(wèn)題、退款申請(qǐng)、技術(shù)支持）引導(dǎo)到不同的下游流程、提示和工具中。
• 將簡(jiǎn)單/常見問(wèn)題路由到Claude 3.5 Haiku等較小的模型，將困難/不尋常問(wèn)題路由到Claude 3.5 Sonnet等功能更強(qiáng)大的模型，以優(yōu)化成本和速度。

  工作流：并行化 Workflow: Parallelization

LLM有時(shí)可以同時(shí)處理任務(wù)，并以編程方式聚合其輸出。這種工作流程，并行化，體現(xiàn)在兩個(gè)關(guān)鍵變體中：

• 分段：將任務(wù)分解為并行運(yùn)行的獨(dú)立子任務(wù)。
• 投票：多次運(yùn)行相同的任務(wù)以獲得不同的輸出。

并行化工作流

何時(shí)使用此工作流：當(dāng)劃分的子任務(wù)可以并行化以提高速度時(shí)，或者當(dāng)需要多個(gè)視角或嘗試以獲得更高的置信度結(jié)果時(shí)，并行化是有效的。對(duì)于具有多個(gè)考慮因素的復(fù)雜任務(wù)，當(dāng)每個(gè)考慮因素由單獨(dú)的LLM調(diào)用處理時(shí)，LLM通常表現(xiàn)更好，允許將注意力集中在每個(gè)特定方面。

并行化有用的示例：

分段：

• 實(shí)現(xiàn)護(hù)欄，其中一個(gè)模型實(shí)例處理用戶查詢，而另一個(gè)模型實(shí)例篩選不適當(dāng)?shù)膬?nèi)容或請(qǐng)求。這往往比讓相同的LLM調(diào)用同時(shí)處理護(hù)欄和核心響應(yīng)表現(xiàn)更好。
• 自動(dòng)評(píng)估LLM性能，其中每個(gè)LLM調(diào)用在給定提示下評(píng)估模型性能的不同方面。

投票：

• 審查一段代碼是否存在漏洞，如果發(fā)現(xiàn)問(wèn)題，幾個(gè)不同的提示會(huì)審查并標(biāo)記代碼。
• 評(píng)估給定內(nèi)容是否不合適，多個(gè)提示評(píng)估不同方面或需要不同的投票閾值來(lái)平衡誤報(bào)和誤報(bào)。

  工作流：協(xié)調(diào)員-工作者 Workflow: Orchestrator-workers

在orchestrator-workers工作流中，中央LLM動(dòng)態(tài)分解任務(wù)，將它們委托給工作LLM，并綜合它們的結(jié)果。

業(yè)務(wù)流程協(xié)調(diào)程序-工作程序工作流

何時(shí)使用此工作流：此工作流非常適合無(wú)法預(yù)測(cè)所需子任務(wù)的復(fù)雜任務(wù)（例如，在編碼中，需要更改的文件數(shù)量和每個(gè)文件中更改的性質(zhì)可能取決于任務(wù)）。雖然它在地形上相似，但與并行化的關(guān)鍵區(qū)別在于它的靈活性——子任務(wù)不是預(yù)先定義的，而是由編排器根據(jù)特定輸入確定的。

orchestrator-workers有用的示例：

• 每次對(duì)多個(gè)文件進(jìn)行復(fù)雜更改的編碼產(chǎn)品。
• 涉及從多個(gè)來(lái)源收集和分析信息以獲取可能相關(guān)信息的搜索任務(wù)。

  工作流：評(píng)估器-優(yōu)化器 Workflow: Evaluator-optimizer

在評(píng)估器-優(yōu)化器工作流程中，一個(gè)LLM調(diào)用生成響應(yīng)，而另一個(gè)在循環(huán)中提供評(píng)估和反饋。

評(píng)估器-優(yōu)化器工作流

何時(shí)使用此工作流程：當(dāng)我們有明確的評(píng)估標(biāo)準(zhǔn)，并且迭代細(xì)化提供可衡量的價(jià)值時(shí)，此工作流程特別有效。良好匹配的兩個(gè)跡象是，首先，當(dāng)人類表達(dá)他們的反饋時(shí)，LLM響應(yīng)可以明顯改善；其次，LLM可以提供這樣的反饋。這類似于人類作家在制作精美文檔時(shí)可能經(jīng)歷的迭代寫作過(guò)程。

評(píng)估器優(yōu)化器有用的示例：

• 文學(xué)翻譯，其中有翻譯LLM最初可能無(wú)法捕捉到的細(xì)微差別，但評(píng)估LLM可以提供有用的批評(píng)。
• 需要多輪搜索和分析以收集綜合信息的復(fù)雜搜索任務(wù)，評(píng)估者在其中決定是否需要進(jìn)一步搜索。

  智能體（Agents）

隨著LLM在關(guān)鍵能力方面的成熟——理解復(fù)雜輸入、參與推理和計(jì)劃、可靠地使用工具以及從錯(cuò)誤中恢復(fù)，Agent正在生產(chǎn)中嶄露頭角。Agent從人類用戶的命令或交互式討論開始他們的工作。一旦任務(wù)明確，Agent就會(huì)獨(dú)立計(jì)劃和操作，潛在地返回給人類以獲取進(jìn)一步的信息或判斷。

在執(zhí)行過(guò)程中，Agent必須在每個(gè)步驟（例如工具調(diào)用結(jié)果或代碼執(zhí)行）從環(huán)境中獲得“地面實(shí)況”，以評(píng)估其進(jìn)度。然后，Agent可以在檢查點(diǎn)或遇到阻塞器時(shí)暫停以獲得人類反饋。任務(wù)通常在完成后終止，但也經(jīng)常包括停止條件（例如最大迭代次數(shù)）以保持控制。

Agent可以處理復(fù)雜的任務(wù)，但它們的實(shí)現(xiàn)通常很簡(jiǎn)單。它們通常只是循環(huán)中使用基于環(huán)境反饋的工具的LLM。因此，清晰而深思熟慮地設(shè)計(jì)工具集及其留檔至關(guān)重要。我們?cè)诟戒?（“提示工程您的工具”）中擴(kuò)展了工具開發(fā)的最佳實(shí)踐。

自主代理

何時(shí)使用Agent：Agent可用于難以或不可能預(yù)測(cè)所需步數(shù)的開放式問(wèn)題，以及您無(wú)法硬編碼固定路徑的問(wèn)題。LLM可能會(huì)運(yùn)行許多回合，您必須對(duì)其決策有一定程度的信任。Agent的自主權(quán)使它們成為在可信環(huán)境中擴(kuò)展任務(wù)的理想選擇。

Agent的自主性質(zhì)意味著更高的成本和可能的復(fù)合錯(cuò)誤。我們建議在沙盒環(huán)境中進(jìn)行廣泛的測(cè)試，以及適當(dāng)?shù)姆雷o(hù)措施。

Agent有用的示例：

以下示例來(lái)自我們自己的實(shí)現(xiàn)：

• 一個(gè)編碼Agent，用于解決SWE工作臺(tái)任務(wù)，其中涉及根據(jù)任務(wù)描述對(duì)許多文件進(jìn)行編輯。參考鏈接：https://www.anthropic.com/research/swe-bench-sonnet
• 我們的“計(jì)算機(jī)使用”參考實(shí)現(xiàn)，其中克勞德使用計(jì)算機(jī)來(lái)完成任務(wù)。參考鏈接：https://github.com/anthropics/anthropic-quickstarts/tree/main/computer-use-demo

編碼Agent的高級(jí)流程

組合和自定義這些模式

這些構(gòu)建塊不是規(guī)定性的。它們是開發(fā)人員可以塑造和組合以適應(yīng)不同用例的常見模式。與任何LLM功能一樣，成功的關(guān)鍵是衡量性能和迭代實(shí)現(xiàn)。重復(fù)一遍：只有在明顯改善結(jié)果時(shí)，您才應(yīng)該考慮增加復(fù)雜性。

總結(jié)

LLM領(lǐng)域的成功并不在于構(gòu)建最復(fù)雜的系統(tǒng)。這是關(guān)于為您的需求構(gòu)建正確的系統(tǒng)。從簡(jiǎn)單的提示開始，通過(guò)全面的評(píng)估對(duì)其進(jìn)行優(yōu)化，只有在簡(jiǎn)單的解決方案不足時(shí)才添加多步驟Agent系統(tǒng)。

在執(zhí)行Agent時(shí)，我們嘗試遵循三個(gè)核心原則：

1. 保持Agent設(shè)計(jì)的簡(jiǎn)單性。

2. 通過(guò)明確顯示Agent的計(jì)劃步驟來(lái)優(yōu)先考慮透明度。

3. 通過(guò)徹底的工具留檔和測(cè)試，精心制作您的Agent-計(jì)算機(jī)接口（ACI）。

框架可以幫助您快速入門，但不要猶豫，減少抽象層并在轉(zhuǎn)向生產(chǎn)時(shí)使用基本組件進(jìn)行構(gòu)建。通過(guò)遵循這些原則，您可以創(chuàng)建不僅強(qiáng)大而且可靠、可維護(hù)且受用戶信任的Agent。

  致謝

由Erik Schluntz和Barry Zhang撰寫。這項(xiàng)工作借鑒了我們?cè)贏nthropic建立Agent的經(jīng)驗(yàn)和客戶分享的寶貴見解，我們深表感激。

附錄1：實(shí)踐中的Agent

我們與客戶的合作揭示了AIAgent的兩個(gè)特別有前途的應(yīng)用程序，它們展示了上述模式的實(shí)際價(jià)值。這兩個(gè)應(yīng)用程序都說(shuō)明了Agent如何為需要對(duì)話和行動(dòng)的任務(wù)增加最大價(jià)值，具有明確的成功標(biāo)準(zhǔn)，啟用反饋循環(huán)，并集成有意義的人類監(jiān)督。

  A.客戶支持

客戶支持通過(guò)工具集成將熟悉的聊天機(jī)器人界面與增強(qiáng)的功能相結(jié)合。這是更適合開放式Agent的自然選擇，因?yàn)椋?/p>

• 支持交互自然遵循對(duì)話流程，同時(shí)需要訪問(wèn)外部信息和操作；
• 可以集成工具拉取客戶數(shù)據(jù)、訂單歷史、知識(shí)庫(kù)文章；
• 可以以編程方式處理退款或更新票證等操作；和
• 成功可以通過(guò)用戶定義的決議來(lái)清楚地衡量。

一些公司已經(jīng)通過(guò)基于使用的定價(jià)模型證明了這種方法的可行性，這種模型只對(duì)成功的解決方案收費(fèi)，顯示了對(duì)其Agent有效性的信心。

  B.編碼Agent

軟件開發(fā)領(lǐng)域已經(jīng)顯示出LLM功能的巨大潛力，其能力從代碼完成發(fā)展到自主解決問(wèn)題。Agent特別有效，因?yàn)椋?/p>

• 代碼方案可通過(guò)自動(dòng)化測(cè)試驗(yàn)證；
• Agent可以使用測(cè)試結(jié)果作為反饋來(lái)迭代解決方案；
• 問(wèn)題空間定義清晰、結(jié)構(gòu)化；和
• 輸出質(zhì)量可以客觀地衡量。

在我們自己的實(shí)現(xiàn)中，Agent現(xiàn)在可以僅根據(jù)拉取請(qǐng)求描述在SWE工作臺(tái)驗(yàn)證基準(zhǔn)測(cè)試中解決真正的GitHub問(wèn)題。然而，盡管自動(dòng)化測(cè)試有助于驗(yàn)證功能，但人工審查對(duì)于確保解決方案符合更廣泛的系統(tǒng)要求仍然至關(guān)重要。

附錄2：快速設(shè)計(jì)您的工具

無(wú)論您正在構(gòu)建哪個(gè)Agent系統(tǒng)，工具都可能是您Agent的重要組成部分。工具使Claude能夠通過(guò)在我們的API中指定它們的確切結(jié)構(gòu)和定義來(lái)與外部服務(wù)和API進(jìn)行交互。當(dāng)Claude響應(yīng)時(shí)，如果它計(jì)劃調(diào)用工具，它將在API響應(yīng)中包含一個(gè)工具使用塊。工具定義和規(guī)范應(yīng)該像您的整體提示一樣得到及時(shí)的工程關(guān)注。在這個(gè)簡(jiǎn)短的附錄中，我們描述了如何提示您的工具進(jìn)行工程設(shè)計(jì)。

參考鏈接：

工具：https://www.anthropic.com/news/tool-use-ga

工具使用塊：https://docs.anthropic.com/en/docs/build-with-claude/tool-use#example-api-response-with-a-tool-use-content-block

通常有幾種方法可以指定相同的操作。例如，您可以通過(guò)編寫diff或重寫整個(gè)文件來(lái)指定文件編輯。對(duì)于結(jié)構(gòu)化輸出，您可以在markdown或JSON內(nèi)返回代碼。在軟件工程中，這樣的差異是表面上的，可以無(wú)損地從一個(gè)轉(zhuǎn)換到另一個(gè)。然而，對(duì)于LLM來(lái)說(shuō)，某些格式比其他格式要困難得多。編寫diff需要在編寫新代碼之前知道塊頭中有多少行正在更改。在JSON內(nèi)編寫代碼（與markdown相比）需要額外轉(zhuǎn)義換行符和引號(hào)。

我們決定工具格式的建議如下：

• 在模型陷入困境之前，給它足夠的令牌來(lái)“思考”。
• 保持格式接近模型在互聯(lián)網(wǎng)上自然出現(xiàn)的文本。
• 確保沒(méi)有格式化“開銷”，例如必須準(zhǔn)確計(jì)算數(shù)千行代碼，或?qū)λ帉懙娜魏未a進(jìn)行字符串轉(zhuǎn)義。

一個(gè)經(jīng)驗(yàn)法則是考慮在人機(jī)界面（HCI）上投入多少精力，并計(jì)劃在創(chuàng)建良好的Agent-計(jì)算機(jī)界面（ACI）上投入同樣多的精力。以下是一些關(guān)于如何做到這一點(diǎn)的想法：

• 設(shè)身處地為模型著想。根據(jù)描述和參數(shù)，如何使用這個(gè)工具是顯而易見的，還是需要仔細(xì)考慮？如果是這樣，那么對(duì)于模型來(lái)說(shuō)可能也是如此。一個(gè)好的工具定義通常包括示例用法、邊緣情況、輸入格式要求以及與其他工具的清晰邊界。
• 如何更改參數(shù)名稱或描述以使事情更加明顯？將其視為為團(tuán)隊(duì)中的初級(jí)開發(fā)人員編寫出色的文檔字符串。在使用許多類似工具時(shí)，這尤其重要。
• 測(cè)試模型如何使用您的工具：在我們的工作臺(tái)中運(yùn)行許多示例輸入，以查看模型犯了哪些錯(cuò)誤，并進(jìn)行迭代。
• 對(duì)你的工具進(jìn)行防錯(cuò)設(shè)計(jì)（Poka-yoke your tools.）：改變論點(diǎn)，這樣更難犯錯(cuò)誤。

在為SWE工作臺(tái)構(gòu)建Agent時(shí)，我們實(shí)際上花了比整體提示更多的時(shí)間來(lái)優(yōu)化我們的工具。例如，我們發(fā)現(xiàn)在Agent移出根目錄后，模型會(huì)在使用相對(duì)文件路徑的工具時(shí)犯錯(cuò)誤。為了解決這個(gè)問(wèn)題，我們將工具更改為始終需要絕對(duì)文件路徑-我們發(fā)現(xiàn)模型完美地使用了這種方法。

SWE工作臺(tái)鏈接：https://www.anthropic.com/research/swe-bench-sonnet

本文轉(zhuǎn)載自 ??王吉偉??，作者： 王吉偉