作者 | AICon 全球人工智能開發與應用大會

策劃 | 李忠良

編輯 | 宇琪

從數年前的斯坦福小鎮，到今年爆火出圈的 Manus 和 MCP，Agent（智能體）已然成為當下人工智能的代名詞。然而，當 Agent 成為所有人討論的焦點時，其本質反而愈發難以看清。究竟何為 Agent？未來 Agent 生態將如何演變？又哪些機遇值得我們提前搶占先機？

近日 InfoQ《極客有約》X AICon 直播欄目特別邀請了商湯科技研發總監王志宏擔任主持人，和騰訊云智能體平臺產品中心總經理王磊、彩訊股份 AI 產研部總經理鄒盼湘一起，在 AICon全球人工智能開發與應用大會2025 深圳站即將召開之際，共同探討 Agent 應用工程化落地的架構范式。>

部分精彩觀點如下：

在專業門檻高、勞動重復、價值感低的場景中， Agent 正好可以發揮巨大作用，以智能化手段解決低效問題。

Workflow 太剛性，面對復雜問題往往無能為力。此時，自主規劃 Agent 的分析與執行能力就能帶來更強的靈活性和創造性。

強化學習提供了一種以“任務為導向”的模型優化路徑，更適配當前 Agent 的任務規劃邏輯。

當前的重點，是以技術手段實現預期結果，然后再思考是否可以進一步規范化、協議化，促進各系統之間更順暢的協作。

在 8 月 22-23 日將于深圳舉辦的 AICon全球人工智能開發與應用大會上，我們特別設置了 專題。該專題將涵蓋多 Agent 協作系統設計、AgentOps 等多個話題，暢談 Agentic 應用產業化落地的無限可能。

查看大會日程解鎖更多精彩內容：

https://aicon.infoq.cn/2025/shenzhen/schedule

以下內容基于直播速記整理，經 InfoQ 刪減。

Agent 的定義與價值

王志宏：當前行業中，“Agent”常被提及。Agent 的概念是什么？Agent 與傳統 IT 服務或 AI 服務有什么本質區別？

王磊：可以從狹義和廣義兩個維度來理解和定義：狹義上的 Agent，能夠自主與環境交互，獨立進行編排和決策，以完成特定的任務目標；而廣義上的 Agent 更加通俗，通常被泛指為大模型應用，它包括兩類：一類是前面提到的狹義 Agent，另一類是利用大模型技術，通過 Workflow 編排來完成任務的應用。

2023 年，OpenAI 最初提出 Agent 的概念時，也給出了一個更泛化的定義：Agent = 語言模型（language model） + 執行器（executor）+ 計劃模塊（planner）+ 工具（tools）。我認為這個定義很契合目前業內對 Agent 的主流理解。

鄒盼湘：如果將傳統的 IT 系統視為一種工具，是我們用來完成工作的輔助工具，那么 Agent 更像是一個“伙伴”。它不僅可以與我們互動、協作，還能夠自主完成某些任務。理想狀態下，Agent 無需人工干預，就能實現自主感知、任務規劃、執行和調整。

從結果導向來看，Agent 是以目標為核心的系統。它具備將抽象目標轉化為具體行動的能力，而不是簡單地響應輸入。例如，它不只是執行某個按鈕命令或應答一句指令，而是可以根據實際情況動態調整策略，以達成用戶設定的預期目標。

Agent 還應具備動態適應和持續學習的能力，它能夠根據環境反饋或用戶在使用過程中的輸入，不斷學習每位用戶的行為模式和歷史信息，自動記錄并優化自身的決策策略，從而實現更高效、更精準的任務完成。

相較于傳統以開發者驅動為主的 IT 系統，Agent 更體現為一種“以模型驅動”的開發范式。它依賴大模型以及其他基礎模型，能夠自主規劃、調用、反思，并提升整個系統在決策方面的智能化水平。

王志宏：哪些行業或場景會對 Agent 的需求最為迫切，通過 Agent 解決了哪些核心痛點？

鄒盼湘：我認為未來幾乎所有行業都會通過 Agent 進行業務重構。如果要選出幾個應用最迫切的領域，首先是企業知識庫。現在大多數企業的知識尚未得到充分利用，一方面缺乏有效的沉淀機制，另一方面即便沉淀了，也缺乏明確的場景或鏈路將這些知識的價值釋放出來。

通過基于大模型的企業知識庫類 Agent，可以顯著提升知識獲取效率，同時保障企業知識的傳承和組織智慧的積累。此外，它還能幫助實現信息的一致性與準確性，加快新員工培訓、工具使用賦能、開發規范理解等流程。跨部門協作方面，不同部門擁有各自的知識庫，Agent 可以幫助了解其他領域的流程和信息，促進協作。

另一個典型場景是企業智能 BI（AIBI）。隨著企業規模擴大，數據分析工作日益復雜，傳統上需要數據分析師、數據挖掘師乃至數據庫工程師，負責數據查詢、建庫和挖掘價值。而通過 Agent，我們可以重構整個流程，使企業內的每一位員工都具備“數據分析師”的能力。

Agent 可根據用戶需求，快速提供所需數據并釋放其價值。即便是非技術人員，也可以基于不同維度，輕松獲取并理解數據潛在含義，比如掌握當日銷售情況或市場波動，實現數據的民主化應用。

此外，Agent 還能優化資源配置，例如預測庫存水平、制定營銷預算，并根據不同預算或活動策略進行資源分配，避免浪費。過去這些工作依賴專業團隊，周期以“月”為單位，現在通過 AIBI 可以將數據分析的響應時間縮短至“小時”級別。

王磊：目前 Agent 落地最廣泛的場景之一，就是與知識服務相關的部分。企業的知識服務大致可以分為兩類。第一類是面向外部用戶，主要包括政策類咨詢服務，例如公積金、社保等政府政策，或企業產品的售前售后咨詢，這類服務核心在于知識的對外傳遞和答疑。

第二類是面向企業內部的知識服務，又可以細分為兩類：一是業務知識問答，例如保險企業內部關于定損、合規、政策解讀、賠付規則等方面的知識查詢；二是辦公效率提升類應用，如合同審查、項目周報、會議紀要整理等。這些看似瑣碎的工作日常高頻發生，但若通過 Agent 處理，可有效釋放員工的時間和精力。

現在業界也廣泛部署了“代碼助手”類的 Agent，這一類應用在國內外發展迅速，能夠自動生成約 25%–30% 的代碼，其質量和采用率也都較高。本質上，這些應用都是在解決實際問題，創造新增價值。

在我們的觀察中，Agent 的價值主要體現在兩個方面。第一是降本增效：很多重復性任務并不需要人工完成，使用 AI 來處理既高效又降低人力成本，人類通常也不喜歡這類機械性工作。

第二是知識輔助：企業中很多崗位對知識的記憶和積累要求極高，比如要成為某一領域的專家可能需要上萬小時的訓練，但這類專家資源一旦缺位，或新人入職時經驗匱乏，就容易出現斷檔。Agent 在這種場景下可以作為輔助力量，幫助企業保持知識傳承和業務連續性。

此外，在產品創新方面，Agent 也具有重要意義。比如現在的交互方式已經從傳統操作界面轉向自然語言，甚至語音驅動，未來還會融合視覺，實現多模態的智能交互體驗。

這些變化將極大革新人與系統之間的交互方式。我自己在使用 AI 工具時就明顯感受到，它們比傳統工具更易用、更吸引人，這正是產品創新帶來的價值。

王志宏：我今年一直在推進 AI 的私有化落地，也接觸了不少客戶。他們普遍存在一個特點：很多核心業務場景高度依賴專業人才。雖然需要資深專家處理問題，但這些問題往往重復且枯燥。

比如專家要不斷地培訓新人，解答常見問題；醫生要反復面對不同病人的基礎問診；律師則需要頻繁為客戶查閱法律文件、做出解釋。這些工作雖然對專業性要求高，但價值密度卻不高，其中可能有 80%–90% 是重復勞動。

這就造成了一個矛盾：會做的人不愿意做，不會做的人做不了。我們可以通過訓練行業 Agent 來緩解這一問題，讓它們充當專業人才的智能助理，承擔重復、標準化的部分工作。

很多行業任務雖然需要專業知識背景，但其中有大量結構化、流程化的操作，而這正是 Agent 能發揮作用的地方。它可以通過學習知識庫、流程經驗等先驗知識，去自動完成一部分專業工作。

這些場景共同的痛點是：專業門檻高、勞動重復、價值感低。而 Agent 正好可以在這類場景中發揮巨大作用，以智能化手段解決低效問題。

企業落地的技術與實踐挑戰

王志宏：目前市面上 Agent 兩種形態：基于 Workflow 構建的 Agent 和自主規劃 Agent，這兩類 Agent 構建的核心技術差異是什么？分別適用于哪些場景？

王磊：基于 Workflow 構建的 Agent，通常是通過 DAG（有向無環圖）流程來完成任務編排。而具備自主規劃能力的 Agent，則是依靠模型本身的主動思考和時間規劃來推進任務。這兩種方式在技術路徑上有本質差異。

具體來看，基于 Workflow 的 Agent 本質上是規則驅動的自動化流水線。開發者在構建時已明確整個流程的步驟、每一步的輸入輸出以及執行動作，因此核心依賴規則引擎。

此外，還需要模塊化的編排工具，使開發者能靈活組合節點來完成特定任務。除此之外，Workflow 系統還要具備健全的異常處理機制，以應對復雜的邊界條件。

而自主規劃型的 Agent 則更依賴于強化學習和因果推理能力。通過獎勵函數來優化策略，再結合反思機制不斷糾正錯誤，實現自我優化。此外，它還需具備動態任務分解能力，能夠將任務拆解為若干動作或子任務，逐步執行，最終完成整體目標。在此過程中，Agent 要能判斷何時調用哪種工具，確保任務得以順利推進。

從長遠看，我們當然希望實現具備自主思考與規劃能力的第二類 Agent。但在當前實踐中，由于大模型存在幻覺問題，難以保證準確性和可控性，而企業對可控性和精度要求很高。

因此在現階段，基于 Workflow 的 Agent 反而應用更廣，具備較強的工程可行性。

鄒盼湘：從構建路徑來看，Workflow 型 Agent 相當于預設了一套任務流程，而自主規劃型 Agent 則具備一定的思考能力。Workflow 的構建不僅需要一個編排畫布，方便快速設計業務流程，還需要強大的執行引擎來運行這些流程。

我們在構建 Workflow 時，會考慮串行、并行、回環、全局跳轉等模式，以支持多樣化的業務需求。

而自主規劃 Agent 的底層邏輯則是 REACT 框架：推理、執行、觀察、循環與工具調用。它強調激發大模型的能力，讓其自主調用資源，通過不斷迭代完成復雜任務。

相比之下，這類 Agent 具備更強的泛化能力和靈活性，適用于任務復雜或意圖模糊的場景，不再是簡單的 API 映射。

王志宏：Workflow 型 Agent 的優勢在于流程明確，它能將專家經驗轉化為固定的行為路徑，每一步輸入輸出都清晰可控。開發者可以通過可視化工具如拖拽連線，或基于開源框架如 LangChain、LambdaIndex，或自研工具如 LazyLLM 編排完整流程。

這種模式適用于需要高準確率的企業服務場景，尤其是批量處理成千上萬個任務時，對系統穩定性和結果一致性要求極高。

Workflow 太剛性，面對復雜問題往往無能為力。此時，自主規劃 Agent 的分析與執行能力就能帶來更強的靈活性和創造性。

因此在實際落地中，我們常常將兩種 Agent 結合使用，在 Workflow 中嵌入具備思考能力的節點，在自主 Agent 中集成流程引擎，二者相輔相成，現在很多框架都支持這樣的融合開發。

王志宏：對于 Agent 系統來說，RAG、強化學習、分布式推理這些技術分別起到什么作用，為什么今年各大廠商和研究機構會大力推崇強化學習？

鄒盼湘：從 Agent 的幾個關鍵組件來看，RAG 本身可以獨立構建成一個應用。但在我們當前的 Agent 開發實踐中，RAG 更多是作為數據來源的工具，用于為 Agent 提供推理和規劃所需的背景知識。

相比傳統意義上主要依賴本地知識庫進行檢索的 RAG 應用，我們目前采用的方式更加多樣化。除了從本地知識庫中召回信息外，還引入了 Agent 記憶機制，甚至整合了互聯網的多源知識。這種整合方式有助于 Agent 獲取更全面的決策依據。

至于強化學習，它的核心作用在于提升模型在特定垂直領域的推理能力。在 B 端應用場景中，企業通常有專屬的業務流程、系統與數據。大模型要充分理解這些復雜的上下文，面臨較大挑戰。通過強化學習的方式，可以逐步增強模型在行業特定任務中的“智力上限”。

另外一個關鍵技術是分布式推理，它主要用于兩個方面。一是支持多 Agent 系統的運行，這類系統往往對計算資源和協同機制要求較高；二是優化性能表現。相比傳統 IT 系統，當前的 Agent 系統響應速度慢、算力消耗大。分布式推理有助于提升響應速度和并發能力。

對于復雜任務，我們不再依賴單一模型處理全部問題，而是將其拆分成相對獨立的子問題，通過多 Agent 協作解決。這種松耦合的結構更具可擴展性與可維護性，也使系統能動態應對環境變化。

多 Agent 之間的協商機制，能夠實現整體任務的最優執行。它不僅使系統對環境更加敏感、靈活，也更容易適應業務需求的變化，強化學習在其中的角色也逐漸重要起來。從去年底到今年初，業界對強化學習的討論明顯增多，部分原因是傳統的模型訓練路徑面臨瓶頸——數據集已被廣泛使用，新數據稀缺，舊的擴展方式難以為繼。

而強化學習提供了一種以“任務為導向”的模型優化路徑，更適配當前 Agent 的任務規劃邏輯。因此，它逐漸成為大模型廠商提升推理能力的主要方向。

王志宏：RAG 是一種非常典型的廣義 Agent，在企業中的落地效果尤為顯著，原因在于企業通常擁有大量專有知識，這些知識往往因保密需求無法用于大模型的訓練。例如航空航天、基建、鐵路等行業，企業數據長期封閉于局域網之中，使得現有模型難以有效回答行業相關問題。

客戶普遍反饋，大模型在通用領域表現優秀，但在本行業則常出現知識不足甚至錯誤的情況。因此，許多企業傾向于構建自有 RAG 系統，用作企業知識庫，這類知識庫在私有化部署場景中尤其受到青睞。

相比其他 Agent，RAG 更易穩定落地，尤其在準確率要求高的業務場景中表現優異。Agent 可以提升 RAG 的能力，例如在初次問答質量不高時，Agent 可對用戶問題進行拆解、判斷回答準確性，并通過迭代優化生成結果；同時，RAG 也可為 Agent 提供知識支撐，例如作為工具知識庫，幫助 Agent 從海量工具中選擇最合適者。

考慮到大模型的上下文長度有限，如果需要從成千上萬個工具中選出合適的一個，就必須借助一個結構化的工具描述庫，而這正是 RAG 的用武之地。通過存儲每個工具的名稱和功能簡介，RAG 可輔助 Agent 做出更優的工具選擇。

此外，RAG 還能作為記憶模塊，減少 Agent 的工具選擇錯誤，提升決策穩定性。因此，RAG 本身既是一個 Agent，也可以與其他更復雜的 Agent 配合，共同完成高難度任務。

關于強化學習，我認為其核心價值在于降低標注成本。在大模型訓練中，算力和高質量標注數據是主要瓶頸。強化學習通過引入沙箱環境和獎勵函數機制，讓模型在無需人工標注的情況下自行學習。

例如，當模型輸出正確時給予獎勵，錯誤時施以懲罰。這樣一來，模型便可通過試錯優化策略，極大降低人力成本。對企業而言，這種方式實實在在地“省錢”，因此強化學習也越來越受到青睞。

王志宏：在多 Agent 系統中，存在規劃驅動（中央規劃）與自治驅動（各 Agent 自主決策）兩種模式，更看好哪種模式在企業級場景中的落地？為什么？它們在實際部署中各有哪些優勢和挑戰？

王磊：在規劃驅動（Plan-and-Execute）模式中，系統通常由一個計劃器（Planner Agent）和一個執行器（Executor Agent）組成。用戶發出請求后，計劃器會對任務進行分析并生成任務列表，再將其交由執行器完成各項子任務。任務全部完成后，結果返回給計劃器，由其進行總結并生成最終響應，返回給用戶。

而多 Agent 協作（Multi-Agent）模式，通常包括一個主控 Agent（或稱入口 Agent）與若干專家 Agent。通過配置 handoff 機制，各個 Agent 能夠根據任務判斷是自行處理，還是轉交給更合適的 Agent，由此實現復雜任務的協作完成。

在多 Agent 模式下，我們可以調用具備特定功能的協同 Agent，例如一個內嵌 Workflow 的 Agent。至于兩種模式孰優孰劣，其實更多是“選擇題”而非“標準答案”，因為它們各有優劣。

從靈活性角度來看，Multi-Agent 模式配置靈活、上手簡單，但對底層大模型能力依賴較高，輸出效果易受影響；Plan-and-Execute 模式則相對定制化、配置不夠靈活，但對模型的要求較低，落地效果更穩定，尤其適合當前大模型能力尚不完全可靠的階段。

從執行速度來看：Multi-Agent 更適合快問快答場景，響應速度快，通常為同步執行。Plan-and-Execute 更適合需要深入推理、系統分析的任務，通常響應較慢，采用異步機制。

鄒盼湘：目前從我們正在推進的項目和產品規劃來看，市場上的主流仍然是規劃驅動的模式。這種方式通常由一個監督者進行任務的分發與調度，主流的多 Agent 平臺基本上也采用這種模式。

具體來說，這種模式中會有一個名為 planner 的主 Agent，負責對用戶需求進行整體規劃、任務拆解，并將各個子任務分配給對應的子 Agent 執行。

主 Agent（planner）會根據任務特點，選擇最合適的子 Agent 來完成相應的工作。如果執行失敗，它會根據失敗反饋重新判斷，是繼續由原子 Agent 執行，還是重新分配給其他 Agent。這個主 Agent 就像一個大腦，或者說是一個“組長”，統一安排任務和調度資源。

自治驅動，則可以類比為一個團隊在沒有明確組長的情況下，自主協商如何完成任務。各個 Agent 之間可以自由通信，而不是被動等待任務分配。類似于一個課題組，成員們共同討論并決定誰負責分析、誰執行、誰測試等。

這種模式目前還主要應用在探索性或較淺層的場景中，尤其在 B 端的垂直業務場景里，我們會更加謹慎地使用這種模式。

這兩種模式的本質區別在于通信方式：規劃驅動是單向通信，由主 Agent 向下指令；而自治驅動是雙向或多向通信，Agent 之間可以互相交流。從實際使用效果來看，尤其是在實現多 Agent 協同和打通各業務系統的需求下，我們認為仍需要一個統一的“組織者”角色來接收任務并進行協調。這是因為真實場景中除了數據流轉和任務規劃，還涉及權限控制和安全等復雜問題。

如果權限放得過寬，允許各個 Agent 自由通信，可能會帶來權限濫用、注入攻擊或敏感信息泄露等風險。因為系統并不知道應當向哪個 Agent 傳遞哪些信息，這就是在組件化模式下的一個關鍵挑戰。

但從未來技術發展趨勢來看，自治驅動模式無疑是一個重要方向。它能夠極大地激發創造力，提高多系統協同處理能力。

相比于由主控體統一規劃的方式，自主協作可以解放任務邊界，更容易激發團隊潛力。例如，在一個研究小組中，若允許成員之間自由交流，往往能取得更多具有創造性和突破性的成果。

如果完全依賴組長指派任務，多 Agent 系統的能力上限將受到組織結構的限制。一旦主控體判斷失誤，整個系統的任務可能無法完成。換句話說，這取決于我們是信任“組長”的能力，還是信任“團隊”的集體智慧。

從落地的可行性和投入產出比來看，目前仍是第一種模式更具實用性。自治驅動的模式雖然具備長遠潛力，但其挑戰也很明顯：首先是更高的算力消耗與成本；其次，缺乏明確的溝通邊界，難以控制溝通的對象和時長，導致任務的完成時間和標準難以界定。因此，當前它更多用于技術探索和研究方向。

王志宏：目前市面上仍以 PE（Plan-and-Execute）模式為主，無論是 Deep Research 還是 Manus 等平臺，基本都采用這種架構。PE 模式之所以被廣泛采用，關鍵在于它調試方便、安全性高、可靠性強，這些都是我們當前選擇它的重要原因。

而多 Agent 系統對模型能力的要求非常高。在多個人協作的情境中，如果缺乏明確的負責人，即便表面上大家達成共識，實際上各自對信息的理解往往存在細微差異，結果就是需要頻繁召開溝通會、對齊會，以確保所有人理解一致。

每個 Agent 對同一句話或任務的理解可能不完全一致。因此，系統必須具備一個強大的決策機制，比如在意見不一致時由誰拍板？如何判斷已經達成共識？只有事先設定清晰的規則，未來在 Agent 能力足夠強大的時候，Multi-Agent 系統才有可能在活力與創造力方面超越當前的 PE 模式。

此外，除了模型能力的差異，不同場景對模式的選擇也有所不同。例如在 AI 游戲中，涉及多個 NPC 的互動，Multi-Agent 模式更為合適；而在處理明確、單一任務，如回答具體問題時，PE 模式可能更高效。

因此，選擇哪種模式不僅取決于 Agent 本身的能力，也要考慮具體的應用場景。

王志宏：當前是否已有多模態輸入、RAG 與外部工具調用融合的統一架構或行業標準？若尚未形成，主要技術和組織障礙是什么？

鄒盼湘：目前，無論是 Agent、多 Agent，還是 Agent 與工具之間的協作，都在逐步走向標準化。近期較為流行的 MCP 協議，便是用于規范 Agent 與工具之間如何高效調度，以及如何構建更完善的工具生態體系。

同時，也有如 A-to-A AMP、ACPS 等 Agent 間通信協議，旨在規范多 Agent 之間的協作方式。

然而，具體構建方式及落地路徑仍存在較大差異，這主要受到應用場景、現有業務系統、數據結構以及流程差異的影響。即便方向一致，也很難在技術路線層面實現統一。

比如 RAG 雖已提出多年，也是應用最廣的一類技術路徑，但在具體策略上，如多路召回、切片策略等仍無統一標準，因為不同文檔類型和領域數據的切分方式千差萬別。

召回方式也各不相同，既包括向量召回、傳統的 BM25，也可能結合知識圖譜等策略。雖然知識圖譜在理論上被廣泛提及，但在實際落地中使用頻率較低。

此外，目前我們所提到的工具和流程，仍然強烈依賴于傳統業務系統。構建 Agent 系統并非從零開始，許多 OA 系統、郵箱系統、HR 系統等早已建成，不可能因大模型的出現而全部推翻。

因此，我們更多是在現有系統的基礎上做升級與改造，這就要求我們在系統、環境和流程層面進行適配，也正是技術路線難以統一的重要原因之一。

王磊：無論是 Agent 還是 RAG，大家都在嘗試將其與大模型結合，進而構建解決具體業務問題的 Agent 系統，優化原有流程或提升產品體驗。

然而在這個過程中，我們仍在不斷驗證技術效果，即是否真正帶來業務或產品價值。如果不能帶來實際成效，技術實現就失去了意義。因此當前的重點，是以技術手段實現預期結果，然后再思考是否可以進一步規范化、協議化，促進各系統之間更順暢的協作。

MCP 協議的推出就是一個很好例子，發布后大家迅速達成共識，插件之間的互通得以實現，服務能力在跨平臺、跨模型場景下顯著提升，其可用性和可接入性都得到了極大增強。

目前仍處于技術和產品價值驗證的初期階段，這是第一點。第二點是“快”——AI 本身發展迅猛，而大模型是“卷中之卷”，在這個賽道中，無論是模型本身還是其應用形式都在快速迭代，大家幾乎都在全速前進。

也正因為如此，規范的建立往往滯后于技術發展，大家還沒來得及停下腳步去制定統一的接口或協同機制。但從長遠來看，行業一定會逐漸走向規范化，就像互聯網發展一樣，最終會形成互聯互通的生態。

王志宏：目前大模型的發展非?；馃?，技術迭代速度極快，這也導致現有的一些規范和約束機制難以跟上底層能力的快速演進。MCP 協議的出現，某種程度上反映出行業希望通過協議化的方式，使 Agent 系統的構建更加有章可循。

在開發 Agent 方面，目前市面上涌現了許多優秀的框架，比如 LangChain、LlamaIndex 等；除了代碼層面的開發框架，也有像 Define 這樣的應用編排框架，它們在敏捷開發中非常實用。

然而，實際情況是，很多企業在生產環境中并不采用這些框架，或者只是用它們快速搭建一個 demo，最終在真正上生產時往往選擇放棄這些框架，重新自行開發，重新“造輪子”。

這種現象其實反映了敏捷開發與工業化生產之間的權衡：在快速迭代階段，我們傾向于選擇使用成熟且易用的開源框架；但在進入生產環境后，會發現這些框架難以支撐穩定性、安全性與一致性要求，也無法形成統一的技術架構或行業標準。

王志宏：構建可復用、易擴展的 Agent 平臺時，您推薦哪些核心設計原則或參考框架？

王磊：在 Agent 系統設計中，其實已經逐漸形成一些核心的共識性原則。首先是分層解耦的架構設計，即感知、決策與執行相互獨立。例如，在感知層可接入視覺等多模態輸入，在決策層通過動態規劃和任務路徑管理，實現高效調度，而在執行層則通過標準化接口調用工具，并支持諸如事務管理、回滾等機制，以增強系統的穩定性和可控性。

其次是模塊化設計和組件復用。我們傾向于對常用工具進行封裝，形成可插拔、靈活組合的能力模塊，從而提高開發效率和系統擴展性。再者是通信協議的標準化，我們正在全面擁抱如 MCP 這樣的通信協議，以促進插件和服務之間更開放、標準化的交互。

此外，在多 Agent 協作方面，我們也探索了多種框架，包括基于 DAG 的任務流 Agent，實現底層的任務調度和協同。

由于 ToB 服務和產品對質量要求較高，我們也在建設全鏈路可觀測性體系，覆蓋創建、調試、優化和發布的全流程，以便于客戶和開發者高效使用。這些都是我們目前所堅持的設計原則和實踐路徑。

鄒盼湘：在 Agent 開發框架方面，我認為應避免回到傳統的“意圖分發”模式。即便在任務目標清晰、可控性要求高的場景下，我們也應盡可能讓模型主導 Workflow 的驅動，調動多個工具協同工作。

此外，我們應當以“AI native”的理念來思考整個系統的構建，無論是數據處理、策略治理，還是應用層設計，甚至是 UI 交互，都應盡量擺脫對傳統技術路線的依賴，以全新視角構建新一代 AI 系統。

在開源框架方面，市面上已有諸如去年較為流行的 Swarm、Node Graph 等多 Agent 協同框架。它們在實踐中值得參考，但我們不應被任何一個框架限制，核心仍應圍繞目標達成和技術可行性展開：我們要了解當前模型能力的邊界，并據此制定合理的工程實現路徑。

在構建中控 Agent 時，核心工作往往是“構建上下文”（context build）。不管是做 RAG、任務推理還是工具調用，最終都是在為模型創建一個有效的上下文環境。這包括從用戶輸入出發，通過 query 的重構和分解、知識的調取將信息聚合，形成新的上下文。

每一次任務的迭代，本質上都是一次新的 context 構建。因此，我建議大家可以將重點從傳統的 prompt 工程轉向 context 構建，逐步向“Context Engineer”的方向演化。

關于 AI 應用的構建范式，我認為可以根據具體場景進行拆解與規劃。比如在工具使用和任務交付環節，我們在 Deep Research 項目中采用的是 PE 模式，但未來是否繼續采用該模式，還是引入新的架構，要視其可控性和落地可行性而定。沒有一種模式是通用答案，選擇需基于現實需求和未來預期進行權衡。

最后，我認為 REACT 的思想應該被持續發揚，它結合了 reasoning 與 action，是一種非常契合 Agent 特性的機制。它支持信息反饋、任務迭代與優化，是實現人機對話與互動的核心思路之一。

王志宏：一個好的 Agent 平臺必須足夠簡單，門檻要低。例如，配置好環境變量，輸入 API key，再寫兩三行代碼，就能在網頁上輸入問題并獲取答案。這種“即插即用”的體驗非常重要。

其次，平臺需要提供一站式服務，覆蓋從應用創建、效果驗證、調優到發布的全過程。例如，我們希望用戶能快速將想法變成應用，部署到客戶環境中后，通過真實場景反饋進行迭代優化。

一個理想的框架應該具備完整的部署能力，支持一定并發量，同時擁有良好的擴展性。若框架封裝過于嚴密，開發者很難添加新功能，必須改動源碼，這顯然不利于引入先進算法。相反，如果框架足夠靈活，就可以輕松集成各種新興的開源算法。

以 RAG 為例，我們可能會引入多路召回策略，每一路使用不同的文本切分方法，甚至提前總結關鍵詞、QA 或提綱?？蚣軕苤С诌@些靈活配置。

此外，框架需要靈活支持向量召回或傳統方式。同時，應具備開放架構，允許各個組件可插拔替換。例如，一個客戶需要使用 Newmas 數據庫，另一個客戶更適合使用 Fast，因為他們硬件資源有限；有的用 Elasticsearch，有的用 OpenSearch，框架都應能適配。

數據庫方面，在私有化部署中，不同客戶有不同需求。多數情況下 PostgreSQL 就夠了，但對于強調自主可控的客戶，我們也會推薦 TiDB 或達夢這樣的國產數據庫。組件要能靈活替換，同時保證使用體驗一致。

大模型也要支持靈活切換。例如今天用本地模型 DeepSeek V2，明天想換成某個廠商的在線模型，應該只需修改配置，代碼其他部分無需變動。理想狀態是用戶切換模型如同換插頭，不影響整體流程。

會議推薦

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