在硅谷，圍繞一個(gè)問(wèn)題的爭(zhēng)論正在升溫：

AI，尤其是 Agent，會(huì)不會(huì)取代 SaaS？

最早給出明確判斷的是SaaS 領(lǐng)域的知名專欄作者 Jamin Ball。

在《Long Live Systems of Record》一文中，他直言不諱地反對(duì)“Agent 會(huì)殺死一切舊系統(tǒng)”的說(shuō)法。

在Ball 看來(lái)，Agent 越強(qiáng)大，對(duì)底層數(shù)據(jù)準(zhǔn)確性的要求就越高。因此，作為數(shù)據(jù)“看門人”的傳統(tǒng)記錄系統(tǒng)（Systems of Record），其壁壘非但沒(méi)有消失，反而因掌握了解釋權(quán)而變得更昂貴。

但Foundation Capital 的合伙人 Jaya Gupta 認(rèn)為，Ball 只看到了硬幣的一面。

她在最新文章《人工智能的萬(wàn)億美元機(jī)遇：上下文圖譜》中指出，傳統(tǒng)系統(tǒng)的盲區(qū)不在于“數(shù)據(jù)”，而在于“上下文”匱乏。

企業(yè)真實(shí)的運(yùn)行邏輯，往往不記錄在CRM 的標(biāo)準(zhǔn)化表格里，而是藏在例外的特批、臨時(shí)的調(diào)整、跨部門的 Slack 溝通中。

Gupta 將這些隱性的過(guò)程定義為「決策軌跡」。

當(dāng)這些決策軌跡被持續(xù)記錄，并在時(shí)間和業(yè)務(wù)對(duì)象之間連接起來(lái)，就會(huì)形成一種新的結(jié)構(gòu)——上下文圖譜。

這不僅是數(shù)據(jù)的堆砌，更是對(duì)企業(yè)“推理過(guò)程”的復(fù)刻。下一個(gè)萬(wàn)億級(jí)平臺(tái)的機(jī)會(huì)，不是給舊系統(tǒng)裝上AI，而在于誰(shuí)能抓住這些“數(shù)據(jù)”與“行動(dòng)”之間的灰色地帶。這才是AI創(chuàng)業(yè)公司需要抓住的真正機(jī)會(huì)。

今天，我們就來(lái)拆解這個(gè)超級(jí)賽道的核心邏輯。

上下文圖譜：AI 時(shí)代企業(yè)最值錢的“第二資產(chǎn)”

上一代企業(yè)軟件通過(guò)成為“記錄系統(tǒng)”（Systems of Record, SoR），創(chuàng)造了一個(gè)萬(wàn)億級(jí)的生態(tài)系統(tǒng)。Salesforce 管理客戶數(shù)據(jù)，Workday 管理員工數(shù)據(jù)，SAP 管理運(yùn)營(yíng)數(shù)據(jù)。

它們的邏輯是：掌握權(quán)威數(shù)據(jù)，掌控工作流，從而實(shí)現(xiàn)客戶鎖定。

現(xiàn)在的爭(zhēng)論焦點(diǎn)在于：在向Agent（人工智能體）轉(zhuǎn)型的過(guò)程中，這些舊系統(tǒng)還能存活嗎？

Jamin Ball 最近的文章《記錄系統(tǒng)萬(wàn)歲》（Long Live Systems of Record）觸動(dòng)了很多人的神經(jīng)。

他反駁了“Agent 將殺死一切”的論調(diào)，認(rèn)為 Agent 不會(huì)取代記錄系統(tǒng)，反而會(huì)提高對(duì)一個(gè)優(yōu)秀記錄系統(tǒng)的要求標(biāo)準(zhǔn)。

這個(gè)觀點(diǎn)是對(duì)的。Agent 是跨系統(tǒng)的，且以行動(dòng)為導(dǎo)向。工作的用戶體驗(yàn)（UX）正在與底層的數(shù)據(jù)層分離。Agent 變成了交互界面，但底層仍然需要某種權(quán)威的東西來(lái)支撐。

但需要補(bǔ)充的是，Ball 的觀點(diǎn)假設(shè) Agent 所需的數(shù)據(jù)已經(jīng)存在于某個(gè)地方，Agent 只需要更好的訪問(wèn)權(quán)限、更好的治理、語(yǔ)義契約以及明確的規(guī)則。

這只是一半的圖景。另一半是目前缺失的、真正驅(qū)動(dòng)企業(yè)運(yùn)行的那一層：決策軌跡（Decision Traces）。

這些決策軌跡包括例外情況、覆蓋操作、此前案例以及跨系統(tǒng)的上下文。目前，它們散落在Slack 的討論串里、交易審批臺(tái)（Deal Desk）的對(duì)話中、升級(jí)電話會(huì)議里，以及人們的大腦中。

這就引出了一個(gè)至關(guān)重要的區(qū)別：

規(guī)則（Rules）告訴 Agent 一般情況下應(yīng)該發(fā)生什么（例如：“使用官方 ARR 數(shù)據(jù)進(jìn)行報(bào)告”）。

決策軌跡（Decision Traces）記錄了具體案例中發(fā)生了什么（例如：“我們使用了 X 定義，依據(jù) v3.2 政策，經(jīng) VP 特批，基于 Z 先例，且我們做了如下修改……”）。

Agent 不僅僅需要規(guī)則，更需要訪問(wèn)決策軌跡，以了解過(guò)去規(guī)則是如何被執(zhí)行的、在哪里獲得了例外豁免、沖突是如何解決的、誰(shuí)批準(zhǔn)了什么，以及實(shí)際上是哪些先例在主導(dǎo)現(xiàn)實(shí)。

這就是“Agent 系統(tǒng)”類初創(chuàng)公司擁有結(jié)構(gòu)性優(yōu)勢(shì)的地方。

它們處于執(zhí)行路徑上。在決策發(fā)生的當(dāng)下，它們能看到全貌：從各個(gè)系統(tǒng)中收集了哪些輸入、評(píng)估了什么政策、調(diào)用了什么例外路徑、誰(shuí)進(jìn)行了批準(zhǔn)、寫(xiě)入了什么狀態(tài)。

如果你將這些軌跡持久化保存下來(lái)，你就得到了大多數(shù)企業(yè)今天所不具備的東西：一份關(guān)于決策是如何做出的、可查詢的記錄。

我們將這些軌跡積累形成的結(jié)構(gòu)稱為上下文圖譜（Context Graph）：它不是“模型的思維鏈（Chain-of-Thought）”，而是一份鮮活的記錄，將決策軌跡跨越實(shí)體和時(shí)間串聯(lián)起來(lái)，使“先例”變得可搜索。

隨著時(shí)間的推移，這個(gè)上下文圖譜將成為自動(dòng)化真正的事實(shí)來(lái)源（Source of Truth）——因?yàn)樗粌H解釋了發(fā)生了什么，還解釋了它為什么會(huì)發(fā)生。

核心問(wèn)題不在于現(xiàn)有的記錄系統(tǒng)是否會(huì)存活。而在于是否會(huì)涌現(xiàn)出全新的系統(tǒng)，不僅僅是對(duì)象的記錄系統(tǒng)，而是決策的記錄系統(tǒng)，以及這些系統(tǒng)是否會(huì)成為下一個(gè)萬(wàn)億級(jí)平臺(tái)。

記錄系統(tǒng)沒(méi)能捕捉到的東西

當(dāng)Agent 正在被部署到真實(shí)的工作流中，比如合同審查、報(bào)價(jià)到現(xiàn)金（Quote-to-Cash）、客服解決方案，團(tuán)隊(duì)往往會(huì)率先撞上一堵“墻”。

這堵墻不是缺數(shù)據(jù)，而是缺決策軌跡。Agent 遇到了人類每天都要用判斷力和組織記憶來(lái)解決的模糊性問(wèn)題。但這些判斷的輸入信息并沒(méi)有作為持久的資產(chǎn)被存儲(chǔ)下來(lái)。具體來(lái)說(shuō)：

1.存在于人們腦中的例外邏輯?！拔覀兛偸墙o醫(yī)療保健公司額外 10% 的折扣，因?yàn)樗麄兊牟少?gòu)周期太殘酷了?！边@句話不在 CRM（客戶關(guān)系管理系統(tǒng)）里。它是通過(guò)入職培訓(xùn)和私下交談傳遞的“部落知識(shí)”（Tribal Knowledge）。

2.過(guò)去決策的先例?！吧蟼€(gè)季度我們?yōu)?X 公司設(shè)計(jì)了類似的交易結(jié)構(gòu)——我們應(yīng)該保持一致。”沒(méi)有系統(tǒng)將這兩筆交易聯(lián)系起來(lái)，也沒(méi)有記錄為什么要選擇這種結(jié)構(gòu)。

3.跨系統(tǒng)的綜合判斷?？头鞴茉赟alesforce 中查看客戶的 ARR（年度經(jīng)常性收入），在 Zendesk 中看到兩個(gè)未解決的升級(jí)投訴，讀到一條標(biāo)記流失風(fēng)險(xiǎn)的 Slack 消息，然后決定升級(jí)處理。這種綜合判斷發(fā)生在他的腦子里。而工單上只寫(xiě)著：“已升級(jí)至 Tier 3”。

4. 系統(tǒng)之外的審批鏈。一位 VP 在 Zoom 通話或 Slack 私信中批準(zhǔn)了折扣。機(jī)會(huì)記錄（Opportunity Record）只顯示最終價(jià)格，不顯示是誰(shuí)批準(zhǔn)了偏差，也不顯示原因。

這就是“從未被捕捉”的含義。這并不是說(shuō)數(shù)據(jù)是臟的或孤立的，而是說(shuō)連接數(shù)據(jù)與行動(dòng)的推理過(guò)程，從未被當(dāng)作數(shù)據(jù)來(lái)對(duì)待。

把“決策現(xiàn)場(chǎng)”永久保存下來(lái)

當(dāng)初創(chuàng)公司在Agent 編排層（Orchestration Layer）進(jìn)行部署，讓每次運(yùn)行都生成決策軌跡時(shí)，他們就得到了企業(yè)幾乎從未有過(guò)的東西：

一段結(jié)構(gòu)化的、可回放的歷史，記錄了上下文是如何轉(zhuǎn)化為行動(dòng)的。

這在實(shí)踐中是什么樣子的？

一個(gè)續(xù)約Agent 提議給予 20% 的折扣。公司政策規(guī)定續(xù)約折扣上限為 10%，除非批準(zhǔn)了“服務(wù)影響例外”。

Agent 從 PagerDuty（運(yùn)維監(jiān)控）拉取了三個(gè) SEV-1 級(jí)事故，從 Zendesk 拉取了一個(gè)未解決的“不修復(fù)就解約”的升級(jí)投訴，并調(diào)取了上季度一位 VP 批準(zhǔn)類似例外的續(xù)約溝通記錄。

它將特殊申請(qǐng)?zhí)峤唤o財(cái)務(wù)部門，財(cái)務(wù)批準(zhǔn)。最終，CRM 中只留下了一個(gè)結(jié)果：“20%折扣”。

一旦你有了決策記錄，“為什么”就變成了頭等數(shù)據(jù)。

隨著時(shí)間推移，這些記錄自然形成了一個(gè)上下文圖譜：企業(yè)已有的實(shí)體（賬戶、續(xù)約、工單、事故、政策、審批人、Agent 運(yùn)行記錄）通過(guò)決策事件（關(guān)鍵時(shí)刻）和“為什么”的鏈接連接在一起。

公司現(xiàn)在可以審計(jì)和調(diào)試自動(dòng)化的過(guò)程，并將例外情況轉(zhuǎn)化為案例，而不是每個(gè)季度都在 Slack 里重新學(xué)習(xí)一遍相同的邊緣案例。

反饋循環(huán)是讓其產(chǎn)生復(fù)利效應(yīng)的關(guān)鍵。捕捉到的決策軌跡變成了可搜索的先例。每一個(gè)自動(dòng)化的決策又向圖譜中添加了一條新的軌跡。

這一切都不需要從第一天起就實(shí)現(xiàn)完全自動(dòng)化。它從“人機(jī)協(xié)同”（Human-in-the-loop）開(kāi)始：

Agent 提議、收集上下文、路由審批并記錄軌跡。隨著時(shí)間的推移，當(dāng)類似的案例重復(fù)出現(xiàn)，越來(lái)越多的路徑可以被自動(dòng)化，因?yàn)橄到y(tǒng)擁有一個(gè)結(jié)構(gòu)化的過(guò)往決策和例外庫(kù)。

即使仍由人類做決定，圖譜也在不斷生長(zhǎng)，因?yàn)楣ぷ髁鲗訉⑤斎?、審批和理由捕捉為持久的先例，而不是讓它消散在Slack 中。

/ 04 /

為什么現(xiàn)有巨頭建不了上下文圖譜

Ball 樂(lè)觀地認(rèn)為，現(xiàn)有的玩家會(huì)進(jìn)化成這種架構(gòu)。按照這個(gè)劇本，現(xiàn)有的巨頭們只需要在龐大的數(shù)據(jù)資產(chǎn)上外掛一個(gè)AI 大腦，就能平滑過(guò)渡到下一個(gè)時(shí)代。

Salesforce、ServiceNow 和 Workday也相信這一點(diǎn)，他們都在兜售同一個(gè)故事：“我們擁有數(shù)據(jù)，現(xiàn)在我們加上智能?！?/p>

但這個(gè)邏輯有一個(gè)硬傷：它們的底層架構(gòu)是為“當(dāng)前狀態(tài)”（Current State）設(shè)計(jì)的。

以Salesforce 為例，它本質(zhì)上是一個(gè)巨大的、復(fù)雜的分類賬本。它精準(zhǔn)地知道一個(gè)銷售線索現(xiàn)在長(zhǎng)什么樣，但它無(wú)法回溯決策發(fā)生那一刻世界長(zhǎng)什么樣。

比如，當(dāng)一個(gè)20% 的違規(guī)折扣被批準(zhǔn)時(shí)，Salesforce 記錄的是“折扣已批準(zhǔn)”。

但那個(gè)證明折扣合理性的上下文，比如PagerDuty 剛剛報(bào)警顯示服務(wù)宕機(jī)、Zendesk 里客戶正在咆哮、Slack 群里VP的臨時(shí)授權(quán)。在寫(xiě)入 Salesforce 的那一刻，全部丟失了。

無(wú)法回放決策時(shí)的世界狀態(tài)，就意味著無(wú)法審計(jì)決策，更無(wú)法將其轉(zhuǎn)化為AI 可學(xué)習(xí)的“先例”。

一個(gè)客服問(wèn)題的升級(jí)，往往取決于CRM 里的客戶等級(jí)、計(jì)費(fèi)系統(tǒng)里的 SLA 條款，甚至 Slack 里的流言蜚語(yǔ)。沒(méi)有一個(gè)現(xiàn)有的 SaaS 巨頭能看到全貌，因?yàn)樗鼈兊囊曇皟H限于自己的圍墻之內(nèi)。

既然應(yīng)用層不行，那么處于底層的Snowflake 和 Databricks 呢？它們同樣被寄予厚望，被視為AI Agent 的基石。

確實(shí)，數(shù)倉(cāng)擁有基于時(shí)間的快照，看起來(lái)像是擁有了“上帝視角”。但問(wèn)題在于，它們處于數(shù)據(jù)的“讀路徑”（Read Path），而非“寫(xiě)路徑”（Write Path）。

數(shù)據(jù)進(jìn)入數(shù)倉(cāng)，通常是在決策發(fā)生之后，經(jīng)過(guò)漫長(zhǎng)的ETL（提取、轉(zhuǎn)換、加載）管道搬運(yùn)而來(lái)。這就像是正在發(fā)生激戰(zhàn)的前線，數(shù)倉(cāng)只是那個(gè)戰(zhàn)后打掃戰(zhàn)場(chǎng)的記錄員。

當(dāng)數(shù)據(jù)最終落地Snowflake 時(shí)，那個(gè)充滿博弈、權(quán)衡和突發(fā)狀況的“決策上下文”已經(jīng)蒸發(fā)殆盡。也就是說(shuō)，它還是只能告訴你發(fā)生了什么，但不能告訴你為什么。

Databricks 雖然在拼命整合碎片，但“存儲(chǔ)數(shù)據(jù)的地方”和“決策發(fā)生的執(zhí)行路徑”之間，依然隔著一道無(wú)法逾越的鴻溝。

與這些大公司相比，Agent 系統(tǒng)類初創(chuàng)公司擁有結(jié)構(gòu)性優(yōu)勢(shì)：它們處于“編排路徑”上。

當(dāng)一個(gè)Agent 正在分流工單、響應(yīng)事故或?qū)徟鷪?bào)價(jià)時(shí)，它不僅僅是在調(diào)用工具，也在執(zhí)行工作流。

它處于風(fēng)暴的中心，從多個(gè)系統(tǒng)拉取信息，評(píng)估規(guī)則，解決沖突，然后行動(dòng)。

因?yàn)樯硖帯皥?zhí)行路徑”，它擁有了巨頭們無(wú)法觸及的特權(quán)：在“提交時(shí)刻”（Commit Time），將所有的輸入、邏輯、例外和原因，完整地“凍結(jié)”下來(lái)。

這就是上下文圖譜，也是AI 時(shí)代公司最有價(jià)值的單一資產(chǎn)。

當(dāng)然，現(xiàn)有巨頭也會(huì)反擊。他們會(huì)嘗試通過(guò)收購(gòu)來(lái)通過(guò)“打補(bǔ)丁”的方式增加編排能力。他們會(huì)鎖定 API 并采用數(shù)據(jù)流出費(fèi)用（Egress fees）來(lái)讓數(shù)據(jù)提取變得昂貴。

這與超大規(guī)模云廠商使用的劇本相同。他們會(huì)建立自己的Agent 框架，并推行“把一切都留在我們的生態(tài)系統(tǒng)中”的敘事。

但是，捕捉?jīng)Q策軌跡需要在提交時(shí)刻（Commit Time）處于執(zhí)行路徑中，而不是事后強(qiáng)加治理。巨頭可以讓數(shù)據(jù)提取變得更難，但他們無(wú)法將自己插入到一個(gè)他們從未參與過(guò)的編排層中。

/ 05 /

初創(chuàng)公司的三條路徑

Agent 系統(tǒng)類初創(chuàng)公司將采取不同的路徑，每條路徑都有自己的權(quán)衡。

1.從第一天起就取代現(xiàn)有的記錄系統(tǒng)。

圍繞Agent 執(zhí)行重構(gòu) CRM 或 ERP，將“事件源狀態(tài)”（Event-sourced state）和“政策捕捉”作為架構(gòu)的原生功能。這很難，因?yàn)榫揞^根深蒂固，但在技術(shù)代際更迭的轉(zhuǎn)折點(diǎn)，這并非不可能實(shí)現(xiàn)。

在眾多追逐AI SDR（銷售開(kāi)發(fā)代表）類別的初創(chuàng)公司中，Regie選擇了構(gòu)建一個(gè) AI 原生的銷售參與平臺(tái)，以取代像 Outreach/Salesloft 這樣的傳統(tǒng)平臺(tái)（后者是為人類在碎片化工具鏈中執(zhí)行序列而設(shè)計(jì)的）。

Regie 專為混合團(tuán)隊(duì)設(shè)計(jì)，其中 Agent 是一等公民：它可以挖掘潛在客戶、生成外聯(lián)、跟進(jìn)、處理路由并升級(jí)給人類。

2. 取代模塊而不是整個(gè)系統(tǒng)。

這些初創(chuàng)公司針對(duì)特殊情況和審批集中的特定子工作流，成為這些決策的記錄系統(tǒng)，同時(shí)將最終狀態(tài)同步回現(xiàn)有巨頭系統(tǒng)。

Maximor 在財(cái)務(wù)領(lǐng)域就在踐行這一邏輯。它自動(dòng)化了現(xiàn)金流、結(jié)賬管理和核心會(huì)計(jì)工作流，卻保留了 ERP 作為底層總賬（GL）的地位。

換句話說(shuō)，ERP 依然是那個(gè)記賬的“賬本”，但 Maximor 成為了掌握對(duì)賬邏輯的“大腦”。

3. 創(chuàng)建全新的記錄系統(tǒng)。

這些公司從編排層起步，捕捉了企業(yè)從未系統(tǒng)化存儲(chǔ)過(guò)的東西——決策痕跡。隨著時(shí)間推移，這種可回放的關(guān)系數(shù)據(jù)變成了一種新的權(quán)威資產(chǎn)。

此時(shí)，Agent 不再僅僅是自動(dòng)化工具，而是成為了企業(yè)回答“我們?yōu)槭裁催@樣做”的檔案室。

PlayerZero 是這種模式的典范。生產(chǎn)工程（Production Engineering）長(zhǎng)期處于 SRE、QA 和開(kāi)發(fā)的交匯點(diǎn)，這是一個(gè)典型的“膠水職能”，依靠人類的經(jīng)驗(yàn)來(lái)承載軟件無(wú)法捕捉的上下文。

PlayerZero 建立了一個(gè)關(guān)于代碼、配置和客戶行為交互的“上下文圖譜”。當(dāng)生產(chǎn)環(huán)境出問(wèn)題時(shí)，它能回答“為什么會(huì)壞”以及“這個(gè)變更會(huì)帶來(lái)什么后果”——這是任何現(xiàn)有系統(tǒng)都無(wú)法回答的問(wèn)題。

而在這些路徑之上，一個(gè)新的基礎(chǔ)設(shè)施正在形成：Agent 的可觀測(cè)性（Observability）。

隨著決策軌跡的堆疊，企業(yè)需要像監(jiān)控代碼一樣監(jiān)控Agent 的行為。

Arize 正試圖成為這一新堆棧中的 Datadog。它讓團(tuán)隊(duì)能夠看到 Agent 如何推理、在哪里失敗，并評(píng)估其決策質(zhì)量。在自主決策的時(shí)代，這不僅僅是工具，更是安全感。

/ 06 /

創(chuàng)業(yè)者的兩個(gè)關(guān)鍵信號(hào)

對(duì)于創(chuàng)業(yè)者而言，應(yīng)該在哪里落子？市場(chǎng)釋放的信號(hào)雖然重疊，但指向了不同的機(jī)會(huì)。

首先是兩個(gè)通用的信號(hào)：高人力投入與高意外率。

第一，高人力投入。如果一家公司還在用50 個(gè)人手動(dòng)路由工單或核對(duì)數(shù)據(jù)，這就是最直接的信號(hào)。大量勞動(dòng)力的存在，恰恰證明了決策邏輯太復(fù)雜，傳統(tǒng)工具做不到自動(dòng)化。

第二，需要處理大量的“意外”情況。那些充滿“視情況而定”的交易審批、合規(guī)審查環(huán)節(jié)，因?yàn)檫壿嫃?fù)雜且先例重要，也是 Agent 建立決策血緣的最佳土壤。

而另一個(gè)信號(hào)，則專門指向了“新記錄系統(tǒng)”的誕生：系統(tǒng)交匯處的“膠水職能”。

RevOps（收入運(yùn)營(yíng)）的存在，是因?yàn)闆](méi)有人能同時(shí)搞定銷售、財(cái)務(wù)和市場(chǎng)系統(tǒng)；DevOps 的存在，是因?yàn)殚_(kāi)發(fā)和運(yùn)維之間有深溝；安全運(yùn)營(yíng)（SecOps）則卡在 IT 和合規(guī)之間。

這些角色的出現(xiàn)，本身就是對(duì)現(xiàn)有軟件生態(tài)的一種諷刺——因?yàn)闆](méi)有單一的記錄系統(tǒng)能擁有跨職能的視野，組織只能創(chuàng)造一個(gè)人類角色來(lái)充當(dāng)“人肉中間件”，承載那些軟件無(wú)法捕捉的上下文。

一個(gè)自動(dòng)化該角色的Agent，其價(jià)值不僅僅是效率，而是它通過(guò)持久化保存決策、例外和先例，將這種隱形的“膠水”實(shí)體化了。這不是在拆除現(xiàn)有的巨頭，而是在捕捉一種只有當(dāng) Agent 介入工作流時(shí)才會(huì)顯現(xiàn)的真理。

回到最初的問(wèn)題：記錄系統(tǒng)會(huì)存活嗎？

當(dāng)然會(huì)。Salesforce 和 SAP 不會(huì)消失。

但真正的問(wèn)題是，下一個(gè)萬(wàn)億級(jí)的平臺(tái)會(huì)是什么？它是通過(guò)簡(jiǎn)單地給現(xiàn)有冷冰冰的數(shù)據(jù)添加AI 補(bǔ)丁構(gòu)建的？還是通過(guò)捕捉那些讓數(shù)據(jù)具有行動(dòng)力（Actionable）的決策軌跡而構(gòu)建的？

我們賭注押在后者。而今天那些正在構(gòu)建“上下文圖譜”的初創(chuàng)公司，正在為這個(gè)新時(shí)代打下地基。

PS：如果你對(duì)AI大模型領(lǐng)域有獨(dú)特的看法，歡迎掃碼加入我們的大模型交流群。