制度、流程、产品资料、客户记录、会议纪要、项目复盘，散落在网盘、知识库、CRM、邮件、聊天记录和员工电脑里。很多企业因此认为，只要把这些资料集中起来，再接入一个大模型，AI就能理解公司、回答问题，甚至自动工作。

但真正上线后，常见的结果是：AI能找到一份文件，却不知道它是不是最新版；能读懂一段制度，却不知道适用于哪个部门；能总结历史方案，却不知道这次客户已经进入什么阶段；能给出一个看似合理的答案，却无法说明依据来自哪里、谁有权使用、下一步可以做什么。

问题不一定出在模型，也不只是“检索不够准”。

更根本的原因是：企业把文档存储，当成了知识系统；把能被搜索，当成了能被执行。

对AI Agent而言，真正有价值的不是“更多文件”，而是在当前任务中可验证、可授权、可行动的上下文。

从文档仓库到企业上下文系统

01 文档回答“写了什么”，上下文回答“现在该怎么做”

一份文档通常记录某个时点的内容。它可能是一项制度、一套方法、一段经验，也可能只是某次讨论的中间结果。

但企业行动需要的，不只是内容本身，还包括内容周围的关系：

·这份信息的权威来源是谁？

·它在什么时间、什么范围内有效？

·它与哪些客户、合同、产品、流程和指标有关？

·当前任务处于哪个状态？

·当前使用者能看到什么、能修改什么？

·哪些动作可以自动执行，哪些必须人工审批？

·执行结果是否需要回写，谁负责确认？

这些信息合在一起，才构成Agent能够工作的“企业上下文”。

Anthropic在其Agent上下文工程文章中指出，随着系统从单轮问答走向长周期、多步骤执行，关键问题已经不只是如何写提示词，而是如何持续选择并维护模型在当下真正需要的信息。上下文窗口再大，也会受到无关信息、过期信息和注意力分散的影响。

这意味着，企业知识建设的目标不能只是“把所有资料都塞给AI”。更可靠的方向是：在需要时提供最小而高信号的信息集合，并保留回到原始来源的路径。

02 为什么传统知识库很难直接支撑Agent

第一，缺少唯一可信来源

同一个政策可能存在三个版本；同一个客户可能在CRM、表格和群聊中有三种状态；同一个指标在不同部门有不同口径。

人可以通过经验猜测“哪个大概是真的”，Agent却会把冲突内容一起检索出来。如果没有明确的权威系统、版本和责任人，AI越善于生成语言，越可能把冲突包装成一个流畅答案。

第二，缺少业务关系

传统文档以文件夹和页面组织内容，企业运行却依赖实体与关系：客户属于哪个行业，合同关联哪个项目，项目采用哪套交付方法，指标由谁负责，异常要升级给谁。

如果这些关系没有被表达，Agent看到的是许多文字片段，而不是一个可以推理和行动的业务世界。

第三，缺少实时状态和权限

“标准销售流程”写在文档里，但某个客户现在是在初次接触、方案评估还是合同谈判阶段，往往记录在业务系统中。能否向客户发信、能否读取报价、能否修改项目状态，也取决于用户身份和当前授权。

Microsoft关于企业Agent知识层的官方资料，把多来源检索、引用、访问控制和调用者身份放在同一套机制中。它所揭示的原则很重要：知识是否可用，不能脱离谁在问、为什么问、在什么权限下问。

第四，缺少从结果回到知识的闭环

很多知识库只负责收集，不负责验证使用效果。AI引用了什么、采用了哪条方法、结果是否正确、专家做了什么修正，这些信号没有回流。

于是知识库越积越大，组织却不知道哪些知识真的帮助了决策，哪些已经失效，哪些只是看起来专业。

03 FutureFusion企业可执行上下文五层模型

为了让知识真正支撑Agent工作，我们建议把企业上下文分成五层。它不是某一家厂商的标准，而是FutureFusion基于公开实践形成的实施框架。

企业可执行上下文五层模型

第一层：权威来源层

保存事实所在的原始系统：合同在合同系统，客户状态在CRM，财务数据在财务系统，制度在受控文档库，项目决定在正式决策记录中。

这一层首先回答：什么是事实，事实在哪里，以谁的记录为准。

Obsidian可以承载人类可读的知识、方法和决策脉络，但不应代替需要唯一性、权限控制和强一致性的交易系统。

第二层：语义关系层

把企业中的客户、产品、项目、角色、指标、规则和方法等对象表达出来，并建立它们之间的关系。

这一层不是追求一次建成庞大的知识图谱，而是围绕当前场景先表达足够的业务含义。例如：客户—对应—项目，项目—采用—交付方法，异常—升级给—负责人。

第三层：规则与权限层

记录适用条件、敏感等级、角色权限、审批要求、禁止动作和有效期限。

同一条知识，对不同的人可能可见范围不同；同一个建议，在不同风险等级下可能对应自动执行、人工审批或禁止代理。它与上一期提出的“动作分级”和“六道控制门”共同组成治理边界。

第四层：工作流状态层

告诉Agent当前任务正在发生什么：目标、责任人、截止时间、前置依赖、已完成步骤、异常状态和验收标准。

没有这一层，AI只能回答“通常应该怎么做”；有了这一层，AI才可能判断“这一次下一步应该做什么”。

第五层：按需供给与行动层

Agent不必一次读完所有资料，而应根据任务按需检索，把少量高相关、可追溯的信息装入当前上下文；随后在授权范围内调用工具、生成结果，并把引用、动作和结果留下记录。

这也是“可执行上下文”与普通搜索最大的区别：它不仅帮助AI回答，还约束AI如何行动。

04 从文档库走向可执行上下文，不需要先做大工程

企业最容易犯的错误，是一开始就规划一个覆盖全公司的“统一知识大脑”。项目范围迅速膨胀，业务价值却迟迟无法验证。

更稳妥的路径，是从一个真实工作流开始。

第一步：选择一个高频、边界清晰的任务

例如售前方案准备、项目周报生成、客服升级判断、设备故障初步诊断或合同条款核对。

首个场景应满足三个条件：有人持续使用，结果可以验收，错误可以被发现和纠正。

第二步：声明每类信息的权威来源

不要只列“有哪些文件”，而要明确：客户状态以CRM为准，价格以报价系统为准，标准条款以受控合同模板为准，项目经验以已验收复盘为参考。

当来源冲突时，系统不应自行平均，而应暴露冲突并请求确认。

第三步：把内容分成事实、判断、决定和方法

事实需要证据；判断需要说明推理依据；决定需要责任人和日期；方法需要适用条件、步骤与验收方式。

如果这些类别混在一起，Agent很容易把某次讨论意见误当成正式政策，或把历史做法误当成当前决定。

第四步：补上关系、权限和时效

至少回答四个问题：它与谁有关，适用于什么情境，谁可以使用，什么时候需要复核。

这一步往往比增加更多文档更能提高AI的可靠性。

第五步：让使用结果反向更新知识

记录Agent检索了哪些来源、哪些内容被采纳、专家修改了什么、最终结果如何。被重复验证的方法可以升级为标准流程；被纠正的内容需要标记原因；过期知识要保留历史但停止默认推荐。

企业知识从工作中持续生长

05 衡量知识库，不要只看“收录了多少篇”

文档数量、页面访问量和向量条目数，能够描述系统规模，却不能证明它产生了业务价值。

更值得关注的是：

·权威来源覆盖率：关键问题是否能落到明确的系统或责任人？

·引用可追溯率：Agent给出的重要结论能否回到原始证据？

·知识新鲜度：高影响内容是否按时复核，过期内容是否被识别？

·权限正确率：不同用户是否只得到其有权访问的信息？

·无法回答率：当证据不足时，Agent是否会明确说不知道并升级给人？

·返工率：Agent产出被人工大幅修改的比例是否下降？

·业务结果：交付时间、决策周期、错误率或客户响应是否改善？

Microsoft的Agent采用指南把知识质量称为规模化的关键约束之一，并建议持续观察事实准确性、引用覆盖、知识新鲜度和回退情况。这里最重要的不是照搬某家平台的指标，而是承认一个现实：没有质量度量的知识库，只是在积累未经验证的输入。

结语：知识的终点不是被保存，而是被正确使用

企业知识库的下一阶段，不是把更多文件交给大模型，而是建立一条可信链路：

从权威来源出发，经过语义关系、规则权限和实时状态，在需要的时刻形成最小高信号上下文，支持Agent完成受控行动，再把结果反馈回知识系统。

这条链路一旦建立，知识就不再只是供人查阅的历史资料，而会逐步成为企业工作流中的基础设施。

AI Agent真正需要的，从来不是一个无限扩张的文档仓库。

它需要的是一个知道什么可信、什么相关、谁能使用、何时有效，以及下一步允许做什么的企业上下文系统。

资料来源

1.Anthropic, Effective context engineering for AI agents, 2025-09-29：https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

2.Microsoft Learn, What is Foundry IQ?，页面标注更新于2026-08-01：https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/what-is-foundry-iq

3.Microsoft Learn, Business Expert Empowerment adoption pattern：https://learn.microsoft.com/en-us/agents/adoption-patterns/pattern-business-expert-empowerment

4.Microsoft Learn, Connect Agents to Foundry IQ Knowledge Bases，页面标注更新于2026-09-17：https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/foundry-iq-connect

5.Palantir, The Ontology system：https://www.palantir.com/docs/foundry/ontology/overview