如何構建和調優高可用性的Agent？淺談阿里雲服務領域Agent構建的方法論

背景

近一年多的時間，我一直在和Agent打交道，中間也產出了多篇Agent相關的思考文章，從最早在阿里雲客服機器人中引入Agent能力的實踐文《阿里雲服務領域Agent智慧體：從概念到落地的思考、設計與實踐》，到後來開始深度探索Agent的時候發出的《為什麼一定要做Agent智慧體？》的思考，再到對Manus這個當紅通用Agent產品的剖析《Manus的技術實現原理淺析與簡單復刻》，這些文章也從側面反映出了我們在Agent這個技術領域上的各種思考和業務落地上的“心路歷程”，歡迎有興趣的朋友們前去閱讀。

隨著整個AI業界的發展，我逐漸發現無論是集團內外，還是各行各業，都有越來越多人開始關注、學習Agent，並且開始實踐、開發、部署Agent。因此，無論是從Agent的概念，還是具體落地方法論上，也出現了越來越多的爭議和討論，當然，這種思維模式和落地實踐上的百花齊放，也是非常有利於促進Agent這個新興技術的持續發展的。

本文我想要探討的一個主要話題就是“如何構建真正能在業務上落地的、可用性高的Agent”。當然，這個問題也是一個比較複雜、龐大的話題，我無法在文中給出通用的解決方案，僅僅是從阿里雲服務領域的Agent構建視角出發，來討論一下我們在Agent開發和調優的過程中走過的路、踩過的坑。也希望這些方法論，能夠拋磚引玉、對其他領域（尤其是to B領域）提供一點點參考價值～

Agent概念的爭議

Agent這個技術近些年越來越火，各種Agent產品也是層出不窮，從早些年的各種大模型應用開發平臺、大模型開源框架，到後面逐步發展成各種Agent產品和Agent平臺，比較火的有阿里雲百鍊、Dify、Coze等通用Agent構建平臺、AgentForce之類的垂類Agent平臺，以及Manus、Opeartor、AutoGLM這樣的通用Agent產品，還有許多如Cursor、Claude Code、TRAE這樣的集成了Agent能力的AI專案。

以上這些，應該沒有人會否認他們是Agent平臺或Agent產品（包括含Agent能力的專案），但我也聽到了許多人在Agent概念上存在著各種各樣的討論甚至是爭論。究其根本原因，是Agent這項技術本身還在快速發展和演化中，因此會出現非常多不同的聲音，我認為這是很正常的。

關於Agent的概念和定義，我在之前的文章《為什麼一定要做Agent智慧體？》的“什麼是Agent”部分中有過詳細介紹和描述，在這裡我就不贅述了，但是我曾參與過多次線上線下交流，也看過很多網上的爭論，因此，本文我主要將大家對於Agent概念的爭論的主要矛盾點總結一下，主要聚焦在以下幾個方面：

智慧體 vs 代理：

Agent一定是要“智慧”的嗎？這意味著Agent是否必須是由LLM驅動？滿足“代理”能力的程式、程式碼塊是否可以叫Agent？

自主規劃 vs 工作流：

Agent一定是要能“自主規劃”嗎？預定義好的規劃（如Workflow），是否能被叫做Agent？

函式呼叫 vs 角色扮演：

Agent一定要實現函式呼叫嗎？如果只是透過Prompt完成一段指令，是否被稱作Agent？Agent一定要有“人”的屬性嗎？角色扮演類的LLM，是否屬於Agent？

關於上述這些爭論，我們一個一個來討論。

智慧體 vs 代理

首先，是“智慧體”和“代理”之爭。

Agent這個詞在英文語境下的原始詞義，主要是“代理人”的含義，但是也有“代理”的含義。這裡的“代理”指的是一種行為，主要指的是可以代替人來完成某些事情的行為，而“代理人”這個詞有一種“人”的屬性在裡面，像客服、助手，很多時候在英文中就會翻譯成Agent，更接近一種有“智慧”能力的生命體、智慧體。因此，國內的學術界、工業界很多就給Agent翻譯成“智慧體”，這其實是衍生出了一個更“高大上”的中文翻譯，當然這麼翻譯也沒問題，更加側重於將它的“智慧化”、“自主決策”能力比較形象的刻畫了出來。

但是，另外也有一派人認為，Agent更應該翻譯成“代理”，這樣翻譯不會刻意強調其“智慧化”的屬性，它更貼合Agent這個詞在英文中的“代理”人做某件事情這個行為的本意。其次，他們認為，在LLM火爆之前，計算機領域和AI領域，也早就已經有了Agent這個技術名詞了，Agent並非LLM時代才有的專屬名詞，只是LLM的出現讓Agent這個技術的能力又進一步提升了一個更高的層次。

比如，在雲計算領域，我們會在彈性計算伺服器ECS上，安裝“Agent”，這個Agent指的就是一種伺服器代理程式，它是方便我們管理ECS資源、安全監控的一種“代理程式”，雖然阿里雲將這種Agent起名叫“雲助手”，但這個Agent他只是一個程式碼程式，並非真的存在“智慧”能力。另外，在強化學習領域，也很早就有了Agent的概念，跟現在LLM驅動的Agent定義上更接近了，主要指的是一種可以從環境學習、感知、更新的策略模組，但這個強化學習的概念提出的也比較早，這裡的Agent未必一定是由大模型LLM驅動，他可以是小模型，比如BERT，甚至也可以是一段能更新固定引數的策略程式碼，只要符合從環境中感知、學習、更新的這個行為，就可以稱其為是一個Agent。

因此，Agent其實是一個早於LLM就有了的技術名詞，所以也有很多人將現在的這種更加智慧化的Agent稱為AI Agent或者LLM Agent，來和之前的Agent程式做區分，大家如果看一些相對嚴謹的學術文章或者技術部落格，確實會有在Agent前面加一些字首，其目的就是為了避免與其他Agent混淆，讓大家搞不清這篇文章究竟是在講哪種Agent。

自主規劃 vs 工作流

另外一個爭論比較多的，就是Agent是不是應該必須要有“自主規劃”能力。

這個爭論，其實也是由“智慧體”vs“代理”之爭引申而來的，Agent如果定義為“智慧體”，那麼，他必須得有自主規劃的能力，因為只有真正遇到問題的時候，能自己規劃、分解、解決問題，才有了一種生命體、智慧體的感覺，才更符合大家對於“智慧體”這個詞的認知。

然而，認為Agent是“代理”的人，也會很自然而然的認為，只要Agent能夠完成代理的這個行為，它就可以被稱為是一種Agent，因此不一定非要強調Agent的自主規劃能力；透過LLM或者程式硬編碼等方式，即使按照人工提前預編排好的流程Workflow，它能一步一步執行下去，這也是一種代理模式，因此也符合Agent代理的概念。所以這一派會認為，無論是大模型自主規劃、還是Workflow預先編排，只要能實現“代理完成任務、解放生產力”這個過程，他就是一種Agent。

下面是LangChain的一張描述Workflow和Agent的區別的圖[3]，Workflow是透過預編排的流程來控制LLM作為嵌入節點，或者用LLM直接來控制流程，而Agent則是大模型自主進行環境感知作出反饋。而左側這種繼承了LLM能力的Workflow是否屬於Agent，是目前存在爭議的地方。

隨著技術的發展，現在越來越多出現了Workflow和Agent的各種交叉組合，比如Agentic的Workflow，可以理解為是大模型自主規劃的Workflow，大模型遇到複雜任務的時候，先生成Workflow，然後按照Workflow去執行；還有基於Workflow來構建的Agent或者Multi-Agent，是在Agent外層大的框架是由Workflow設定的，避免發散跑偏，但內部的模組是LLM驅動的，可以根據具體情況自主決策。

即使是像Manus/OpenManus這樣的“通用AI Agent”，我們仔細來看其外部也是有一個大的Workflow框架來約束LLM的規劃步驟，確保LLM不會徹底讓流程發散失控，但其內部的每個節點都是由LLM進行自主規劃，以實現更加靈活的效果，最終展示出來的也是一種很高度智慧化、但同時又相對穩定的通用Agent效果，所以現在來看，Workflow和Agent已經是相互依賴、相輔相成的關係了，無法徹底切割清楚。

函式呼叫 vs 角色扮演

第三個爭論點，聚焦在Agent承擔的任務範圍和互動形式上。

如果我們把Agent看做是“智慧體”的概念，那麼很容易會想到它要有一定的“人設”，所以很多人認為，角色扮演這類才屬於Agent，必須要有一個“擬人”的屬性在，類似“數字人”的概念，比如可以是一個雲計算領域“專業客服工程師”、可以是一個“三甲醫院的專家醫生”，也可以是你喜愛的某個動漫人物、角色等。即使是僅僅是寫了一個人設，寫一段Prompt，使用LLM來執行，哪怕不需要規劃、子任務分解、函式呼叫，只要有人設，這就算是一種Agent。

而將Agent看做“代理”的人會認為，Agent的重點不一定要有“擬人化”的屬性，只要能完成規劃、問題分解，甚至只要有函式呼叫，就可以認為是一種Agent，因為Agent只要是接入了函式呼叫能力，能夠代理完成某個具體任務，這類大模型甚至是程式，就可以被認為是一種Agent。

Agent的概念梳理

看完上面的各種派別，是不是感覺已經繞進去了，Agent由於概念的特殊性，不同人、不同企業、不同學者對它的認知其實是有較大差異的，會出現很多不同的理解，這個其實也很正常，因為很難統一所有人的想法，而且也不需要統一所有人的想法，這些想法的多樣性，正恰恰促進了Agent這項技術的不停發展和革新。

前段時間吳恩達有一個採訪[1]裡，提到了一段話：

他指出，當時很多人在爭論“這個系統到底是不是 Agent”、“它是否真正具備自主性”，但這類爭論本身並沒有太大價值。與其浪費時間在這些語義層面的問題上，不如換一種方式思考。他提出“agenticness 是一個光譜”的概念：不同系統具有不同程度的 agenticness，從幾乎無自主性到高度自主都是合理的存在，只要系統具備一定程度的自主性，都可以歸入 agentic 系統的範疇。

“如果你想構建一個具備一點點或者很多自主性的 agentic 系統，那都是合理的。沒必要去糾結它是否‘真正是 Agent’。”吳恩達說。

吳恩達所說的這個系統裡的agenticness類似是一個光譜，指的是一個系統自主性的程度，可能是從完全沒有智慧能力到非常智慧化的場景，因此這個agenticness是一個光譜。

為了讓大家更好的理解Agent，我們暫且把Agent定義的分成“廣義的Agent定義”和“狹義的Agent定義”兩種型別。

狹義的Agent定義：

即理想狀態下的“Agent”，是一種“智慧體”，能夠聽懂人的自然語言指令，完成複雜任務的自主規劃、分解、執行、反思、決策等，有較強的主觀能動性，無需人為干預其內部細節。

廣義的Agent定義：

更側重於“自動化的任務代理”，不糾結於是否以大模型為基礎，可以透過大模型、小模型、硬編碼、規則引擎等在內的一種或多種技術的混合，以幫助人自動化完成任務為主要目標。

從這裡能看到，廣義的Agent概念裡是包含了狹義Agent的，目前國內外許多企業研發的Agent平臺，其實都在“廣義Agent定義”的範疇裡，因為“狹義的Agent定義”，目前來看還是一種“技術理想主義”，是一個我們需要不斷努力為之奮鬥的、美好的目標。然而，現實是比較殘酷的，“狹義的Agent”雖然構建起來很簡單，任務要求全盤交給大模型來做即可，但是效果的穩定性不佳，落地過程中有太多的問題，導致大家不得不採用各種各樣的方法來約束Agent，時期更加可控，所以說，想要做到理想狀態下的大模型自主決策，現在技術還不夠成熟。

Agent落地過程中的挑戰

“如何構建Agent”的問題已經有很多的文章在討論了，比較好的一篇文章是Anthropic的《Building Effective Agents》[2]，這裡面已經給出了許多構建Agent的正規化和方法論，大家可以去閱讀參考。本文更希望討論的是如何構建更加“高可用性”的Agent。

前文說到“狹義的Agent”是一種技術理想主義，至少在現階段的大模型的能力上還是不夠完善和成熟的，無法做到完全達到預期的智慧化，因此在這種背景下，大家在Agent構建落地的過程中很容易遇到非常多的挑戰和問題，因此，接下來，我希望能在文章中探討這些具體挑戰應該如何解決，從而能總結出如何構建更加容易落地、更加高可用的Agent。

我總結了下Agent構建過程中的問題，大致可以分為以下四大類。

挑戰一：執行效果不穩定

構建Agent非常重要的一項工作，就是提示詞（Prompt）。提示詞通俗來講，其實就是用自然語言描述一下任務要求，看起來其實很簡單，但實操過的話，大家會很容易發現，想要寫出一個能夠穩定執行的提示詞，並不是很容易，甚至大家有的提示詞寫出來像小作文一樣長，越寫越複雜複雜。而且寫完之後，提示詞在執行過程中很容易出現不穩定的情況，然後還要不斷去調優它，甚至出現無論怎麼調優，Agent依然不穩定的情況，這是非常痛苦的一點。

挑戰二：規劃如何平衡

第二個痛點，之前我們講到，廣義的Agent裡面是有很多種技術方案的，大致上可以分為大模型自主驅動的以及Workflow預編排的型別。然而大模型自主驅動的模式也是很容易不可控的，可能我的預期是這樣執行，但它自己經過規劃、執行、反思、總結之後變成了另外的方向，甚至完全走偏，這都是很有可能的。然而，如果透過Workflow的方式去做規劃，又需要投入大量人力成本去編排，導致Agent的構建也會非常低效，有時候要好幾天才能搞出一個相對完善的Workflow，這就讓Agent的構建成本越來越高，因此怎樣去平衡規劃的問題也是一個比較痛的點。

挑戰三：領域資訊整合

第三個挑戰，就是如何將領域資訊或者領域知識注入到大模型裡面。因為大家很多時候用的模型都是通用領域的基座大模型或者開源的基座大模型，基本上都不具備領域垂類的知識資訊，因此，大模型對於領域特定詞彙、特定知識、甚至領域特定流程的理解上就都會很難理解，因此怎樣合理的把領域知識注入到Agent裡面，也是一個挑戰。

挑戰四：Agent的響應速度

第四個痛點，是Agent的響應速度問題。如果將Agent上線到生產環境中，作為需要穩定執行的一段程式，這時候效能問題就變得非常重要。大家會發現，大引數的模型執行Agent的效果還不錯，但速度實在是非常慢，尤其是帶有思考的推理模型要更長的時間。而小引數的模型雖然速度快了很多，但執行Agent的效果又一般，經常不穩定。執行效能和推理效果是呈反比的關係，這也是讓很多人對Agent落地比較頭痛的一個問題。

從提示詞調優出發

首先看第一個挑戰：Agent執行效果不穩定。Agent執行不穩定，大機率是提示詞書寫不當導致的不穩定。提示詞確實還是不太容易寫好的，一般情況下直接寫很容易出現下面的問題：

提示詞過短：

任務要求主體不明、表意不明、模糊不清；模型在不清晰的情況下，只能“腦補”，按照自己的理解來執行任務，容易與預期不符。

提示詞過長：

注意力失焦，重點遺忘；現在的模型雖然都有長上下文的視窗，但從實際情況來看，當提示詞比較長的時候，模型在執行過程中很容易顧頭不顧尾，導致有些指令遵循，有些不遵循。

提示詞中存在衝突、矛盾等：

這個很可能你自己都沒有意識到提示詞的衝突，這會讓模型理解起來有些困困惑。模型會在執行過程中一會兒遵循你的某一條要求，一會兒遵循你的另一條衝突的要求，導致不穩定。

具體如何寫提示詞的文章、教程，公司內外各大平臺如ATA、知乎、掘金等等已經非常之多了，在這裡我不會具體去講如何寫提示詞的結構和書寫規範這些，而是關注在當我寫完一套提示詞，如果效果不好，該如何解決？

我們的解法，最開始是提供一套提示詞模板。這些模板經過大量除錯、測試，發現執行已經比較穩定了。然後讓寫提示詞的同學儘量遵循這個模板來寫，相對來講，就比每個人直接寫要更容易穩定。但我們後來發現這個方式也有些問題，很多時候大家過度套用模板，不需要寫的內容，也一定要生搬硬套寫進來，或者模板有好幾套，也不知道該選擇用哪套。寫的過程中也會出現一些跟模板衝突的問題等等。

之後，我們採用AI輔助做提示詞生成和調優，把提示詞模板給到AI，結合你的需求，先寫一版，你來確認提示詞的邏輯是否正確，如果有問題，你可以及時跟AI提出來去調整，然後由AI來幫你繼續調優。比如說衝突、矛盾的部分AI就是可以檢測出來的，它可以告訴你這其中某些要求和另外一些要求之間是有邏輯問題的。因為“最懂大模型的是大模型自己”，所以我們可以先搞清楚大模型的“腦回路”，才能更好的讓大模型理解我們的需求，可以不斷的和大模型進行溝通，持續迭代的把提示詞整理優化出來，再讓它自己去執行這個提示詞來看效果到底是否符合預期。

Agent規劃層的權衡

第二個挑戰：規劃如何平衡。這裡的規劃（Planning），主要指的是Workflow和大模型自主規劃如何權衡的問題。這裡我參考LangChain的Blog畫了一張圖[4]來表達Workflow和自主規劃的可控性和智慧化能力，很顯然會看到一個規律：LLM自主規劃的智慧化程度越高，可控性越低，而Workflow編排的可控性越高，則智慧化則越低。

可控性高但智慧化要求低的場景，通常是一些標準化、重複執行的場景，更適合Workflow。

從阿里雲客戶服務領域的視角來看，什麼樣的場景適合Workflow呢？比如訂單財務類，就是典型的標準化場景，舉個例子，要去查詢某個訂單有沒有過期，或者要計算是否需要退訂部分費用，這些都是標準化的，如果這類邏輯判斷、數學計算類的場景讓大模型深度參與，就很容易出現幻覺。

再比如，排班類場景也是類似，需要定時提醒客服具體的排版時間，這類情形需要嚴格按照排班表去推送，如果出現幻覺，比如遺漏了某些同學，沒提醒到位，就可能會導致他沒有按時上班，那就非常麻煩。所以像這些場景，我們為了避免出現這些不穩定、幻覺的問題，就可以選擇透過Workflow的方式實現，確保可控性優先，適當降低自主性和智慧化。

但智慧化要求較高的場景，通常是一些探索化、問題複雜的場景，更適合大模型自主規劃。

比如RDS資料庫的例項異常診斷，一般客戶來諮詢的時候就只是描述說“我的RDS查詢非常緩慢”或者“例項有異常”，這類描述一般都比較模糊，但使用者也很難給出更多資訊了，因為這確實是需要我們要進入例項仔細排查、診斷的。比如需要診斷資料庫的會話連線數有沒有異常？QPS有沒有異常？記憶體、慢SQL是不是都有可能導致這個問題？因此，它涉及到的可能性就非常之多，很難透過一個大而全的Workflow去承載所有的可能性。

如果針對這些場景要編排一個Workflow出來，可能要非常龐大，而且可能會出現很多排列組合的分支判斷，這很可能會容易崩潰掉。這類場景就比較適合用大模型自主決策，因為首先大模型在訓練階段就學習過RDS資料庫基礎的技術語料，再結合我們透過提示詞給它幾個大的方向，比如檢查會話連線數、CPU、記憶體、慢SQL等方向進行排查，它就能知道結合使用者輸入的問題，排查RDS異常時大概從哪幾個維度開始，就可以透過我們的工具API去自主查詢、診斷、決策、解決這些問題。它不一定要全部診斷完成，根據前一步的診斷結果，再進一步決定下一步要如何決策，這樣一步步走下去，就非常適合用大模型自主規劃。

還有一種場景比較適合大模型自主規劃的是Agentic RAG。阿里雲客戶服務場景中，有許多的中長尾產品或場景，尤其是長尾產品，我們其實不一定都有梳理好的知識庫，但是能找到相應的官方文件或者使用者手冊。在沒有高質量的知識的情況下，又需要去解決這些問題，就可以用Agentic RAG的方式，讓大模型自主生成搜尋的query，搜尋完成之後再進一步自主檢查、反思搜尋結果是否符合預期，然後決定是否自主去調整query重新搜尋，進行這種更加deep search的搜尋，最終經過多次搜尋、檢驗的過程，找到最合理的答案。這種場景也非常適合大模型自主規劃模的式。

那麼，這兩種情況是上面曲線圖最兩端的情況，能否實現上面曲線的中間狀態呢？

答案是可以，如果想要實現上面曲線圖裡的中間狀態，就需要做到LLM自主規劃與Workflow相結合，也就是使用Multi-Agent（多智慧體）架構來實現。在阿里雲服務領域，有個場景是“郵箱無法收發信診斷”，客戶來諮詢的時候一般會說我郵箱無法收發信了，有的使用者會把郵箱賬號發過來，有的使用者會把郵箱域名發過來，有的使用者會直接把具體報錯發過來，可能性比較多。但排查郵箱賬號的狀態和域名狀態，還有報錯的時候，這些中間過程是可以編排一個確定性的排查過程的，所以我們就把這些中間過程做成了穩定、可控的Workflow，但是為了應對客戶可能的多種不同型別的輸入形式，為了讓模型更加自主靈活的決策排程，於是在這些Workflow的外面，我們又使用一個LLM來動態決策呼叫哪個Workflow，實現了一種“內部穩定可控+外部自主靈活”的效果。

那麼，這種“內可控、外自主”的模式就是一種基於Multi-Agent實現的模式，那麼也可以反過來，比如“外可控、內自主”，比如前文提到過的Manus/OpenManus，也是外面有一個大的Workflow框架，內部的每個節點都是由LLM進行自主規劃的模式。

Workflow的演化路徑探索

LLM自主規劃這個其實主要就是提示詞在驅動大模型完成複雜任務，大部分的過程也是都是模型黑盒的內部決策，實際上沒有太多技術上的方案。但是在Workflow這塊的探索，其實就有非常多模式了。在這裡，我也想花點篇幅，分享一下我們在Workflow這條路上探索過的一些演化路徑。

首先，由於我們的Agent平臺是面向客服和業務同學的，因此我們最開始的一版的Workflow實現，就樹立了一個“儘可能降低使用者編排Workflow的成本和複雜度”的目標，因此，就讓使用者用自然語言來編排Workflow，當時的設計思路是“自然語言編排流程圖+LLM驅動按步執行”。具體的操作過程，就是讓使用者先用自然語言描述出你的流程，然後透過AI大模型來幫你生成流程圖（DAG圖），然後讓大模型驅動，按照流程圖一步一步執行，直到最終完成整個流程節點。這樣做的好處是構建方法和成本確實很低，自然語言描述即可，允許可以編排一個“不完備”的流程圖，大模型執行過程中也會智慧化的識別每個步驟的任務要求，自動補充節點之間的引數銜接問題。但也有其問題，比如執行速度太慢，因為每個環節都要大模型決策，節點一旦比較多，全部走完一遍要很長時間；並且只能從頭開始執行，一路到結尾，暫時無法從中間某個環節直接進入。

所以後來為了提升速度和穩定性，我們就做了第二種Workflow，是“程式碼/大模型混編 + 規則驅動按步執行”，為了節省時間，不需要全部節點都用大模型來驅動，而且改用規則引擎驅動。使用者描述流程，還是透過自然語言的方式描述，但經過大模型AI轉換成流程圖之後，所生成的流程圖中間的節點除了必須用大模型來生成、總結的情況之外，其他節點型別你都可以用程式碼、指令碼、規則來實現，類似一種離線的預編譯過程，儘可能減少大模型帶來的耗時增加、幻覺、不穩定性的問題，將這些邏輯固化為程式碼、規則。經過這樣的設計，我們發現執行速度確實變快了很多，但依然只能從頭執行到尾，如果中間過程出現一些客戶的問題，發生了轉移或者跳轉，我們沒辦法做非常靈活的控制；同時，由於引入了程式碼和大模型的混合編排，導致Workflow的構建成本比純自然語言的形式高了很多，因為規則引擎驅動的流程圖，必須是“完備”的流程圖，節點之間的引數傳遞必須準確無誤，否則就會報錯，因為大部分客服和業務同學很難直接介入對程式碼、規則的調優，導致Workflow的構造過程門檻變的很高，AI生成的流程圖很多時候也並非完全完備，導致構建過程頻繁出現各類問題，需要花費大量人力去除錯。

之後，由於更加靈活的場景的需要，我們需要大模型更靈活的在Workflow的流程的多個節點或者分支之間可以更靈活的識別和流轉，我們演化出第三種Workflow思路，即“自然語言編排 + 大模型自主規劃執行”。自然語言編排過程，與第一種沒有什麼太大差別，也還是自然語言描述，然後AI轉換成“不完備”的流程圖即可，但是在執行的時候，不是讓大模型從頭一步一步執行到結束，而是大模型基於這個流程圖，直接去回覆客戶，執行相應動作。也就是說，我們不讓大模型完全自己發揮去做規劃，而是用這張流程圖作為參考資訊給大模型去做類似RAG的這種參考規劃，這樣的模式相比前兩種模式，更加靈活、更加智慧。

目前，這三種Workflow模式我們是並存的，在實際場景中具體應用哪一種更合理，是要具體問題具體分析的，沒有一種完全完美的解決方案。

領域資料整合與響應速度最佳化

另外還有兩個挑戰，一個是領域資料整合的問題，另一個是響應速度最佳化的問題，我放在一起說下。

首先，如何在通用基座大模型中整合領域資料？這塊主要有下面三個方法：

Prompt中動態領域要求：

根據服務場景匹配度，在Prompt載入的過程中動態引入領域先驗知識，透過類似RAG的方式根據場景動態搜尋和匹配載入領域的知識或者業務經驗，能夠更好的讓模型瞭解領域知識，通常又不會佔用太多的上下文視窗

引入外部技能：

透過呼叫領域工具、知識庫、文件等，讓LLM有更多方式自主選擇獲取領域資料，可以透過讓模型自主選擇在某些場景下是不是可以自主決策呼叫，這些工具、知識庫、文件能夠額外引入一些動態的領域資訊

領域大模型訓練：

在上面的方法實在搞不定領域知識理解的情況下，可以透過訓練領域大模型來注入領域知識，將領域知識透過模型預訓練、後訓練等多階段的訓練可以將領域知識注入到大模型中，從根本上提高領域任務的精準性，但成本相對較高，比如先構造領域資料來源，比如領域知識庫、文件，SOP工具API、各領域產研提供的一些MCP Tools、阿里雲的OpenAPI。接下來經過彙總、清洗，構造成語料，包括單步工具呼叫、多步工具呼叫、反問澄清、Multi-Agent呼叫、條件判斷、場景拒識等等，然後給模型去做SFT/DPO/GRPO等等。評估的方式也有多種，比如說工具選擇準確率、動作執行準確率、引數提取準確率，以及模型生成回覆的效果評估。最後，模型可以在線上推理、規劃、動作、觀察反思、生成等環節得到相比通用模型更好的效果。

另外一個痛點是Agent的執行速度問題，大引數的模型速度慢、小引數的模型效果不好，應該如何解決呢？我們也有一些探索過的方法論給大家分享一下：

程式碼引數預轉換：

在前文Workflow演化路徑的這個探索過程中，我有提到，可以儘量減少Agent中大模型參與的比例，比如使用流程預編譯好的Workflow，將非必要的LLM模組轉換為程式碼或指令碼語言，來提高執行效率

各種推理加速方式：

透過各種加速推理的最佳化方法來提升模型的執行效率，比如模型量化（Int4、int8等）、最佳化KV Cache、使用各種加速框架（如FlashAttention、vLLM等）、更換高效能GPU等

降低模型引數量：

在滿足需求的前提下選用小引數模型，如果這是高頻場景，比如Function call，那就非常適合小引數模型，用大引數量的LLM作為教師模型去蒸餾小引數量的LLM，也可以在提高速度的同時，儘量保留大引數模型的推理效果。

Agent構建和持續調優的路徑

根據上面的一些調優的方法論，我最後總結了一個Agent構建和持續調優的路徑圖，如下所示。

首先，在嘗試使用Agent來解決一個需求問題的時候，可以先從大模型自主決策的方式構建一個原型Demo的Agent，因為透過提示詞工程先做一版Agent，是ROI最低的方式，先透過簡單的實現，看下初始的Agent版本形態是否符合業務或自己的需要。然後在提示詞的基礎上，按照上文所屬的讓提示詞更穩定的調優方法多次調優幾個版本，看看是否能保持穩定的執行。

如果發現效果依然不好，在某些情況下總是出現不穩定的情況，可以嘗試第二步：在Agent的規劃Planning層面，開始嘗試拆解Workflow，透過構造更加結構化的Workflow，來讓Agent在一定的框架範圍內驅執行，來提高它的穩定性，同時Workflow如果使用程式碼規則編排，也可以提升其執行速度，達到一些效能上的要求。

如果發現Workflow的方式雖然穩定，但智慧化能力變弱，開始出現固化、不靈活等情況，或者分解了Workflow依然搞不定，比如說我需要某些地方足夠的靈活，又需要某些環節足夠可控，我們就需要設計更加複雜的Multi-Agent架構，透過將複雜任務拆解成多個子任務，透過多個子Agent來承接這些子任務，並設計多個子Agent之間的通訊方式和形態，最後進行端到端的測試，看這樣部分靈活+部分可控的方式是否能夠滿足複雜場景下的要求。

最後，如果實在前面的方式都嘗試了，某些情況下還是很難調優，或者對準確率、速度、穩定性、智慧化能力都有著極高的要求，那麼就需要對這個Agent的一些關鍵環節做模型的定製化訓練和調優了，這個步驟一版是先確定要訓練的任務，然後需要花較大的經歷去尋找和構造所需的訓練資料，之後做相應的模型訓練和調優。最終，來驗證經過訓練後的模型對相應的任務問題是否能到達預期。

從使用提示詞開始構建原型，到Workflow的構造、Multi-Agent架構設計、模型的訓練和調優，這個成本是隨之不斷的在上升的，但理想情況下，Agent的執行效果也是隨著成本的投入在不斷得到提升，至於要做怎樣的技術選項、投入多大成本，最後達到怎樣的效果，這取決於你的場景的具體要求。

總結與展望

在阿里雲服務領域Agent建設這1年多的時間範圍內，我們探索過很多，也走過很多彎路、踩過很多坑，今天我把這些自己這段時間探索的一些思考、方法論以文章的形式沉澱下來，也是希望能給其他從事Agent落地的同學們提供一些思路，少走一些彎路。當然，各個業務的場景複雜度也不盡相同，我們的服務領域也不能代表各行各業，在大家的領域裡面一定有許多我們沒有考慮到或者沒有做過的方法論，也歡迎大家多多提出、交流，我們互相學習，共同提升，能夠更好的利用Agent這個技術在自己所屬的領域業務中應用落地。