Alessandro Cotrufo：上下文是企业 AI 面临的最大挑战

Alessandro Cotrufo 对“模型优先”的企业 AI 路线提出了质疑，一则 Google News 标题将他的立场浓缩为一个鲜明的冲突：更好的模型并非主要限制。更棘手的问题在于，当 AI 必须回答问题或采取行动时，如何为它提供新鲜、相关且受治理的业务上下文。

这则归属于 Carroll County Mirror-Democrat 的标题，几乎没有提供可独立核实的 Cotrufo 言论细节。不过，他的公开活动显示他与 Redis 有关联，并且一再倡导同样的“上下文优先”观点。Redis 也已将这一立场纳入其近期面向生产环境 AI 智能体的产品战略。

这种区分很重要，因为企业多年来一直在比较 OpenAI、Google、Anthropic、Meta 及其他供应商的模型。Cotrufo 的观点将审视重点从基准测试分数转向这些模型周边的系统。如果他是对的，那么更换模型无法修复缺失的记录、过时的政策、失效的权限或未被记录的决策。

这并不是说模型已不再重要。模型质量依然影响推理、指令遵循、工具使用和输出准确性。变化在于，模型选择越来越像是一个更庞大可靠性问题中的组成部分。

Google News 标题指向更广泛的 Redis 战略

最重要的发展并非一款新的基础模型，而是将企业上下文打造为明确基础设施类别的日益增长的努力。

原始的 Google News 条目将 Cotrufo 的观点描述为对传统企业 AI 优先事项的直接挑战。但除经转载的标题外，原始文章难以核实。因此，读者应谨慎看待具体归因，尤其是任何未由可访问的一手来源复现的细节。

Cotrufo 的公开帖子为这一更广泛的立场提供了更有力的证据。他将智能体描述为存在上下文问题，而非智能问题。他还认为，生产环境 AI 依赖于实时保持数据、特征和决策的一致性。

这种表述与 Redis 当前的产品方向高度吻合。2026 年 5 月，该公司推出 Redis Iris，这是一套旨在将智能体与碎片化企业数据连接起来的上下文与记忆系统。Redis 将上下文引擎描述为智能体与其采取行动所需信息之间的一层。

该公司的上下文引擎文档列出了四项托管服务。LangCache 会复用对语义相似提示的响应。Agent Memory 保留短期和长期信息。Context Retriever 为智能体提供对业务数据的结构化访问。Data Integration 同步来自关系型数据库的变更。

这一架构将 Cotrufo 的观点转化为一项具体的商业论点。模型只能基于某一特定推理步骤中可获得的信息进行推理。如果最新退款政策仍被困在一个无法访问的系统中，再强的推理能力也无法凭空获取它。

当智能体遇到相互矛盾的记录时，同样的限制也会出现。客户数据库可能显示一名账户所有者，而支持平台显示另一名。某封邮件线程可能包含最新的例外情况，但没有正式系统记录它。

模型可以围绕这些矛盾生成流畅的语言。除非周边架构提供相应规则，否则它无法独立判断哪个系统拥有权威性。因此，上下文不仅包括更多文本，还包括含义、所有权、权限、时效性和来源。

这构成了文章的核心张力。模型供应商持续提升通用能力，而企业部署则遭遇根植于私有运营条件的失败。这些条件因公司而异，而且往往比模型训练周期变化得更快。

Google News 用一个简洁标题呈现了这一观点，但 Redis 提供了更具影响力的信号。该公司正将上下文处理定位为一个协同的生产层，而不是一系列定制集成的组合。

这种框架也服务于 Redis 自身的利益。该公司销售用于存储状态、检索信息和快速移动数据的基础设施。其诊断不应被视为某一个平台能够解决所有上下文故障的中立证据。

不过，根本问题超出单一供应商的范围。Google Cloud 现在将AI 上下文工程定义为设计 AI 系统所使用的数据环境和记忆。这种独立的一致性表明，该类别正成为主流企业架构的一部分。

因此，这则新闻反映的是重点的转变。企业正在从询问哪个模型最聪明，转向询问哪些信息会传递给模型、遵循什么规则，以及在什么时刻传递。

为什么模型升级无法修复缺失的业务知识

更强的模型可以更好地推理，但无法基于企业从未提供的私有事实进行推理。

基础模型从大型训练集合中学习广泛模式。这使它们适用于通用写作、编程、摘要和分析。但这并不赋予它们对公司现行合同、内部 API、审批规则或客户历史的自动认知。

以处理退款请求的支持智能体为例。模型可能了解常见零售实践，并生成一份有说服力的回复。它是否有用，取决于能否获得适用政策、购买记录、产品类别、客户状态及任何已批准的例外。

缺失的政策文件会带来一种故障模式，过时的副本则会带来另一种。过度检索也可能让无关材料淹没决定性的段落，使更大的上下文窗口不如预期有用。

上下文工程正是为解决这一选择问题而生。它是在推理过程中组装模型所接收的指令、记录、记忆、工具描述和运行状态的过程。目标不是提供一切，而是提供支持下一项决策所需的、最小且可信的信息集合。

当 AI 系统跨多个步骤采取行动时，这一要求会变得更难。传统聊天机器人可以回答一个孤立的问题。智能体则可能检查账户、比较政策、请求授权、更新工单并通知客户。

每一步都会改变相关状态。智能体必须记住已经检查过什么，识别新数据，并避免重复操作。它还必须维持其可读取的信息与可执行操作之间的边界。

更大的模型无法消除这些工程义务。它或许能更从容地应对含糊指令，但仍需要有效凭据和一份已完成操作的可靠记录。

这也解释了为什么上下文的范围比检索增强生成，即 RAG，更广。RAG 会搜索知识源，并在生成前将相关材料加入提示词。它可以为回答提供依据，但仅靠检索无法管理智能体工作环境的每个部分。

生产级上下文层还可包括会话记忆、用户偏好、数据库模式、实时事件、访问控制、工具输出和工作流状态。它必须决定保留什么、丢弃什么，以及刷新什么。

Stack Overflow 以企业特定的软件开发说明了这一差距。其对企业上下文问题的分析指出，通用助手可能了解公共库，却不了解组织的私有架构或过去的技术决策。

该文章介绍了 Uber 的 Genie，这是一款在 Slack 频道中使用的内部助手。根据 Stack Overflow 的说法，Genie 将内部、经人工验证的知识库与 OpenAI 模型结合使用。工程师可以检查来源，而非接受缺乏依据的回答。

这一案例并不能证明每个具备上下文的智能体都会成功。它表明，模型智能与机构知识承担着不同的职责。模型提供语言与推理能力，知识层则提供公司特定的约束和证据。

机构知识还包括很少出现在结构化数据库中的解释。一个团队可能因为某个库在此前迁移中失败而放弃它。另一项服务可能因一项旧有的合规承诺而需要特殊审批。

这些事实往往存在于会议记录、聊天线程、本地文件和员工记忆中。因此，构建可用的上下文层，首先是一个组织问题，之后才是检索问题。

一个可搜索的知识库可以让分散材料更易获取。然而，搜索质量无法弥补所有权缺失、政策不明确或无人维护的文档。

Cotrufo 的立场在这一点上最具说服力。企业无法仅靠选择最新模型，就购买到摆脱未文档化运营流程的能力。它们必须让自身的内部现实能够被机器理解。

真正的较量是模型更换与上下文投资

核心竞争在于反复替换模型，还是持续投资于围绕每个模型的数据、记忆和治理。

“模型优先”的团队会通过测试另一家供应商、扩展提示词或选择更大的上下文窗口来应对效果不佳。当原始失败涉及推理质量或指令遵循时，这些实验可能有所帮助。

但当源记录本身错误时，它们作用有限。如果销售智能体收到的是上季度的产品目录，再领先的基准测试模型也无法可靠地推断每一项变化。如果缺少权限，模型便无法安全地获取受限合同。

“上下文优先”的团队则从系统必须做出的决策开始。它识别权威来源、所需时效性、用户权限、历史状态和可接受的不确定性。随后，模型在这一运行环境中接受评估。

这种方法改变了采购问题。买方仍必须比较模型准确性、延迟、安全性和兼容性。但他们还必须测试周边应用是否检索到正确证据，并遵守访问边界。

Google News 搜索往往突出可见的模型发布，因为发布会带来明确事件和广为人知的名称。上下文工作则不那么显眼。它体现于数据契约、评估套件、检索管道、身份系统和维护流程中。

然而，正是这些不那么显眼的组件，决定了智能体能否从演示走向重复性工作流。精致的演示通常使用精心挑选的文档和可预测的问题。生产环境则会暴露相互冲突的输入、权限变更、缺失字段和异常情况。

“上下文优先”的观点也会影响供应商锁定。当业务含义被置于某个模型供应商的提示词或专有记忆系统中时，切换会变得昂贵。独立治理的上下文层可以在模型变化时保留机构知识。

这种优势并非自动获得。上下文存储和编排产品可能会形成自身的依赖关系。数据格式、向量索引、工具架构、评估历史和访问策略，仍可能将企业绑定在某一种架构上。

因此，企业应将持久资产与可替换组件区分开来。持久资产包括源数据所有权、业务定义、审批规则、评估用例和可追溯记录。模型、检索算法和编排框架则应始终能够基于这些资产进行测试。

Redis 的策略体现了这种划分。其 Redis Iris announcement 描述了一层可向代理提供记忆、结构化数据、搜索、缓存和最新运营信息的能力。模型位于该层之上，理论上可以更换。

该公司表示，其 Context Retriever 可根据既定业务实体生成受控工具。这一方法很重要，因为不受限制的数据库访问会让代理接触到它们既不了解、也无权使用的数据。

工具可以收窄可执行操作的范围。代理无需被允许执行任意查询，而是可以获得一个经批准的函数，通过客户标识符检索订单。该函数可执行行级访问控制，并返回可预测的架构。

这是一种可执行策略形式的上下文，而不仅仅是附加到提示词中的文档。它规定了代理可以请求什么、能看到哪些数据，以及应如何解释这些数据。

RelationalAI 首席执行官 Molham Aref 从市场的另一端提出了相关观点。在 2026 年 6 月一场关于 enterprise context layer 的讨论中，他表示，仅靠文档无法捕捉运营决策背后的关系和业务逻辑。

这种区别对于供应链、定价、风险和欺诈分析至关重要。这些领域依赖于结构化交易和不断变化的关系，而不仅仅是文本表述。AI 系统需要理解记录之间如何关联，以及哪些计算定义了某个业务概念。

因此，竞争并不只是 Redis 与另一家数据库公司的较量。更深层的竞争在于架构。一种路径将模型视为产品中心，并在需要时连接数据；另一种则将模型视为受治理信息系统中的推理组件。

Cotrufo 的观点倾向于后者。随着基础模型越来越容易替代，而企业数据依然难以组织，这一主张的吸引力也在增强。

更好的上下文也会带来新的准确性和安全风险

上下文可以减少缺乏依据的回答，但治理不善的上下文可能让 AI 系统在接触更多敏感信息的同时，自信地给出错误答案。

这是对 Cotrufo 观点最有力的挑战。将上下文称为最大问题，可能让解决方案听起来很直接：连接更多数据、加入记忆，并检索正确的记录。

但每一项操作都会引入风险。记忆服务可能保留早先对话中的错误假设。检索可能调出已被取代的政策。同步管道则可能更快地传播源系统中的错误。

更多上下文也可能扩大暴露面。连接到客户记录、内部消息和运营系统的代理，会成为更有价值的攻击目标。检索到的文档中若含有恶意指令，可能试图重定向代理，或提取受限信息。

因此，访问控制必须随用户和任务而变化。能够查看某个区域账户的员工，不应仅因代理的共享索引同时包含其他数据，就获得全球访问权限。搜索相关性并不能证明访问已获授权。

出于同样的原因，来源可追溯性同样重要。每个重要答案都应说明由哪些记录支撑、这些记录何时发生变化，以及由哪个系统负责管理。没有这条链路，上下文只会带来自信，却没有问责。

记忆还会带来另一个治理问题。一些信息应在会话之间持续保留，例如已确认的用户偏好。另一些信息则应过期，包括临时指令或从未得到验证的假设。

团队需要制定保留规则，区分对话历史与持久事实。还需要建立纠错路径。当用户纠正错误时，系统必须更新或使旧记忆失效，而不是在之后同时检索两个版本。

语义缓存也存在类似权衡。复用先前的回答可以降低延迟，避免不必要的模型调用。但如果底层政策在缓存过期前发生变化，它也可能返回过时的答案。

因此，安全的缓存不应只依赖相似度匹配。它还需要过期规则、对来源版本的感知，以及对要求使用最新数据的决策设置排除条件。缓存的解释或许可以接受，但缓存的账户余额则不行。

评估仍是最后一道护栏。团队应测试完整应用，而不只是模型本身。有效测试应衡量检索精度、来源新鲜度、权限执行、工具完成情况，以及在缺少必要证据时的系统行为。

系统必须能够拒绝或升级处理。一个总能给出答案的代理，会用看似合理的语言填补上下文缺口。生产环境中的可靠性，部分取决于系统能否识别现有证据不足以支持行动的时刻。

美国国家标准与技术研究院的 generative AI profile 强调在设计、部署、监控和治理全流程中开展风险管理。这种生命周期视角适合上下文工程，因为信息质量和权限会在系统上线后发生变化。

供应商的说法也需要在客户环境中验证。Redis 表示，其服务可提供持久记忆、受治理的访问控制和近实时同步。但如果源数据不准确、规则配置不当，这些能力并不能保证业务决策正确。

广义的上下文论点也不能证明模型差异已经变得无关紧要。一些任务需要更强的推理能力、更好的多语言表现，或更可靠的工具选择能力。能力较弱的模型仍可能误用优质上下文。

实际情况并不像 Google News 标题所暗示的那样绝对。企业可靠性来自模型能力与上下文质量之间的相互作用。Cotrufo 提出的有益纠正是，买方往往仔细审视前者，却对后者投入不足。

上下文工程正在给所有企业 AI 供应商施压

上下文转向迫使模型提供商、数据平台、应用供应商和企业买方证明整个工作流中的可靠性。

基础模型公司面临压力，需要让其模型更易于连接、治理、评估和替换。原始能力仍然重要，但企业买方日益需要可预测的工具使用方式和清晰的控制机制。

云平台则面临不同挑战。它们已经管理数据、身份和应用基础设施。它们的机会在于将这些资产整合到代理平台中，而不强迫每个客户使用同一种模型或数据格式。

数据库和搜索公司将上下文视为扩张市场。Redis 强调实时状态和记忆。其他供应商则聚焦向量检索、知识图谱、语义层或数据仓库。每家企业都将其既有优势描述为缺失的企业层。

应用供应商同样具备优势。它们的产品本已包含工作流规则和用户权限。客户服务平台了解工单，销售平台则了解账户和商机。

然而，应用专属的上下文可能加深碎片化。跨销售、计费、支持和产品系统运行的代理，必须协调不同的身份和定义。没有任何单一应用能自动代表完整的业务。

咨询公司和内部平台团队将面临整合这些系统的压力。它们的价值将从构建孤立的演示案例，转向定义可复用的上下文服务、评估标准和治理控制。

企业买方承担着最艰巨的责任。供应商可以提供连接器和记忆系统，但只有企业自身能够决定哪个来源具有权威性。企业必须定义“活跃客户”“已批准折扣”或“已解决事件”究竟意味着什么。

这项工作往往会暴露出早于 AI 的分歧。两个部门可能对同一指标名称采用不同计算方法。代理并不会制造这种冲突，但可能将其暴露并放大。

知识工作者也应关注，因为上下文设计会影响哪些判断被编码进系统。如果系统只纳入正式文档，有价值的例外情况和实践经验可能会消失；如果纳入所有非正式对话，隐私和质量风险则会增加。

经过审慎设计的 second brain 可以帮助个人保存决策及其支撑材料。企业系统还需要针对共享所有权、权限、保留和可审计性设置额外控制。

开发者需要将上下文管道视为生产软件。检索提示词、文档解析器、排序规则、记忆策略和工具架构，都需要版本控制和测试。任何一层的变化都可能改变代理的行为。

产品经理需要使用范围不止于使用量的指标。一个被频繁使用的助手，仍可能提供低质量建议。更好的信号包括经过验证的任务完成情况、纠正率、升级处理模式、来源覆盖率，以及在既定工作流中节省的时间。

安全团队将成为核心参与者，而不再只是最终审核者。代理权限必须与用户身份、任务范围和现行政策相匹配。日志必须同时显示信息访问情况和已采取的操作。

因此，Cotrufo 的框架重新分配了组织内的关注重点。企业 AI 项目不再主要是模型集成项目，而是持续组织知识、权限、记忆和反馈的工作。

这比“安装一个更聪明的模型”提出了更高要求。它也解释了为何上下文可能成为持久的差异化因素。竞争对手可以授权使用相似的模型，但并不共享同样的机构知识或运营纪律。

Google News 读者接下来应关注什么

上下文优先的论点将由生产环境证据验证，而非新一轮品类发布公告。

第一个信号是可衡量的工作流表现。企业应报告具备上下文感知能力的代理是否能准确完成既定任务，而不只是员工是否打开了聊天机器人。纠正率、升级处理、来源有效性和成功的工具操作，比采用总量更能说明问题。

如果这些指标在企业维持相同基础模型的情况下得到改善，Cotrufo 的论点就会更有说服力。如果模型升级带来的提升大于上下文变化，这一标题所构建的层级关系就更难成立。

第二个信号是模型可移植性。供应商日益宣称，企业可以在更换模型的同时保留其上下文层。买方应通过在多个提供商之间运行相同任务、证据、权限和评估来检验这一承诺。

成功切换将表明，机构上下文正在成为持久资产。昂贵的重写成本或重大的行为变化，则会揭示所谓模型中立系统中隐藏的依赖关系。

第三个信号是实时条件下的治理。上下文平台必须证明，它们能够处理被撤销的权限、变化的政策、被删除的记录和被污染的内容，同时不会泄露数据或循环使用陈旧答案。

在静态演示中表现良好、却在政策更新后失效的系统，并没有真正解决企业问题。信息新鲜度、可追溯性和纠错能力必须持续有效。

这则 Google News 标题值得关注，因为它捕捉到了企业 AI 优先级的真实变化。但不应将其解读为 Cotrufo、Redis 或其他任何供应商已经解决了上下文问题的证据。

对于开发者和企业采购方而言，眼下的行动很明确：从源记录到最终决策，审计一条生产环境工作流程。识别模型看到了什么、遗漏了什么、每项事实由谁掌控，以及错误如何得到纠正。

随后，测试更换模型是否能够解决已观察到的失败问题。如果不能，瓶颈很可能存在于其他环节。只有当上下文投入能在真实业务压力下带来更安全、更准确的工作成果时，Cotrufo 的主张才会获得持久的现实意义。