System of Record 2.0：为什么真正的护城河是「决策轨迹」而不是大模型？

【摘要】Agent 时代，真正难复制的不是模型规模，而是企业自己的决策轨迹与上下文图谱。

引言

过去二十年，企业 IT 的主角是各种 System of Record（SoR，记录系统），从 Salesforce 到 SAP，再到 Workday，这些系统通过掌握关键业务数据的最终版本，把自己变成企业运转的“事实基座”。谁控制了“单一真相源”，谁就有机会构建一整套生态。

现在，AI Agent 开始接管大量具体操作，前端界面从“人点系统”变成“人说目标，Agent 调系统”。很多人开始预测传统 SoR 会被颠覆，甚至有人直接说 SoR 已死。站在架构角度看，这种判断不准确，甚至会把企业带到错误的技术路线。自动化程度越高，真正稀缺的不是模型，而是哪里存放真相，以及有没有结构化记录决策是如何发生。

大模型很重要，但它越来越像“通用算力”。对企业来说，可复制的模型永远比不可复制的数据更容易获得，可公开获取的基础模型只会越来越多，成本也会逐步下降。接下来几年，决定企业 AI 项目成败的，很可能不是“谁用的模型更大”，而是“谁先把自己的决策轨迹和上下文图谱建起来”。下面会用一个更工程化的视角，把这件事拆开讲清楚。

◆ 一、System of Record 2.0：从“人点系统”到“Agent 调系统”

1.1 SoR 的历史角色与边界

传统 SoR 的核心价值可以用一句话概括，就是**“这一类数据最终以我为准”**。这里的“准”，包含三个层面。第一，数据定义的权威性，例如收入怎么算成 ARR，客户状态怎么算“活跃”，都需要有一个统一口径，否则财务报表和业务指标永远对不上。第二，业务流程的强制性，销售不把机会录入 CRM，就拿不到佣金；财务不在 ERP 里过账，这笔收入在系统里就不存在；HR 不在系统里走完审批，请假就不算数。第三，合规与追责能力，审计、监管、内控都依赖这些系统，看是谁在什么时候做了什么修改，流程有没有按规定走完，这部分能力让 SoR 有了安全和合规上的话语权。

也可以用一个简单的对照，把 SoR 和普通业务应用区分清楚。

传统 SoR 之所以能撑起万亿市值，不是因为 UI 做得多好，而是因为掌握了“最终记账权”。一旦数据定义和最终确认权落在某个系统手里，业务流程就不得不围绕它转，粘性就会自然形成。

1.2 Agent 改变的是交互，不是“真相”的必要性

AI Agent 的引入改变了交互模式。过去的流程是，人打开系统、找到页面、输入数据、点提交；现在可以变成，人说一句“帮我处理这个续约”，然后 Agent 去查 CRM、查计费、算折扣、起草邮件，再把结果发到 Slack 请你确认。看起来，人和系统之间多了一层“智能代理”，人不再需要亲自点击每一步。

很多判断据此认为 SoR 会被边缘化。因为如果 Agent 能拿到它需要的数据，在外部把事情做完，只把结果回写一下甚至不回写，那原来那个“必须经过”的系统好像就没那么关键了。这种想法只看到交互层的变化，忽略了 Agent 自身的一个前提，就是必须知道哪些数据是可信的，且在冲突时应该以谁为准。

在真实企业里，即便是看似简单的指标，比如 ARR，也经常存在多个版本。销售有一个版本，用来算业绩。财务有一个版本，用来对外披露。法务在合同条款里可能还用的是另一个口径。人可以凭经验知道，在给董事会写报告时，要用财务口径；在写销售周报时，用的是销售口径。Agent 如果没有显式的真相源标记，会在多个数据源之间摇摆不定，最后只是在放大混乱。

所以，自动化程度越高，“真相以谁为准”越关键。SoR 不会因为 Agent 出现而消失，反过来会变成 Agent 能否安全落地的硬前提。变化在于，SoR 不再主要服务人，而是逐渐变成**“面向 Agent 的底层状态机与数据注册中心”**。

1.3 SoR 2.0 的新标准

从架构角度看，可以把传统 SoR 和 SoR 2.0 的差异，总结成几个新要求。

1. 从“人类界面优先”变为“API 优先”
   过去 SoR 做得好不好，很大程度取决于页面好不好用、审批配置好不好配。Agent 时代，UI 仍然重要，但更重要的是 API 的完整性、稳定性和语义清晰度。Agent 不会点按钮，它只会调接口。如果 SoR 的接口颗粒度混乱、含义含糊，Agent 很难可靠使用。对于 SoR 2.0 来说，对外暴露的状态机和事件语义要清晰可依赖，这会直接影响 Agent 能否安全调用。

2. 从“被动记录”变为“可被机器理解的真相注册表”
   传统 SoR 假设使用者是人，人可以在脑子里补完背景信息和含义。面向 Agent 时，需要显式表达哪些字段在哪些业务场景下才算权威。例如，同一个“ARR”字段，可能要标注“用于财务披露”的版本、“用于销售管理”的版本，并带上适用场景和优先级。SoR 2.0 需要承担起**“truth registry” 的责任**，让 Agent 能在冲突时做出一致的选择，而不再全靠 prompt 里的隐性约定。

3. 从“当前状态”走向“状态随时间的演化轨迹”
   很多 SoR 对历史状态的记录能力不够友好，特别是在跨系统场景中。Agent 要审计某次决策是否合理，需要还原当时世界的状态，而不是只看现在。SoR 2.0 要更系统地支持事件溯源、版本管理和时间查询，帮助 Agent 在需要时回答“当时是什么样”的问题，而不仅是“现在是什么样”。

4. 从“只管自己那一亩三分地”到“主动参与跨系统编排”
   SoR 2.0 不一定要自己编排流程，但需要为跨系统编排提供可靠锚点。这意味着更好的事件订阅机制、更稳定的变更通知，以及与工作流系统、Agent 平台的紧密结合。否则，Agent 要么频繁轮询导致性能问题，要么拿到的是延迟和不一致的数据。

可以用一个简单表格总结 SoR 2.0 的新标准。

SoR 2.0 的核心，不在于给页面加 LLM 助手，而在于变成 Agent 眼中可靠的状态机和真相注册表。这是后续所有“决策轨迹”和“上下文图谱”的基础。

◆ 二、企业真正缺的不是数据，而是「决策轨迹」

2.1 规则充足，决策记录稀缺

大多数中大型企业，规则、字段、流程都不缺。审计、内控、合规要求推动了大量制度和配置的沉淀。审批矩阵、风控规则、折扣策略、SLA 条款，往往都写得很细。问题出在另一侧，这些规则在一次次具体决策中是怎样被应用的，几乎没有被系统化记录。

我们平时看到的是规则层面的话语。例如“续约折扣上限是 10%”“医疗行业客户可以适当放宽付款周期”“超 10 万的折扣必须 VP 批准”。但在每一次真实交易或事件处理中，参与者几乎都在做一件事，就是在规则的灰度空间里做判断，又尽量不违背制度红线。这里面包含大量细节，包括对客户关系的判断、对历史问题的认定、对未来风险的权衡。可惜的是，这些判断大多停留在聊天记录、会议现场和个人经验里，过几周后就很难再系统复盘。

可以把这种缺失总结成一个对比。

所以问题不是数据不够多，而是**“决策轨迹” 被系统长期忽视**。这也是为什么很多企业在做 Agent 时，常常发现模型能生成合理的草案，却很难让它在关键决策上放心落地。原因不在于模型不行，而是缺乏可依赖的“决策谱系”作为参考。

2.2 决策轨迹的组成

为了让“决策轨迹”这个概念可操作，需要把它拆成若干可以落地的构件。

1. 例外
   很多流程都设计了默认路径和例外路径。例外不是随便破例，而是某些条件满足时可以进入特批逻辑。比如，客户在过去三个月遭遇多次重大服务中断，可以超出常规折扣上限。决策轨迹需要记录，每一次例外是为什么触发的，引用了哪些客观事实，过程是怎样审批的。这些信息能帮助未来在相似情景下找到有依据的参考。

2. 覆盖
   一些情况下，默认规则并不合适，需要进行覆盖。例如对战略客户采用特殊计价方式，对某些区域采用差异化 SLA。覆盖的记录需要标清用的是哪种规则版本、哪个策略集，避免后面的人无法复盘当时的逻辑。

3. 先例
   组织内部很多判断依赖“之前类似情况怎么处理过”。但这些先例大多藏在邮件、文档和人的记忆里。决策轨迹如果能把“与此前哪几次决策相似”结构化记录下来，会极大提升相似场景下的判断效率。

4. 跨系统上下文
   一次决策往往会同时参考多个系统的信息。比如在决定是否升级一个客户问题时，会查 CRM 里的客户级别和 ARR，查计费系统里的 SLA 条款，查监控系统里的事故记录，再看内部沟通工具里关于该客户的讨论。决策轨迹需要在合理粒度上记下这些上下文的关键点，不能只剩下最后那一条“已升级”状态。

5. 参与者与责任
   决策从提出到最终批准，通常有多个角色参与。是谁提出的建议，谁给出了评估意见，谁最后拍板，这些信息如果不被记录，后续追责、学习、经验传承都会非常困难。

把这些部分合起来，一条完整的决策轨迹大致会包含这几块内容。第一，触发点，包括触发源事件、相关实体和初始上下文。第二，评估过程，包括引用了哪些规则、检索了哪些历史先例、查阅了哪些系统信息。第三，例外与覆盖路径，包括走了哪个例外分支、是否覆盖了默认规则。第四，审批链路，包括哪些人或角色参与、审批结果及时间。第五，最终写回，包括对哪些 SoR 产生了哪些具体状态变更。

从工程角度看，决策轨迹不是一个巨大的日志 blob，而应该是一个结构化、可索引、可过滤的决策记录。只有这样，Agent 才能在未来的类似情境中查询和复用。

◆ 三、「上下文图谱」：决策轨迹的长期沉淀结构

3.1 从一次次决策到一张上下文图谱

当系统把每一次决策的上述要素都完整记下来，并且长期保存，就会自然形成一张上下文图谱（Context Graph）。和传统的业务图谱相比，它有几个关键区别。传统图谱往往以客户、订单、产品等业务实体为中心，记录它们之间的静态关系，比如客户与订单的关联、订单与产品的关联。上下文图谱的中心则是决策行为本身，也就是“在什么上下文下做了一次怎样的判断”。

可以用一个简化的 mermaid 图示意这种结构。

在这张图谱中，节点不仅有客户、合同和工单，还有大量“决策节点”。每个决策节点都链接着当时引用的规则版本、调用过的上下文、走过的审批链路和最终修改的 SoR 记录。随着时间推移，这张图谱会越来越密集。新决策可以指向旧决策作为先例，旧决策可以被新的规则版本标注为“已废弃”或“仅供参考”，图谱会逐渐体现出组织真实运作的轨迹。

这种上下文图谱有几个直接价值。第一，让历史先例变得可搜索、可引用、可度量。Agent 在遇到边界场景时，可以主动问“过去三次类似情况是怎么处理的”“这些处理是否带来了负面后果”。第二，为自动化系统提供可解释性和可审计性。出问题时，可以清楚看到某个自动化决策是基于哪条规则、哪几个先例、哪次审批做出的。第三，成为训练和微调企业专属模型的数据基座。这些决策轨迹比纯文本日志更有结构和语义，更适合作为监督信号和对齐基准。

3.2 上下文图谱与现有数据资产的关系

上下文图谱不会替代数据仓库、湖仓和现有 SoR，而更像是它们之上的一层“决策层事实源”。可以把企业关键数据层分成三层来理解。

1. 底层 SoR 层
   负责各类业务对象的权威记录。比如客户主数据、合同条款、账务记录、员工信息等。这一层关注“对象现在长什么样”。

2. 分析与度量层
   各种数据仓库、湖仓、指标平台处在这一层。它们汇总多个 SoR 数据，构建统一的度量和报表。关注的是“在特定维度下，数据怎么统计”。

3. 决策轨迹与上下文图谱层
   这一层关注每一次具体决策是如何发生的。它会引用 SoR 和仓库中的信息，也会产出可以回写到 SoR 的状态变更。关注的是“在特定上下文里，为什么选择了这个动作”。

用表格对比会更清晰。

上下文图谱可以直接消费 SoR 和分析层的数据，也可以通过事件总线订阅关键变更。但它的核心资产来自自己的记录，也就是那些发生在执行路径中的决策轨迹。它不是被动读库，而是主动站在流程之中，把决策及其上下文记录下来。

3.3 操作上下文与决策上下文的分层

很多讨论把上下文图谱直接与决策挂钩，中间少了一层基础设施。为了让决策轨迹这件事可落地，需要先构建一层操作上下文（Operational Context），再在其之上构建决策上下文（Decision Context）。

操作上下文解决的是“Agent 是否真正看懂了企业现实世界”这个问题，至少包括下面几块内容。

1. 身份解析
   同一个人或实体在不同系统里的 ID 往往不同。邮件里有一个发件人，Slack 里有一个账户，CRM 里有一个销售负责人字段，还有门禁系统里的员工号。如果不能把这些统一到一个“人”的实体上，Agent 就无法准确知道“谁做过什么决策，谁有审批权，谁对哪些客户负责”。身份解析需要跨系统做映射，并且持续维护。

2. 所有权与关系图谱
   哪个团队负责某个服务，哪个客户属于哪个区域，某条工单和某个项目的关联，这些信息散落在组织结构表、配置管理库、项目管理工具里。操作上下文层需要把这些关系抽取出来，形成一张实体-关系图，让 Agent 能够围绕责任人、业务域、服务边界来推理。

3. 时间状态建模
   决策永远发生在某个具体时刻。要复盘一条决策轨迹，需要知道那一刻世界的状态，而不是事后再去猜。操作上下文需要记录关键实体状态随时间的演变，例如合同条款从哪个版本切到哪个版本，服务级别在何时调整，客户等级何时发生变化。只有这样，决策上下文里引用的“当时上下文”才有可靠来源。

4. 跨系统信息汇总能力
   很多决策依赖多个系统的合并视图。操作上下文层需要提供统一 API，让 Agent 可以用较简单的查询拿到“与某客户相关的所有关键信号”，而不需要自己逐一拼装各个系统的字段。这一层更像是一个面向 Agent 的企业知识接口，让 Agent 能够在一个合理延迟范围内看到完整而一致的上下文快照。

在操作上下文之上，决策上下文才有基础。这一层主要关注三件事。第一，决策轨迹本身的结构化记录，也就是前面提到的触发点、评估过程、例外与覆盖、审批链路、最终写回。第二，先例与模式的提炼，可以把一系列高度相似的决策轨迹视为同一模式的实例，帮助 Agent 把“历史经验”转化成可引用的模板。第三，可审计与解释支持，也就是针对合规和管理诉求，提供横向和纵向的决策分析，例如“过去一年多少次违反某条规则的例外审批”“哪些审批人倾向于批准高风险例外”。

操作上下文是地基，决策上下文是建在地基上的房子。如果直接在没有身份、关系、时间建模的环境里记录“决策日志”，这些记录会变得很难查询和对齐，只能在出问题时人工一点点回溯。那样的系统难以支撑大规模 Agent 自动化。

◆ 四、为什么 RAG 与 AI Memory 解决不了这个问题

4.1 RAG 的适配边界

目前很多企业把“给 Agent 提供上下文”的主要手段，放在 RAG 检索上。RAG 在很多场景确实有价值，尤其是在长文档问答、政策解释、产品 FAQ 等场景，可以很快建立一个基于文档的问答系统。但用在“决策轨迹和上下文图谱”上时，它有几个结构性短板。

第一，RAG 的单位是文本片段，而不是实体和关系。当你问某个客户相关的问题时，RAG 通过向量检索只会找到包含客户名字的段落，却不知道这个客户在组织里的真实关系网络。它无法直接回答“哪位销售对这个客户负责”“最近哪些重大事件与这个客户有关”，这些需要显式的实体建模和关系图谱支持。

第二，RAG 没有时间轴概念。在一些简单场景可以通过文档版本弥补，但对于跨系统、多事件的复杂决策，单靠检索文本段落很难还原当时世界的状态。RAG 可以找到“曾经有人讨论过这件事”，却很难精确定位“在某次关键决策时，引用的是哪个版本的合同、哪个政策、哪些监控数据”。

第三，RAG 检索不到执行路径中的隐性判断。很多关键判断从来没有被写进任何正式文档，而是存在于聊天记录、临时会议或者电话沟通中。即便这些内容被录音或转成文本，大多也缺乏结构化标记。RAG 可以找到类似语句，却很难把它们组织成一条完整的决策路径。要构建决策轨迹，需要在执行时主动捕获结构化记录，这已经超出了 RAG 的职责。

所以，在决策轨迹和上下文图谱这个主题下，RAG 更适合作为**“补充信息源”**，而不是底座。它可以帮助 Agent 在特定节点找文档佐证，却很难成为组织级决策的唯一上下文基础。

4.2 AI Memory 平台的局限

另一类常见方案是各种 AI 记忆平台。这些系统会记录人与 AI 的对话，把一些关键信息抽取成“记忆”，用来增强后续对话的个性化程度。这类产品对个人效率提升有帮助，对团队知识共享也有一定价值。不过放在企业级决策轨迹的语境里，它也有明显缺口。

第一，记忆对象是“与 AI 的对话”，而不是组织的真实运行。很多关键决策过程根本不会发生在与 AI 的对话中，而是发生在业务系统的操作、审批流转和人际沟通中。AI Memory 捕获的是用户告诉 AI 的那一面，忽略了大量在系统之间、人在系统里发生的操作行为。

第二，缺少统一实体和关系建模。AI Memory 记住的是一条条对话或事实，而不是一张覆盖全组织的实体图谱。某个客户在不同对话、不同用户那里被提到多次，很难自动归一到同一个实体，更别说和 CRM、工单系统、监控系统里的记录对齐。这意味着它无法承载“统一的操作上下文”，最多只是一个松散的知识碎片集合。

第三，时间与版本意识不足。记忆平台可以按时间排序对话，但很难做到针对某一次决策，还原那时世界的完整状态和相关政策版本。缺乏清晰的版本和时间建模，决策轨迹容易变成事后拼接，而不是在发生时就有结构化记录。

因此，无论是 RAG 还是 AI Memory，都不能直接替代一个完整的操作上下文层和决策轨迹层。它们可以作为上层工具被利用，但如果企业把全部上下文寄托在这两类方案上，Agent 在关键决策场景中的表现很难达到“可审计、可解释、可复制”的工程标准。

◆ 五、传统 SaaS 巨头的结构性短板：不在执行路径中

5.1 运营系统的天然视角局限

CRM、ERP、工单系统这类传统运营系统，本身就不是为“记录决策轨迹”设计的。它们的设计重点在于记录和管理当前业务状态，例如当前机会处于哪个阶段，当前应收账款是多少，当前工单是开放还是已解决。这种“当前状态优先”的设计在当年合理，因为主要使用者是人，人可以根据现状和少量历史记录自行补齐决策过程。

在需要记录决策细节的地方，这些系统往往提供“备注”“评论”“活动记录”等字段。这些字段通常是纯文本，缺乏结构化约束，也缺少跨系统、跨实体的统一关联。时间长了，记录变成“信息垃圾场”，谁也不愿意回头翻看。这类文本很难被系统化利用，更无法成为 Agent 可依赖的决策谱系。

另外，每个运营系统只看得到自己负责的那一段现实。CRM 对客户关系清楚，ERP 对财务状态清楚，监控系统对技术状态清楚，工单系统对问题处理进度清楚。单个系统几乎没有跨出自身边界的能力，不知道其它系统在同一时间点发生了什么，更不知道一次跨系统决策的全貌。

5.2 分析系统的“事后世界”视角

数据仓库和湖仓的引入，在横向打通数据层面做了大量工作。它们可以把 CRM、ERP、工单系统、监控日志拉进一个统一平台，构建一致的维度和指标，让管理层能够做跨系统分析和报表。但这类系统有一个共同特点，就是几乎都处在运营世界的下游。

数据进入仓库时，通常已经错过了“决策发生的那一刻”。仓库能告诉你，在某一天之后，某个字段的值是某个数字，却很难精确地告诉你，在特定决策当时，所有相关系统处于什么状态，哪些状态变更是由那次决策引起的，哪些是独立发生的变化。这种事后视角适合做统计分析，但不适合做细粒度的决策审计和先例复用。

即便在仓库里构建了决策主题模型，如果底层没有在执行路径中捕获结构化的决策轨迹，很多东西依然需要依赖字符串匹配和启发式推断。这样得到的“决策路径”更多是事后重构，不够稳固。

5.3 编排层的结构性优势

要完整捕获一条决策轨迹，系统必须出现在决策发生的执行路径中，也就是处在跨系统编排层，而不是仅仅接收事后的数据。对 Agent 来说，这个编排层通常就是 Agent 自身或 Agent 平台中的工作流引擎。

当 Agent 执行一个跨系统任务时，会经历一系列步骤。第一，从多个 SoR 和上下文系统中拉取必要信息，比如客户数据、合同条款、历史工单、监控告警。第二，根据政策和历史先例，构建一个或多个备选方案。第三，在必要时发起审批流程，引入人类参与。第四，根据最终决策写回多个系统，更新状态。这一整套链路，如果在编排系统里有完整的执行图和状态，就能自然成为结构化决策轨迹的来源。

可以看到，编排层天然掌握“全景视角”。它知道一次决策涉及哪些系统、引用了哪些上下文、触发了哪些分支、哪一步由人拍板、哪一步由模型自动通过。反观传统运营系统和数据仓库，要么只看其中一段，要么只在事后看到结果。差别类似“录像机”和“回忆录”，前者可以按时间轴完整重放，后者只能事后整理片段。

这也是为什么系统型 Agent 创业公司有机会在这一轮架构变迁中占据重要位置。只要它们站在跨系统执行路径的中枢，就有能力把决策轨迹和上下文一次性捕获下来，并长期沉淀为图谱。传统巨头也会尝试补齐这块能力，有的会通过并购，有的会通过扩展自身产品线。但它们要想在所有跨系统场景里成为编排中心，既有商业和政治阻力，也有技术上的历史包袱。

◆ 六、系统型 Agent 创业公司的三条路径

6.1 路径一：重写 SoR，构建 Agent-native 记录系统

第一条路是最直接也最激进的，就是从一开始就把传统 SoR 重写成 Agent-native 的记录系统。在这种设计里，事件溯源、状态机建模、政策与决策捕获都是系统原生能力。系统既服务人，也服务 Agent，Agent 不再是外挂层的自动化脚本，而是和人一样的一等操作主体。

这条路径的优势很明显。第一，可以在架构层面彻底摆脱旧系统遗留的技术债。例如可以原生支持事件流、时间版本查询、决策轨迹记录，不需要在旧系统上做复杂补丁。第二，有机会拿到“新一代 SoR” 的标准制定权。如果有足够多企业迁移过去，这个平台会自然而然承接起下一轮生态的位置。

代价也很明显。第一，需要正面对抗现有巨头，进入它们占据多年的核心领地，销售周期长，替换风险高。第二，需要在功能和生态成熟度上达到一个阈值企业才会真正迁移，这对早期公司要求很高。从技术视角看，这条路径适合那些已经在某个业务域积累很深，并且有明确机会窗口，把旧范式替换掉的团队。

6.2 路径二：占领例外密集的关键模块

第二条路更务实一些，是不替换整个 SoR，而是替换其中例外密集、决策复杂的模块。这些模块往往是规则失效最频繁、人力投入最多的环节，例如交易审批、合同例外处理、高价值客户升级、复杂对账与关账等。

在这条路径里，新的系统会做两件事。第一，在该模块内成为决策的 System of Record，也就是所有例外和审批都必须经过这里，系统完整记录触发上下文、评估过程、审批链条和结果。第二，把最终经过决策后的结果，同步回既有的 SoR，例如把最终批准的价格写回 CRM，把最终对账结果写回 ERP。

这种架构下，原有 SoR 仍然保持“总账本”角色，只不过某条关键领域的“记账逻辑”被迁移到了新系统。新系统成为这个模块范围内的“真相源”，特别是在解释“为什么这个结果合理”时，只有它有完整信息。对于企业而言，这种方案的迁移成本更可控，因为不涉及全系统替换，而是从单点突破开始。

6.3 路径三：在编排层创建新的决策 SoR

第三条路是很多系统型 Agent 公司正在走的路径，就是从编排层起步，逐步演化成“决策事实源”。在这种模式下，公司先为某个跨系统工作流提供 Agent 或自动化解决方案，例如自动化 L2/L3 支持、自动处理客户升级、自动处理部分财务对账。随着系统承担的决策越来越多，它会顺手把这些决策的轨迹全部结构化记录下来。

时间一长，这个平台就会积累一张大量覆盖跨系统行为的上下文图谱，变成企业里唯一能回答“当初为什么这么决定”的系统。哪怕原有 SoR 没有被替换，它们在解释“为什么”这件事上也要依赖这张图谱。这样，系统从“自动化工具”慢慢升级成“决策的 System of Record”，在事实层面成为新的权威。

这条路径的优势在于，不需要一开始就说服企业替换核心系统，而是从“帮你干活”开始切入。缺点是需要有耐心和长期愿景，愿意在早期就为决策轨迹的结构化投入工程精力，否则容易变成另一个黑箱自动化平台，错失长期护城河。

◆ 七、「上下文图谱 + 决策轨迹」为何是下一代万亿美元级基础设施候选

7.1 To C 革命在界面层，To B 深水在事实层

消费者侧，AI 革命的主战场是界面层。输入法、手机助手、浏览器插件不断刷新交互方式，减少人和应用之间的摩擦。消费者的数据相对简单，决策后果的合规压力也小，一些“模糊但便利”的能力可以被接受。

企业侧，情况完全不同。业务决策牵涉合同、财务、合规和品牌风险，任何自动化都会面临更高的可靠性要求。这里的关键不再是“交互多顺滑”，而是自动化行为是否在正确的事实基础上发生，且是否可以审计和解释。所以 To B 的深水区不可能只停留在“给每个软件加一个 AI 助理”，而一定会落到记录系统和事实层。

在这种环境下，真正难以复制和迁移的护城河，不在于谁接了更多工具 API，也不在于谁选了哪个大模型，而在于谁掌握了企业级的操作上下文，谁积累了可查询、可审计、可复用的决策图谱。模型可以换，工具 API 可以重接，但几年的决策轨迹和上下文沉淀，一旦绑定到某个平台上，切换成本就会非常大。

7.2 IT 战略与业务战略的重新对齐点

这一轮变革会强行把 IT 战略与业务战略拉到同一张桌子上。过去谈“记录系统”，更多是 CIO 的议题，业务方关心的是功能好不好用、报表够不够看。Agent 时代，“记录什么”和“为什么记录”本身就是业务战略问题，因为它直接决定了未来哪些决策可以自动化，哪些风险能被控制。

企业在规划 AI 战略时，至少需要同时回答几个问题。第一，哪些关键流程可以接受部分自动化或半自动化，而且必须有可审计的决策轨迹。第二，在这些流程里，哪些数据源是权威的，哪些只是参考，这种区分是否在系统里有清晰表达。第三，组织是否愿意为构建操作上下文和决策上下文投入长期建设，而不是只做几个月的 Demo。

从架构角度看，上下文图谱与决策轨迹层正在成为新的“企业事实层”。上一代事实层记录“发生了什么”，下一代事实层记录“为什么这样发生”。谁能尽早在这层完成布局，不只是多部署了几个 Agent，而是为整个组织建立了一条新型的“神经系统”。

结论

System of Record 不会被 Agent 杀死，而是在被重新定义。它从面向人类的表单和界面，演进为面向 Agent 的状态机和真相注册表。自动化程度越高，“真相以谁为准”越重要，这一点在企业环境里不会被改变。真正被彻底暴露出来的缺口，不是规则和字段，而是决策轨迹。组织里大量“为什么这样决策”的关键信息一直散落在聊天、会议和个人经验中，几乎从未被当作一等数据资产来治理，这让 Agent 在边界场景中缺乏可靠的依托。

要弥补这一缺口，需要先搭好操作上下文的地基，把身份、实体、关系和时间状态统一建模，再在其上构建决策上下文，系统化记录每一次决策的触发、评估、例外和审批。随着这些轨迹长期沉淀为一张上下文图谱，企业会第一次拥有一套真正能回答“当初为什么这么做”的系统，而不仅是“当时做了什么”。传统 SaaS 巨头难以独立完成这件事，是因为它们大多不在执行路径之中，只能看到某一段现实或事后数据。处在跨系统编排层的 Agent 平台和系统型 Agent 公司则天然具有结构性优势，可以在决策发生时抓住全貌，而不是事后拼图。

无论选择重写 SoR，还是占领关键模块，或者在编排层创建新的决策事实源，目标都不只是在旧流程上加一层智能，而是在组织里建立起一套可靠的“决策谱系”。在这套谱系之上，大模型只是一个更强的执行器和推理器，其价值会随着上下文图谱的丰富程度而成倍放大。下一代万亿美元级平台，很可能诞生在这一层，而不是某个单一模型或单一应用里。对每一家希望认真落地 AI 的企业来说，现在开始把“决策轨迹 + 上下文图谱”当作战略级建设，而不是战术级功能，是一个需要尽快完成的认知调整。

📢💻 【省心锐评】

真正决定 AI 项目成败的，不是模型跑得多快，而是企业是否有勇气把自己的决策过程结构化并长期保存。