最近有一个关于“AI’s trillion-dollar opportunity: Context graphs”的讨论很热，值得深入学习。
过去一两年业界对Systems of Record(SoR) 的趋势出现了一些分歧，个人认为2026应该会有一个初步的结论。
a16z的看法倾向于颠覆式：“In 2026, the system of record will finally start to lose primacy. The traditional system of record slips into the background as a commodity persistence tier—its strategic leverage ceded to whoever controls the intelligent execution environment.”
BVP 的看法则倾向于演进式：“AI-native systems of record can now offer a 10X more compelling value proposition, putting entire business processes like procurement, cash flow forecasting, and sales operations on autopilot.”
一边认为传统SoR 会失去控制点，另一边说认为演进后的AI-Native SoR可以提供"10 倍价值主张"。
谁对呢？搞明白“什么是"新一代 SoR？”这个核心问题后会发现，两边都对。
“Systems of Record weren’t designed to capture decisions — they were designed to store the outcomes of decisions.”
— Ashu Garg, Foundation Capital
传统 SoR 记录"发生了什么"，新一代 SoR 记录"为什么这样决定"。不是 Agent 替代 SoR，而是 Agent 将成为新的 SoR。
过去四十年，Enterprise Software的控制点经历了三次转移：
本地部署时代（1970s-1990s），控制点在 Systems of Record（Oracle、SAP），用于记录业务数据
云计算与 SaaS 时代（2000s-2010s），转移到 Systems of Engagement（Salesforce、Workday），用于协调工作流与用户交互
大模型时代（2023-），正在转移到 Systems of Action——AI Agent 不再只是"记录"或"协调"，而是自主执行决策。每次转移都重新定义企业软件的价值捕获点，诞生新的万亿美元市场。
这次的核心变化是：记录的对象从"业务数据"变成"决策轨迹"，软件的用户从"人类"变成"Agent"。谁能在决策发生的那一刻捕获完整Context，谁就成为新一代 SoR。
What: AI Agent 成为新一代 SoR
要理解 Agent 如何成为新 SoR，先要理解旧 SoR 的价值主张——以及为什么这个价值主张正在失效。
Source: Chinenye Nwaneri, “System of Record, System of Reference, Golden Records, and other confusing terms in Master Data Management”, Medium, 2019
SoR 的原始价值主张：数据垄断创造Lock-in
过去二十年，企业软件通过成为Systems of Record创造了万亿美元生态。SoR 的核心逻辑简单而强大：
谁控制了业务数据的唯一真相源（Single Source of Truth），谁就控制了工作流，进而控制了客户。
Salesforce 就是个教科书案例。它记录每个销售机会、客户互动、合同条款、跟进历史。销售流程必须经过它——查询客户、更新机会、生成报价，都依赖 Salesforce 数据。如果企业已经有了数十年客户历史数据、数千条定制字段、几百个集成，换系统意味着重建整个销售运营。这就是数据垄断的Lock-in。
Workday 记录员工，SAP 记录运营，ServiceNow 记录 IT 服务。每个都在各自领域建立了数据垄断。在纸质时代，这些信息散落在文件柜、Excel、个人记忆里。SoR 把它们集中、结构化、可查询——这是千亿市值公司的基础。
旧范式的两大盲点
但这一代的SoR 有两个致命缺陷，在今天的环境下变得越来越明显。
内容盲点：只记录"发生了什么"，不知道"为什么"。传统 SoR 是看比分牌（如12-11），数据仓库是看赛后统计，AI Agent 的 Context则是坐在教练席。所在位置决定了能看到什么。
形态盲点：为人类设计，不适应 AI Agent。传统 SaaS记录的是：人类登录 UI、按席位付费、产品边界清晰。AI Agent则是：直接调用 API、跨系统整合、按结果定价、替代人类角色。
双重盲点的后果
如果 AI Agent 成为主要用户，则UI 变得无关紧要，单系统边界变成劣势，席位定价崩溃。比如，一个 Agent 替代 5 个人，却只能收一个Seat的钱？
人工为主，Agent为辅的Copilot 模式注定只是个过渡。当 Agent 准确率超过 90%，人类审批从"价值增值"变成"流程瓶颈"。经济利益自然会推动 Autopilot：未来的企业不会仅为了"保留人类审批权"而放弃 10 倍效率提升。当然，这是我的个人“暴论”。
Why: 为什么这个转变不可避免
传统 SoR 无法适应决策密集型场景，不是功能问题，是结构性缺陷。
为什么是现在？
三个环境变化让这个转变不可避免。
组织为碎片化付出隐性成本。企业使用10+ SaaS 工具，但每个都有自己的数据孤岛。
决策复杂度爆炸。每个决策需要整合 10+ 系统的数据，传统 SoR 只记录自己系统内的结果，最有价值的决策逻辑永久丢失。
决策频率爆炸。如果从"每月一次定价审批"到"每天 100 个动态决策"时，单靠人工无法保持一致性和完整记录。
这三个变化趋势的交汇，创造了一个新需求：不只记录"发生了什么"，还要记录"为什么这样决定"。
传统 SoR 的根本问题：只见结果，不见过程
想像这样一个场景：
销售 VP 批准了 20% 的续约折扣，超出公司政策上限。三个月后 CFO 问：“为什么？”
CRM 只记录：折扣 20%，时间，批准人。不记录：客户三个月遇三次严重故障、正考虑取消、这个折扣与上季度先例一致、决策综合了 CRM+Zendesk+PagerDuty+Slack等业务系统的完整 context。
所以，传统 SoR更像快照相机——只捕捉画面，决策故事线全丢了。决策逻辑从未被当作数据，每次组织都在重新学习。
显然，这完全不符合当下的AI时代期望：为什么这次告诉AI怎么做了，下一次它还是做不对呢？
技术原因：只记录 State，不记录 Event
每个系统都有两个时钟：
状态时钟（State Clock）记录"现在是什么"——CRM 的最终成交价、配置文件的当前参数。
事件时钟（Event Clock）记录"为什么变成这样"——谈判过程、推理链条、架构决策背后的两场辩论。
我们为状态时钟过去这些年建了数万亿的基础设施，比如关系数据库、数据仓库等，但事件时钟几乎不存在。原因？状态很容易——覆盖写数据库；事件很难——必须追加，必须捕获推理，而推理和决策过程本身则未被当作数据。即使有些想存推理和决策过程，但很多关键的决策逻辑只在人的脑子里。
为什么单靠数据仓库不够？ 大多数数据仓库只存 state，不存 event trace。它告诉你"客户 A 本季度 ARR 是 ，但不知道为什么从800K 降到 $500K、关键对话在哪、故障的完整 context。
更关键的是：数据仓库通过 ETL，在决策发生后才接收数据——Slack 讨论、实时系统状态、备选方案已经永久丢失。这就是为什么 Snowflake 能做预测分析，但比较难做决策自动化。
数据仓库只回答 “what is”，而Context Graph期望还能回答 “why it became”。Context Graph 的多维索引（按时间、按实体、按上下文）让 Agent 能检索"类似故障怎么处理的"，这是二维表做不到的。
Logs vs. Traces
Trajectory logs 记录"Agent 做了什么"——时间戳、API 调用、返回值。序列数据，按时间排序，存在 append-only 日志里。Decision traces 记录"为什么这样做"——考虑了哪些选项，为什么选 A 不选 B，依赖哪些 context，与哪个先例一致。图结构，节点是决策点，边是因果依赖。
关系数据库重建决策链需要 JOIN 多张表。Context Graph 可能需要一次图遍历，因为决策天然是条件依赖的 DAG——“如果客户 LTV>$1M 且有 P0 事故，允许超政策折扣”。强行塞进二维表，WHERE 子句爆炸。
当人是推理层时这没问题，因为组织的"事件时钟"分布在员工大脑里。但现在要 AI 做决策，怎么给Agent事件时钟就是个问题了。
Context Graph 的本质就是为组织建立事件时钟。
How：如何构建下一代 SoR
3.1 How to Build — 技术实现路径
构建 Context Graph 的核心挑战：如果观察不到全部系统，就无法预定义组织本体论，因为一切都在变化。传统KG是静态的，决策轨迹必须动态捕获。
真实的决策过程：需跨系统的 Join
传统数据库的 join 靠稳定的键：customer_id = order.customer_id。一对一映射，确定性查询。
决策推理需要五种不同的 join。
场景：生产事故调查。你需要连接：
配置改动（时间维度）：“上周二谁把 timeout 从 5s 改成 30s？”
事件序列（事件维度）：“部署→警报→回滚，哪个先？”
业务含义（语义维度）：“这是性能优化还是紧急修复？”
决策归属（归属维度）：“谁批准的？走的哪条例外路径？”
实际影响（因果维度）：“这个改动导致客户投诉增加 20%？”
五种 join，五种类型：时间是线性的，事件是序列的，语义在向量空间，归属是图，因果是 DAG。关系数据库的 WHERE 子句只能处理简单的比较和匹配。但"这个ticket的语义和那个note相关"不是相等，是向量相似度。"这个部署导致那个事故"不是外键，是因果推理。
为什么传统方案不够？
Graph database 和 vector store 存储 state，但 Context Graph 必须捕获 event clock，如决策如何展开、状态如何传播、实体如何交互）。积累足够结构后，Context Graph 成为 world model——不只回答"过去类似情况？“还能模拟"如果这样做会怎样？”
比如，PlayerZero 的 code simulation 可以在 production system 的 world model 上推演假设变更，预测结果。要做到这样，就需要从足够多生产问题轨迹中学到的模式。
Learned Ontology：从轨迹中涌现的结构
Palantir 5000亿美元市值是建立在 prescribed ontology 上：工程师预先定义实体、关系、规则，系统强制执行。这在结构稳定的领域有效——会计准则、监管合规、供应链管理。
Prescribed ontology 的前提：你能提前知道组织如何运作。
但最有价值的决策模式是隐性的：哪些上下文真正影响审批？哪些先例可以泛化？哪些例外路径常被调用？这些不是 CRM 字段或政策文档，是从实际决策中归纳的规律。无法预先定义，只能从决策中学习。
Context Graph 是 learned ontology 的基础设施。 传统 SoR 让工程师预定义字段，比如"紧急程度有三种选项”，Agent 从决策中学到的Ontology完全不同，比如"紧急程度 = SLA 到期时间 × 客户 LTV“。Prescribed ontology 是设计的，learned ontology 是学习的。
Agent 轨迹提供学习信号。 当 agent 解决问题时，它隐式执行所有五种 join - 时间排序、事件关联、语义理解、归属遍历、因果追踪。从这个视角看，轨迹是成功 join 的样本。 如果积累足够轨迹，系统就可以学会如何在五种坐标系统之间建立映射。
下一个类似Palantir的5000亿美金公司将建立在 learned ontology 上。组织的决策逻辑比数据结构更复杂、更有价值、更难复制。
Context Graph 的三层架构
Context Graph 不是单一数据结构，而是三层架构：Content 层存储原始交互（Slack 消息、会议记录、ticket等），Entities 层维护结构化实体（客户、事故、部署），Facts 层记录带时间有效性的决策事实（validAt/invalidAt）。
传统知识图谱的 Facts 是永恒真理（“客户 A 属于行业 B”），但组织决策的 Facts 有生命周期——“客户 A 的优先级是 P0"在签约时为真，流失后失效。temporal validity 让 Agent 理解"当时为什么那样决定"而非只知道"现在是什么”。
如何学习结构
传统 embedding 是语义的（相似含义→相近向量），但组织推理需要结构化表征——不是"概念意思相似"，而可能是"哪些实体实际是在扮演着相似角色"、“哪些事件在决策链中共同出现”。具体技术上，随机游走的共现统计能编码结构，不需要预先理解图结构。
在这个层级架构里，Local walks 学习 homophily（直接相连的相似性）,global walks 学习 structural equivalence（角色相似但不直连）。两个从不交互的高级工程师，homophily 看不出相似，但结构上等价——相同角色在不同子图，相似决策模式，相似升级路径。
Agent 不是 random walker，是 informed walker——通过实际工作（调查事故、完成任务等）遍历组织状态空间。轨迹是问题导向的，会适应发现的内容：调查生产事故时，先全局探索（最近所有系统的变更？结构等价领域），证据积累后收窄到具体服务、部署历史、请求路径（局部探索，同质性领域）。
Random walks 通过暴力覆盖发现结构，informed walks 通过问题导向覆盖发现结构——Agent 去问题引导的地方，问题揭示什么真正重要。
值得特别指出的是：Agent 在尝试解决值得付费的问题，Context Graph 是过程中的副产品。更好 context→更强 Agent→更多部署→更多轨迹→更好 context，形成一个企业的关键决策数据飞轮。
真正有效的Agent 需要在生产环境大规模运行。不是为了"测试"，是为了积累规模化的训练信号——每个成功的决策轨迹都在教系统如何 join。但实际落地的痛点，经常是技术团队和业务团队因为“先有鸡，还是先有蛋”的问题达不成共识。
为什么现在才可行？LLM 推理能力的快速提升，Inference 成本指数级下降，Agent基础设施工程成熟度达到生产级，这几方面的技术突破在2026让Context Graph可行。
How to Win — 商业战略路径
技术能力是必要条件，但从技术到商业胜利的关键是战略位置——在决策发生的那一刻捕获完整上下文。System of Agents 创业公司不是都在做同一件事，有三条路径，风险-回报权衡完全不同。
路径选择框架：
路径 1：完全替换 SoR
Regie 瞄准的是 Sales Engagement 市场——价值 90 亿美元，代表公司是 Outreach 和 Salesloft。
传统 Sales Engagement 平台帮销售管理外联、跟进、多渠道触达。但这些工具为人类设计。SDR 每天手动配置序列、A/B 测试消息、逐个点击发送。AI SDR 出现后，这些成了瓶颈。Agent 不需要漂亮的 UI，需要 API。不需要人工审批每个决策，需要政策引擎。
Regie（“The AI Sales Engagement Platform for modern GTM”）的策略不是给 Outreach 加个 AI 功能，而是重建整个平台。AI Agent 是一等公民——自主寻找潜客、生成外联、处理回复、决定何时升级到人类。每个外联决策都被记录下来。为什么选这个潜客？为什么用这个消息？为什么这个时间发？Context Graph 随每次互动增强。
商业模式也不同。不按席位收费，按"AI SDR 容量"收费——处理多少潜客。客户可以直接算账：雇 5-10 个初级 SDR 的成本 vs 买 Regie 的成本。成本降 70%，ROI 清晰。Outreach 和 Salesloft 还困在旧架构和席位定价里。
这个策略在新兴类别最可行——AI SDR、AI 客服。这些类别还没有深度锁定，客户愿意尝试新工具。成熟类别像核心 ERP 就难多了，迁移成本太高。
路径 2：替换部分 SoR 模块
Maximor 瞄准的是财务关账——CFO 们每个月的噩梦。
每月月底，财务团队开始关账。从 ERP、银行、支付网关提取数据，手动对账每笔交易，调查差异，调整分录。整个流程 5-15 天，错误率高。每次审计季，审计师都会问一堆问题——“这笔差异是什么？”“为什么调整这个分录？”"依据是什么？"财务团队翻遍 Excel、邮件、Slack 找证据。
完全替换 ERP？迁移成本太高，没人敢动。给 ERP 加 AI？ERP 供应商不在对账的执行路径上，动力不足。
Maximor 的定位是"Audit-Ready Agentic Automation for the Strategic CFO"。他们的策略很聪明——模块化切入。ERP 还是总账的 SoR，Maximor 只做对账逻辑。Agent 自动提取所有来源的数据、执行对账规则、标记例外、结果写回 ERP。人只处理真正的例外情况。Context Graph 记录每个对账决策——“这笔差异是银行延迟”、“上月遇到类似的 Stripe 退款模式”。
商业模式也很直接。不替换 ERP 许可，只按处理的交易数或节省的时间收费。价值主张清晰——关账周期从 10 天降到 2 天，错误率降 80%，审计师满意因为有完整轨迹。
这个策略在明确痛点工作流最有效——对账、合规检查、例外审批。不需要说服客户"换系统"，只需要说服他们"让 AI 处理最痛苦的那部分"。
路径 3：创建全新类别 SoR
定位为”AI Support and QA agents“的PlayerZero AI， 瞄准的是生产事故响应——每个软件公司都头疼的问题。
周五晚上 10 点，网站崩了。客户投诉涌入。工程师要快速找到答案。什么坏了？监控工具 Datadog 显示 API 延迟飙升。什么时候开始的？日志系统 Splunk 显示 9:45 开始报错。谁改了什么？Git 显示下午 3 点有个部署。为什么会炸？Slack 里工程师在争论，没结论。上次类似问题怎么修的？没人记得，要翻 Jira 工单。
这些信息散落在 5+ 个系统。每次出事故，工程师都在重新拼图——从监控找症状、从日志找错误、从 Git 找改动、从 Slack 找讨论、从 Jira 找历史。没有一个系统知道完整的故事。
传统 SoR 各管一块。监控看到 API 慢了，不知道为什么。日志有原始报错，看不出因果。工单系统知道有人报了 bug，不知道根因。APM 工具看到性能瓶颈，不知道是代码、配置还是基础设施。
PlayerZero 把这些个系统的信息自动连接起来，形成生产知识图谱，创造出一个全新类别的SoR。
起点是自动化技术支持——agent 接收警报、自动诊断、推荐修复方案。真正的资产是从每次事故中学习。“部署 XYZ 后，API 延迟增 3x”（因果关系）、“代码改动影响基础设施，进而影响用户体验”（跨系统连接）、“上次这样修的，这次也这样”（决策历史）。
商业模式分三阶段。第一阶段按自动化的工单收费，替代人工客服。第二阶段按生产知识访问收费，工程师查询"类似问题怎么解决的"。第三阶段成为生产决策的 SoR，回答"这个改动安全吗？会影响哪些用户？"
现有工具做不到，因为都是局部视角。监控看症状、日志看报错、APM 看性能、工单看投诉。PlayerZero 在事故响应的执行路径中，构建了跨系统的完整视角。
What’s Next: 三个关键预测
预测 1：编排层独立化
数据库从应用分离用了 30 年（1970-2000）。编排层从 SoR 供应商分离会快得多——驱动力不是技术先进性，是价值使然。
企业平均使用 10+ SoR，每个都想推自己的 agent 平台。Salesforce 的 agent 只懂 Salesforce 数据，ServiceNow 的 agent 只懂 ServiceNow 工单。真实工作流跨越所有系统——一个采购审批要查 ERP 预算、Salesforce 合同、Slack 讨论、财务系统余额。
中立编排平台的价值主张：对所有系统一视同仁，创新速度不受 SoR 发布周期拖累。Workato、Temporal 已在 2025 验证模式。2026-2027 会看到企业级采用——不是全面替换，是从"跨系统痛点工作流"切入。
封闭生态会输。Salesforce Agent 只在 Salesforce 数据上最优，其他系统永远是二等公民。企业不会为每个 SoR 各养一套 agent 基础设施。中立平台 + observability 工具（Arize、LangSmith）会吃掉这层价值。
预测 2：Context Graph 质量成护城河
LLM 正在快速商品化——GPT-5.2、Claude Opus 4.5、Gemini 3 性能趋同，开源 Llama 4/Qwen 2.5 逼近闭源。但 Context Graph 质量无法商品化，这是 System of Agents 公司的唯一防线。
更好上下文 > 更大模型。用 GPT-5 + 优质 Context Graph 能击败 GPT-5.2 Pro + 通用知识。原因很简单，GPT-5.2 不知道你企业 2026 年的新定价政策，Context Graph 知道就够了。
推理时分工：
固定模型（GPT-5.2）：提供推理能力，如因果推理、模式识别等
动态世界模型（Context Graph）：提供当前事实，如最新 50 个定价决策、Q1 预算季的审批模式、P0 事故的处理先例等
资深员工与新员工的差异不在"认知模型"，更在于"组织世界模型"。见过足够多情况后，能推演：“周五部署会让 on-call的人周末过的很糟糕”。这不需要查记录，是基于经验的模拟。Context Graph 把"组织经验"变成可查询、可推理、可继承的资产。
但这一切需要时间。Context Graph 的价值密度与数据量非线性相关，初期积累几乎无用，因为太稀疏，看不出模式。一旦跨过临界质量后，就会形成可泛化的决策模式。
预测 3：决策层成新价值捕获点
企业软件栈将增加第四层：用户意图 → 决策层（← 新价值捕获点）→ 编排层 → 数据层。
传统三层的价值在数据层，谁控制数据谁控制客户。但数据层正在商品化，GDPR/CCPA 强制可移植、API 标准化、云仓库让复制变容易。逻辑层也在解耦，如无代码/低代码、agent 编排平台。
决策层无法商品化：
Context Graph 独特（每个组织的决策拓扑不同）
需时间积累（无法通过收购快速获得）
有网络效应（更多决策轨迹 → 更好模式识别 → 更多部署 → 更多轨迹）
Lock-in 的本质变了：从数据垄断到轨迹垄断。
20 年前，Salesforce 说"我有你的客户数据，你走不了"。但 GDPR 让数据可移植，API 让迁移成为可能，数据垄断的锁定在削弱。
20 年后，System of Agents 说"我有你的决策历史，丢了就是组织失忆"。这是更强的锁定。
一旦数据可以导出，决策轨迹脱离 Context Graph 就没用。就像神经网络的权重脱离模型架构是无意义的数字，决策事件脱离 Context Graph 是无法理解的日志。隐含在 Context Graph 的关联结构中，与特定系统的推理引擎、先例检索、因果链条耦合。
未来企业选 System of Agents 供应商时，最关心的问题会从"能做什么功能"变成"切换时组织记忆能否迁移"。当客户主动要求"决策数据可移植性方案"时，说明决策层的锁定效应已被广泛认知。
控制决策记忆 = 控制组织。下一代 的Salesforce 将在决策层诞生，Lock-in会比数据时代深 10 倍。
巨头的"创新者窘境"
巨头面临三个无解的结构性问题。
架构不兼容
Salesforce 的核心是 sync + request-response：用户点击按钮，查询数据库，返回结果，渲染页面。整个技术栈为此优化——stateless API、短连接、事务一致性。
Agent 需要 async + event-driven：监听多个系统的事件流，维持长期上下文，异步决策，回写多个目标。需要消息队列、状态机、最终一致性。
数据层冲突更深。传统数据库只存状态快照——客户 A 的折扣是 20%，覆盖写，旧值丢失。Agent 需要决策轨迹——"为什么批准 20%？考虑了哪些因素？与哪个先例一致？"这需要 append-only 事件日志、图结构索引、时间旅行查询。
不是加个功能的问题，是重写整个 logging、storage、query 层。Salesforce 有 25 年的技术债——数千张表、几百万行存储过程、向后兼容承诺。改 logging 系统会波及所有模块。
收购也救不了。创业公司进来后，发现无法接入现有系统的事件流（因为根本不存在），只能包一层 adapter。80% 时间处理"如何不破坏现有客户"，agentic 架构妥协到面目全非。Salesforce 2016 年收购的 AI 公司 MetaMind 和 PredictionIO，今天在产品里几乎看不到痕迹。
商业模式冲突
假设Salesforce Sales Cloud 按席位收费，月人。一个销售团队人，年费90K。
如果一个 AI SDR agent 替代 5 个初级 SDR，席位从 50 降到 10。年费从 降到18K，营收砍 80%。
这不是"新产品蚕食旧产品"，iPhone 替代 iPod，但Apple还是赚钱。这是新商业模式摧毁旧商业模式的经济基础。
Salesforce 有两个选项，都是死路：
选项 A：保持独立。Agent 产品独立运营，不整合进 Sales Cloud。结果：自己的 $30B ARR 被 cannibalize。销售团队的 KPI 是保护现有客户，会全力阻止迁移。
选项 B：整合进来。把 Agent 功能整合进 Sales Cloud，按"AI 容量"加价。结果：席位收费客户不会付两份钱，只能降价或免费送。边际成本（LLM API 调用）上升，客单价下降，毛利率崩塌。
组织的每个激励都在对抗这个转变。销售 VP 的奖金与 ARR 增长挂钩，推 Agent = 自降 ARR。产品团队的 roadmap 是"提升席位价值"，不是"消灭席位"。财报分析师问"为什么客单价下降？"CEO 怎么解释？
这就是为什么真正的颠覆来自外部。不是因为巨头技术不行，是因为他们不能在经济上自我否定。
数据积累的时间窗口已关闭
Context Graph 的价值密度与数据量非线性相关。
早期（< 1000 决策轨迹）：几乎无用。太稀疏，看不出模式。"上次类似情况怎么处理"返回空或不相关结果。
临界点（1000-10000 轨迹）：开始有用。能匹配到少量先例，但泛化能力弱。"P0 客户的折扣审批"能找到 5 个案例，不够学出规律。
规模化（> 10000 轨迹）：质变。跨越足够多场景，学到可泛化的决策模式。不只是"检索相似案例"，是"理解决策逻辑"——哪些因素真正影响结果？哪些先例可以类推？
Regie、Maximor、PlayerZero 在 2024-2025 已经跨过临界点。每天处理几千个真实决策，Context Graph 在生产环境持续学习。
Salesforce 现在想追，面临冷启动问题。收购一家 Agent 公司，买到的是代码和初期轨迹（< 1000），买不到的是在生产环境积累两年的决策拓扑——哪些 context 真正重要？哪些先例可以泛化？哪些例外路径最常被调用？
这些隐性知识编码在 Context Graph 的关联结构里——不是数据本身，是数据之间的关系。脱离原生系统的执行环境，这些关系就失效。就像把 AlphaGo 的神经网络权重复制到另一个围棋引擎，参数还在，但配合整个系统的调优全丢了。
时间窗口的不可逆性
2024-2025 是原生玩家建立领先的窗口。2026 开始，差距会加速扩大：
原生玩家：更好 Context Graph → 更高决策质量 → 更多客户采用 → 更多轨迹积累 → 更好 Context Graph（飞轮加速）
巨头：不敢大规模运行 agent（客户不信任，内部 KPI 冲突）→ 无法积累轨迹 → Context Graph 质量追不上 → 客户更不信任（死锁加深）
这个 gap 每个季度扩大，且不可逆。不是技术能力问题，是结构性位置问题。就像诺基亚有最好的硬件工程师，但无法在 iOS/Android 生态建立的两年后追上。时间窗口关闭后，再多钱也买不回来。
小结
三个关键洞察：
1. 原语决定生态
过去 40 年企业软件建在"持久化数据"这个原语上——表、行、外键、事务。整个生态围绕它展开：ER 建模、SQL、ACID、数据仓库、BI 工具。
AI Agent 需要新原语：“持久化决策轨迹”——事件、先例、上下文、因果链。新原语需要新生态：Context Graph、learned ontology、trajectory mining、决策可解释性工具。
原语不兼容，生态无法移植。这不是功能迭代，是基础设施重建。就像从大型机到客户端/服务器、从单体到微服务，每次原语变化都诞生新的千亿美元公司，旧玩家很少能跨越。
2. 不对称竞争的根源
创业公司 vs 巨头不是技术能力对比，是结构性位置差异：
创业公司每个决策都强化 Context Graph（产品即数据飞轮）
巨头每个决策都在保护现有 ARR（组织激励对抗转型）
创业公司的"缺陷"变成优势：没有技术债（可以原生设计 event-driven）、没有现有客户（可以按结果定价）、没有 ARR 压力（可以激进部署 agent）。
巨头的"优势"变成包袱：庞大代码库（改不动）、巨额 ARR（不敢动）、复杂组织（转不动）。这不是执行力问题，是博弈论必然——在商业价值上自我否定是不可能完成的任务。
3. 时间窗口已经打开
Context Graph 的非线性特性创造了不可逆的时间窗口。2024-2025 是冷启动期，原生玩家已跨过临界质量。2026 开始进入飞轮加速期——先发者的 Context Graph 质量优势会自我强化，每个季度扩大。
原生玩家在 2024-2025 积累的两年决策轨迹，巨头用再多钱也追不回来。不是资本问题，是物理时间——Context Graph 需要在真实生产环境中积累足够轨迹才能跨过临界质量。
企业软件的控制点正在从数据层转移到决策层。Salesforce 用 20 年建立的数据垄断，在 GDPR 和 API 标准化后开始松动。下一代Lock-in会更深，因为AI Agent不仅有企业的Data，还有企业组织如何决策的Memory。
Enjoy!
References
a16z, “Big Ideas 2026: Part 1”, Andreessen Horowitz, December 2025.
Jaya Gupta and Ashu Garg, “Context Graphs: AI’s Trillion-Dollar Opportunity”, Foundation Capital, December 2025.
Bessemer Venture Partners, “Roadmap: AI systems of action”, BVP Atlas, May 2025.
Palantir Technologies, “Foundry Ontology - Core Concepts”, Palantir Documentation, 2025.
Jamin Ball, “Long Live Systems of Record”, Clouded Judgement, December 2025.
