提升Agent的可信度后，企業會多一批好用的“數字員工”嗎？

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

策劃 | 李忠良

編輯 | 宇琪

隨著 AI 技術從“工具化”向“自主化”嚴謹，智能體（Agent）正在成為企業應用大模型的重要形態。那么，如何優化 Agent，讓它變得更可信、更好用，最終能夠成為企業優秀的“數字員工”？

近日 InfoQ《極客有約》X AICon 直播欄目特別邀請、RBC senior application support analyst 馬可薇擔任主持人，和值得買科技 CTO 王云峰、商湯科技大裝置事業群高級技術總監魯琲、明略科技集團高級技術總監吳昊宇一起，在AICon全球人工智能開發與應用大會2025 北京站即將召開之際，共同探討如何提升企業 Agent 的“可信度”。

部分精彩觀點如下：

• 未來可能真的不再存在傳統意義上的軟件界面，UI 可能完全消失，取而代之的是由 Agent 與系統直接交互。

• 協議的價值在于讓生態中的每個角色，提供大腦、數據、工具或執行能力的廠商，都能使用同一種語言溝通，使大家可以把精力集中在自身專業領域，而無需耗費大量時間做適配工作。

• 許多模型在長文本中間部分存在遺忘問題，大海撈針本身就是不現實的任務。盡管大家都宣稱擁有超長 context window，但真正有效的部分其實沒有那么多。

• 真正的難點是業務模型與技術模型如何統一、如何對齊。純技術層面的參數對齊反而是最不需要擔心的，畢竟大家都是寫程序的。

在 12 月 19-20 日將于北京舉辦的AICon 全球人工智能開發與應用大會 2025 北京站上，我們特別設置了 【企業級 Agent 的設計與落地】 專題。該專題將探討企業級 Agent 的產品設計、算法優化、工程實踐，幫助大家找到最佳的 Agent 企業落地場景。

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

https://aicon.infoq.cn/202512/beijing/schedule

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

定義 Agent 的技術邊界

馬可薇：很多人覺得 Agent 就是 Chatbot 加了幾個插件。但從技術架構視角看，當系統目標從“對話”變成“行動”，你們認為技術棧上產生的最大一個質變是什么？

王云峰：我認為 chatbot 本身只是一個交互形態。過去大家在互聯網上主要依賴點擊，后來 AI 具備了對話能力，人們開始在對話框中和它交互；再后來端到端語音出現，AI 獲得更強的多模態能力，使對話變得更自然、更強大；隨后 Agent 的興起又進一步擴展了它的可操作范圍。

chatbot 只是一個界面，而關鍵邏輯在于背后的大模型。我們常把大模型比喻為“一個大腦”，而傳統 chatbot 只是讓用戶通過簡單的交互去壓榨它的知識。但一個聰明的大腦需要外圍系統，就像人需要眼睛、鼻子、觸覺去感知世界，需要手腳完成操作。

完整的過程包括：模型接收任務，判斷應采取的行動，感知外界、接收反饋，并基于反饋不斷調整規劃。這與過去單純的 chatbot 模式有巨大差異，其技術復雜度和對生態的要求都遠高于對話系統。

魯琲：以對話為目的的 AI 與以行動為目的的 AI，其核心區別在于前者關注過程，后者關注結果。許多程序員應該還記得 GitHub Copilot 剛問世、沒有 Agent 模式時的狀態。當時它只有代碼補全功能，本質上就是一個 chatbot。常見流程是：模型補全代碼，如果結果不理想，程序員再向模型反饋并請它修改；代碼執行報錯后再把報錯貼回去，讓模型繼續改，如此反復直到運行成功。

后來出現 Agent 模式，本質上仍是同一件事，只是 Agent 可以自動執行整套流程。之前的規劃由人來做，需要人在腦中維護任務步驟、判斷接下來要切換到測試、再根據結果回到編碼等一系列上下文管理。

Agent 的出現把這些過程都包進了系統中：Agent 會自行規劃、調用工具、管理上下文。核心在于模型具備了更強的記憶和上下文管理能力，把過去由人維持的短期、中期、長期記憶和狀態切換能力轉移到 Agent 內部。

因此，Agent 能夠在一個循環中持續工作幾十分鐘甚至數天，并且始終知道自己做了什么、正在做什么、接下來要做什么，這體現了當前 Agent 技術棧的重大質變。

吳昊宇：這也與最近豆包手機爆火有關。豆包和努比亞聯合推出的手機能夠被 AI 直接操控，但隨后微信、淘寶等平臺禁止其登錄。我體驗了一會兒，確實很強，它已經不再是對話形態，而是能夠根據你的指令在手機上逐步完成操作。

這意味著 AI 具備了任務規劃和執行能力，在企業場景中同樣重要。例如，當我們讓 AI 判斷某個話題的熱度，它不能只是簡單搜索并回答，而應該規劃整套步驟，包括檢索、匯集相關詞和帖子、進行情緒聚類、生成報告等。與過去只做問答或簡單文本分析完全不同，對規劃與調度能力的要求顯著提高。

其次，系統具備“動手”能力后，其權限與責任也隨之擴大。AI 可以訪問手機相冊、聊天記錄；在企業內部它可能訪問工作軟件、數據庫。這意味著系統必須具備可追溯、可干預的能力，并設置明確的安全邊界，否則行為將不可控。因此，在 Agent 架構中，我們加入大量監控、可驗證機制以及人工閉環控制，這也是與過去 chatbot 模式最大的差異之一。

馬可薇：目前的 Agent 經常“變笨”或“卡住”。從算力供給、數據供給、協議交互這三個環節看，目前的“短板”究竟在哪個環節？是推理速度太慢跟不上思考，還是上下文記憶太短限制了邏輯？

魯琲：更準確地說，是高性價比算力的短缺。從實際落地的 Agent 來看，問題往往不在于是否有算力，而在于成本與效果之間的權衡。很多應用場景并不會使用旗艦模型，而是選擇 30B 甚至 7B 這樣更小的模型。盡管這些模型可能支持 100K 甚至 200K 的上下文窗口，實際使用時仍會將上下文限制在 32K 或更小的范圍內，本質上是為了降低成本。同樣地，我們也會限制 Agent 深度思考的輪次，比如在 Cursor 中開啟 Max 模式、使用最好的模型讓它生成一個 feature，執行二十分鐘就能耗盡當月配額。如果未來有更多高性價比算力可用，現有的頂尖模型與算法才能在更廣泛的場景中充分發揮能力。

吳昊宇：上下文的數據質量同樣極為重要。即便上下文很長，如果信息質量低、噪聲多，模型輸出的任務規劃和結果仍然不會理想。像我們做輿情分析時，常用的是小紅書、微博等平臺的帖子，但這類信息密度普遍較低。如果直接把一萬條帖子全部丟給大模型做總結，得到的觀點和事實要么不完整，要么存在偏差。因此，我們通常會對數據進行預處理，再交給模型生成總結或報告。

此外，Agent 的上下文往往來自先前多輪的交互，其中有些信息有用，有些只是無效嘗試。現在雖然已有上下文壓縮技術，但大多是被動的：在快達到窗口上限時才進行壓縮。實際上我們需要更頻繁地壓縮，使保留下來的信息密度更高、更加真實可靠，從而提升 Agent 的規劃能力。因此，要讓 Agent 運行得更好，必須提供可信、高密度、高質量的數據。

王云峰：隨著模型變得更強、上下文窗口更大，真正決定 Agent 效果的往往不是模型，而是企業內部的私有數據質量。模型是可以選擇的，不行就換更好的，或者通過微調、蒸餾改善效果；但數據預處理的難度遠大于選模型或微調模型。我們必須承認，未經處理的數據是完全無法使用的，而高質量數據的構建難度非常高。

盡管上下文窗口越來越大，如果輸入內容過長，模型產生錯誤的概率仍然會上升。例如在一些需要了解用戶需求的場景中，一萬篇內容遠不足以形成合理判斷，合理的采樣量級應該是十萬甚至上百萬篇。但當數據量達到百萬級別時，直接輸入模型的結果幾乎不可用。并且隨著處理鏈路變長，哪怕每個環節的可用性有 90%，經過十個環節后整體可用性也會下降到不可接受的水平。

一個 Agent 的完成需要多個環節、多個模塊共同協作。大腦只是其中一個模塊，還需要大量數據，而這些數據既包括企業私有數據，也包括金融、法律、隱私保護等方面的專業信息。未來每一種能力或模塊都可能由不同廠商提供，例如大模型由一批廠商專注提供，讓“智能大腦”越來越強，而數據提供方則確保數據真實可靠、信息密度高，還有一些數據來自實時感知。

在這樣多方協作的體系中，協議的重要性就凸顯出來了。沒有任何一家廠商能夠完成所有工作，生態必然需要眾多參與者。如果每次調用外部數據或工具都要重新適配，將極大降低效率。因此協議的價值在于讓生態中的每個角色，提供大腦、數據、工具或執行能力的廠商，都能使用同一種語言溝通，使大家可以把精力集中在自身專業領域，而無需耗費大量時間做適配工作。

馬可薇：如果未來是多 Agent 協作的世界，Agent 之間溝通需要標準。王總在推 MCP (Model Context Protocol)，魯總和吳總怎么看？2026 年，Agent 的互聯協議會走向開源統一，還是大廠割據？

魯琲：未來必然是多 Agent 協作的世界，而且 Agent 之間的關系將遠比今天復雜，會呈現多對多、開放式的交互。因此，統一的 Agent 交互協議顯得格外重要。我個人堅信協議最終會走向開源統一，走向中立、開放、自主的狀態，而且速度很可能會非常快。

我們可以回顧互聯網發展史。例如最初 TCP/IP 協議與 OCI 競爭了十多年，最終 TCP/IP 被交由 IETF 維護，形成中立治理。期間，硬件廠商和軟件開發者都面臨需要同時適配兩套協議的困境。HTTP 也經歷了類似的過程，花了很長時間才走向開源和自治。而更近代的協議如 Kubernetes、gRPC，大約兩三年就進入中立治理階段。MCP 也是如此，我記得就在最近，Anthropic 剛剛把 MCP 協議捐贈給 AIF，而 OpenAI、Google、微軟都是其成員，MCP 從首次發布到現在不過一年左右。

在當前的技術環境下，各大廠商都充分認識到：擁抱開源、共同建設生態、避免協議戰爭，才能為開發者和企業提供穩定預期，讓大家可以放心基于 MCP 生態構建系統，而不必擔心被某個廠商鎖定。

吳昊宇：各大廠對 MCP 的支持力度非常大，盡管它誕生僅一年，但已展現出強大的優勢，幾乎所有廠商都已接入，基本成為多 Agent 溝通的事實標準。此外，Anthropic 在 MCP 之上也推出了許多新玩法。例如標準的 MCP 需要逐次調用并等待回復，而 Anthropic 最近的 PDC 協議則通過代碼方式將多次 MCP 調用合并為一次。我們的測試結果，與 Anthropic 的官方結論一致：這種方式可使上下文長度縮短 80% 甚至更多。

因此，即便底層協議統一，上層生態仍會不斷創新，尤其在大模型時代，可能出現許多此前從未見過的新協議和新生態。如果底層協議穩定可靠，上層生態的創新空間就更大。對于做應用的廠商而言，基于協議探索新的能力和玩法，不僅是機會，也能幫助我們更好地服務企業與用戶。

圍繞 Agent 架構層層解剖

馬可薇：魯總，企業落地 Agent 最大的攔路虎往往是成本。Agent 的運行模式決定了它需要維護極長的上下文，這對顯存和帶寬的消耗是巨大的。在大裝置層面，你們有沒有針對 Agent 這種“長程推理任務”的專用優化方案？

魯琲：隨著 Agent 單任務運行時長不斷延長，上下文會出現明顯的膨脹，這不僅影響性能，也顯著增加成本。為解決長程推理中的上下文問題，目前有多種方法。最基礎的是上下文壓縮，包括摘要、結構化壓縮等；另一類是長期記憶的持久化，即將高價值、高信息量的內容保存在外部存儲，如 Vector DB 或知識圖譜，以實現高價值信息在跨 Session 之間的傳遞。這些都屬于“上下文工程”的范疇，本質上都是提升信息密度的有效手段。

此外，我們也會對 KV Cache 做優化。例如利用 CPU 內存甚至 SSD 進行分層存儲，以提升系統吞吐量；同時可對 KV Cache 進行不同層級的量化。不過，這類方案都會帶來精度損失，因為 GPU 中存儲的 KV Cache 不是完整版本，在進行前段推理時難免丟失部分信息。根據我們的測試，精度損失大約在 1% 到 10% 之間，具體取決于緩存和同步策略。不同的業務對精度的要求不同，可以選擇相應的優化方案，以支持長程、高效、高吞吐的推理過程。

馬可薇：王總，作為買單方，如果商湯告訴您“降低一點精度能便宜 50%”，但在導購推薦時可能會偶爾算錯價格，值得買的業務容忍度在哪里？

王云峰：每個業務都由多種組件組成，其中一些適合使用 AI 解決，另一些則并不適合。舉例來說，若某項能力精度下降 50%，但成本降低 50%，如果這意味著價格計算可能出現錯誤，那這種情況在業務上往往是無法接受的。相反，有些任務則完全沒有必要依賴大模型解決。例如常被討論的“3.9 和 3.11 到底誰大”的梗，在實際業務中這種計算完全可以由傳統方法處理，不必依賴大模型。因此，成本與精度的權衡必須與業務深度結合。我們內部使用了大量模型以及外部 API，不同參數規模、不同價格的模型都會用，關鍵是把合適的模型放在合適的任務中。

在一些高容忍度的業務場景中，前期并不需要極高精度，因為在海量數據下，整體系統的容錯能力非常強。例如輿情分析，其統計特性使得局部精度的誤差并不會帶來實質影響。但在某些場景下，一點錯誤也不允許，因此對精度的要求極高。企業必須結合自身特點和業務需求：若天然容錯度高，可以使用低成本、精度略低的模型；如容錯度低，則必須使用更高精度的方案。最終企業要算整體成本，使整體投入與產出合理。

馬可薇：Agent 需要外掛知識庫。現在模型窗口越來越大，很多人說直接把書扔進去就行。但對于需要“精準執行”的 Agent 來說，知識圖譜（KG）的結構化優勢是否比長文本（Long Context）更適合作為 Agent 的“長期記憶”？為什么？

吳昊宇：知識圖譜天然具備知識壓縮、事實邊界與操作約束等特性，因為它由企業大量事實性文檔中高頻出現的關系和約束構成，再經過專家校驗，因此其中存儲的內容本質上是企業知識的高度濃縮。當我們以結構化方式將這些濃縮知識提供給大模型時，其約束和提示效果遠強于輸入冗長且價值不高的文本。其次，知識圖譜具有持久性，可以長期存儲在圖譜庫中，根據上下文需求進行調取。在長期記憶方面，它比一次性塞入的大段文本更加穩定、有效。

企業知識庫常用的 RAG，本質上還是長文本檢索，但它有幾個明顯問題。第一，由于依賴相關性檢索，若關鍵知識被埋在長文本內部，整體相似度反而可能不如一些不太相關的文本片段，導致真正有用的內容無法被檢索到。第二，因為受限于上下文窗口的長度，我們不可能把檢索到的 10 段文本全部輸入，通常要經過人工篩選或重排序，但這會帶來信息覆蓋不全面的問題。

相較之下，知識圖譜更能保證信息的完整與高度相關。查詢一個實體時，其所有相關內容都能被提取，再進行過濾后輸入模型，得到的上下文質量顯著高于 RAG。此外，我們在許多 deep search 場景中測試，基于知識圖譜的 Agent 表現也比 RAG 更優，且生成所需的上下文更短、效率更高。

王云峰：人在處理復雜任務時，最近的記憶細節更豐富，但遠期記憶往往只保留關鍵內容。這種機制其實與知識圖譜很相似，都強調保留高價值的信息、過濾無用細節。

在企業中，數據對結果的影響往往大于模型本身。我們常常要面對大量原始數據，其中不少未經結構化處理，也缺乏版本管理。有時同一知識點已被更新，但舊數據無人維護卻仍然被輸入模型，導致混亂。因此，大量預處理工作十分必要，而知識圖譜就是一種極具代表性的結構化方式。它能提升信息密度、利用率，并且便于模型調用。

魯琲：我們主要用圖譜來支持 Agent 的長期記憶，并且讓 Agent 能進行一定程度的自我進化。知識圖譜是結構化數據，非常符合人類記憶模式，很多事件的細節會隨時間遺忘，但關鍵步驟和方法會被保留，而下一次遇到類似任務時，人會依賴這些高層經驗更快解決問題。

我們的一些 Agent 負責線上集群運維，例如 debug 真實故障。最開始它們可能需要反復試錯、循環許多輪才能找到解決路徑。成功經驗隨后會寫入知識圖譜作為長期記憶，并經過一定的反思。當再次遇到類似問題時，Agent 會優先檢索圖譜，看之前是否成功處理過，從而復用最佳方案。我們看到相同任務從需要 20 分鐘逐漸縮短到僅需 5 分鐘，這就是長期記憶帶來的效率躍遷。

馬可薇：魯總，從算力角度看，是“暴力增加上下文長度”（讓模型自己找）更劃算，還是“外掛一個知識圖譜檢索”更劃算？

魯琲：把整本書塞進 context window 與從知識圖譜中精準取回高信息密度的節點，兩者的算力差距是成百上千倍的，這個賬非常好算。

王云峰：千萬別動不動就扔長文本。

魯琲：許多模型在長文本中間部分存在遺忘問題，大海撈針本身就是不現實的任務。盡管大家都宣稱擁有超長 context window，但真正有效的部分其實沒有那么多。

王云峰：以前沒別的辦法，大家只能塞文本。現在如果還在往里扔長文本，某種意義上是在“為難模型”，甚至是在刻意找模型的短板。既然有更高效的方式，就應該讓模型發揮長處，而不是持續增加它的負擔。

觀眾：企業想要 AI，但不知道如何落地以及不確定投入產出，該從哪一些維度去做決策？

魯琲：對于具有長期性質的 AI 落地項目而言，大家此時關注的并不是投入產出比，而是項目是否真正能做成。以行業中常見的視角來看，目前能夠實實在在為企業賦能的，是那些已經被大規模使用的 AI 應用，比如 AI Coding。現在大型廠商，如微軟和谷歌，從去年開始就強制要求員工使用 AI 生成一定比例的代碼。如果大廠都在推行這種工作流程，那么企業跟進后帶來的效率提升幾乎是確定的，性價比也是正向的。至于那些更長期的項目，我認為干脆不必談性價比，能真正落地就已經非常不錯了。

王云峰：AI 的價值主要體現在兩個方面：一是提效，也就是原本由人完成的工作轉由 AI 處理，并且效率更高；二是 enable something，即讓過去在沒有 AI 時無法實現的事情變得可能。關于提效，當前 AI 在許多場景中基本可以達到初級到中級人員的能力水平。

如果某項工作具有較高頻次、規則性強、同時容錯率允許，那么交給 AI 來做效率往往顯著更高。而在一些強調創意性的工作中，AI 也表現突出。至少從我們觀察到的發展歷程看，AI 最初被大量應用的就是創意類任務，比如生成視覺作品，這類任務中 AI 的多樣性優勢非常明顯。

相比之下，編程反而比早期的繪圖類任務更晚成熟，因為編程對結果準確性要求更高。不過編程也有其優勢：程序本身規律性強、歷史代碼庫豐富，因此模型能夠較快適應。相反，對于那些既要求極高準確性，又缺乏明顯規律性的任務，AI 目前仍難以勝任。

現在前兩類任務 AI 已經能處理得比較好。但如果我們追求 enable something，即實現過去無法做到的事，那么此時無需過多考慮成本，只要在可承受范圍內即可。因為一旦能開拓出全新的領域，其性價比可以說是無限大。

吳昊宇：第一個問題是：業務方能否明確說明 AI 的衡量標準？也就是效果好壞需要有客觀評估，而不是憑拍腦袋判斷。第二個問題是：業務方是否掌握數據？如果沒有數據，只能完全依賴大模型從零推斷，往往難以取得理想結果；但如果業務方有數據，可以用于提示或微調，AI 的效果通常會更好。還有一點是業務方是否有預算。不能既不給資源又要求結果。如果同學們正在推進類似項目，可以用這幾條先和業務方對照一下：他們想實現什么目標？希望達到什么效果？是否有數據積累？如果完全一無所有，或許換個方向會更合適。

馬可薇：王總，您之前的分享提到了 MCP Server。在實戰中，讓通用大模型通過 MCP 協議去調用值得買復雜的電商接口（查價、領券），最難解決的“協議對齊”問題是什么？ 如何防止 Agent 因為“誤解”協議參數而亂操作？

王云峰：真正最難的不是協議對齊，而是業務對齊。起初確實會遇到一些協議層面的參數不一致等問題，但從技術角度看，這些都是可解的。有時通過調整模型，或者增加一輪反思，理解用戶意圖后，再結合傳統方法與模型能力，大多能解決協議層面的對齊。真正困難的是業務層面的對齊。雖然協議提供了共同語言，但即便使用同一種語言，相同的詞在不同語境下表達的含義也不同。比如“好”或“優惠”等詞，在不同業務場景中有不同的業務語義。因此，我們在實踐中踩過的坑，往往集中在如何與合作伙伴在業務理解上達成一致。

接下來要考慮的是，這種業務預期是否應該由我們現有接口提供，還是需要新增接口。同時，我們的合作伙伴數量眾多，他們各自有自己的設計與呈現方式，而我們需要保持服務的相對標準化，不可能為每家都做定制化。因此真正的難點是業務模型與技術模型如何統一、如何對齊。純技術層面的參數對齊反而是最不需要擔心的，畢竟大家都是寫程序的。

吳昊宇：這讓我想到 text-to-SQL 的場景。老板問問題時從不會按照模型需要的方式來問，他只會說：“今年業績怎么樣？”這背后對應的是一大堆圖表。

馬可薇：是的，仍然需要把自然語言或老板的需求轉化成機器能理解的表達方式。

王云峰：大模型帶來的真正挑戰，對技術人員來說，是角色要求的變化。以前很多專業難題需要技術人員憑專業能力解決，現在模型提高了效率，也補足了短板。但這同時帶來一個誤區，讓一些人認為 AI 無所不能，把它當作許愿池。真正的挑戰是我們這些技術人員是否能向前邁一步，不僅掌握技術，還要理解業務需求，理解業務語言。大模型雖能理解自然語言，但不一定理解業務語言。

吳昊宇：業務語言需要大量“翻譯”。

王云峰：這也是未來 AI 普及后，對程序員、工程師和架構師的真正挑戰。

魯琲：隨著 Agent 能力增強，我們常舉例，現在讓一個 Agent 做圖表，工程師能輕松實現。但如果未來企業內部有大量 Agent 參與工作，你告訴 Agent 說：“我給你設一個目標：明年一季度增長 25%。”它該如何實現？這種業務語言的對齊確實很難。

馬可薇：吳總，在處理政企復雜流程時，您覺得這種“調度邏輯”是應該寫死在代碼里（SOP），還是應該讓大模型自己去“動態規劃”？

吳昊宇：兩種方式以及中間狀態都可能需要。在要求特別高的領域，例如大型企業，或者老板偏好確定性結果的場景，可以使用 SOP 的方式寫死，或采用 workflow 方法，確保可用性和正確性。

在更動態的場景下，可以充分發揮模型能力，比如調研、動態執行等場景。我們現在常用 Claude Code 的 skill 機制，通過約束把技能中的核心流程固定下來，而外圍處理交由模型自主完成。這樣既有 SOP，又能保留靈活性。

舉個例子：我們的一位 HR 想做員工能力評估模型，他給了我們一份咨詢報告，希望提煉成能力模型。我們使用“提煉技能”的能力，把文檔總結成一個能力模型技能，再將員工的郵件、績效記錄及其他非結構化數據輸入，模型就能按技能中的 SOP 自動總結。這樣 HR 在幾分鐘內就獲得了一個強大的技能。這個方式能很好地平衡 SOP 與靈活性。在輿情分析等場景也是類似，不同分析師的數據來源和路徑不同，但分析框架是一致的，而技能機制可保持這種一致性與靈活性。

馬可薇：那現在主流是兩種方式混合使用，還是更傾向代碼寫死或模型動態規劃？

吳昊宇：仍然取決于具體場景。如果業務方要求嚴格，那我們會采用 workflow 的方式處理，雖然現在基本不再直接寫代碼。

觀眾：可信 Agent 目前是主要靠 RAG 和知識圖譜嗎？有沒有其他方式？

王云峰：我認為目前如果完全依賴模型，幻覺問題在一些場景下是不可避免的。根據已有研究，在加入 RAG 后，幻覺可以被有效抑制，雖然無法降到零，但確實是目前較好的解決方案。不過，幻覺問題目前沒有 100% 徹底解決的辦法。如果業務場景要求完全無幻覺，仍需要依靠額外的外圍機制或校驗流程來確保結果的可靠性，而這也取決于具體的應用場景。

馬可薇：當成千上萬個 Agent 同時跑起來，這就不是單卡訓練的問題了。魯總，面對這種碎片化推理請求，異構集群（國產 / 英偉達混用）怎么保證調度不卡頓？

魯琲：調度本質上是推理過程，調度算法需要實時感知推理節點的負載情況，再進行 workload 分發。在同構集群中，判斷節點負載已相當復雜，需要綜合考慮 GPU 利用率、隊列長度、內存占用、以及新任務可能生成的 Token 數等因素；而在異構集群中，這些問題會被進一步放大。同一請求落在不同類型的節點（如國產芯片與英偉達芯片）時，其真實計算消耗往往不同，原因包括算子優化差異、內存訪問模式差異、精度差異，甚至節點之間通信方式（NVLink 或 RoCE）的差別。不同設備之間很難完全對齊，因此在實際落地中通常會根據不同卡的壓測結果，調整負載評估邏輯并設置不同的權重。

最終通常采用多種調度策略組合，根據不同 workload 的 SLA 要求進行分配。例如，對響應速度要求極高的請求，會優先調度到性能強、負載低的節點；對要求較低的請求，用來做整體負載均衡；而離線推理或批處理任務，會被安排到功耗更低、速度相對慢的設備上。這樣可以在保證高 SLA 請求優先滿足的同時，讓低 SLA 請求提高集群整體利用率，從而形成一套兼顧性能與性價比的組合式調度策略。

馬可薇：吳總，在算法層面，如何設計調度策略，是優先保 Agent 的響應速度，還是保系統的整體吞吐量？

吳昊宇：在我們大規模的 Agent 集群中，更關注的是調度鏈路是否穩定。因為 Agent 的執行過程通常包含規劃、工具調用、反思等多輪循環，實際的性能瓶頸往往不在 GPU 或大模型本身，而是在外部異步任務或外部調用時產生大量耗時。因此，我們優化的重點是確保 Agent 能順暢執行。

這些 Agent 也有不同類型：部分用于實時交互，部分處理異步任務，還有部分負責大批量任務，如處理海量帖子或抓取網頁。調度策略必須確保實時交互不卡頓，同時離線任務能充分利用外部資源。我們采用多 Agent、多模型尺寸的結構，讓簡單任務使用成本較低的小模型，復雜任務使用更強但更耗資源的大模型。通過這種組合優化，可以提升整體并發數，并保持較低時延。

馬可薇：王總，在電商導購場景，延遲的“生死線”是多少毫秒？超過多少毫秒用戶就會關閉頁面？”

王云峰：在 C 端場景中，尤其是對話類場景，1 秒內若不能輸出首 token，體驗基本就失敗了。雖然大家對大模型的容忍度比傳統應用高，因為用戶已經習慣稍等片刻再看到結果，但總體上仍需在 1–2 秒內給出首 token，并保持持續輸出。對于簡單問答類場景，幾秒內完成輸出較為理想；若是深度思考類任務，用戶還能接受更長的等待時間。而對離線處理來說，關注的重點變成吞吐量，時延并不那么關鍵，因此調度策略會根據不同任務類型采取不同側重。

馬可薇：企業用 Agent 最怕它“死循環”或“胡說八道”。在你們的架構中，哪里是那個“紅色按鈕”（熔斷機制）？在應用層，MCP Server 有沒有設計業務邏輯上的“熔斷機制”？在基礎設施層，有沒有資源消耗上的“硬熔斷”？

王云峰：一般來說，我們會設置一個循環閾值，超過后即可認定系統已出現崩潰，這是最基礎的做法。對于對外提供的 MCP Server，由于全部是預處理好的數據，因此通常不會出現死循環的問題，但我們會對吞吐做一定的熔斷和限制。整體機制與傳統系統中的熔斷并無本質區別。

魯琲：我們的熔斷機制更多是在技術架構層面，在基礎設施層面通常會為每個 Agent 分配獨立的 API key，并對各 API key 設置 rate limit 和預算上限。即使 Agent 進入死循環，在 Token 消耗超限后也能被限制住。MCP Server 也是類似邏輯：為了防止 Agent 死循環，需要在 API 層面設置 rate limit。整個系統的構建都基于“互相不完全信任”，因此必須做各種層次的防御。

吳昊宇：我們的 Agent 基礎設施，主要通過沙盒機制實現隔離。Agent 的執行環境運行在獨立的虛擬機中，即使出現循環、資源耗盡或掛掉的情況，也不會影響外部的主控系統。其次，我們會監控 Agent 的執行狀態，包括是否循環、資源占用是否異常、是否頻繁發送請求等，并通過網絡、硬盤、CPU、內存等維度進行監控。如果判斷運行異常，會在外部直接將其 kill 掉。

此外，在 Agent 執行過程中，人工可以隨時中斷其運行，通過外部協作判斷 Agent 是否正常。面向企業場景時，我們還需對模型及其任務規劃、執行模型進行調整，確保規劃路徑和執行動作符合可信標準，避免生成過于離譜的操作，并在執行中加入必要的安全檢查，防止觸發高危操作。

展望 Agent 的未來形態

馬可薇：如果 Agent 成為主流，未來的軟件（ERP/CRM）會不會消失，只剩下 API？作為技術人，我們現在是應該去學“怎么寫 Agent”，還是去學“怎么寫被 Agent 調用的 API”？

魯琲：我相信在非常長遠的未來，軟件形態本身會消失。但在這一未來到來之前，在相當長的一段時間里，軟件的核心功能仍將被保留，而其中與人交互的部分會逐漸淡出，由類似 Agent 的交互模式取而代之。在這種模式下，Agent 事實上承擔了軟件外殼的作用。軟件的核心功能會以 API 的形式暴露給 Agent。

對初級開發者而言，仍需通過扎實學習掌握復雜的后端 API 開發和業務核心功能，并逐漸形成對系統架構和高并發系統的深入理解。而對中高級開發者來說，在具備 API 層面的深刻認知后，可以進一步嘗試 Agent 的開發，更好地彌合 AI 應用與后端服務之間的 gap。我認為這類具備雙向能力的人，未來會在市場上變得非常稀缺。

吳昊宇：未來可能真的不再存在傳統意義上的軟件界面，UI 可能完全消失，取而代之的是由 Agent 與系統直接交互。當然，軟件本身仍可能以 API 形式存在，因為構建完整系統仍需專業軟件廠商去完成，只是 UI 不再由人直接使用，而由 Agent 處理。企業內部甚至可能形成一個“超級 Agent”，管理幾乎所有業務流程。

基于此，即便技術人員沒有從事 Agent 開發，我仍建議大家理解 Agent 的工作原理，包括它如何運作、如何被調度、運行基礎是什么，以及 Agent 之間如何交互。至于 API 的學習需求，則取決于各自的工作方向。面對高并發場景或后端基礎能力的建設，相關技能依舊必不可少。幸運的是，現在比過去有了更好的學習條件，AI 能幫助理解架構、編寫代碼和傳授經驗，對技術人員而言是非常好的時代。

王云峰：Agent 之所以強大，是因為它站在“巨人”的肩膀上，而這些巨人就是歷史上無數程序員一行行寫出的代碼。二十五年前，會寫 HTML 都是非常重要的技能，寫頁面的人收入甚至比寫 C++ 編譯器的人還高；但市場很快變化了，因為這些技能極易被新工具替代。

現階段，會使用 AI、會搭建一個 Agent 是一種偏表層的能力，而更核心的依然是對計算機整體運行機制的理解。我不知道量子計算機何時普及，但至少目前 Agent 的上層表現再“神奇”，底層仍是基于最基本的數學和計算機原理，在馮·諾依曼體系結構上運行。因此，如果希望避免被時代淘汰，就必須知其然并知其所以然。

很多依賴記憶或機械性勞動的工作未來會被 Agent 覆蓋，但真正理解底層原理的能力，才能幫助我們把握 AI 的能力邊界，識別它的長板與短板，并更有效地利用它。因此，計算機最基礎的知識永遠有價值。你可能不會顯式意識到自己在使用這些知識，但它們形成的思維習慣與直覺，會成為你使用 AI 能力的重要底層支撐。

馬可薇：在 Agent Infrastructure（基建）領域，2026 年最可能爆發的一個技術變量是什么？

魯琲：我認為未來應當形成多 Agent 的治理體系。2025 年 Agent 的發展非常迅速，從早期的 demo 已經逐漸落地到生產環境，并出現了許多現象級的 ToC 應用，如 Manus。到 2026 年，我相信 Agent 將被更多企業級應用采用，逐步成為企業運行基礎設施的重要組成部分。

生產級的多 Agent 落地很可能在 2026 年大規模發生。從技術角度看，多 Agent 之間的交互協議基礎已經初步具備。然而，單 Agent 的運維、調試、性能監控與迭代本身就極為復雜；當系統擴展到多 Agent 后，這些復雜性將呈指數增長，多 Agent 的交互邏輯會隱藏大量潛在問題，一個 Agent 的異常輸出可能污染整個系統的上下文，甚至導致系統性失敗。因此，構建完善的多 Agent 治理體系，是企業級落地的必要前提。

吳昊宇：Agent 體系確實是非常重要的發展方向。目前常見的 Claude Code 以及我們公司自研的一些 Agent 框架，實際上都在探索多 Agent，只是距離成熟還很遠。我們關注的核心問題是：如何讓企業敢在真實生產環境中使用 Agent？關鍵在于讓 Agent 的產出結果具備可信性。

我們主要從兩個層面提升可信性。第一是數據可信，即數據源是否真實、有效，并通過知識圖譜等方式增強上下文的可靠性，避免 Agent 在執行過程中偏離核心語義。第二是模型輸出可信，即從任務規劃到任務執行的整個鏈路都要可控、可靠，確保規劃合理、執行安全，不產生危險操作，并能準確落實意圖。

王云峰：從技術層面看，不確定性仍然很多，算法和算力的發展方向也未必有明確答案。但我認為最關鍵、也最希望發生的事情并不在技術本身，而在市場端：希望在 2026 年，市場對 Agent 的認可度能夠顯著提高。

AI 是一種徹底的顛覆性技術，與以往技術不同，它在很多方面甚至需要整個市場被重新教育。在人們沒有形成足夠理解之前，很難發揮其全部能力。尤其在企業場景下，對安全性、數據與結果準確性都有更高要求。如果仍停留在“要么把它當萬能許愿池，要么認為一無是處”的極端認知，那 Agent 很難發揮作用。

我們期望有越來越多的用戶和企業找到適合自身業務的 Agent 使用方式，發揮其長板、規避其短板，使 Agent 真正為業務創造價值。今年我們一直在講“Agent 元年”，而一個行業之所以能持續有人投入研究與建設，最終仍需要在市場中產生真實成效。

AI 重塑組織的浪潮已至，Agentic 企業時代正式開啟！當 AI 不再是單純的輔助工具，而是深度融入業務核心、驅動組織形態與運作邏輯全面革新的核心力量。

把握行業變革關鍵節點，12 月 19 日 - 20 日，AICon 全球人工智能開發與應用大會（北京站） 即將重磅啟幕！本屆大會精準錨定行業前沿，聚焦大模型訓練與推理、AI Agent、研發新范式與組織革新，邀您共同深入探討：如何構建起可信賴、可規模化、可商業化的 Agentic 操作系統，讓 AI 真正成為企業降本增效、突破增長天花板的核心引擎。