文：王智遠 | ID:Z201440

上周五，2024年12月20日。

Anthropic這家AI公司發布一份報告，題目是《Building effective agents》（構建高效的智能代理）。

你可能沒聽過Anthropic，但他們的產品你可能知道，比如Claude系列的AI助手，有Claude 3.5 Haiku和Claude 3.5 Sonnet等等。

這份報告，是基于他們過去一年與數十個團隊合作構建LLM（大語言模型）代理系統的經驗總結。我周末看了，大概有五點內容：

一，對代理系統Agents的定義；二，討論什么時候用代理系統；三，五種核心的工作流模式；四，一些現實中的例子。最后，給開發者提供一些實踐認知。

我覺得內容對開發者，或者對智能體、工作流感興趣的人挺有幫助；所以，把有價值的內容理解后，跟你匯報下。

01

Agents不少人聽過，Anthropic這家公司怎么理解的呢？他們認為，代理可以有很多種定義。

有些客戶把代理看作是完全獨立的系統，可以長時間自主運行，使用各種工具來完成復雜的任務；另一些客戶則把這個詞用來描述那些按照預先設定的流程運行的系統。

在Anthropic，把所有這些不同的形式都叫做代理系統（agentic systems），但在工作流（Workflows）和代理（Agents）之間，有很大的區別。

區別在哪呢？

工作流，是提前寫好的代碼來協調人和工具的系統；代理是自己動態管理自己的流程和工具使用，保持對完成任務方式的控制。

這種區別很重要，因為它幫我們理解了代理系統的本質：即，不是所有的AI輔助系統都得完全自主，有時候一個提前設定好的工作流更適合某些情況「1P」。

那么，什么時候該用工作流、什么時候該用智能體？

其認為，如果任務定義得很清楚，工作流更適合，因為它能提供可預測性和一致性。

如果要大規模的靈活性和模型驅動的決策，代理是更好的選擇，但對很多應用來說，優化單個LLM調用，配合檢索和上下文示例通常就夠用了。

通俗的說：工作流更適合任務明確、步驟固定的工作。就像你按照食譜做菜，每一步都寫得清清楚楚，只要跟著做就行了。

而智能體適合要靈活應對、隨機應變的情況。比如：你要去一個新城市冒險，沒有固定的路線，要根據實際情況來決定下一步怎么走，此時，智能體能幫你在復雜多變的環境中做出決策「2P」。

關于定義，這是第一部分內容。第二部分是什么呢？

Anthropic提出，目前，看到市面有四種流行開發框挺火。分別是：LangChain的LangGraph、Amazon Bedrock的AI Agent框架、Rivet和Vellum。

相信你看到名字有些理解不透，別著急，我和你一樣，于是，索性查了一下。

先說說LangChain。它是一個工具，幫我們創建和管理語言模型（LLM）的工作流。你可以把它想象成一個圖表，幫開發者把不同的任務和步驟連起來，這樣，就能清楚地知道每一步該怎么做，調整起來也方便。

接下來是Amazon Bedrock的AI Agent框架。

這是亞馬遜提供的一個框架，像一個工具箱，里面有很多現成的工具和資源；幫開發者快速搭建智能應用，你可以用它來設計和運行各種AI任務，不用從頭開始。

然后是Rivet，它是一個拖放式的圖形用戶界面（GUI）工具，專門用來構建語言模型的工作流。

我們可以把它想象成拼積木一樣，把不同的功能和步驟拖到一起，形成一個完整的工作流程，這種方式簡單直觀，適合不太會編程的人。

最后是Vellum，它也是一個圖形用戶界面工具，主要是用來構建和測試復雜的工作流；設計完成后，你可以在Vellum里測試，確保一切正常運行。就像一個實驗室，讓你可以在里面嘗試各種方案。

總的來說，四個工具區別在于：LangGraph用圖表連接任務和步驟；Amazon Bedrock的AI Agent框架提供全面的工具箱，讓開發者不用從零開始；Rivet是一個拖放式的GUI工具，適合不懂編程的人；Vellum專注于復雜工作流的設計和測試。

Anthropic給了一個建議：

開發者可以先直接用LLM API來開發，因為很多功能用幾行代碼就能搞定；如果要用框架，一定要弄懂底層代碼，要小心，框架可能會讓調試變難，別因為框架功能多就亂加復雜性。

們還特別提醒，客戶常犯的一個錯誤是，對框架底層實現有誤解。這告訴我們，工具只是幫手，真正重要的是理解背后的道理。

所以，結論是：一，框架確實能讓一些基本任務變簡單，比如調用LLM、定義和解析工具、鏈接調用，但框架不應該成為我們增加不必要復雜性的理由；二，保持系統簡單、好維護、好調試，這才是最重要的。

02

第三部分，報告中詳細介紹五種核心工作流模式。

這部分很重要，首先提到，提示鏈式工作流（Prompt chaining）。怎么理解？

想象一下，你要完成一個復雜的寫作任務，比如寫一篇很棒的營銷文案。你可能先寫個大綱，檢查一下大綱合不合格，然后，再根據大綱寫出完整的文案。

這種工作流的要點是，把一個大任務拆成一連串的小步驟。每個步驟都是一個LLM調用來處理的，而且后面的步驟會用前一個步驟的結果作為輸入「4P」。

在這個過程里，你還可以加一些檢查點（報告里叫“gate”），確保一切都在正確的軌道上。

這種工作流最適合能明確分成幾個固定小任務的情況。主要目的是讓每個LLM調用都專注于更簡單的任務，提高整體的準確性，雖然可能會多花點時間。

具體例子是：

文檔寫作流程：第一步，生成文檔大綱；第二步，檢查大綱是否符合特定標準；第三步，基于審核過的大綱寫完整文檔。

優勢是每個步驟都專注做一個任務，提高準確性；可以在關鍵點加質量檢查；流程清晰，容易調試和優化。

第二種是：路由工作流（Routing）。

這個模式挺有意思，處理很多用戶請求時，會遇到各種各樣的問題；有的問題簡單，有的要專業技術支持，還有的可能涉及到退款這種敏感操作。

路由工作流，它關鍵是先對問題進行分類，然后引導到最合適的處理流程，這樣做的好處很明顯：可以針對不同類型的任務優化不同的處理方式，而不是用一個通用的辦法來應對所有情況「5P」。

舉個例子：

客戶服務系統里，收到用戶的問題后，路由工作流可以先判斷這是個一般問題、退款請求還是技術支持需求，然后分別引導到不同的處理流程。

更聰明的是，它還能根據問題的復雜度選擇用不同能力的模型。比如，簡單常見的問題可以交給像Claude 3.5 Haiku這樣快速的模型處理，復雜或不常見的問題可以交給像Claude 3.5 Sonnet這樣強大的模型來解決。

這樣既能保證服務質量，又能優化成本和速度，關鍵是，這種分類可以通過LLM來完成，也可以用傳統的分類模型或算法。

所以，它的優勢在于靈活性和可擴展性，隨著業務的發展，你可以輕松添加新的分類和處理流程，不會影響現有的功能。

03

第三種，是并行化工作流（Parallelization），這個模式適合要同時處理好多任務。

比如：你在做一個大項目，得同時考慮好幾個方面；類似于開發軟件，要一個模型來檢查用戶輸入的安全性，同時另一個模型來生成代碼。

并行化工作流，就是為了應對這種要同時做多件事的情況設計。

報告里說，并行化主要有兩種實現方式：

一，把任務拆成獨立的小任務，讓它們同時進行，這樣可以省時間；二，通過投票機制，讓好幾個模型處理同一個任務，然后匯總結果；這樣做的好處是，你能從不同的角度得到不同的輸出，提高結果的可信度「6P」。

總的來說，它像一個多功能團隊，每個人都做自己最擅長的事，一起合作，最后得到一個更強的結果。

協調者工作者工作流（Orchestrator-workers）是什么？

你在組織一場音樂會，總得有個人來管大局，確保每個細節都能順利進行，這個人就像「協調者」。

其他人就負責具體的活兒，比如：調音響、弄燈光、賣票這些，他們就是“工作者”，協調者得根據現場情況靈活調整誰干什么。

報告里說，協調者-工作者工作流的點子是一個中央LLM（就是協調者）來動態分配任務，讓好多工作者LLM去完成這些任務。

這樣，協調者能根據實際情況，靈活決定要做哪些小活兒，而不是一開始就把步驟都定死了。

這個模式適合你沒法提前知道具體要干啥的情況，比如軟件開發里的編程任務，每次根據需求，可能要改好多文件，協調者就能根據實際情況決定哪些活兒先干，哪些可以放一放。

總之，協調者-工作者工作流就像是一位指揮家。

接下來說說第五種：評估者-優化者工作流（Evaluator-optimizer），這個模式適合要反復改進和反饋的任務。

比如：你寫文章，可能先寫個草稿，然后請朋友看看，提提意見；你根據意見再修改，讓文章更好。這個過程就跟評估者-優化者工作流差不多。

再舉個例子，我們搜一個東西可能要好幾輪；評估者工作流，會看看現在的搜索結果滿不滿足要求，不滿足繼續搜，直到找到想要的信息。

報告里說，這種工作流的關鍵是循環：

一個LLM先給出初步的回應，另一個LLM來評估這個回應，然后提供反饋，這個過程可以一遍遍重復，直到得到一個更好的結果「8P」。

好處在于它可以一遍遍改進，通過不斷的反饋和調整，最后的輸出質量能提高很多；所以，評估者-優化者工作流就像一個嚴格的編輯，幫你把文章改得更好。

以上五種核心工作流模式，你對哪一種印象比較深？

記不住也沒關系，有一個辦法是，用個人工作的方式，去嵌入幾種模式中，看看哪些業務、項目、任務適合哪一種。

04

第四部分主要講述了：智能代理怎么工作。其提到：

代理會先根據用戶的命令或者和用戶的互動，來搞清楚要干啥。一旦任務明確，代理就自己開始干活。

干活時，代理得知道周圍的情況，比如用工具得到的結果或者代碼運行的反饋，這樣它才能知道自己干得怎么樣。

如果代理在干活的時候碰到難題，它可以停下來，找人問問，確保任務能順利完成；任務干完了就結束了，但也可以先設定好一些停止的條件，比如最多干多少次，這樣能控制整個過程「9P」。

在第10頁中，Anthropic給了一些實際例子。

他們強調，代理特別適合處理開放性的問題，尤其是步驟不好預測的任務。因為代理能自己干活，所以，在信任它們的地方，它們能幫大忙。

比如：有個編碼代理，用來解決軟件工程里的任務，代理自己先看看哪些文件需要改，然后反饋出來，這樣能大大提高開發的速度。

這就是第四部分。最后，第五部分里，Anthropic給出了一套開發工具的好點子，他們覺得：

一，工具在代理系統里特別重要。它們能讓代理和外面的服務、API好好交流；所以，工具設計和做出來時要清楚明白，這樣代理用起來才順手「13P」。

二，開發者得給模型足夠的時間思考。別讓模型在生成輸出的時候卡殼，工具的輸入格式和參數描述要簡單明了，這樣模型才能更好地理解和用這些工具。

三，工具的定義和規格要和整體的提示工程一樣重視。

開發者要考慮不同格式對模型表現的影響。比如：在編輯文件時，可以選擇用差異格式或者重寫整個文件，要確保選的格式能讓模型更容易生成正確的輸出。

報告還建議要多做測試，觀察模型怎么用工具，然后根據測試結果不斷改進工具的設計，通過運行好多示例輸入，開發者可以發現模型可能犯的錯誤，然后改進。

最后，創建一個好的代理計算機接口（ACI）也很重要，開發者要確保工具用起來簡單直接，這樣用戶體驗才好；通過這些方法，Anthropic希望能幫開發者在開發工具的時候避開常見的坑，確保代理系統能高效運行。

總結

你認為哪些有啟發？

我認為最重要部分關于工作流。這五種，何嘗不是由淺入深的一種模式呢？用它來映入個人工作流程，亦是如此。

注釋：

[1].Anthropic. Building effective agents. 2024.12.20；地址：https://www.anthropic.com/research/building-effective-agents