工作上下文与文档库的分工

企业知识管理中，一个常见误区是把工作上下文与文档库当成同一种系统。两者都在承载信息，却解决不同的问题：文档库回答“正式内容在哪里、具体写了什么”，工作上下文回答“这件事为什么这样决定、当前由谁推进、哪些信息仍然有效”。如果不区分二者，企业很容易把所有沟通记录堆进检索系统，最后得到大量相关片段，却无法让 Agent 准确理解任务背景。

文档库负责权威沉淀

文档库适合管理制度、规范、方案、操作手册等相对稳定的内容。它强调版本、权限、分类和统一查阅，核心目标是保证员工能够找到经过确认的正式信息。对于“某项流程如何执行”“制度条款是什么”这类问题，文档库通常是更可靠的依据。

但文档库并不天然记录一项决定是如何形成的。责任人调整、会议中的临时意见、跨部门协作中的约定，往往散落在即时通讯、会议纪要、审批和任务记录中。只依赖最终文档，Agent 可能找到结论，却无法判断它适用于哪个项目、对应哪个阶段，甚至无法识别结论是否已经变化。

工作上下文负责还原关系

工作上下文的价值不在于复制更多文件，而在于整理人与事之间的动态关系。以 MyContext 的定位为例，它可以将即时通讯、文档、日历、会议、审批和本地活动等工作数据，持续整理为私有、可演进的上下文档案。档案不仅包含内容，还可以关联职责范围、协作关系、讨论结论、来源和时间。

这使 Agent 获得了任务判断所需的背景。当同一事项出现前后不一致的信息时，系统不应简单地用“最新内容”覆盖历史，而要区分信息是被替代、并存，还是需要人工确认。来源可回溯尤其重要，因为企业真正需要的不是听起来确定的答案，而是能够复核其依据的判断。

两者应当协同，而不是互相替代

更合理的分工是：文档库保存正式且稳定的权威内容，工作上下文连接动态沟通、协作过程与业务变化。前者提供“规则依据”，后者补足“情境依据”。Agent 先依据权限获取相关上下文，再结合文档库中的正式内容回答或执行任务，才能同时兼顾准确性与可解释性。

企业落地时，应从边界清晰的项目协作或事项跟进场景开始，检查三点：背景信息是否确实存在于可授权的数据源中，关键判断能否追溯到来源和时间，冲突内容是否保留人工确认机制。只有在这三点成立时，工作上下文才不是文档库的重复建设，而是让知识系统从“找到资料”进一步走向“理解工作”。