智能體的下半場：由編排競賽到本體圖記憶
過去兩日，OpenAI 將智能體編排做成公共 API，Salesforce 讓智能體追逐跨週目標，Iyuno CLOE 就揭示咗更深一層：令理解持續複利嘅唔係更大嘅上下文窗口，而係一張隨任務不斷生長嘅持久本體圖。
過去 48 小時，智能體賽道最值得留意嘅唔係又一個更勁嘅模型，而係一次靜靜雞發生嘅焦點轉移：決定長時程智能體成敗嘅，正由「點樣編排」轉向「記乜嘢、記幾耐」。 OpenAI 將編排能力做成公共 API，Salesforce 首次讓智能體以「週」為單位追逐目標，而全球最大媒體本地化公司 Iyuno 公開嘅 CLOE 架構，就將第三塊拼圖擺上咗枱面——一張持續生長嘅持久本體圖。本文拆解呢三則信號，並回答一個對企業更實際嘅問題：你嘅數據智能體，需要一張點樣嘅本體圖。
48 小時入面嘅三則信號
據 AI Agent Store 9 月 13 日嘅每日簡報同行業媒體匯總，過去兩日密集出現咗三則互相印證嘅消息：
第一，OpenAI 將「編排」降維成基礎設施。 OpenAI 嘅 Agents API 進入公測，託管編排、長時程會話同上下文管理一步到位，沙箱算力可以嚟自 OpenAI、客戶自建或者 Vercel、DigitalOcean 等合作夥伴；驅動 ChatGPT Work 嘅規模化智能體基礎設施都同步開放為公共 API，按需拉起一個智能體嘅準備時間唔使一分鐘。即係話，編排本身正在快速商品化——淨係靠「我識編排多智能體」已經築唔成護城河。
第二，Salesforce 將智能體嘅時間尺度拉長到「週」。 Salesforce 一次過發布咗 Casey、Paige、Marshall 等七個具名 Agentforce 智能體，當中外呼銷售智能體 Hunter 首次採用全新嘅 long-horizon runtime——智能體追逐嘅目標唔再係一次會話入面嘅問題，而係跨越幾個禮拜嘅業務流程。多智能體編排（Multi-Agent Orchestration）都同步 GA。
第三，Iyuno 公開 CLOE 嘅 Contextual Memory 架構，畀出咗第三個答案。 呢間全球最大嘅媒體本地化公司詳細拆解咗其商業套件（CLOE Enterprise、CLOE Sub、CLOE Script、CLOE Dub、CLOE Live）正在生產環境運行嘅多智能體工程，核心係一句反共識嘅判斷：對專業領域嚟講，更大嘅模型同更多嘅算力買唔返真正重要嘅嘢。
長時程智能體嘅成本悖論
將三則消息擺埋一齊睇，會發現佢哋指向同一個矛盾：智能體嘅任務時間尺度喺拉長，而上下文窗口嘅經濟學撐唔住呢個尺度。
主流做法係讓一個大模型「包打天下」：將原始數據、歷史對話、工具輸出全部塞入上下文窗口。呢招喺單輪問答冇問題，但一旦任務跨越幾日、幾個禮拜，問題即刻浮面——每一輪推理都要重新讀晒全部歷史，token 消耗隨任務時長線性甚至指數增長；而窗口再大都有邊界，早期嘅理解畀截斷之後，智能體就會「失憶」，同一個錯誤重複犯。
Iyuno 創辦人兼 CEO David Lee 喺公布架構時嘅講法相當直接：對媒體呢類專業領域，規模買唔返真正重要嘅嘢——敘事連續性（narrative continuity）。佢哋揀嘅路係讓專業化智能體工作喺「精確、高密度嘅上下文」上面，其運行足跡「唔會隨內容目錄規模增長」——處理嘅每一部作品都令張圖更勁，而唔係令成本更貴。
CLOE 三原則：一份值得抄嘅功課
CLOE 嘅 Contextual Memory 建立喺三條原則上面，每一條都值得企業數據團隊對照自查：
- 垂直多智能體編排（Vertical Multi-Agent Orchestration）。唔用一個單體模型包打天下，而係一組超專業化嘅微型智能體各司其職——角色關係映射、情感意圖、韻律匹配、品牌合規各自獨立，再由上層編排協同。
- 高密度、低 token 提示（High-Density, Low-Token Prompting）。原始影片、音訊同劇本會先合成為結構化知識圖譜，智能體喺壓縮後嘅高信號上下文向量上面工作，而唔係直接吞原始素材，單部作品嘅 token 消耗同推理成本因此大幅下降。
- 持久圖記憶（Persistent Graph Memory）。呢條係最關鍵：智能體嘅輸出唔再隨任務結束畀人丟棄，而係匯聚入一張持久嘅本體圖（ontology graph）——理解喺作品、季、系列之間持續複利，而推理成本唔會跟住複利。
第三條值得單獨展開。「記憶」呢個詞喺智能體領域畀人用到爛：會話歷史係記憶，向量庫檢索都係記憶。但佢哋有一個共同缺陷——存嘅係「片段」，唔係「結構」。本體圖嘅差異在於：智能體每完成一次任務，產出嘅唔係一條日誌，而係帶實體、關係、語義嘅圖節點，可以畀後續所有任務直接重用。理解係複利嘅，成本唔係。
企業數據智能體需要一張點樣嘅本體圖
將 CLOE 嘅經驗映射到企業數據場景，結論高度一致。事實上，「本體驅動」正正係 OntiCards 由第一日就選定嘅路線：數據卡片作為智能體嘅數據字典、地圖同導航，記錄嘅係「數據喺邊、點樣讀、乜嘢意思、同邊個有關」嘅結構化語義，而唔係業務流水本身；各領域專家智能體基於卡片自主取數，執行結果再沉澱返入本體，畀下一個任務直接調用。
兩種路線嘅差異，用一張表睇得更清楚：
| 維度 | 單體大模型 + 上下文堆積 | 本體圖記憶 + 專業化智能體 |
|---|---|---|
| 上下文來源 | 每輪重讀晒全部歷史 | 只讀高密度結構化語義 |
| 任務之間嘅理解 | 任務結束即丟棄 | 沉澱入本體圖，跨任務重用 |
| 成本曲線 | 隨任務時長／數據量增長 | 唔隨目錄規模複利增長 |
| 錯誤復現 | 失憶後重複犯 | 同類問題一次糾正、全域生效 |
| 可審計性 | 淹沒喺對話流入面 | 圖節點天然可溯源 |
需要提提大家，本體圖唔係買一個「知識圖譜工具」就可以自動攞到。佢需要持續嘅治理：術語口徑統一、關係校準、質素監控——呢個亦係點解我哋之前討論語義層與數據智能體同真實企業庫問數嘅架構真相嗰陣反覆強調，語義基礎設施嘅維護係長跑，唔係一次性交付。同理，智能體運行邊界嘅管控（我哋喺智能體隔離與審計一文詳細討論過）都必須同記憶沉澱機制配套，否則複利嘅就唔止係理解，仲有風險。
畀企業嘅三條落地建議
結合本週信號，畀正在規劃數據智能體嘅團隊三條具體建議：
第一，將「編排」當作商品嚟採購，將「記憶」當作資產嚟建設。 OpenAI Agents API 嘅公測意味住編排、沙箱、會話管理會越嚟越平、越嚟越標準。真正拉開差距嘅，係你嘅智能體每跑完一個任務，留下嘅結構化理解可唔可以畀下一個任務重用。
第二，評估智能體方案嗰陣，加一條「記憶去咗邊」嘅硬指標。 問清楚：任務結束之後，中間產出嘅實體、關係、結論存喺邊？用乜嘢結構存？下一個任務點樣查？如果答案係「對話歷史」或者「向量庫」，就要對長時程場景嘅成本同一致性保持警覺。
第三，由一張細圖開始，但第一日就用本體建模。 唔使等「全域數字孿生」先至啟動。揀一個高頻業務域（例如電商嘅訂單同庫存），將數據卡片同本體關係建起嚟，讓專家智能體喺真實任務入面持續寫返——張圖會自己長大。呢個亦係 OntiCards 喺製造業、能源等行業嘅落地方式：以本體建模為內核，讓理解隨使用不斷複利。想睇呢套架構點樣適配你嘅業務，歡迎聯絡 hello@onticards.com 交流。
