員工吐槽“給 AI 擦屁股”更辛苦？揭秘企業 AI 提效的“悖論”與真拐點

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

策劃 | 李忠良

編輯 | 宇琪

在數字化浪潮席卷全球的今天，AI 正以前所未有的深度和廣度融入企業發展的脈絡之中，成為驅動創新與增長的核心引擎。那么，如何通過 AI 技術發現新的商業與增長機會？又如何利用 AI 實現更高效的用戶拉新、留存與轉化呢？

近日 InfoQ《極客有約》X AICon 直播欄目特別邀請值得買科技 CTO 王云峰擔任主持人，和阿里巴巴高級技術專家梁筱武、彩訊股份 AI 產研部總經理鄒盼湘一起，在AICon 全球人工智能開發與應用大會 2025 北京站即將召開之際，共同探討企業 AI 提效實戰復盤。

部分精彩觀點如下：

• 如果沒有幻覺，就沒有創造力。我們必須接受這種跳脫，同時用工程化手段將其控制在合理范圍內，才能得到我們需要的結果。

• 在所有類型的 Agent 中，數據治理始終是大模型工程的前置關鍵環節。

• 項目一號位必須具備將底層 AI 能力包裝成用戶可感知、可理解、可使用的產品功能的能力，并能與業務部門溝通、熟悉客戶場景和業務流程，從中提出 AI 需求。

在 12 月 19-20 日將于北京舉辦的AICon 全球人工智能開發與應用大會2025 北京站上，我們特別設置了 【AI 驅動的提效與增長實踐】 專題。該專題將探討面向 AI 場景的技術適配與架構演進，展現 AI 如何重塑企業流程、驅動創新與增長。

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

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

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

當“小學生”遇上“博士生”

王云峰：我們先聊聊“模型使用”。百川的王小川總曾經有個比喻，說現在的頂尖模型（像 GPT-4、Gemini 3）智商已經達到了“博士生”水平。 但我個人的體感是：模型雖然是博士生，但我們給它搭建的工程環境、甚至我們給它寫的 Prompt，可能還停留在“小學生”水平。 這種“ 能力錯配 ”，導致我們經常覺得 AI 不聽話。在這一年的實戰中，你們在工程上是如何把這個“博士生”的能力真正用好的？有沒有什么共識性的經驗？

梁筱武：基于我長期從事 GUI 自動化的背景，以及現在嘗試利用 AI 對 GUI 進行能力升級，我總結出三個方面的體會。

第一是要根據具體場景挑選基礎模型。GUI 操作本質上更類似 RPA，它對視覺的 grounding 與推理方式，與語音或文本任務具有顯著差異。因此，在基礎模型的選型與組合上，我們做了大量探索，嘗試過國內外多種模型，最終發現千問 3 在我們 GUI 場景中的推理效果表現較為突出。

第二是 Agent 架構的設計。AI Agent 的架構與傳統微服務工程體系并不相同，它需要從不確定性逐步收斂，而不是遵循固定流程。因此，如何通過工程化手段讓 AI 模型的輸出在可控范圍內，讓這個“博士生”能夠與我們的系統進行可控且有效的交互，是架構設計的核心。

在 GUI Agent 中，我們采用了引入“裁判”角色的方式，在每一步操作加入裁判判斷，這是模型之外的關鍵機制。

第三是上下文工程，即過去所說的 Prompt 工程。由于我們不做基礎模型，頂多只會開發一些垂直的小模型，如分析類小模型或局部圖像識別模型，因此上下文工程成為實現 AI 工程能力的核心。

王云峰：公司前段時間搞黑客松，很多同事反饋說，如果沒有從頭到尾完整地構建過一個 Agent，就不會真正意識到上下文工程的核心意義。我們無法把所有知識一次性塞給模型，但任務往往需要大量信息，如果上下文工程做不好，模型能力只能發揮一小部分。

鄒老師，B 端客戶的需求往往很死板，你們是如何通過工程手段（比如思維鏈 CoT），讓模型既發揮“博士”的智商，又遵守“小學生”的紀律？

鄒盼湘：在 B 端場景中，C 端與 B 端在 AI 應用上差異很大。先談一個常被提到的大模型的“幻覺”問題。很多人認為幻覺是負面的，但實際上正是因為幻覺，模型才具備生成能力。如果模型毫無幻覺，它就只是背知識，無法產生新的內容。

因此，我們會根據具體場景反推是否需要幻覺。絕對消除幻覺不可能，但我們可以決定何時需要降低幻覺。在創作類場景，如視頻營銷面向不同用戶群體時，幻覺有助于生成更具想象力與多樣性的內容；但在 B 端業務場景，我們通常需要盡量降低幻覺。

降低幻覺需要明確方法：降低的時機、方式，以及在降低幻覺的同時如何保持模型的“博士生”水平。上下文工程在降低幻覺方面至關重要，我們需要將專家經驗、工具 API 的執行結果、插件結果、推理鏈等注入模型，以減少偏離。然而，僅靠上下文工程還不夠，因為幻覺問題可能源自多個環節，例如知識檢索、推理規劃、工具調用或意圖識別等。在 B 端，我們無法接受黑箱式流程，因此我們提出了全流程可觀測、可控的方法。

可觀測分為三個階段。第一是意圖理解，不同用戶的問題清晰度不同，因此我們需要意圖澄清過程，確保獲取真實需求。澄清后進入任務規劃階段，每一步的思考過程，包括使用的知識、調用的工具等，都需要打印出來，讓用戶看到模型的推理路徑。例如行程規劃，模型需要反復詢問時間、人數、交通方式、住宿偏好等信息，以確保規劃符合需求。

上線前，我們通過讓流程可觀測、打印每一步推理過程、注入上下文等方式，使模型盡量沿著預期路徑執行。上線后，AI 應用與傳統 IT 應用的最大差異在于邊界不明確。IT 系統的輸出是可預測的，但 AI 只能做到“預估”。我們可以把上線時的水平從 60 分提升到 80 分，但永遠無法達到 100 分。上線后需要不斷通過迭代逐步從 80 分提升到 90、95 甚至 99 分，但依然不可能完美。

因此，我們必須通過工程化手段提前注入內容、人為干預或補充等方式，處理模型無法覆蓋的部分。

AI 模型只是整個系統的一部分，而不是全部。因此，我們會增加許多配套模塊和管理工具，甚至會在某些場景減少模型規模，降低其泛化能力，以提升可控性。有時我們會讓模型先生成規劃，再由人工校驗，最終將規劃轉化為可控的路徑搜索流程。我們在行業內做 Agent 時踩過很多坑，因此總結出 AI 落地應滿足可觀測、可迭代、可控、可信、可集成的要求。這些要求也反向推動交付團隊與產研團隊開發相應工具與工程能力，從而支撐整體落地。

王云峰：無論 C 端還是 B 端，大家最后的認知其實趨于一致：大模型的“智商”已經很高，但僅有一個高智商的大腦解決不了問題，仍然需要大量知識及工程化能力的支撐，而許多知識并不在模型本體中。因此不能期待模型一次給出最終答案，而是需要用工程化手段保證其輸出可控。

模型的創造性、涌現能力來源于多樣性，而多樣性在今天被稱為“幻覺”。如果沒有幻覺，就沒有創造力。我們必須接受這種跳脫，同時用工程化手段將其控制在合理范圍內，才能得到我們需要的結果。

數據的“上下文”缺失

王云峰：聊完模型，咱們聊聊“數據”，這是 AI 的燃料。在值得買，我們為了讓 AI 做好消費決策，必須給它看大量的用戶行為和社區內容。這也是我推動 MCP（模型上下文協議） 的核心動力：我希望解決 AI 和企業私有數據之間的“上下文”連接問題。但實話說，這個過程比想象中艱難。在你們的實踐中，讓 AI “讀懂”企業內部業務邏輯，最大的絆腳石是什么？鄒老師，您在給 B 端客戶交付時，是不是得花大量時間幫客戶“洗數據”？如果客戶的數據爛到根里了，這時候是強行上 AI，還是勸客戶先把數字化重做一遍？

鄒盼湘：在實際落地過程中，許多客戶會提出疑問：模型已經如此強大，為什么仍然需要數據？需要什么類型的數據？又該如何開展數據治理？要回答這些問題，需要從“為什么做數據治理”談起。

首先，模型往往無法理解企業自身的業務場景、流程和垂直領域的術語。例如，在運營商場景中，“套餐”指的是話費套餐，但如果直接詢問模型“幫我定個套餐”，模型可能會理解成麥當勞或肯德基的套餐。因此，在具體業務場景中，我們必須將企業的私域知識傳遞給模型，使其理解特定術語的真實含義。

此外，數據治理還關系到專家經驗的顯性化與傳遞。專家經驗通常體現為問題分析方法和處理流程，而模型依賴的是通用知識。如果缺乏專業知識的輸入，模型無法解決許多場景化問題。

例如在運營商的 10086 客服場景中，用戶可能咨詢套餐、攜號轉網等業務，而攜號轉網有嚴格的流程和條件要求，無法隨意辦理。過去在線客服往往長時間也無法解決，而線下幾分鐘即可完成，就是因為其中涉及業務系統調用、條件校驗等信息，這些內容若不提供給模型，模型便無法真正理解業務。

我們需要明確哪些數據需要治理，可以分為兩大類：一類是知識性數據，包括專家經驗、文檔材料、方案內容以及結構化的分析數據等。這類數據需要顯性化沉淀，通常以 PPT、Word、知識性數據可以通過兩種方式與模型結合：其一是將數據納入知識庫；其二是用于模型訓練。如果用于訓練，需要明確模型類型（如多模態或語言模型）以及訓練階段（如 SFT、強化微調或對齊訓練），相應的數據格式、數據量與處理工具也不同，需要進行清洗、去重、標注、脫敏等工作。

如果知識進入知識庫，則需要考慮數據來源、類型、更新機制、沖突處理與時效性管理。治理的重點集中在解析入庫、索引與召回階段，確保知識在被檢索時一致、有效且準確。

另一類數據是生產過程中的數據，包括 API 調用記錄、系統日志、任務執行鏈路等。這類數據有時會作為模型強化學習的素材，但更多情況下，會在實時推理時作為上下文提供給模型。在此過程中必須設置嚴格的約束，不能將所有數據直接暴露給模型，尤其在多 Agent 環境中，數據可能被模型錯誤緩存并在不同代理間傳遞，從而造成跨權限的數據泄露風險。

例如，若財務 Agent 獲取到企業財務數據并被模型緩存，而招聘 Agent 又在無權限的情況下訪問到這些緩存數據，就會引發嚴重的安全隱患。因此，在生產數據治理中，需要重點關注賬號體系、權限控制、隱私保護、數據脫敏，以及防范外部提示投毒等問題。

完成這些治理措施后，就需要進行模型效果評估。評估可分為技術指標和業務指標兩類。技術評估包括準確率、召回率、回答一致性與相關性等；業務評估則關注用戶增長率、客服難進率、銷售轉化率、用戶活躍度等關鍵指標。這些業務數據的觀測與分析，是 Agent 持續迭代優化的基礎。

Agent 能否持續迭代的核心驅動力是 ROI，因此必須依賴這些上線后的數據來評估收益、定位問題是技術問題還是業務問題。此類數據治理屬于上線后的持續運營工作，而非 AI ready 階段的前置治理。

王云峰：梁老師，飛豬的 GUI Agent 是直接看屏幕的，這看起來好像繞過了“數據接口”的治理難題。這算不算是一種“逃課”？這種方式對數據的理解深度夠嗎？

梁筱武：在 GUI Agent 中，除了知識性數據，還有一個顯著的特殊性：圖形數據。GUI 的圖像數據如果不準確，就會導致模型無法找到界面元素的位置。因此，圖像數據的質量對 GUI Agent 的效果至關重要。

為此我們做了大量工作。例如，在提供 GUI 數據時，我們必須設計大模型能夠理解的格式，這也是上下文工程的一部分。GUI 操作涉及“動作空間”，包括點擊、拖拽等事件，而普通非 GUI 場景并不存在動作空間的概念。因此，我們需向模型明確這些動作的定義，使其能夠正確預測下一步動作。

此外，在實際應用中，模型的準確率永遠無法達到 100%，尤其在各企業存在大量非標準化、定制化 UI 的情況下。標準按鈕模型可以輕松識別，但企業自定義按鈕或特殊組件往往難以識別，因此我們必須通過數據灌入與示例教學幫助模型理解。例如，在處理某些上下滑動組件時，我們需要明確告訴模型這是滑動結構，提供樣例以便其學習，與其他 AI 模型的訓練邏輯類似。

同時，在 GUI Agent 中，我們還會對高頻操作場景采用 CAG（緩存式 LAG）等技術，對熱點圖形數據進行專門處理，以提升識別與操作的穩定性。總體而言，圖像數據的準確性直接決定 GUI Agent 的執行效果，如果模型無法識別圖形或進行糾錯，就無法實現高精度操作。在所有類型的 Agent 中，數據治理始終是大模型工程的前置關鍵環節。

是“真提效”還是“更累了”？

王云峰：老板們都在喊提效，但有時候一線員工反饋是“更累了”：以前自己寫代碼 / 寫文案，現在要給 AI 寫 Prompt，寫完還得復核，出了錯還得背鍋。在你們的項目上線后，有沒有遇到過這種“越用越累”的情況？你們覺得，真正的“提效”拐點在哪里？

梁筱武：“員工是否感覺不累”，核心在于準確率。我們在構建 AI Agent 時始終要面對準確率的問題。與傳統確定性的流程式工程不同，AI 是一個不斷將不確定性收斂的過程。如果準確率較低，員工會缺乏信心，會覺得使用 AI 很累。以我們的 GUI Agent 為例，今年四月份準確率只有約 40%，員工很難依賴它。

而到了九月份，我們將準確率提升到 90%–95% 后，團隊對 AI 的信心顯著增強，也真正看到 AI 在提效上的價值。我們的 C 端業務目前已完全由 AI 接管，效率提升非常明顯。

第二個感受是工程體系和工具體系對提效的影響。在構建 AI 工程時，需要配套調試工具、孵化工具、腳手架、Prompt 模板庫等基礎設施，讓員工能夠直接使用，而不用花時間處理和 AI 本身無關的技術細節，這與過去流程式架構的工具建設類似。

如果基礎設施齊備，整體開發效率會顯著提升。此時員工只需要關注 AI 的核心部分，如上下文工程、推理能力、圖像識別質量或語言質量等。一旦同時具備足夠高的準確率和完善的工程工具體系，員工自然愿意使用 AI，也能在實際業務中真正提升效率。

關于“AI 是提升效率還是讓人更累”這個問題，我認為兩者是并存的。首先，AI 的確顯著提升了效率，包括我個人在寫材料、做調研、分析、制定方案、項目管理和會議記錄等方面，都大量依賴 AI 工具，效率提升非常明顯。

但與此同時，我們也確實變得更累了。一方面，整個行業正處于技術轉型期，我們必須持續學習新技術、拓展認知、補充知識，這本身就會帶來壓力。另一方面，雖然 AI 能替我們處理許多任務，但我們面對的整體工作量和復雜度也顯著提高了。以往做 IT 開發，需求明確，產出可量化，周期也較為可控。

但在 AI 時代，我們需要花大量時間驗證效果、解釋現象、分析問題、不斷探索。以前開發一個頁面三天就能完成，而現在要把 AI 的準確率從 80% 提升到 95%，所需時間幾乎無法預測。項目在估算成本和投入產出時的難度也比過去高得多，一旦有某個點無法突破，投入就會成倍增加，團隊的壓力也隨之上升。

我認為這種“更累”主要出現于當前階段。未來，隨著我們對 AI 的認知逐漸清晰，業務流程被重新梳理，各類改造逐步完善，我們會逐漸進入一個更輕松的階段。但目前我們仍處于最艱難的過渡期，大家都在尋找最優路徑、沉淀工具、做好服務治理和數據治理，同時還要應對算力基礎與模型本身的持續迭代。

王云峰：我想先引用一下我們在直播開場提到的一份報告，其中有些數據非常值得討論。這是 MIT 主導的一項聯合研究，主要評估當前人工智能技術能覆蓋美國經濟中多少勞動力任務。他們提出了一個概念，叫“Iceberg Index”（冰山指數），意指我們通常看到的只是水面上的少部分，而大部分價值都在水下。

研究結論顯示，目前 AI 技術能力已可以覆蓋美國經濟中約 11.7% 的勞動力任務，涉及的薪資規模高達 1.2 萬億美元。但其中有一個反常識的發現：那些位于“冰山之上”的技術圈層任務，實際上只占約 2.2% 的勞動力。如果只看到這些數據，可能會得出“AI 的沖擊主要集中在技術行業”的錯誤結論。

然而，這項研究構建了 1.3 萬個技能，并與 1.3 萬多個 AI 工具進行交叉匹配，最終發現：除了顯而易見的編程和創意類崗位之外，大量認知型和行政型任務在技術上也已高度可自動化。這些任務并非集中在技術密集行業，而是廣泛存在于金融審核、保險理賠審核、物流協調、醫療行政管理、供應鏈監控等領域。

這些崗位并非技術行業，但卻支撐著現代經濟的基礎。換言之，“冰山之下”的任務規模是“冰山之上”的五倍。從這份報告得出的關鍵結論是：真正取代崗位的不是 AI 本身，而是“更會使用 AI 的人”。

更進一步問，隨著 AI 越來越強， 那些原本做基礎工作的人，他們的工作是被 AI 徹底替代了，還是被迫轉型了？ 作為技術管理者，兩位老師現在招人的標準變了嗎？你們更看重候選人的什么能力？

梁筱武：整體來看，AI 確實在這些領域發揮了作用，但我認為崗位不會消失，而是會轉變為借助 AI 完成更高效的工作。例如原來做金融科目核對的人，未來可能會基于 AI 輸出結果進行更深入的分析。

從技術研發的角度看，招聘標準也會有一些變化，但總體而言，軟件工程的基礎能力、架構能力仍是招聘的核心，不會發生根本性變化。可能會新增一些加分項，例如具備 AI 工程相關能力、概率思維能力、效果評估能力等。與大模型交互的工程從來無法做到 100% 準確，因此如何理解概率模型、如何讓模型的輸出收斂到更高準確率，都會成為重要能力。同時，像基座模型效果評估、上下文工程評估等也都是加分項。

若能快速進行評估、具備工具和方法支撐，自然能提升效率。還有一個當下越來越重要的能力，是從業務場景中識別 AI 價值的能力。例如金融從業者需要從對賬走向數據分析，而對開發工程師來說，以往只需按照 PRD 完成功能開發，但今天我們的任務更像是一個 AI 工程：要理解業務場景，找到適用的 AI 技術，并讓工程能夠與之匹配。如果能成功識別場景并找到適配技術，那么無論團隊效率還是個人效率都會顯著提升，這也會讓工程師獲得很強的成就感。

鄒盼湘：我們面向 B 端，同時配置研發和交互團隊，過去幾年也經歷了多輪陣痛，因此在人員要求上做出了較大的調整。過去從需求、方案設計、開發到測試上線，流程清晰，但現在客戶往往不清楚從哪些場景切入、哪些值得做、做完需要怎樣的環境以及能達到什么效果，整體預期并不明確。因此，我們將項目的“一號位”從項目經理調整為兼顧項目管理與產品設計的角色。他必須既理解業務、具備產品思維，又要懂戰略規劃，并掌握一定的 AI 基礎技術。

我們發現很多傳統項目經理難以承擔 AI 項目，因為他們的工作邏輯很難轉變。面對客戶提出的問題，他們往往不知道如何判斷需求是否合理，也缺乏對目標、時間和成本的評估意識，容易導致團隊內部出現大量溝通與執行層面的內耗。

因此，我們要求項目一號位必須具備將底層 AI 能力包裝成用戶可感知、可理解、可使用的產品功能的能力，并能與業務部門溝通、熟悉客戶場景和業務流程，從中提出 AI 需求。同時，他還需理解主流 AI 技術，特別是 RAG 和 Agent，對其原理、能力邊界、適用場景及可達上限有清晰判斷，以確保項目能夠有序、高質量地交付。

另一個關鍵崗位是測試工程師。傳統測試只需驗證功能是否正確、能否跑通、是否有 bug，而現在測試必須具備業務理解和產品思維，參與全流程的質量保障。從真實使用場景出發設計端到端測試用例及邊緣場景測試，不再局限于單個 API 的驗證。同時，他要站在用戶視角評估產品質量與體驗，能識別整體產品問題并提出優化建議。

測試人員還需要具備風險意識，識別 AI 系統在特定業務場景下可能存在的風險，如隱私泄露、決策錯誤及其他不可控問題。這些風險可能需要通過產品功能完善、架構優化或代碼設計調整來解決。此外，測試也必須具備良好的協作與學習能力，能與算法、開發和產品團隊就缺陷及質量風險達成共識。

在學習能力方面，我們要求公司全員具備 AI 能力，包括銷售、解決方案、交付和研發線條。公司為各類崗位提供了 AI 培訓路線、學習資料與評估指標。例如，測試人員需學習對抗性攻擊、大模型評測基準、Agent 評測標準等，以補齊過去無法評價 Agent 效果的短板。

對于前端崗位，過去只需根據 UI 完成功能開發，而現在他們需要參與交互界面設計，提出創新的用戶體驗，包括流式響應、多模態交互、可溯源結果呈現等。在 AI 時代，許多產品界面將大幅簡化，甚至可能只有一個對話框，交互在任務執行過程中實時觸發。因此，前端需要思考何時呈現信息、以何種形式呈現、如何處理多任務并行等問題。

王云峰：AI 產品的開發與傳統開發在范式上有明顯差異，思路也完全不同。我們曾經遇到的問題是，如果研發人員缺乏強學習能力或對新事物的接受能力，無法判斷 AI 的優勢與局限，而繼續沿用傳統確定性技術的思路進行設計，往往無法勝任，甚至可能無法通過試用期。

因此，我們非常看重的一點是候選人是否真正愿意使用 AI，并且在日常中頻繁使用 AI、具備一定判斷力，能形成真實的體感。只有這樣，在產品設計或開發過程中才能把握 AI 的特性與行為規律。其他崗位也同樣如此，廣泛使用 AI 對提升工作效率具有非常顯著的作用。

價值與終局——算賬與未來

王云峰：咱們俗一點，算算賬。現在的 Token 成本、推理成本依然不低 。如果讓您給企業老板一個建議：什么樣的業務場景，是現在立刻、馬上就應該用 AI 重構的？什么樣的場景，建議“再等等”？

鄒盼湘：我認為當前的核心痛點主要集中在場景選擇與價值衡量。做場景選擇時要避免兩個極端：一是好高騖遠，即在探索階段就嘗試對核心系統進行 AI 化升級；一旦出現問題，后果難以承受。二是隔靴搔癢，即選擇極低頻的邊緣場景，雖然安全，但無法產生實際業務價值。

在場景選擇上，我們采用幾個評估原則。首先從業務價值出發，理想場景應具備高頻、剛需和明確的付費方。其次從數據就緒度評估數字化程度、知識結構化程度及相關文檔沉淀情況。理想狀態下，數據已準備充分，具備 AI 升級改造的基礎。

此外，還需關注容錯空間，通過引入 human-in-the-loop 的人機協同模式，將錯誤率控制在可接受范圍內。如果某個場景既無人監管，又屬于核心業務，則不宜在早期觸碰。

場景確定后，需要進一步評估其價值。我們通常從兩方面衡量：一是總擁有成本，包括顯性成本（如 GPU 等硬件投入、Token 費用）和隱性成本（如人力運維、合規與風險成本）；二是價值機會，包括效率提升、體驗改善和決策優化。效率提升對應降本省人，體驗改善可能帶來提價或留存，決策優化有助于規避風險。當價值機會減去總擁有成本為正時，從 ROI 角度看，這個場景就值得投入。

梁筱武：目前還沒有一個能適用所有行業的通用方法來判斷“AI 該在哪個場景落地”。無論是 C 端、B 端、App 端還是機器人，各行業國內外都在試驗，各類應用場景正處于“遍地開花”的探索階段。我的建議是采用快速迭代方式，小規模試點、小流量驗證，持續大膽嘗試。

同時，企業需要具備與大模型類似的“快速反思能力”。在任何項目與產品實踐中，如果發現方向不對，要能迅速糾偏并切換到新的場景繼續驗證。

從當前的實踐來看，在“效率提升”這一方向已有大量成功案例。大模型在效率層面的優勢非常明顯，商業效果則因應用成本和場景不同而存在差異。在企業內部，從簡單任務開始試驗通常最為穩妥，例如使用數據分析類 AI 自動生成日報和周報，以替代重復性的文本整理工作，這類改造通常能取得不錯的效果。

在更復雜的效果型場景，如 Agent 的探索方面，各家公司仍在不斷試驗，目前還很難總結出普適的套路。但我認為，可以大膽嘗試，并盡量貼近大模型的思維方式，將自身產品體系與底層模型能力深度融合。當 Agent 產品與大模型在認知模式和工作方式上實現對齊后，其整體速度和迭代效率將顯著提升。

觀眾：如何精確匹配個人對商品的需求和商品信息？

王云峰：傳統搜索中，用戶輸入 query，系統從原始商品信息中進行匹配，再由用戶判斷結果是否相關。后來出現推薦算法，通過用戶行為進行預測，但這也容易形成“信息繭房”，因為系統會不斷強化用戶過往行為，使其接收越來越同質化的信息。我們認為，如果利用 AI 對全網數據進行結構化整理，可以打破這種局限。

AI 能理解用戶行為背后的真實需求。如果用戶提出一個意圖，我們應充分利用其相關的身份信息去推斷更真實的需求。此外，商品信息往往并不完整，因此需要結合大量用戶描述、社交媒體內容和公開資料，構建對商品的完整表述，以判斷商品適用的場景。用戶的購物需求本質上是特定場景與商品適配性的匹配，通過完善商品與場景的描述，才能更好地實現人與商品之間的精準匹配。

但現有數據質量無法完全滿足這一需求，因此必須在前期進行充分的數據預處理與治理，只有把數據打好底子，后續的匹配效果才能得到保證。

觀眾：鄒老師，您在給企業做 AI 應用落地的過程中遇到的最難環節是什么？

鄒盼湘：這個問題很難回答，因為從整體架構構建、數據治理到賬號權限、安全等模塊都不容易。但如果一定要選最難的環節，我認為是服務治理。B 端場景不是從零構建新產品，而是要把 AI 與企業現有業務流程、業務系統和業務數據深度融合。過去我們做 IT 時，是物理世界與 IT 世界的融合；現在是 AI 與 IT 世界的融合。以我們在南網的智能問訴項目為例，過去制作數據看板和分析流程時，每一步都是人編碼定義，而現在需要實時動態構建，因此必須把原有流程知識化。過去系統由人操作，現在要實現人機協同，讓系統具備一定的思考能力，需要設計好人與系統共生的方式。

在企業項目中還會遇到系統數量龐大的問題。例如在線公司有十幾個業務系統、超過四萬個 API。如何將這些 API 轉化為模型可調度的插件或 MCP 服務，并保證它們的性能、管理、注冊與監控，都是服務治理中的關鍵難題。任何一個環節處理不好，都可能導致整體系統混亂。

觀眾：Agent 自主操作手機的模式會不會失控，讓設備擅自行動？

梁筱武：如果 Agent 的準確率和流程控制在可確定范圍內，它是不會失控的。但由于 Agent 天然具有不確定性，不可能做到 100% 準確。如果準確率是 95%，那么剩下 5% 的不確定場景就需要通過風險前置方式來處理，包括在產品流程和技術實現層面進行防護。例如，在 Agent 需要進行規劃與推理時，一旦前序步驟出現錯誤，我們應該能夠快速終止流程，從源頭避免異常擴散。

我們還可以在產品端加入流程控制機制，例如“閥門式”安全措施；在技術端加入可視化鏈路，甚至引入第三方裁判或監督機制，對關鍵步驟進行實時中斷。通過這些方式，可以有效規避 Agent 在不確定性場景中的風險。本質上，這是關于如何設計 AI 產品與技術體系，使那部分不可避免的不確定性得到妥善處理。

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

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