企业上下文管理：AI 时代不脱节的基础设施

2026 年，真正拉开企业差距的，不是模型本身，也不是又接入了几个智能体。是企业有没有把自身知识，变成 Agent 可依赖、可执行、可审计的上下文。

没有高质量上下文，Agent 只能做表面问答或通用任务。有了它，Agent 才能稳定完成多步业务闭环。

这不是效率优化，而是企业能否在 Agent 时代继续运转的分水岭。

演示好看，生产难用

这两年企业的动作是有节奏的：先试大模型，再上知识库，现在轮到智能体。

门槛也确实塌了。OpenClaw 这类开源智能体框架流行之后，一个人花一晚上就能「养」起一只龙虾——它会自己开浏览器、改文件、发邮件、填表单。它不只是会说话，它会动手。于是企业内部的智能体试点也一批批立了项。

结果却普遍一样：演示好看，生产难用。

演示环节里，问题是精心挑的，数据是干净的，流程只有一步。而一旦进入真实业务，Agent 面对的是同一份报价在三个系统里有三个版本、流程规则写在某个人的经验里而不是文档里、权限边界谁也说不清。它拿到的信息越多，反而越容易被互相矛盾的内容带偏。

核心原因只有一个：上下文质量不过关。

从 Prompt Engineering 到 Context Engineering

行业的重心已经从 Prompt Engineering 转向 Context Engineering。

Anthropic 对它的定义很清楚：Context Engineering 是在推理时系统地筛选、组织、维护进入模型的最优信息集合。

这里的关键词是最优，不是最多。上下文窗口变大之后，很多团队的第一反应是「那就都塞进去」——把整个知识库、整个工单历史、整个代码仓库一股脑喂给模型。这恰恰是在制造问题：无关信息会稀释注意力，过期文档会覆盖正确答案，互相冲突的两份资料会让模型在两个方向之间摇摆。

Prompt Engineering 关心的是「这一句话怎么问」。Context Engineering 关心的是「模型在做决策的那一刻，手里到底握着什么」。前者是技巧，后者是工程。

模型再强，上下文烂，Agent 就会幻觉、漂移、无法交付。

个人养得起龙虾，企业养不起

信息喂错，是第一重问题。第二重问题出在权限上。

一个人养龙虾，最坏的结果是自己电脑上的文件被误删、某个账号被搞乱——代价自己担，一晚上重来一次就是了。企业不行。一个真会动手的 Agent 跑偏，动的是真实订单、真实资金、真实客户。

这就是被称为龙虾悖论的困境：想让它做的事越多，给它的权限就必须越大；而权限越大，出事的代价就越高。想要它有用，就得放开手；一放开手，就没人敢保证它不闯祸。

很多企业的第一反应是收紧权限。收到最后，Agent 退回成一个只能查资料、写草稿的聊天框——安全了，也没用了。这不是解，这是放弃。

悖论的出口，不在「给多少权限」这个刻度上。真正该问的是三个问题：它依据的事实可靠吗？它能动手的范围画清楚了吗？它做完之后查得清吗？

这三个问题，恰好就是下面三根柱子。

可依赖、可执行、可审计

「把企业知识变成 Agent 的上下文」听起来像是一个搬运动作——把文档灌进向量库就完事。但决定成败的是三个工程属性，它们分别回答上面那三个问题。缺一个，Agent 就退回到表面问答。

可依赖，指的是知识有唯一事实源、有时效、冲突有裁决规则。同一个客户的合同金额，如果 CRM、财务系统、某份 PPT 里各写一个数，那么 Agent 引用哪一个都是在赌博。可依赖不是「找得到」，是「找到的那一份可以拿来做决定」。

可执行，指的是上下文不只是能被检索到的文字，而是 Agent 能据此发起动作的结构——接口在哪、参数怎么填、权限边界到哪、什么情况下必须停下来交给人。一段描述退款政策的文字只能用来回答问题；一份带上接口、参数、审批阈值的退款规则，才能让 Agent 真的把退款走完。

可审计，指的是每一次决策都能回溯到它当时看到的上下文。出了问题，你得能分清是模型推错了，还是我们喂错了。没有这一层，任何一次事故都只能归因到「AI 不靠谱」，既修不了，也没人敢再往前推一步。

所以可审计不是事后的合规负担，它是权限敢不敢放大的前提：查得清，才敢放得开。龙虾悖论真正的解，不是把权限调小，而是让每一份放出去的权限都有据可依、有界可停、有账可查。

这三条合起来才叫基础设施：它不是某个部门的项目，而是所有 Agent 应用共用的地基。

分水岭在哪里

判断一家企业有没有跨过这条线，只需要看一个问题：Agent 能不能独立跑完一段完整的业务？

跑不完的，Agent 就停留在助手层——回答问题、生成草稿、总结会议纪要。这些确实省时间，但它省的是个人的时间，企业的流程一步没变。

跑得完的，Agent 才进入流程层——它能查到正确的事实、能调用真实的系统、能在越界时停下来、事后能被复盘。到这一步，企业的运转方式才真正开始改变。

区别不在模型，在上下文。

从哪里开始

不需要一上来就建「企业级上下文平台」，那通常又是一个演示好看的项目。

更有效的做法是反过来：先挑一段真实的、跑得通的业务闭环——一次退款、一次工单流转、一次合规检查——然后只为这一段，把它依赖的知识做成可依赖、可执行、可审计的上下文。跑通之后，这套结构本身就是模板，第二段业务的成本会低得多。

先有一条能跑的闭环，再谈平台。这也是白泽明理一贯的做法：不从「该养哪只龙虾」开始，从「哪一段业务值得先被 Agent 跑通」开始。