编辑|张倩、陈晨 随着特工开始深度介入人类世界，关于豆宝AI手机的讨论或许只是一个开始。在此之前，移动电话和计算机程序是供人类使用的。人类负责一步一步的操作，系统负责存储和计算信息。但现在代理商开始负责这些业务。只需表明您的目标，客服人员就会打开应用程序、输入信息、做出选择，最后返回结果供您审核。这就提出了一个问题。当人们不再需要亲自点击每一步时，是否应该有最初围绕“人交互”而设计的软件和系统？除了C场景之外，比如豆宝AI手机，企业也在讨论这个话题。最近的问题集中在所谓的“记录系统”上。有人说特工破坏了录音系统，也有人说特工只是提高了“良好记录系统”的标准，而其他人则表示，围绕特工执行流程构建的新“记录架构”背后隐藏着数万亿美元的机会。那么到底什么是注册系统呢？你周围的机会在哪里？我们总结了一些相关文章并详细分析了这些主题。录音系统死了吗？简单地说，公司的记录系统就是公司的“账本”和“黑匣子”。谁更改了数据、何时更改、更改了多少次以及过程采取了哪些步骤，都被准确记录下来，以便于后期调整、问责和合规检查。前几代企业软件之所以能够构建数十亿美元的生态系统，是因为它们成为了记录系统。也就是说，因为它最终被用作某些核心业务数据的基础。此前，许多工作都必须经过这些系统。萨尔员工需要将机会输入 Salesforce，财务人员需要在 ERP 中创建凭证，人力资源部门则需要处理工作日的休假请求。我需要运行该表格。如果您不完成或无人看管，您的许可证将不会累积。一旦这些系统提供了数据的标准定义和最终验证，公司的业务流程就必须围绕它们展开，从而为用户造成强大的迁移障碍和僵化。然而，在智能体出现之后，这种逻辑开始动摇。代理的想法比较简单。只要可以获得所需的数据，就可以直接执行工作，而不必强迫用户更新 CRM 或 ERP 记录。结果，出现了新的可能性。 Agent从系统中读取数据，在系统外完成决策和执行，最终只写入结果或根本不写入。结果，最初必须“通过”的记录系统可能会逐渐退化为只读数据存储，不再是流程的核心。于是，诸如“代理是新的记录系统”、“工作流正在蚕食记录系统”、“数据是记录系统，应用程序只是显示层”等声音纷纷出现……近日，美国投资公司 Altimeter Capi 的 Tal 合伙人 Jamin Ball 撰文反驳了这一说法。本文的标题是“记录系统的长寿”。文章指出，录音系统不仅不会消失，而且在未来会更加重要。因为录音系统回答的问题本质上是“真相在哪里？”这个问题很重要，因为随着工作流程变得更加自动化，漏洞通常不在于人工智能模型，而在于代理是否从正确的系统获取正确的数据。博客链接：https://cloudedjudgement.substack.com/p/clouded-judgement-121225-long-live 他指出了一个非常现实的问题：企业数据其实很混乱。以ARR（年度经常性收入）为例。同一家公司的销售、财务、会计和法务部门可以给出完全不同的定义和数字。要求客服人员计算每个分段的 ARR，并向董事会询问如果我要求某人向某人发送消息，我应该使用哪个版本？球发出信号，因为在这种情况下记录系统不起作用的想法是错误的。我们拥有的自动化程度越高，就有越多的人需要付出艰苦的努力来找出正确的答案是什么以及在哪里回答它。记录系统通过拥有自己的流程来解决这个问题：客户的 CRM、财务的 ERP 和员工的 HRIS。然后事情发生了变化，数据仓库/湖屋将所有数据转储到一个池中，添加语义模型和指标定义，并试图成为“单一事实来源”。然而，这些仓库大多存在于生产环境的下游。销售仍然存在于 Salesforce 中，financials 仍然存在于 NetSuite Checkout 中，仓库只是一个回顾性分析工具。代理商已经改变了这一点。首先，代理自然是跨系统的。执行报价到付款工作流程需要多个系统之间的协调，例如 CRM、CPQ、计费和收款。其次，代理本质上是面向行动的，执行的行动实际上改变了底层系统的状态，而不是简单地生成报告。这意味着代理的能力受到理解哪些系统包含哪些真理以及这些真理之间的契约的限制。这就是 Ball 认为这对 Databricks 这样的公司有很大帮助的原因。 Databricks 有潜力成为人工智能代理的中心，并开始构建自己的人工智能代理。鲍尔认为，代理迫使我们将工作的用户体验与事实来源分开。该界面可以是聊天窗口或自然语言界面，但它的下面应该有一些内容：“这个数据仓库和湖仓库是代理工作流程的天然基础，但对于人类查询而言。它们必须从设计转向为代理提供明确的规则和冲突解决机制。Almismo tiempo, los CRM y ERP tradicionales no desaparecerán, sino que evolucionarán hasta conversionirse en “máquinas de estado con API” que atiendenprincipe a máquinas en lugar换句话说，记录系统并没有消失，而是被拆除和重建，而对明确定义的事实来源的需求只会增加，而不是更换记录保存系统，而是提高良好的记录保存系统的标准。 y confiables 上下文：新万亿美元机会球的文章驳斥了代理人的说法，arGumentando que los Agentes no reemplaz 不仅是录音系统，而且还提高了良好录音系统的标准。这一观点得到了风险投资机构 Foundation Capital 合伙人 Jaya Gupta 和 Ashu Garg 的支持，他们还就此主题撰写了一篇文章。这篇文章在X上有数百万的浏览量。文章链接：https://foundationcapital.com/context-graphs-ais-trillion-dollar-opportunity/ 本文首先阐述了Ball的观点。 Ball 指出，客服人员跨系统工作，读取 CRM、ERP、工单、记录、Slack 等。这些代理以行动为导向，直接做某事，而不是简单地回答问题（例如批准、下订单、更新、发放折扣等）。因此，用户不再直接点击系统，代理成为作业的主界面（UX），而原来的系统被移至后端并负责存储精细的事实。然而，底部必须有一个可靠的酸真相（记录系统）。否则，代理人将不知道什么是真实的。鲍尔的论点是，代理所需的数据实际上被隐含地假设为系统维护的。唯一的问题是如何为代理提供更好的数据访问权限，并辅之以更好的治理机制、语义契约，并明确规定在不同场景中使用哪些数据定义。事实上，这只是问题的一半。另一半，即真正推动公司运营的层面，长期以来一直缺失。这是决策的痕迹。具体来说，企业的实际运作不仅取决于写入系统的规则、字段和流程，还取决于具体决策的多少。这些称为决策跟踪，包括： 例外：为什么允许例外是在某些特殊情况下。覆盖：覆盖允许最终结果的默认规则。先例：类似的情况曾经发生过吗？过去。系统间背景：当时一般指的是哪些系统？问题在于，真正确定此类事件发生原因的信息很少被正式记录在任何系统中。这些信息通常存在于 Slack 聊天日志、交易台的内部讨论、客户或事件升级时的电话会议以及员工的个人经历和记忆中。这是最重要的部分。真正重要的区别是规则和决策轨迹不同。这些规则只是告诉代理在常见情况下应该做什么。例如，报告必须使用 ARR 的官方定义。同时，决策跟踪记录了特定决策是如何做出的、使用了哪些定义、基于什么版本的政策、是否授予例外、引用了哪些过去的先例以及最终做出了哪些调整。代理不仅需要规则，还需要访问这些规则的轨迹决定。只有这样，我们才能了解过去如何应用规则、在哪些情况下给予例外、如何解决争议、谁做出了最终决定，以及哪些先例实际上决定了现实的运作方式。这是一个基于代理激活的系统结构优势。这些位于实际执行路径中，并允许做出决策时的完整上下文：整个系统收集了哪些输入，评估了哪些策略，触发了哪些异常流程，谁批准了它们，以及最终写入了哪些状态。当这些信息变得持久化时，它就创造了当今大多数公司所没有的资产：可供查阅的结构化决策记录。这些随时间累积的决策轨迹构成了上下文图。它不是一个模型的思想链，而是跨实体和跨时代的关联决策的活记录，使得历史先例可搜索和可重用。随着时间的推移，这张地图将成为一个TR自治系统的信息来源，不仅解释发生了什么，还解释为什么允许发生这些行为。因此，真正的核心问题不是现有的记录系统是否能够生存，而是专门设计用于记录业务对象和决策本身的全新记录系统是否会出现并成长为下一代数十亿美元的平台。哪些信息不能被记录系统捕获？当代理了解真实的业务流程（例如审查合同、报价现金和处理客户服务问题）时，团队面临着仅靠数据治理无法解决的瓶颈。瓶颈不是缺乏数据，而是缺乏决策途径。智能体所遇到的正是人类每天依靠判断和组织记忆来解决的模糊领域。然而，支持这些决策的关键信息并没有作为长期存储米资产。具体来说，主要体现在以下几个方面： 人脑存在异常逻辑。示例：医疗保健客户的购买流程特别复杂，通常会获得 10% 的额外折扣。这种体验不是 CRM 的一部分，但它通过入职和个人沟通等元素代代相传。这是过去决定形成的先例。示例：上个季度，为公司设计了类似的交易结构。实际上，没有系统可以关联两个交易，更不用说记录为什么选择该结构了。系统之间的信息集成。客户服务经理在 Salesforce 中查看客户的 ARR，在 Zendesk 中查看两个开放的升级票证，阅读有关客户流失风险的 Slack 讨论，并做出升级决定。这一系列的决定都是在他的脑海中做出的，最后，只留下了一条记录。系统。更新至 3 级支持。审批链接发生在系统外部。副总裁可以在 Zoom 通话或非私人 Slack 聊天期间批准折扣。 CRM 中仅记录最终价格，但始终不清楚谁授权了偏离规则的决定或原因。这就是永远不会被抓住的真正含义。问题不在于数据是脏的、不一致的或分散的，而是将数据转化为行动的推理和判断过程没有被视为数据或首先被存储。上下文图是一个已经存在多年的基本层，当初创公司在代理实际执行工作的层（编排层）逐次构建决策轨迹时，他们可以访问当今大多数公司很少拥有的资产：一个结构化的、可复制的故事，清楚地显示上下文如何逐步转化为行动。实际上，该过程如下所示： 续订代理关闭提供 20% 的折扣，但该公司的政策规定，除非服务影响例外获得批准，否则续订折扣上限为 10%。结果，代理自动从 PagerDuty 检索了最近的三起 SEV-1 严重事件，并在 Zendesk 中发现了一个升级工作订单，如果问题未得到解决，该订单将取消合同。我们还发现了合同续签讨论的记录，其中副总裁上季度批准了类似的例外情况。根据这些上下文，代理向财务部门发送例外请求，财务部门会审核并批准该请求。最终，CRM系统中只剩下一个结果事实。也就是说，客户获得了20%的折扣。然而，仅通过查看CRM，公司可能知道结果是什么，但不知道为什么这些结果是合理的，它们基于什么信息，或者谁批准了它们以及在什么情况下批准它们。只有当这些过程被注册（甚至完全作为决策路径）时，“为什么”才变得重要可访问和可查询的数据。企业不再需要在 Slack 中跟踪历史记录。如果您遇到类似情况，请再讨论。因此，请直接参考先例和累积的例外情况，逐步创建可重复使用的决策经验。为此，我们将首先对企业进行审计，并制定自治系统，并转换可重复使用的先例中的例外决定，并在宽松的三个月内修订限制问题。这个系统真正创造复合效应的是反馈循环。托盘决策捕捉到了历史上的先例，这是巴士车和新决策自动化的一个新的托盘托盘。您使用系统越多，您就会越了解业务。这并不是因为模型发生了变化，而是因为总是有更多的经验可用于决策。福此外，它们都不需要从第一天起就完全自主。它可以从人类的参与开始。代理负责提出解决方案、收集背景信息、分发批准并记录整个决策过程。随着类似案例的重复，系统可以逐渐自动化更多的环节，因为它已经拥有一个包含过去决策和异常情况的结构化库。即使最终决定仍然由人类做出，该图仍在继续增长。这是因为工作流层将导致决策的输入、审批流程和推理存储为永久先例，而不是让这些重要信息消失在 Slack 对话中。大型传统企业为何难以创建上下文地图 Jamin Ball 对现有企业软件供应商的前景相对乐观。他相信现有的参与者可以向新的架构发展。数据仓库成为事实记录，CRM 演变成状态机nes 与 API。这是一个逐渐演变而不是完全替代的故事。然而，这种方法充其量只是增加了数据的可访问性，并没有解决理解决策轨迹这一更重要的问题。 Salesforce、ServiceNow 和 Workday 等操作系统自然是孤立的，并且专注于当前状态。他们的共同说法是：“我们已经拥有数据，我们只需要添加情报。”问题在于这些代理继承了其父系统的架构缺陷。以 Salesforce 为例。我们擅长跟踪我们的机会清单是最新的，但我们不知道当特定折扣获得批准时世界会是什么样子。一旦折扣获得批准，支持该决定的上下文就不会保存。由于情况无法重现，决策无法被审核、学习或用作可复制的先例。真正的业务决策很少是在单个系统中做出的。例如，客户服务更新通常取决于 CRM 中的客户级别、计费系统中的 SLA 条款、PagerDuty 中最近的崩溃日志以及 Slack 中的客户流失风险讨论等因素。然而，在这个跨系统执行路径中并没有传统的提供者。每个系统只知道自己的一小部分现实，因此无法掌握其决策的完整背景。一个只允许读者事后查看数据的系统不能成为一个授权的决策登记系统。我们知道发生了什么，但我们永远不知道为什么会发生。上下文映射显示做出决策时系统处于执行路径上的位置，以捕获整个输入、决策、异常和批准流程。应该有。这是传统决策系统结构中最困难的部分。 Databricks 正在进一步集成相关功能，但靠近代理构建位置与位于 exe 上并不相同实际做出决策的路径。系统代理启动具有处于编排路径中的结构优势。当代理对更新请求进行优先级排序、响应事件或决定是否给予折扣时，他们会从多个系统获取上下文、评估规则、解决冲突并采取行动。编排层看到全景一般的AMA：收集什么输入，应用什么策略，允许什么例外，以及它们背后的原因。因为我们正在运行工作流程，所以我们在做出决策时捕获此上下文并将其记录为实时数据，而不是事后 ETL。这就是上下文图，它将成为人工智能时代企业最有价值的资产之一。当然，大型传统企业也不会袖手旁观。他们将通过并购来补充编排能力，锁定API，并引入高额数据渗漏费用以增加提取成本，类似云计算巨头采用的策略。我们还构建了自己的代理框架，以促进一切都留在自己的生态系统内的叙述。然而，理解决策轨迹的先决条件是决策提出时的执行路径，而不是稍后添加治理层。传统供应商可能会让数据提取变得困难，但他们无法强行进入他们从未参与过的编排层。 初创公司的三种路径 系统代理初创公司可以采取不同的开发路径，每条路径都有自己的权衡。第一种方法是从头开始替换现有的注册系统。这些公司正在重新设计其 CRM 或 ERP，以运行代理并管理事件源状态和策略缓存。启用 Puchya 架构的本机功能。传统厂商深厚的底蕴让这条路变得异常艰难，但在关键时刻仍然可行。技术和范式发生转变。在众多进入AI SDR领域的新帝中，雷吉选择了这条道路。我们正在构建一个人工智能原生销售参与平台，以取代依赖分散、手动操作工具链的传统产品（Outreach、Salesloft 等）。 Reggie 旨在为混合人机协作团队提供服务。作为一等公民，座席可以自主执行客户发现、生成外展内容、跟进、处理潜在客户路由，并根据需要升级给人工进行处理。第二种方法是更换系统内的一个重要模块，而不是更换整个系统。此类启动侧重于高度集中的异常和审批线程，成为这些环节上的决策记录系统，并将最终状态与继承的system.original do同步。 Maximor 走的是金融领域的第二条路。它是关于自动化现金管理、结算和核心会计流程，而不取代一般流程。l 分类帐（GL）。 ERP 仍然作为账本存在，但 Maximor 成为了对账逻辑所在的真相来源。第三条路径是建立全新的登记制度。这些初创公司通常从编排层开始，但它们也有一些公司以前没有系统维护过的东西：决策过程本身。随着时间的推移，这个可复制的决策链将成为真正值得信赖的资产，代理层将不再只是一个自动化工具，而是一个企业将依赖的系统来回答“我们最初为什么这样做？”的问题。 PlayerZero 是该模型的一个示例。生产工程（Production Engineering）定位于interseSRE的行动、支持、质量控制和开发。这些是经典的“绑定功能”，长期以来一直依赖人类来传达软件系统无法捕获的上下文。 PlayerZero 从自动化 L2/L3 支持开始，但其真正的核心资产是 Context Graph，一个反映代码、配置、基础设施和客户端行为实际交互方式的动态模型。最终，这张地图成为事实的来源，回答了当前系统无法回答的问题，例如“为什么会发生这种情况？” “这个变化会影响车道吗？”随着越来越多的初创公司遵循这些路径，代理可观察性将成为关键的基础设施。随着决策轨迹的不断积累和上下文图的不断扩展，公司必须监控、调试和评估年龄行为。 Arize 正在为这一新技术堆栈创建一个可观察层，以帮助团队深入了解代理的推理过程、识别失败原因并评估随时间推移的决策绩效。正如 Datadog 已成为应用监控领域领先的基础设施一样，Arize 有望成为监控和提高代理决策质量的核心基础设施。企业家的主要标志或决定从哪里开始重叠，但并不相同。有两个信号适用于上述三个机会途径： 高劳动力密度。假设您的公司有 50 名员工手动完成相同的工作流程（票证路由、请求下载、交叉工作流程等）。系统数据调整），这本身就是一个强烈的信号。这种立场的存在是因为决策逻辑太复杂，无法使用传统工具直接自动化。面向异常的决策。常规和确定性流程不需要决策链；代理人只需遵守规则即可。当逻辑复杂、先例很重要、诚实的答案取决于具体情况时，才是真正有价值的切入点。示例：交易台审批、承保决策、合规审查、升级管理和其他场景。还有另一个迹象特别表明新注册系统的机会。它通常是最重要的之一组织职能处于多个系统交叉点的明显迹象。例如，RevOps 的存在是因为有人需要协调销售、财务、营销和客户成功。 DevOps 的存在是因为需要有人将开发团队、IT 团队和支持团队联系起来。安全运营位于 IT、工程和合规性之间。这些粘附特性本身就是明确的信号。这些问题的发生正是因为没有可以完全管理这些跨职能工作流程的记录系统。因此，必须在组织结构内建立一个角色来传达软件系统无法捕获的上下文。如果代理可以自动化这些角色，他们不仅能够更快地执行步骤，而且还可以系统地存储角色最初用于做出决策的决策、例外和先例。这是通往新一代记录系统的道路。这不是通过替换现有的大型设备来实现的系统，但通过捕捉现实，只有当代理真正集成到工作流程中时，它才变得明显。重新思考记录系统 问题不在于记录系统能否生存。他们会做的。真正的问题是，下一波价值数十亿美元的平台是否会通过将人工智能叠加在现有数据之上，或者通过捕获使数据真正可操作的决策轨迹来构建。 Jaya Gupta 和 Ashu Garg 发现属于后者。创建上下文图的初创公司正在为这个未来奠定基础。从操作上下文到决策图基于上一篇文章中的见解，Graphlit（一家专注于为代理构建“操作上下文层”的基础设施公司）的创始人兼首席执行官 Kirk Marple 表示，这是他所看到的关于企业级人工智能未来方向的最清晰的解释。我想这已经很清楚了。 JayaGupta 和 Ashu Garg 指出，下一个数十亿美元的数字ollar 平台不会通过简单地将人工智能叠加在现有记录系统之上来创建，而是通过捕获尚未系统存储在公司内部的东西：决策的轨迹。痕迹。它们指示如何应用规则、何时允许例外以及为什么允许发生某些操作。马普尔认为贾亚·古普塔和阿舒·加尔格是对的。但他指出，这一论点还涉及一个更值得注意的前提。这意味着，如果不首先解决运营问题，就不可能真正理解决策的轨迹。在有意义地记录为什么做出特定决策之前，代理必须首先了解谁负责什么、实体之间如何相互关联、条件何时发生变化以及信息如何在不同系统之间流动。正是这个基础层构成了建立上下文图的底层支撑。在当今的企业技术环境中，这一层仍然很大程度上是我的唱。 Jaya Gupta 和 Ashu Garg 的文章中对上下文映射的中心讨论首先是对当前人工智能格局的反思。 Salesforce、Workday 和 SAP 等记录系统已经能够发展成为价值数十亿美元的平台，因为它们可以访问标准化、可靠的数据。当前的争论是这些系统是否能够在代理数量增加的情况下继续生存。本文的答案是：代理不会取代记录系统，但它们暴露了一个长期缺失的层。正如文章中提到的，规则告诉代理一般应该发生什么。决策轨迹记录了特定时间具体发生的事情。例如，用户采用该定义。这个认知是非常清晰的。例如，如上所述，如果折扣政策有 10% 的限制，但更新代理建议 20% 的折扣，它会从多个系统检索上下文，包括来自 PagerDuty 的事件历史记录、升级处理g 来自 Zendesk 的日志，以及之前批准的类似先例。这是典型系统中的情况。财务部门最终审核通过后，CRM中只剩下一个结果：20%折扣。所有使该决策合理且易于理解的重要信息都缺失，例如输入来源、政策评估流程、例外路径和审批链。将数据与操作连接起来的推理过程首先并不存储为数据。作者将这些决策轨迹长期积累形成的结构称为上下文图。上下文图是跨实体和一段时间内的轨迹关联决策的活记录，使得先例可搜索和可重用。这就是本文超越大多数类似分析的地方。上下文中的图形对于最重要的政府和语义合同没有单独的意义，它支持新注册系统的提示。什么是记录d 不是对象本身，而是决策本身。柯克·马普尔特工补充说，需要两层背景。实际上，要构建进步背景所需的能力，以及作为市长而不是大使能力的现实。最低且最重要的层称为操作上下文。为什么操作环境至关重要？注册员在做出具体决定之前，首先要了解组织环境并做出决定。换句话说，代理不仅需要看到大量的文本和数据，还需要了解实际的组织结构、功能和关系。初始ID解析（ID解析）是操作环境中最基本的步骤。以莎拉·陈为例。同一个人可以是电子邮件的发件人、Slack 中的 @ 对象以及会议记录中的发言人。这些不同的情况如果系统从消息来源无法确定Sarah Chen实际上是同一个人，经纪人会出现一些无关的片段。当身份变得支离破碎时，后果是非常严重的。代理无法确定谁参与了哪些讨论，他们无法看到谁负责特定帐户或项目，他们无法确定谁拥有批准权限以及谁的意见最有分量。在这种情况下，记录为什么做出特定决策是没有意义的，因为参与者的所有者和决策本身的背景是不明确的。因此，要谈上下文映射，首先要解析操作上下文。第一个操作步骤是将碎片化文本组织中的人和实体转变为统一的、可理解的和理性的对象。在现实的企业决策中，人们并不是仅仅观察某个系统或数据，而是在了解整个组织的运作情况后才采取行动。这种认识主要体现在当前制度普遍缺失的三个方面。第二是所有权和关系。在组织中，很多重要信息没有写入系统并且每个人都知道。例如，谁负责特定的客户账户、哪个工程师最终负责特定的关键服务、服务更新、客户和产品路线图之间的关系是什么？这些信息仅存在于人们的头脑中或分散在 CRM、工作订单系统和项目管理工具中，但从未被一致地建模为可查询和推理的关系数据。当这些关系对代理来说是不可见的时，他们就不知道该向谁求助。第三是天气。决定总是在某个时候做出的，而不是现在。然而，大多数系统只保存当前状态。真正重要的问题是：当时的合同条款是什么？那是什么？当时客户的 ARR 是多少？是否已经存在历史异常现象？如果智能体只能看到当前结果而无法恢复当前结果，那么没有当前状态就无法理解为什么其决策是合理的并且无法修改或重用。四是系统间的综合判断。当做出决策时，人们往往会同时求助于多个系统，例如CRM、工单系统、内部沟通工具、事故平台等，在头脑中整合信息来做出决策。然而，这种合成过程很少被系统记录。系统只记录最后的动作（比如升级到3级），但升级的原因却完全丢失了。因此，操作上下文=身份+所有权+关系+时间理解+系统之间的集成能力。只有通过使用这一层，代理才能对组织的运作方式有一个人类的理解。一个d 只有在此基础上才能建立后续决策的轨迹和上下文图。假设操作上下文已经可用（即，代理知道谁是谁，谁负责什么，实体如何相关，以及它们当时处于什么状态），可以进一步构建决策上下文。这主要体现在三个方面。第一个是决策轨迹。它是记录整个决策过程。门票是什么？评估了哪些政策？是否触发了异常？谁最终批准的？这不再是人类判断中隐含的信息，而是明确存储为结构化记录。其次，先例成为可重用的工件（前例作为工件）。如果再次出现类似情况，座席不必从头开始做出决定，可以直接询问“我们之前是如何处理这种情况的？”分数是多少？这使得体验超越了一对一的范围和 Slack 对话，成为组织的可转移和可学习的资产。第三，可审计性。请不仅回答发生了什么，还要回答为什么允许发生这种情况。这种解释是基于完整的背景，包括情况、参与者、规则和例外，而不是后验原因的集合。总结所以，如果智能体不知道参与者是谁、实体之间是如何关联的、或者做出决策时世界处于什么状态，那么所谓的决策轨迹就是空洞且不可再现的。因此，我们可以说操作上下文是基础，决策上下文是建立在该基础上的结构。但在绝大多数公司中，这两个层面的背景并不真正存在。为什么RAG和AI内存不够用 目前市场上主要有两种解决上下文缺乏问题的方法：RAG内存平台和AI内存平台。然而，这两种方法都没有可以解决操作上下文的问题。 RAG 捕捉的是文本片段，而不是系统的理解。如果您问“Sarah 对 API 集成有何看法？” RAG 将仅搜索包含这些关键字的文档。我不知道Sarah是否是一个有完整交往历史的人，也不知道AP是否是。这个集成是一个涉及三个团队的项目，不可能理解 Slack、电子邮件和会议纪要之间的讨论是如何进行的。 RAG 保留相似性而不是语义或关系。 AI记忆平台存储的是聊天日志，而不是组织的现实。与人工智能对话时所说的话会被记录下来，但让我们理解组织的关键元素（实体、关系和暂时状态）并没有被建模。例如，用户讨论 Acme 定价的记忆并不等同于了解 Acme 客户帐户的历史关系。Acme，相关利益相关者的结构和过去的决策路径。问题的根源是结构性的。这些方法将组织知识视为必须矢量化的文档或必须记住的对话。但实际上，组织知识本质上是一张图。人与账户相连，账户与项目相连，项目与决策相连，决策与结果相连，一切都随着时间的推移而发展。如果没有图表，代理就看不到上下文。您也许能够搜索相关文本，但您永远不会真正了解谁负责什么、如何一步步做出决策以及哪些先例实际上管辖着现实世界的运营。操作上下文层是什么样的？那么构建这样一个基本的操作上下文层到底需要什么？其主要特点是： 实体身份解析详细信息：人员、组织、地点和事件应建模为唯一的、权威的实体，最好符合通用标准，例如 Schema.org。例如，莎拉·陈不应该是一个在不同工具中以不同文本形式出现的片段，而应该是一个统一的实体，将她参与的所有对话、文件和决策统一起来。多模式摄取：操作上下文层需要访问整个企业的信息源，包括 Slack、电子邮件、会议记录、文档、代码、CRM 和项目管理工具。目标不是提取文本，而是保留原始结构和语义。时间建模：不仅记录当前状态，还记录状态如何随时间变化。代理需要了解更改的内容、更改的时间以及更改的顺序，而不仅仅是看到最终结果。 maRelational peo：实体必须明确建模，例如人员所属的团队或文档负责的项目。这些关系是一流的公民图表的内容，而不是文本隐含的背景信息。代理互操作性：任何代理都应该可以通过标准协议访问上下文层，而不是被锁定到特定的提供者模型或生态系统中。企业级部署能力：对于有数据治理和合规要求的企业，上下文层必须支持在自己的基础设施上执行，以满足安全和合规要求。从运营环境到决策图。首先，从运营场景转向决策图是企业AI的必然路径。 Foundation Capital提出的上下文图视角本质上是指向一个方向。企业人工智能不仅需要更强大的模型，还需要能够记录和理解决策如何制定的基础设施。为此，我们必须首先解决操作上下文的建模问题：身份、实体、关系和时间状态。仅在以此为基础，决策路径是否有意义。其次，决策轨迹比传统的智能体可观察性具有更高的抽象级别。目前的代理/法学硕士可观察性侧重于执行级别：调用什么工具，有哪些输入和输出，以及有哪些延迟和资源消耗。这对于调试很重要，但并不等同于决策路径。真正有价值的决策过程描述了触发了哪些例外情况、谁批准了这些例外情况、参考了哪些先例、在什么政策下以及在什么情况下进行。这是语义层面的记录，而不是技术执行的记录。第三，决策轨迹需要标准化，使其成为新的记录系统。如果决策的轨迹最终要成为权威的事实来源，那么每个平台都无法以自己的格式存储它。否则，就无法查阅系统之间的先例。这意味着，类似除了实体层的 Schema.org 和可观察层的 OpenTelemetry 之外，决策层还需要行业级标准来描述策略、异常、授权和先例等内容。因此，有意义的决策图不会凭空出现。它应该基于操作环境。然后，随着操作上下文、决策记录和工作流执行的联系越来越紧密，业务的新事实层将自然发展，它不仅会记录对象是什么，还会记录做出决策的原因。它将开始录制。为什么现在特别重要？三大变化同时汇聚，成为关键的窗口期。首先，ChatGPT 爆发了对业务环境的真实需求。每个组织都希望人工智能能够真正理解他们的业务，而不是简单地使用根据公共互联网数据训练的通用模型。这种需求是真实的，并且永远不会消失。二、MCP标准化互操作性代理之间。模型上下文协议提供了向代理公开上下文的标准方法。上下文层只需构建一次，可以同时提供游标、克隆、本地代理以及未来出现的新工具。第三，几乎所有公司都尝试实施代理，但他们缺乏使代理真正有用的上下文层。这是本文指出的中心差距。代理不断遇到无法仅通过治理、权威和规则解决的障碍。特工需要一个操作背景才能正确推理，只有在政治背景下才能从历史先例中学习。需要有人为这种情况构建基础设施，人们应该关注这一点。 https://x.com/JayaGup10/status/2003525933534179480 https://foundationcapital.com/context-graphs-ais-trillion-dollar-opportunity/https://x.com/KirkMarple/status/2003944353342149021
特别提示：以上内容（包括图片和视频，如有）由自有媒体平台“网易号”用户上传发布。本平台仅提供信息存储服务。
请注意：以上内容（包括图片和视频，如有）由仅提供信息存储服务的社交媒体平台网易提供。由sehao用户上传并发布。
