一、引言Presence 的重點不是又一個聊天機器人2026 年 7 月 22 日OpenAI 正式發(fā)布 OpenAI Presence將其定位為企業(yè)級 AI Agent 運營與治理平臺Enterprise AI Agent Platform。它支持語音與聊天兩種通道面向客服、銷售和內(nèi)部 IT 服務(wù)等場景并可接入 CRM、工單系統(tǒng)等企業(yè)現(xiàn)有系統(tǒng)。如果只看這些功能Presence 很容易被理解為一套更完整的企業(yè)機器人方案。但真正值得關(guān)注的變化在交付方式上它不是注冊賬號、配置幾項參數(shù)即可使用的自服務(wù) SaaS而是面向大型企業(yè)由 OpenAI 的 Forward Deployed Engineers 參與并完成部署。Bain Company 也以合作伙伴身份提供支持。需要說明的是Bain Company 與 Bain Capital貝恩資本并非同一機構(gòu)在缺少更具體披露的情況下本文不進一步推斷其投資關(guān)系。這意味著 OpenAI 正在把自己的角色從 API 提供商擴展為托管式企業(yè)服務(wù)提供商。過去OpenAI 交付的是模型能力企業(yè)或集成商負責(zé)知識庫、系統(tǒng)連接、權(quán)限、安全、評測和線上運營Presence 則試圖把其中更多責(zé)任收進一個平臺和一套服務(wù)體系。2026 年 5 月成立的 OpenAI Deployment Company為這種轉(zhuǎn)向提供了組織層面的注腳企業(yè)落地不再只是模型銷售之后的配套工作而開始成為獨立能力。因此Presence 的價值不能只用“回答是否更聰明”來衡量。對生產(chǎn)環(huán)境而言一個 Agent 能回答問題只是起點它能否在授權(quán)范圍內(nèi)調(diào)用系統(tǒng)、遇到高風(fēng)險請求時停止、把復(fù)雜案例轉(zhuǎn)給人、在上線前經(jīng)過足夠測試并在上線后持續(xù)修正才決定它能不能真正承擔(dān)業(yè)務(wù)。從這個角度看Presence 釋放出的信號很明確企業(yè) Agent 的競爭焦點正在從模型能力轉(zhuǎn)向可運營、可控制、可評估的系統(tǒng)能力。二、核心能力先建立控制面再擴大自動化Presence 基于 GPT-5.6 系列模型但它強調(diào)的并不是單一模型指標而是“governance first”先管好 Agent再逐步放開能力。這套思路可以拆成四個相互連接的環(huán)節(jié)。1. 策略與權(quán)限治理把“能做什么”寫成系統(tǒng)規(guī)則企業(yè)可以自定義 Agent 的操作范圍、審批流程和人工接管規(guī)則。三者分別回答了生產(chǎn)部署中的三個基本問題Agent 可以訪問哪些數(shù)據(jù)、調(diào)用哪些工具什么動作必須由人確認在什么條件下應(yīng)停止自動處理并移交員工。這比提示詞里的“請謹慎操作”更可靠。提示詞是一種行為引導(dǎo)權(quán)限和審批才是控制面。例如一個客服 Agent 可以查詢訂單狀態(tài)卻不應(yīng)默認擁有無上限退款權(quán)限內(nèi)部 IT Agent 可以幫助重置普通賬號密碼但涉及管理員賬號或異常登錄時應(yīng)進入人工審核銷售 Agent 可以整理線索和生成建議卻不應(yīng)在未經(jīng)確認的情況下自動承諾折扣。真正成熟的權(quán)限設(shè)計也不是“允許”與“禁止”的二元開關(guān)而是根據(jù)身份、金額、數(shù)據(jù)類型和風(fēng)險等級分層。Presence 是否能把這些規(guī)則映射到復(fù)雜組織中的角色體系并保持策略一致性將比演示中的對話效果更重要。公開資料確認了它支持自定義治理但尚不足以判斷其策略表達能力、審計粒度和跨系統(tǒng)權(quán)限同步的具體上限這些仍需企業(yè)在項目中驗證。2. Guardrails安全不是拒答而是對越界行為及時干預(yù)Presence 的 Guardrails 會在交互超出企業(yè)預(yù)設(shè)邊界時自動干預(yù)。這里的“邊界”不應(yīng)只理解為敏感詞過濾。Agent 一旦連接 CRM、工單和其他業(yè)務(wù)系統(tǒng)風(fēng)險可能來自錯誤身份識別、越權(quán)讀取、未經(jīng)審批的寫入、承諾超出政策或者在信息不足時繼續(xù)執(zhí)行。因此有效的 Guardrails 至少要落到動作層什么信息可以展示什么工具可以調(diào)用調(diào)用參數(shù)是否合規(guī)執(zhí)行前是否需要確認異常后是否立即中止。模型層的安全回答與系統(tǒng)層的權(quán)限控制需要同時存在前者減少不當(dāng)輸出后者限制真實影響范圍。這也是“governance first”的現(xiàn)實含義Agent 越能行動治理越不能后置。企業(yè)不是先讓 Agent 獲得完整權(quán)限再根據(jù)事故補規(guī)則更合理的順序是從只讀、低風(fēng)險、高可逆的任務(wù)開始用真實運行數(shù)據(jù)證明穩(wěn)定性后再擴大授權(quán)。3. 模擬測試與評估從“看起來不錯”轉(zhuǎn)向可重復(fù)驗收Presence 支持在部署前批量模擬常見請求和邊緣案例并自動評分。這一能力解決的是 Agent 項目中經(jīng)常被低估的問題幾次人工試聊不能代表生產(chǎn)質(zhì)量?？头埱罂赡馨畔⑷笔А⑶榫w激烈、政策沖突、跨系統(tǒng)數(shù)據(jù)不一致銷售場景可能遇到價格邊界、地區(qū)限制和錯誤客戶身份內(nèi)部 IT 則可能涉及權(quán)限升級、設(shè)備丟失和安全事件。邊緣案例出現(xiàn)頻率不高卻往往擁有更高的失敗代價。批量模擬的意義是把這些情況變成可重復(fù)的回歸測試。企業(yè)不應(yīng)只記錄“回答正確率”還應(yīng)關(guān)注端到端任務(wù)成功率、錯誤工具調(diào)用率、人工接管率、越權(quán)攔截率、平均處理時長以及升級模型或修改策略后是否出現(xiàn)回歸。自動評分可以提高測試規(guī)模但涉及政策解釋、客戶承諾和高風(fēng)險動作時仍需要人工抽檢避免讓另一個模型的判斷成為唯一標準。4. 持續(xù)改進學(xué)習(xí)線上問題不等于無條件在線自我修改Presence 能從線上交互中主動學(xué)習(xí)并自動標注不確定性案例。這使評測不再是上線前的一次性門檻而形成“運行—發(fā)現(xiàn)問題—標注—修正—再評測”的循環(huán)。其中最有價值的環(huán)節(jié)可能不是自動學(xué)習(xí)本身而是識別“不確定”。在企業(yè)服務(wù)里可靠地知道何時不該繼續(xù)比勉強生成一個答案更重要。系統(tǒng)可以把低置信、規(guī)則沖突或未覆蓋請求送入人工隊列再將處理結(jié)果沉淀為新的測試樣本。不過“持續(xù)改進”不應(yīng)被理解為 Agent 可以不經(jīng)審核地改變生產(chǎn)行為。策略調(diào)整、知識更新和新動作權(quán)限仍應(yīng)經(jīng)過版本管理、回歸測試和審批。否則今天修復(fù)的一個案例可能成為明天新的系統(tǒng)性偏差。四項能力并不是獨立功能而是一條閉環(huán)策略定義邊界 → Guardrails 在運行時執(zhí)行邊界 → 模擬評估驗證邊界 → 線上不確定案例反哺下一輪策略與測試Presence 的產(chǎn)品成敗很大程度上取決于這條閉環(huán)能否在真實企業(yè)系統(tǒng)中低摩擦地持續(xù)運轉(zhuǎn)。三、場景分析同一個 Agent不同風(fēng)險需要不同自動化等級語音和聊天雙通道讓 Presence 可以覆蓋從呼叫中心到內(nèi)部服務(wù)臺的多種入口但“支持某個場景”不等于適合全自動處理。更合理的做法是按任務(wù)風(fēng)險設(shè)計自治級別。場景適合自動化的任務(wù)應(yīng)設(shè)置的邊界建議人工接管條件客服查詢訂單、解釋標準政策、創(chuàng)建工單、整理對話摘要身份驗證、退款額度、隱私數(shù)據(jù)、補償承諾復(fù)雜投訴、政策沖突、高金額操作、客戶明確要求人工銷售線索初篩、產(chǎn)品問答、會話記錄、跟進提醒折扣權(quán)限、合同條款、客戶數(shù)據(jù)訪問范圍非標準報價、法律條款、關(guān)鍵信息不完整內(nèi)部 IT常見故障排查、知識檢索、普通工單分流管理員權(quán)限、憑證處理、生產(chǎn)系統(tǒng)變更安全事件、權(quán)限提升、批量或不可逆操作以客服為例語音 Agent 可以先識別意圖、查詢訂單并解釋標準規(guī)則。如果客戶要求的退款超過預(yù)設(shè)額度Guardrails 應(yīng)阻止直接執(zhí)行將上下文和已完成步驟一并交給人工坐席。這里的價值不只是“轉(zhuǎn)人工”而是減少重復(fù)詢問讓員工從可繼續(xù)處理的狀態(tài)接管。銷售場景的難點則不在回答產(chǎn)品問題而在承諾邊界。Agent 可以提高響應(yīng)速度卻不能因為追求轉(zhuǎn)化而突破折扣和合同政策。內(nèi)部 IT 的風(fēng)險更技術(shù)化一個能夠調(diào)用工具的 Agent既可能節(jié)省大量一線支持時間也可能因錯誤授權(quán)擴大安全影響。因此Presence 最先產(chǎn)生穩(wěn)定收益的區(qū)域很可能是高頻、規(guī)則明確、結(jié)果可驗證的流程而不是一次性追求端到端無人化。四、定價與商業(yè)模式企業(yè)租用的不是 token而是一套運營能力目前公開信息沒有給出 Presence 的標準價格也沒有可核驗的按席位、按調(diào)用量或按任務(wù)報價?？紤]到它面向大型企業(yè)、不是自服務(wù) SaaS并由 Forward Deployed Engineers 參與部署更審慎的判斷是現(xiàn)階段定價未公開商業(yè)交付預(yù)計以項目制和企業(yè)合同為主具體成本應(yīng)以 OpenAI 的實際方案為準。這與按 token 購買 API 有本質(zhì)差異。API 模式下企業(yè)購買的是模型調(diào)用能力集成、評測、治理和運營成本分散在內(nèi)部團隊與外部供應(yīng)商中Presence 模式下OpenAI 試圖交付可運行的 Agent 及其控制體系。分析師將其概括為“enterprise agents you rent, not own”——企業(yè)租用 Agent而不是完整擁有自建技術(shù)棧。成本與責(zé)任自建 AgentPresence 式托管方案模型與編排企業(yè)自行選型、開發(fā)和維護以 GPT-5.6 系列及平臺能力為基礎(chǔ)交付系統(tǒng)集成內(nèi)部團隊或集成商負責(zé)OpenAI 部署團隊深度參與治理與評測企業(yè)自行搭建規(guī)則、測試與監(jiān)控平臺提供治理、Guardrails、模擬評估和改進閉環(huán)上線速度取決于團隊積累前期建設(shè)較重有望縮短建設(shè)周期但仍受企業(yè)系統(tǒng)復(fù)雜度影響控制與可替換性自主性更高維護責(zé)任也更重運營負擔(dān)可能更低但供應(yīng)商依賴更高定價信息人力、基礎(chǔ)設(shè)施、模型調(diào)用等成本可拆分標準價格未公開預(yù)計以項目制和企業(yè)合同為主“租用”并不天然更便宜也不天然更貴。企業(yè)應(yīng)該比較的是總擁有成本部署周期、內(nèi)部工程人力、集成維護、人工接管、合規(guī)審查、失敗損失和供應(yīng)商切換成本而不是只比較 token 單價。這種模式的優(yōu)勢是把稀缺的 Agent 工程和運營經(jīng)驗一并引入代價則是更強的供應(yīng)商依賴。企業(yè)需要在合同和技術(shù)評審中問清數(shù)據(jù)如何處理、策略與評測資產(chǎn)能否導(dǎo)出、接口如何替換、服務(wù)中斷如何降級以及終止合作后知識、日志和流程配置如何遷移。所謂“不擁有”真正影響的不是法律措辭而是未來能否保留業(yè)務(wù)連續(xù)性和議價能力。五、競爭格局Presence 爭奪的是企業(yè)工作流控制層Presence 將直接面對 Salesforce Agentforce、Microsoft Copilot 和 Zendesk AI。由于目前沒有同口徑的價格、成功率和部署周期數(shù)據(jù)不能僅憑發(fā)布信息給出誰更強的結(jié)論。更有意義的是比較各自進入企業(yè)的路徑。平臺主要進入路徑Presence 需要證明的優(yōu)勢企業(yè)選型時的關(guān)鍵問題OpenAI PresenceGPT-5.6 系列、托管部署、治理優(yōu)先能否跨現(xiàn)有系統(tǒng)交付穩(wěn)定的 Agent并持續(xù)運營集成深度、治理能力、項目成本、供應(yīng)商依賴Salesforce AgentforceSalesforce 及 CRM 業(yè)務(wù)流程Presence 在非單一業(yè)務(wù)系統(tǒng)中的整合與模型能力企業(yè)流程是否主要沉淀在 Salesforce 體系Microsoft CopilotMicrosoft 辦公與企業(yè)軟件生態(tài)Presence 能否在專用業(yè)務(wù)流程中提供更深交付身份、數(shù)據(jù)和協(xié)作環(huán)境是否已高度微軟化Zendesk AI客服與工單場景Presence 能否從客服擴展到銷售和內(nèi)部 IT并保持專業(yè)深度需求是專注客服還是跨部門統(tǒng)一平臺Salesforce、Microsoft 和 Zendesk 都擁有各自的企業(yè)入口業(yè)務(wù)數(shù)據(jù)、辦公身份體系或客服工作流。OpenAI 的優(yōu)勢起點更接近模型和 Agent 能力Presence 則要通過 Forward Deployed Engineers 與治理平臺補上最后一公里。這也解釋了為何 OpenAI 需要從標準化 API 走向高接觸式服務(wù)。大型企業(yè)的障礙通常不是“找不到模型”而是系統(tǒng)割裂、權(quán)限復(fù)雜、歷史數(shù)據(jù)質(zhì)量不一以及沒有人能為跨部門流程負責(zé)。前沿模型可以提高能力上限卻不能自動解決組織和集成問題。Forward deployed 模式本質(zhì)上是用高密度工程服務(wù)換取落地速度同時把客戶實踐帶回產(chǎn)品迭代。但這種模式是否能規(guī)?；孕栌^察。每家大型企業(yè)的流程和治理要求不同項目越定制交付成本越高平臺越標準化又越可能無法覆蓋關(guān)鍵例外。Presence 必須找到可復(fù)用平臺與客戶定制之間的平衡。Bain Company 的參與也與這類項目涉及流程重構(gòu)和管理決策的特征相吻合。市場空間足以支持這場競爭。按給定公開市場統(tǒng)計口徑2026 年全球 AI 客服市場約 151 億美元年復(fù)合增長率約 25.6%整個客服中心軟件市場約 778 億美元。不過不同報告的分類口徑可能不同市場規(guī)模也不等于 Presence 可直接獲得的收入。它首先要證明 Agent 能降低每次有效服務(wù)的綜合成本同時不以更高的合規(guī)風(fēng)險、接管負擔(dān)和客戶體驗波動為代價。六、對中國開發(fā)者與技術(shù)管理者的影響自建還是采購問題正在改變Presence 未必會成為中國團隊可以直接采購的默認選項但它體現(xiàn)的平臺化方向具有參考價值未來企業(yè)評估 Agent不會只問用了哪個模型還會問權(quán)限如何定義、風(fēng)險如何攔截、上線前如何測試、失敗如何接管、線上數(shù)據(jù)如何形成改進閉環(huán)。這對開發(fā)者意味著Agent 工程的價值重心正在上移。提示詞、工具調(diào)用和 RAG 仍然重要但僅完成一個可演示原型已經(jīng)不夠。真正稀缺的能力會包括策略引擎、身份與權(quán)限映射、評測數(shù)據(jù)集、可觀測性、審計、版本管理和人工工作臺。換句話說模型能力可能越來越容易采購圍繞模型建立可信運行系統(tǒng)仍需要長期工程積累。對技術(shù)管理者自建與采購可以用四個問題判斷流程是否構(gòu)成核心差異化如果 Agent 直接承載獨特業(yè)務(wù)邏輯且規(guī)則變化頻繁自建控制層更有價值標準化服務(wù)流程則更適合采購成熟平臺。數(shù)據(jù)和合規(guī)邊界是否允許托管數(shù)據(jù)駐留、跨境訪問、審計要求與行業(yè)監(jiān)管可能先于模型能力決定方案是否可行。企業(yè)是否具備持續(xù)運營團隊Agent 不是一次開發(fā)完成的軟件。沒有評測、運營和業(yè)務(wù)專家協(xié)同自建系統(tǒng)很容易停留在試點。能否承受供應(yīng)商鎖定需要評估模型、策略、對話記錄、測試集和系統(tǒng)連接器的可遷移性而不是只確認 API 是否開放。一個審慎的落地路徑可以分為三步。第一步從單一部門的高頻、低風(fēng)險任務(wù)開始建立人工基線和失敗分類第二步用真實歷史請求構(gòu)建測試集比較端到端成功率、人工接管率、P95 響應(yīng)時間和單次有效任務(wù)成本第三步再根據(jù)風(fēng)險逐級開放寫操作并為關(guān)鍵動作設(shè)置審批和回滾。中國團隊在評估國際平臺、國內(nèi)平臺或自建方案時也應(yīng)堅持同一口徑。不要拿某個平臺的演示成功率與另一方案的真實生產(chǎn)數(shù)據(jù)比較不要只看模型回答分數(shù)而忽略系統(tǒng)可用性、中文業(yè)務(wù)規(guī)則、數(shù)據(jù)合規(guī)、技術(shù)支持和長期遷移成本。Presence 最值得借鑒的不是某個品牌選擇而是把治理和評測放到項目第一天。七、總結(jié)Agent 治理才是真正的門檻OpenAI Presence 的戰(zhàn)略意義不是 OpenAI 發(fā)布了一個更大的客服機器人而是它開始交付模型之上的企業(yè)運行體系由 GPT-5.6 系列提供能力以策略和權(quán)限設(shè)定邊界用 Guardrails 進行運行時干預(yù)通過部署前模擬與自動評分建立質(zhì)量門檻再從線上不確定案例形成持續(xù)改進循環(huán)。這標志著 OpenAI 從 API 提供商向托管式企業(yè)服務(wù)提供商邁出更明確的一步也讓它與 Salesforce Agentforce、Microsoft Copilot、Zendesk AI 的競爭從模型層進入工作流和運營層。其 Forward Deployed Engineers 模式可能加快復(fù)雜項目落地但項目制交付的成本、規(guī)?；室约翱蛻魧?yīng)商依賴的接受程度仍需要真實案例驗證。對企業(yè)而言最重要的采購問題不是“Agent 能不能回答”而是“Agent 在什么條件下可以行動出錯時誰能發(fā)現(xiàn)風(fēng)險擴大前誰能阻止改動之后如何證明沒有退化”。對開發(fā)者而言長期壁壘也不會只是調(diào)用某個模型而是把權(quán)限、評測、監(jiān)控、接管和業(yè)務(wù)反饋組織成可持續(xù)的系統(tǒng)。如果說大模型決定了 Agent 能做多復(fù)雜的事那么治理決定了企業(yè)敢讓它做多少事。Presence 把后一個問題放到了平臺中心。它能否成為企業(yè) Agent 的主導(dǎo)方案尚無定論但“先治理再放權(quán)”很可能會成為這一階段更重要的產(chǎn)品原則。