**企业上下文工程，就是把散落在消息、文档、CRM、ERP 和项目系统里的信息，整理成 AI 在当前任务中能正确使用的“人、对象、状态、证据和权限”。**它不是把资料全部塞进向量库，而是让 AI 知道哪位“王经理”、哪个项目、哪份版本，以及此刻谁有权看到什么。
它适合客户多、项目多、文档版本频繁变化、同一任务跨群聊和业务系统的企业；如果资料量很小、答案长期固定、只需按关键词查文档，先做好普通知识库即可。
为什么搜到资料仍然会答错
企业里的错误通常不是“完全没搜到”，而是搜到了不该拼在一起的东西：群里有人说“已完成”，代码其实只是提交；旧报价和新报价同时存在；项目群里并行讨论多个工作；销售姓名出现在目录里，却不是 CRM 当前负责人。
| 常见提问 | 只搜文档的风险 | 上下文工程应返回什么 |
|---|---|---|
| 这个客户现在怎样 | 拼出几段跟进和方案 | 当前负责人、有效商机、订单、回款、项目、最近事件与下一动作 |
| 项目做完了吗 | 命中“已完成”三个字 | 实现、部署、激活、真实验证、客户验收等各轴状态 |
| 这是谁决定的 | 把讨论当决定 | 决定人、时间、适用范围、生效状态及替代对象 |
| 哪份制度有效 | 新旧文件一起召回 | 当前批准版本、有效期、Owner、例外和历史版本 |
| 能否修改这条记录 | 只判断“查得到” | Agent 能力、请求人权限、对象政策与当次审批的交集 |
这张表也是立项判断：如果企业最痛的是“资料难找”，先做 企业知识中枢；如果最痛的是“找到了仍不知道当前到底怎样”，就要进入对象和状态层。
六层结构：从证据到可执行上下文
上下文工程可以按六层理解：
- 证据：原消息、文档、合同、数据库记录和日志只追加保存，不被 AI 改写；
- 陈述：从证据中抽取事实、决定、承诺、观察或推论，并保留是谁说的；
- 对象与关系：给员工、客户、项目、订单、制度等稳定 ID，名称只是别名；
- 事件与状态：用事件重建当前态，旧状态不被一句新摘要覆盖；
- 工作对象：把决定、任务、风险、指标、验收变成可跟踪对象；
- 动作：查询与写入分开授权，执行后保存回执并回读终态。
真正送进 Agent 的，也不是十段“相似文本”，而是“请求者身份 + 本次目的 + 对象关系切片 + 当前状态 + 最近事件 + 未完成任务 + 规则 + 证据 + 冲突 + 允许动作”。这比无限扩大上下文窗口可靠得多。
从一个项目开始怎么做
不要从全公司对象图谱开始。先选一类高频提问，例如项目经理每天都要回答的“项目现在到哪、下一步谁负责”。
**第一步，列对象。**至少拆开客户、商机、合同、订单、项目和验收，不把它们压成一个“项目状态”。
**第二步，定权威源。**合同金额回合同或财务，客户负责人回 CRM，发布状态回 Git、CI 和生产探针；群消息只作为过程和承诺证据。
**第三步，定状态轴。**方案完成、代码完成、已经部署、真实业务跑通、客户验收不是同一个状态。每条状态都要有时间和证据。
**第四步，定权限。**销售可看自己客户，项目经理可看交付范围，财务字段按角色单独控制。权限应在检索前生效，不能先把敏感内容召回后再遮字。
**第五步，跑冲突用例。**故意放入旧版本、同名人员、矛盾进度和缺字段，检查 Agent 会不会明确说“存在冲突，待确认”，而不是自行选一个顺眼答案。
**第六步，接一个低风险动作。**例如生成项目风险待办草稿，由项目经理确认后写回，再独立读取系统确认写入成功。
验收不要数“导入了多少文档”
第一阶段更值得看的指标是：对象事实准确率、引用能否定位、过期内容误召回率、跨项目越权率、冲突误裁率、承诺遗漏率和写后回查率。其中跨项目越权必须为零。
如果当前 RAG 还没有 Owner、版本、权限和评测集，先读什么是 RAG：先管住知识边界；如果已经准备让 Agent 执行动作，再对照AI Agent 数据安全架构和企业 AI 落地工程补齐授权、审计与验收。
上下文工程的目标不是建立一个“知道一切”的大脑，而是让 AI 对每次任务都拿到足够、当前、可追溯且不越权的事实。少而准的上下文，比一仓库未经裁决的资料更有用。
