知识治理与 AI 准备度
盘点、清理、去重、分类并管理企业知识版本，使其可以被 AI 可靠使用。
真正的瓶颈通常在模型之外。
当上下文分散、过期、缺少权限控制，或者没有连接真实业务流程时，企业 AI 很难进入生产。
- 知识互相冲突
- 制度、手册和产品资料版本不一致，AI 往往检索到最容易找到的版本。
- 实时数据被隔离
- 库存、价格和状态留在 ERP、CRM 或数据库中，静态文档索引无法保持最新。
- 权限在回答时消失
- 如果没有身份和访问控制，同一个正确答案也可能泄露给不该看到的人。
- 缺少生产反馈闭环
- 团队看不到检索失败、无依据结论，以及系统反复答不好的问题。
企业上下文栈
一个系统，七层上下文。
上下文工程规定 AI 可以知道、检索、记住、调用和呈现什么，并为每一层设置责任人与边界。
- 指令
- 系统规则、回答边界和人工升级策略。
- 身份
- 提问者、角色、部门、语言和会话范围。
- 企业知识
- 经过清理、版本管理的文档、定义和产品资料。
- 检索
- 信息源选择、过滤、排序和证据质量。
- 记忆
- 哪些内容可以保留、保留多久、谁能检查或删除。
- 工具与实时数据
- 对 ERP、CRM、数据库、计算器和 API 的受控访问。
- 权限与来源
- 访问控制、引用、时间戳和完整审计记录。
我们设计和构建什么
项目从真实业务问题出发，只组合解决这个问题所需要的上下文层。
企业 RAG 与 AI 搜索
构建具备权限控制、准确引用、拒答规则和可测评能力的检索系统。
业务数据与工具集成
把数字和实时状态问题路由到 SQL、ERP、CRM 或边界明确的 API。
Agent 与工作流上下文
设计工具白名单、记忆边界、审批节点、迭代预算与审计日志。
让每类问题走正确的路径。
生产级上下文层会根据数据来源和任务类型进行路由，同一种检索方式无法处理所有企业问题。
| 问题类型 | 合适路径 | 原因 |
|---|---|---|
| 答案存在于受治理文档中 | 带引用的 RAG | 速度快、行为可预测，方便核验。 |
| 汇总、趋势或当前业务数值 | SQL 或实时 API | 答案需要计算或读取系统当前状态。 |
| 可重复的多步骤输出 | 确定性工作流 | 固定路径更容易测试、运维和审计。 |
| 跨多个来源且路径未知 | 有边界的 Agentic Retrieval | 下一步搜索取决于上一步发现的证据。 |
从一次上下文评估开始。
一小部分真实数据和真实问题，就足以在大规模建设前确定正确架构。
你提供
- 20 到 50 个真实业务问题
- 文档与数据源样本
- 现有权限规则和失败案例
你获得
- RAG、SQL、工具和 Agent 路由图
- 按影响排序的知识与权限风险
- 带评估标准的生产实施方案
- 回答因用户而不同
- 销售、工程、客服和客户不应该获得完全相同的上下文。
- 事实分散在多个系统
- 文档解释规则，ERP 或 CRM 保存当前数值。
- 来源必须可以核验
- 重要结论需要对应文档、页码、责任人和日期。
- AI 需要采取行动
- 工具调用和流程变更必须有审批、限制与审计记录。
决策者常见问题
企业上下文工程常见问题
什么是企业上下文工程？
企业上下文工程负责设计 AI 系统可以知道、检索、记住和执行的一切。它连接受治理的企业知识、实时数据、身份、权限、工具和来源信息，使回答保持相关、安全并且可以核验。
上下文工程和 RAG 是一回事吗？
RAG 是上下文架构中的检索层。企业上下文工程还包括知识治理、实时系统、身份权限、记忆、工具访问、引用和生产反馈。
企业是否需要购买上下文工程平台？
不一定。平台可以加速检索、治理或数据连接，但企业自己的数据模型、权限和流程通常仍然需要定制集成。评估会明确哪些应该购买、集成或定制。
可以把 AI Agent 连接到 ERP、CRM 和内部数据库吗？
可以。实时数值应通过范围明确、经过权限检查的工具或查询读取。文档类知识则保留在受治理的检索系统中。
什么时候应该使用 Agentic RAG？
当答案路径会随着证据变化，并且需要跨多个来源继续搜索时，可以使用有明确边界的 Agentic Retrieval。可预测的文档问题通常只需要高质量 RAG。
先构建上下文，再扩大 Agent 的能力。
带上真实问题、真实信息源和试点失败的约束，我们会设计一套能够可靠回答的最小生产架构。