← 返回博客技术实践

智能体的下半场:从编排竞赛到本体图记忆

过去两天,OpenAI 把智能体编排做成公共 API,Salesforce 让智能体追逐跨周目标,Iyuno CLOE 则揭示了更深一层:让理解持续复利的不是更大的上下文窗口,而是一张随任务不断生长的持久本体图。

OntiCards 团队·2026-09-14·8 分钟阅读
智能体的下半场:从编排竞赛到本体图记忆

过去 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)正在生产环境运行的多智能体工程,核心是一句反共识的判断:对专业领域而言,更大的模型和更多的算力买不来真正重要的东西。

Iyuno CLOE 多智能体架构三原则示意图
Iyuno CLOE 多智能体架构三原则示意图

长时程智能体的成本悖论

把三则消息放在一起看,会发现它们指向同一个矛盾:智能体的任务时间尺度在拉长,而上下文窗口的经济学撑不住这个尺度。

主流做法是让一个大模型"包打天下":把原始数据、历史对话、工具输出全部塞进上下文窗口。这在单轮问答里没问题,但一旦任务跨越数天、数周,问题立刻暴露——每一轮推理都要重新读取全部历史,token 消耗随任务时长线性甚至指数增长;而窗口再大也有边界,早期的理解被截断后,智能体就会"失忆",同一个错误反复犯。

Iyuno 创始人兼 CEO David Lee 在公布架构时的表述相当直白:对媒体这样的专业领域,规模买不来真正重要的东西——叙事连续性(narrative continuity)。他们选择的路是让专业化智能体工作在"精确、高密度的上下文"上,其运行足迹"不随内容目录规模增长"——处理的每一部作品都让图更强,而不是让成本更贵。

一次性丢弃输出与持久本体图记忆的对比
一次性丢弃输出与持久本体图记忆的对比

CLOE 三原则:一份值得抄的作业

CLOE 的 Contextual Memory 建立在三原则上,每一条都值得企业数据团队对照自查:

  1. 垂直多智能体编排(Vertical Multi-Agent Orchestration)。不用一个单体模型包打天下,而是一组超专业化的微型智能体各司其职——角色关系映射、情感意图、韵律匹配、品牌合规各自独立,再由上层编排协同。
  1. 高密度、低 token 提示(High-Density, Low-Token Prompting)。原始视频、音频和剧本先被合成为结构化知识图谱,智能体在压缩后的高信号上下文向量上工作,而不是直接吞原始素材,单部作品的 token 消耗和推理成本因此大幅下降。
  1. 持久图记忆(Persistent Graph Memory)。这是最关键的一条:智能体的输出不再随任务结束被丢弃,而是汇聚进一张持久的本体图(ontology graph)——理解在作品、季、系列之间持续复利,而推理成本不会随之复利。

第三条值得单独展开。"记忆"这个词在智能体领域被用滥了:会话历史是记忆,向量库检索也是记忆。但它们有一个共同缺陷——存的是"片段",不是"结构"。本体图的差异在于:智能体每完成一次任务,产出的不是一条日志,而是带实体、关系、语义的图节点,能被后续所有任务直接复用。理解是复利的,成本不是。

企业数据智能体需要一张什么样的本体图

把 CLOE 的经验映射到企业数据场景,结论高度一致。事实上,"本体驱动"正是 OntiCards 从第一天就选定的路线:数据卡片作为智能体的数据字典、地图和导航,记录的是"数据在哪、怎么读、什么意思、和谁有关"的结构化语义,而不是业务流水本身;各领域专家智能体基于卡片自主取数,执行结果再沉淀回本体,供下一个任务直接调用。

OntiCards 本体驱动的数据智能体架构:数据卡片 + 专家智能体 + 记忆沉淀
OntiCards 本体驱动的数据智能体架构:数据卡片 + 专家智能体 + 记忆沉淀

两种路线的差异,用一张表看得更清楚:

维度单体大模型 + 上下文堆积本体图记忆 + 专业化智能体
上下文来源每轮重读全部历史只读高密度结构化语义
任务间隔的理解任务结束即丢弃沉淀进本体图,跨任务复用
成本曲线随任务时长/数据量增长不随目录规模复利增长
错误复现失忆后反复犯同类问题一次纠正、全局生效
可审计性淹没在对话流里图节点天然可溯源

需要提醒的是,本体图不是买一个"知识图谱工具"就能自动获得的。它需要持续的治理:术语口径统一、关系校准、质量监控——这也是为什么我们在之前讨论语义层与数据智能体真实企业库问数的架构真相时反复强调,语义基础设施的维护是长跑,不是一次性交付。同理,智能体运行边界的管控(我们在智能体隔离与审计一文中详细讨论过)也必须与记忆沉淀机制配套,否则复利的就不只是理解,还有风险。

企业本体图记忆的三步落地路线
企业本体图记忆的三步落地路线

给企业的三条落地建议

结合本周信号,给正在规划数据智能体的团队三条具体建议:

第一,把"编排"当作商品来采购,把"记忆"当作资产来建设。 OpenAI Agents API 的公测意味着编排、沙箱、会话管理会越来越便宜、越来越标准。真正拉开差距的,是你的智能体每跑完一个任务,留下的结构化理解能不能被下一个任务复用。

第二,评估智能体方案时,加一条"记忆去哪了"的硬指标。 问清楚:任务结束后,中间产出的实体、关系、结论存在哪里?以什么结构存?下一个任务怎么查?如果答案是"对话历史"或"向量库",就要对长时程场景的成本和一致性保持警惕。

第三,从一张小图开始,但第一天就用本体建模。 不必等"全域数字孪生"才启动。选一个高频业务域(比如电商的订单与库存),把数据卡片和本体关系建起来,让专家智能体在真实任务中持续写回——图会自己长大。这也是 OntiCards 在制造业、能源等行业的落地方式:以本体建模为内核,让理解随使用不断复利。想看这套架构如何适配你的业务,欢迎联系 hello@onticards.com 交流。

参考来源

技术实践

对 OntiCards 感兴趣?