阿裡雲客服 Agent 業務提效實踐：靈活可控的落地方法論

隨著 AI Agent 技術的快速發展，業界許多企業開始在 Agent 方向進行深層次探索，而不僅僅是停留在「大模型 + 工具調用」的簡單應用上。 在 AICon 2025 上海站上，來自阿裡雲的演算法專家姜劍（飛欛）發表題為《阿裡雲客戶服務領域 Agent 在業務提效上的思考與創新實踐》的演講，介紹了“阿裡雲服務領域 Agent 平臺”，以及阿裡雲基於 Agent 快速賦能業務提效的方法論。

Agent 的技術本質與常見模式

Agent 這個詞現在非常火熱，在 AICon 的各大分論壇有很多人在提 Agent 和智慧體。 其實把 Agent 翻譯成智慧體是比較好的，將它的自主決策能力刻畫了出來。

但實際上如果去查一下這個詞在詞典裡面的原始含義，它更想表達的是一種代理或代理人的意思。 所以將 Agent 技術總結成一句話，就是用大模型來代理或類比人的行為，使用某些工具來完成某個任務的能力，它就叫 Agent。

Agent 的運作模式是從我們的環境裡感知用戶的問題、用戶的任務要求，然後輸入到它的大腦里。 它的大腦里就是大模型，有自己的知識儲備，或者使用你提供的一些外部工具或 RAG 的知識儲備，從而做決策和推理，最終產出一些 Action，這些動作又返回來作用到我們的環境中，給客戶回復或者解決各種任務。

當前 Agent 領域可謂百花齊放，我們將它大致分為兩類。 一類大模型自主規劃的，更加整體的一種模式。 另外一類就是 Workflow 預編排類。

大模型自主規劃類的典型代表就是前段時間非常火的 manus，你給它問題或需求，它幫你自動做規劃，拆解執行，然後觀察反思，再進行下一步的規劃分解，直到最後把任務完成，將結論反饋給客戶。

這種模式的好處是它有非常高度的靈活性，可以動態適應環境的變化，而且容錯率較高，一旦出現問題它會自我糾正。 你也可以查看它的結果，但它的可控性會比較低，因為很多時候它其實有自己的一套邏輯思維在運作，所以很多時候我們想干預它反而並不那麼容易。

這種 Agent 適用於探索類、複雜類的問題，就是說我自己也不知道這個問題怎麼解決的情況下，你先給我搞一版，這種情況就非常適合大模型自主規劃類的 Agent。

但我們 ToB 領域在落地的時候有非常多的可控性要求，就是我要求它必須按照我的要求一步一步來完成，這種情況就非常適合用 Workflow 的預編排類 Agent。 它的靈活性相對低一些，因為它需要我們預定義流程。 但它的可控性就會高很多，因為它的每一步執行都是非常清晰可見的。

所以它非常適合標準化場景、重複的重要任務、週期性任務。 這一類的典型有我們阿裡雲的百鍊，還有像 LangGraph 這樣通過預編排流程來實現的 Agent。

在 Agent 模式的基礎上，我們也有非常多的 Multi-Agent 多智慧體的體系。 這類體系常見的有轉交模式，A 執行完給 B，B 執行完給 C。 有嵌套模式，A 調 B，B 調 C，然後 C 再逐步回溯到 B，再回溯到 A，實際上像堆疊的運行狀態一樣是嵌套式的。

另外還有主代理模式，也可以叫做監管者模式或 Supervisor 模式，它通過主 Agent 跟客戶交流，主 Agent 在背後會根據需求去調用各種子 Agent 完成任務。 最後一種就是群聊模式，比如說我的任務扔到群裡，群有很多 Agent 討論或者爭論，最後給我結論或組合的方式來回復我。

當然還有很多類型，這邊就不一一列舉，但總結成一句話就是讓多個 Agent 來代理或類比一群人的行為，每個 Agent 各司其職完成任務，多個任務協同起來去完成複雜任務。

Agent 給客戶服務領域帶來的價值增益

Agent 這種技術能夠給我們客服領域帶來哪些價值？ 第一點，也是我認為非常重要的價值，就是說 Agent 的技術是能夠改變我們的需求研發範式。

首先我們看一下傳統的研發邏輯是什麼樣子的。 我們的客服領域有很多業務或客服同學，他們會有很多需求，需求提過來后，我們需要專門的產品研發人員投入進來，排期去給他們開發任務，開發完后我們還要交付，過程中有問題還要再回溯，重新調整返工，再繼續反覆運算優化。

整個這一輪走下來大概也有幾周或者上月的時間。 主要的問題在於懂業務的同學不懂技術，懂技術的同學不懂業務，所以業務同技術之間反覆溝通，確保我們的思路是一致的，然後才能把問題解決掉。 在 AI 時代或者 Agent 時代，其實就可以發生一些變化。

我們的一種理想狀態是說開發人員負責開發模組化或原子化的 API，把它包裝成現在最火的 MCP Server 給業務同學，業務與客服同學只需要選擇他們需要用的工具，然後按照需求和業務流程，通過 Prompt 或 Workflow 組裝成 Agent，就可以為他自己所用。

也就是說如果我們讓業務同學掌握了低成本構造 Agent 的技術，實際上業務跟技術就融為一體了，他們就可以去研發自己想要的一些工具，來實現一些個人化的 Agent，這是第一個優勢。

第二個優勢是 Agent 可以簡化業務的複雜流程。 做 ToB 時，很多業務的 Workflow 非常複雜，流程編排起來錯綜複雜。 一個簡單的例子，比如說我調用 API Tools，原來我在調度 Tools 之前和之後，都要做非常多的預處理和後處理，比如你的參數要求是這種類型的輸入結構，我必須要把我的參數轉換成你這種結構，然後去調你，然後你輸出結果我還要做解析轉換，然後再執行下一步。

但大模型天然有一種能力，它可以根據你的 API 的 Schema 來自動喚起 API，它可以把輸入和輸出轉換成這個 API 真正需要的，然後把 API 返回的結果轉換成你真正需要的，這個過程就簡化了很多。

這樣的場景其實非常多，在我們的業務流轉過程中，這種參數的轉換、傳遞、變換是非常佔據我們的編排時間的，通過 Agent 可以緩解這樣的問題。

第三個優勢，Agent 的交互也是非常多樣性的。 雖然 Agent 是基於大模型，一提到大模型就會感覺像 App 一樣一定是一種文本的交互，但實際上現在有非常多的 Agent 已經走向了基於 GUI 的方式。

比如像這個圖裡是微軟的案例，它是供應商的 Agent。 如果我們通過純文本的形式去展示 Agent 裡的資訊，我們會看到很多文字，哪怕你再結構化，看起來也很費勁，我要第一眼看到重點內容其實是不太容易的。

但如果把它可視化出來變成圖表，我就可以一眼看到哪一塊供應商、供應鏈出了問題，哪塊出現了延誤，就能第一時間提醒出來。 從交互層面來講，它已經脫離了原來的單純的 LUI 的模式，走向了 GUI。

阿裡雲服務領域的業務背景與挑戰

那麼我們阿裡雲的客服領域有哪些背景和挑戰？

雲領域的客服模式其實大同小異。 我們也是前面有個智慧問答，當客戶有問題時先來和機器人交互，機器人如果能解決你的問題，那就非常高效。 如果機器人解決不了，我們可以用人工服務，我們人工服務會自動根據使用者的問題識別它對應的最優技能組。

在客服同學解決的過程中，他旁邊也有即時的 Copilot 大模型來做實時輔助，提高解決問題的效率，這是我們的基本模式。

我們阿裡雲這邊用戶的問題有哪些特性？ 第一個特性，也是非常重要的特性，就是阿裡雲這邊的產品有幾十個產品線，幾百款產品，產品維度很複雜。

然後像 ECS 這樣的頭部產品下面還有非常多子類型的伺服器，像 PAI 或百鍊上也有大量不同的模型型號。 總體來講，我們產品的複雜性導致了我們解決用戶問題時的難度飆升。 這是第一個維度。

第二個特性是用戶的問題維度。 我們雲計算領域的問題屬性同傳統的客服領域或電商領域有很大差別。 我們除了諮詢類問題，還有很多技術類問題。 所謂諮詢類問題，就是比如我要查個訂單，要續個費，要查一下某某產品支援哪些功能，這種諮詢問題在電商領域非常常見。

但在雲領域，我們還有非常多的問題是技術類的，比如說我伺服器埠不通，某個 API 調用報錯，或者我的某個功能變數名稱解析過程中出現了什麼問題，這種就需要深入到伺服器里，深入到你的產品里去深入排查，這些問題通過完全自動化的 AI 方式很難解決，也就是客服機器人的解決率不是很高，很多都到了人工環節，這是我們問題特性的原因導致的。

第三個特性就是意圖表達維度。 很多時候用戶問題的描述不一定是清晰的，可能很難問得清楚到底這個問題的本質是什麼。 也可能有的客戶的問題非常複雜，他會把一大堆報錯 Log，或大量的前因後果都扔過來，其實都是一些影響我們識別或者技術判斷的因素。

所以總結來說我們有三個痛點，第一個痛點就是雲領域的計算技術複雜性確實非常高，場景複雜，診斷也複雜。 基於大量產品線和產品的情況，我們就要有大量診斷工具來診斷，因為你說你的伺服器出問題了，埠有問題，我就只能登錄你的伺服器去看到底埠是怎麼配置的，你的安全組是怎麼配置的，你的防火牆是怎麼攔截的，所以我們要出大量的工具去診斷這些東西。

這就帶來第二個痛點，就是我們的研發效率也比較低，這些工序都要人開發，然後我們產品又多，所以只能顧頭不顧尾。 頭部產品我們覆蓋了很多工具，但中長尾產品又缺失一些資訊，導致我們的客服同學只能用最原始的方式排查。

第三個通點，語音這個領域還有一個比較特殊的點，就是個人化流程很多，它不像其它服務領域，有個 SOP 下來一步一步執行就 OK 了。 語音這個場景有點像我們的客服又稱為技術工程師一樣，它其實也是一種工程師，所以它就和我們寫代碼一樣，需求提過來后，我寫的和你寫的代碼很難講誰寫的一定好或不好，但只要解決這個問題它就是好的代碼。

我們解決問題的過程也是一樣的，就是客服在服務的過程中，診斷過程因人而異，不一定是誰對誰錯，有一定個人化因素，這就導致我們的研發工序更困難了。

我們調研的時候會發現 A 客服會反饋，說我一般這樣排查，然後 B 客服說我一般那樣排查，我們的管理人員、督導同學又有另外的想法，所以最後在收斂需求過程中非常困難。 我們很多客服同學的領域知識是沉澱在知識庫里，或者文檔裡，其實這些文檔在傳播知識的過程中是有很多損失的。

我寫的文檔你可能看懂了百分之五六十，然後他可能看懂了百分之三四十，中間有很多資訊就丟掉了，導致我們的客服同學的培訓成本就非常高。

Agent 技術就能解決裡面大部分的痛點。 首先 Agent 能帶來整個研發範式的變革，所以開發同學只需要關注核心 API 工具的開發，然後業務同學進來就可以根據需求來自主構建。 Agent 來幫助我們分散研發成本。

另外我們也可以根據自己的喜好構建個人化的 Agent。 比如說我習慣某種流程，我就把我這個流程寫成 Agent 來賦能我自己。 我經常以這種風格或者回復方式去回復客戶，我可以把我話術的風格或者回復方式寫成 Agent，然後大模型按照我的方式去回復。

Agent 也可以沉澱領域經驗，我們既可以把 Prompt、Workflow 共用給別人，還可以運行別人的 Agent，得到別人的處理流程。

阿裡雲服務領域 Agent 的設計方法論

所以說我們就開始投入到 Agent 的構建，我們的客服和業務同學開始大規模寫 Agent。 但在寫 Agent 的過程中我們發現了非常多的問題，可以總結成四大類。

第一個問題是運行效果。 提示詞並不是很好寫，有的提示詞寫出來像小作文一樣非常長，非常複雜，它有一定門檻，並不是那麼簡單寫得出來的。 寫完之後，提示詞在運行過程中有可能會不穩定，你要去調優它，就導致 Agent 不穩定，這也是最痛的一點。

第二個痛點，我們有兩種類型的 Agent，分別是大模型整體驅動和 Workflow 預編排的類型。 前者的模式是非常不可控的，我可能預期是這樣子運行，但它自己規劃后變成了另外的方向，完全走偏，這是很有可能的。

但 Workflow 的方式又要去編排，可能非常低效，可能一些客服同學要好幾天才能搞出 Workflow，怎樣規劃平衡的問題也是痛點。

第三個挑戰就是領域知識怎麼注入。 因為大家用的很多模型都是通用模型，怎樣把領域知識注入進來，是非常痛的點。

第四點就是 Agent 的回應速度問題。 大參數的模型效果還不錯，但非常慢，尤其是帶有思考的推理模型要很長時間。 小參數的模型速度非常快，但效果又一般。

我們來一個個解決。 首先看第一個問題。 提示詞不穩定的問題主要因為提示詞不是太好寫，你直接寫很容易出現這些問題，過短、主體不明、過長、注意力失焦，導致模型運行過程中可能顧頭不顧尾，有些指令遵循，有些不遵循，或者遺忘重點。

甚至有些時候會出現提示詞的前後矛盾，你可能自己沒有意識到，導致模型理解起來有困難。 它就會在運行過程中一會兒遵循你的第一條，一會兒遵循你的第二條，導致不穩定，這是非常痛的問題。

我們的解法是首先提供一套提示詞範本。 這個範本經過大量調試、測試，運行過程中已經比較穩定了。 然後讓業務同學盡量遵循這個範本來寫提示詞，這就比較穩定了。

但我們後來發現這個方式也有問題，很多時候他們過於套用範本了，或者範本有好幾套，你也不知道用哪套。 寫的過程中也會出現一些跟範本衝突的問題等等。

最後我們的方法是用 AI 來輔助提示詞調優， AI 幫你寫一版，你來確認，如果有問題，你可以及時跟 AI 提出來去調，然後 AI 可以幫你調優。 比如說衝突的部分 AI 是可以檢測出來的，它可以告訴你這其中某些資訊是有問題的，我幫你優化成這樣子可能會好一點。

因為最懂大模型的是大模型自己，所以你可以通過這種方式跟它溝通，告訴它需求，讓它把提示詞整理出來，再讓它自己去運行提示詞來看到底效果好不好。

第二點是 Workflow 和大模型自主規劃的權衡問題。 我畫了一張圖，是說越智慧化的東西它可控性越低，越個人化可控性高的東西，智慧化越低。

其實這張曲線里的中間點也是可以存在的。 那麼怎麼樣去平衡它？ 我們來看一些在客服領域的常見場景，第一個是訂單財務類。 像這種標準化場景，比如說我要去查訂單有沒有過期，或者我要計算有沒有該退訂的一些費用，該怎樣給客戶回復，這些都是要標準化的，如果你讓大模型深度參與很容易出現幻覺。 像排班類問題也是一樣，管理同學要定時看一下到底哪個同學沒有按時上班，不要出現拖班之類的情況。

這裡的定時提醒我們也要嚴格按照排班表去推送，如果出現幻覺，遺漏了某些同學，導致他沒有上班，這個問題也是非常麻煩的。 所以像這些場景，我們為了盡量避免出現這些問題，就通過 Workflow 的方式實現。

但另一類場景，比如說 RDS 實例異常診斷，有非常多的客戶來諮詢問題時就一句話，說我的 RDS 運行非常緩慢，我的實例有異常，我的 SQL 跑半天才跑完，這個描述非常模糊，但可能使用者也不能給出更多資訊了，因為這確實是我們要進入仔細看的。

比如說到底你的會話連接數有沒有異常，你的 QPS 有沒有異常，你的記憶體、MySQL 是不是都有可能導致這個問題？ 既然它的可能性非常之多，你很難通過 Workflow 去容納所有可能性。

如果你要編排 Workflow 出來，可能要非常龐大，而且可能會出現一些矛盾或者問題，導致你可能很容易崩潰掉。 這種情況就非常適合用大模型自主決策，你只要給它幾個大的方向，比如說這幾個方向你排查一下，然後模型有很多時候自己內部訓練過這些語料，它知道排查 RDS 異常時大概是哪幾個維度，就可以通過我們的 API 去診斷，然後自主決策要分析哪些問題。

它不一定全部診斷一遍，它可能根據診斷結果就定位出來可能的原因，然後一步步走下去，這就非常適合用大模型自主規劃。

還有一種場景是 Agentic RAG。 我們有非常多的中長尾，尤其是長尾產品，我們其實不一定有知識，但是有相應的用戶文檔或手冊。

我們不一定有非常高品質的知識，但又要解決這些問題，就可以用 RAG 來讓大模型自主生成 query，搜索完了後自主檢查搜尋結果是否符合預期，然後自主去調整，進行類似於 deep search 的搜索，最終找到合理的答案。 這也非常適合大模型自主規劃模式。

在上面的曲線圖裡其實我們還可以有中間狀態，就是大模型與 Workflow 可以結合。 比如郵箱診斷這個場景，可能客戶會說我郵箱無法收發信了，有的使用者會把郵箱賬號發過來，有的使用者會把郵箱功能變數名稱發過來，有的使用者只會把報錯發過來，或者只會說這麼一句話，其實可能性非常多。

但我們排查郵箱賬號的狀態和功能變數名稱狀態，還有報錯的時候，我們沒辦法窮舉，所以我們就做了一些中間狀態的 Workflow，然後讓模型自主決策調度，靈活性就非常高，就是外部靈活內部可控的樣子。

我們在 Workflow 這塊也有非常多的演化路徑。 首先我們在探索 Workflow 時，最開始的一版，我們為了降低用戶編排 Workflow 的複雜度，其實是讓使用者用自然語言編排的。 就是你用自然語言描述你的流程，然後幫你生成圖，然後讓大模型按照流程圖一步一步執行，完成這個任務。

結果發現這樣的方法成本很低，但運行速度太慢，全部走完一遍要很長時間，因為每個環節都要大模型決策。

所以後來為了提升速度和穩定性，我們就做了第二種，就是代碼和大模型混排，中間某些部分你可以用代碼，有些部分可以用大模型來編排，然後讓規則引擎來驅動。

但我們發現雖然這樣速度快了，但只能從頭支撐到尾，如果中間過程出現一些客戶的問題，發生了轉移或者跳轉，我們沒辦法做非常靈活的控制。

於是我們演化出第三種方法，自然語言編排加大模型自主規劃。 也就是說我們不讓大模型自己做全部規劃，我們會把這張流程圖作為參考資訊給大模型去做類似 RAG 的自動規劃，結果發現效果更靈活一些，這三種我們目前是並存的，具體用哪一種，根據我們的場景可以自己選型。

另外一個話題是領域數據集成和回應速度優化的問題。 領域數據集成這塊主要的方法是動態載入一些 Prompt，Prompt 里你可以把一些領域數據背景通過動態 Web 的方式載入進來，另外你可以通過引入一些外部技能，讓模型自主選擇是不是要調工具或者知識庫的文檔。 實在搞不定的情況下，我們可以訓練領域大模型來注入領域知識。

為了提高回應速度，我們用把一些中間過程預編譯成代碼或者參數的方式來提高效率。 第二點就是通過各種加速推理方法，比如模型量化、KV Cache 優化等來提高速度。

第三點就是降低模型參數量，如果這是高頻場景，或 Function call，那就非常適合小參數模型，用大模型去蒸餾小參數模型，也可以提高速度。

我們在 Agent 這塊也是訓練一些模型的。 首先我們會構造領域數據源，源來自多個地方，比如說我們的領域知識庫和文檔，還有一些 SOP 標準工具的 API，以及我們各領域產研提供的一些 MCP 措施，包括阿裡雲的 OpenAPI。 接下來我們會匯總清洗，構造成語料，包括單步、多步、反問澄清、Multi-Agent 調用的，和條件判斷、場景拒識，然後給模型去做 SFT 或 RL。

評估的方式也有多種，比如說工具選擇準確率、動作執行準確率、參數提取準確率，以及模型生成回復的效果評估。

線上推理階段，包括規劃、動作、觀察反思，最後生成，並給使用者提供 Agent 調優路徑。 我們可以先通過大模型自主決策的方式構建原型，通過提示詞工程調優一版，看形態是否符合業務需要。

如果效果不好，第二步拆解 Workflow，構造更加複雜的 Workflow，來提高它的穩定性或速度與可控性。

Workflow 如果搞不定，比如說我這個地方需要靈活，又要可控，我們就拆解 Multi-Agent 來做指令設計，然後端到端測試。

最後如果實在搞不定，某些環節可能要做模型調優，確定訓練任務，尋找構造確定的訓練數據，然後做相應的訓練。 這個成本是隨之上升的，但效果也是隨著你成本的上升在不斷提升。

阿裡雲服務領域 Agent 平台的設計與落地

基於這些方法論，我們構造出來的 Agent 平臺的目的就是要提高平台應用性，也要提高產品的可用性。 我們通過 AI 的方式來輔助生成 Agent，你手動構建 Agent 的方式雖然也方便，但它的產品可用性不太穩定。 傳統的寫代碼方式雖然效果好，但寫代碼的方式不太好用。 所以我們只有用 AI 方式來構造 Agent。

那麼我們的 Agent 平臺主要聚焦三個點。

第一，聚焦領域問題，我們這個平臺不是通用雲平臺，它只是解決雲計算領域問題，集成領域的數據和領域的模式。

第二，它一定要低成本，因為我們面向的是業務同學和客服同學，他們沒有非常高的代碼能力、模型調優能力，一定要最簡單的方法讓他們能夠實現一定的構建。

第三，它是個領域沉澱平臺，能夠把領域思路、流程沉澱到平臺上，這個流程既可以看也可以運行，這是我們的定位。

在我們的全鏈路生產過程中，從提示詞到技能，包括 MCP tools 到知識庫的調用，到流程編排，再到最後的交互應用上，我們全鏈路都是用 AI 輔助的。 比如說 AI 去引導，提需求，然後 AI 生成 Prompt，AI 調優 Prompt，AI 幫你匹配 MCP tools，匹配文檔，AI 幫你編排 Workflow，最後 AI 去生成各種開場白、交互，包括一些 Artifact，還有調用 Agent。

平台架構圖如下。 最底下是我們的基礎設施，在此基礎上我們有 Knowledge 和 Prompt，管理 Knowledge 是我們的重要一環。 然後有各種措施的集成。 Planning 有自主的也有多種風格 Workflow 規劃。

再往上，我們有各種交互和多模態。 管理部分，我們有 Memory 管理，Agent 之間可以通過 Memory 共用。 然後我們有調試診斷、版本管理，你可以回溯到某一版，防止出現線上的不穩定。 你可以灰度、授權、統計分析。

比較重要的一塊是 AI Generator。 裡面的很多資訊，你可以手動編排，同時也有 AI 生成的方式來編排。 最後我們也支持多種 Multi 模式。

下面展示幾個 Demo。 第一個就是大模型自主規劃的，我們可以選擇引導式，然後選擇任務型，就是大模型自主規劃。 我可以寫 Prompt 寫需求，它幫我分析這個需求要做哪些事情，然後生成需求文檔。 你這個需求其實可以寫得非常簡單，然後你來確認這個需求文檔是不是你要的。

它會根據需求文檔自動尋找 MCP tools，然後你去圈選你要使用的那些工具，避免混淆。 選完之後我們構建 Prompt，它會自動寫結構化的 Prompt，包括怎麼調用外掛程式，怎樣輸出，包括一些約束條件和一些示例，極大簡化了我們的業務同學去寫提示的難度。 然後我們選模型，可以調試，比如說我要診斷郵箱的問題，然後郵箱發送信了，你通過這個功能變數名稱解析角度來分析一下。

郵件發出去后，我們的模型它自動列了幾項，我要檢查這幾項，然後自己去寫代碼，調用我們的工具去執行代碼，然後一步步診斷。 最後全部查完，它會總結出可能的結論，這就是非常高效了。

原來我們的客服同學要去查這幾項，最起碼得半個小時過去。 現在我先給一版去看一下有沒有問題，當然過程中也可能會有些地方不是那麼的完美，但絕對能提高我們的效率。

第二個 Demo 是 Workflow。 我們也做了 Workflow 的編排，也是一樣引導式創建，然後選擇加速性，就是我們規則引擎驅動的 Workflow。

然後我寫簡單的業務流程，比如先輸入使用者識別 ID，然後判斷我的 ECS 是哪種付費類型，如果是包年包月就輸出什麼，如果是按量付費怎麼輸出，它會把整理成需求文檔。 然後我們點擊下一步，尋找 tools，我們發現有能夠查付費類型的 tools，然後去創建，就開始構建 Prompt。

我們的 Prompt 也是流程化的 Prompt，然後把 Prompt 轉換成流程圖。

之所以要做這一步，是因為我們有的時候 Prompt 也不一定完全是準的，還需要人工再確認一道，確認後把圖生成出來。 這個圖是可以看的，也可以去調，也可以去運行。 運行的時候它就告訴我這是什麼樣的伺服器類型，邏輯是一樣的，哪怕複雜的上百步的也是這麼個邏輯。

最後一個 Demo，我們通過 AI 的方式輔助生成了一些 Artifact。 比如說功能變數名稱資訊展示，如果我們展示過程全是文字，看起來很痛苦，就可以通過表格的方式展示。 我們也可以通過這種方式讓模型自動生成圖表，來渲染 MySQL 中 QPS 的圖。

這些東西原來都是需要我們研發去做成工具，做成非常複雜的交互，然後讓使用者去用的。 現在我們的客服業務同學只需要簡單寫寫需求，我們自動生成 Prompt，自動去轉換，變成可以真正落地的一些效果。

總 結

最後的話我講一句話，Agent 到底應該是靈活自主還是穩定可控？ 其實這並不是非此即彼的狀態，其實取決於你的場景。 你可以選其中某一種選型，也可以用 Multi 的方式結合它們來實現更加智慧化、更加可控化的能力。

專題演講嘉賓：姜劍（飛樰）

姜劍是阿裡雲演算法專家，負責阿裡雲服務領域 Agent 智慧體平臺的演算法架構設計。 曾負責阿裡雲智慧客服機器人整體演算法架構設計、服務領域大模型訓練、對話機器人鏈路體系的構建等。 在阿裡雲服務領域深耕 7 年，逐步建設起了阿裡雲服務領域的演算法技術體系，曾主導構建了雲計算服務領域的問答系統、知識圖譜、推薦系統等。

會議推薦

首屆 AICon 全球人工智慧開發與應用大會（深圳站）將於 8 月 22-23 日正式舉行！ 本次大會以 「探索 AI 應用邊界」 為主題，聚焦 Agent、多模態、AI 產品設計等熱門方向，圍繞企業如何通過大模型降低成本、提升經營效率的實際應用案例，邀請來自頭部企業、大廠以及明星創業公司的專家，帶來一線的大模型實踐經驗和前沿洞察。 一起探索 AI 應用的更多可能，發掘 AI 驅動業務增長的新路徑！