通用上下文工程（含 MyContext 类）
能到这一步，已经很强了
- 四条信息全部收拢、去重、带出处
- 识别出 1 与 2、3 存在事实冲突
- 下调置信度
- 每条可点回原始群聊 / 系统记录
最终产物
「存在冲突，请人工判断。」
企业上下文工程
上下文不只是数据，它还需要一部宪法——在「认知上下文」与「行动上下文」之外，补上缺位的第三类：规范上下文，把公司的制度、口径与合规红线写成 Agent 认得的规矩。
20+ 行业 · 50+ 案例1–7 天整套方案交付可接在钉钉 / 企微 / 飞书上下文之上
Context Is the Bottleneck
2026，所有人的 Agent 都听不懂人话
不是模型不够强，是 Agent 从没进过公司的业务现场。
150PB
中大型企业平均数据规模
66%
认为数据基建拖慢 Agent 落地
80%
已把“用好自家数据”列为优先
数据来源：Confluent 2026 企业调查 · 2026 杭州云栖大会
Four Players, One Gap
全行业达成共识：上下文是瓶颈
但四条路线，解法完全不同。
| 玩家 | 核心主张 | 它补的是哪一层 | 它回答的问题 |
|---|---|---|---|
| Palantir | Ontology 统一企业对象、关系与业务逻辑 | 可执行语义层 | 企业里有什么，怎么连 |
| Glean | Enterprise Graph 连接人 · 项目 · 文档 · 实体 | 关系图谱层 | 谁和谁有关 |
| Microsoft | Microsoft Graph + Copilot Connector | 数据接入与权限层 | 你能看哪些数据 |
| 千问办公（2026.9.22 云栖大会） | MyContext / Enterprise Context | 上下文加工层 | 发生过什么 |
四条路线方向一致，但都停在同一个地方——它们告诉 Agent 「企业是这样运转的」，没人告诉它「哪些运转是违规的」。这就是我们要补的最后一公里：规范上下文。
A Real Monday Morning
先别谈架构，看一个真实的周一早上
同一个问题，两套上下文的产物完全不同。
▍业务现场：客户王总到底签约了没有？
钉钉群聊 · 昨天 19:40
销售小李：「客户王总口头确认了，下周就签约！」
CRM 系统 · 今天 08:00
合同状态 = 草稿，未提交审批
ERP 系统 · 今天 08:00
该客户名下无订单、无框架协议
项目周报 · 今天 09:00
项目经理：「流程还没走完，别发货。」
企业上下文工程 · FlyOntOS
再往前一步：自动裁决，且可追溯
- 命中《合同管理办法》第 3.2 条
- 该条款声明：以 CRM 合同状态为唯一有效口径
- 销售口头承诺不构成有效承诺，降为辅证
- 同时激活「流程待办」提醒 → 推送 PM
最终产物
「未签约。依据：合同管理办法 §3.2，口径源：CRM。冲突已留痕，待办已派发。」
前者把裁决权还给人类；后者把裁决权写进契约，人类只在例外时被叫醒。
Three Types, Not Two
企业上下文，其实有三类
认知上下文让人懂，行动上下文让人做，规范上下文让人不敢乱来。
| 类型 | 回答的问题 | 内容是什么 | 行业现状 |
|---|---|---|---|
| 认知上下文 Cognitive | 发生了什么？ | 组织知识、业务事实、流程状态、人与关系 | ✓ 千问 MyContext 已解决 |
| 行动上下文 Actionable | 我能做什么？ | 工具、权限、API、可执行动作边界 | ✓ Agent 托管 / MCP 已覆盖 |
| 规范上下文 Normative | 什么是被允许的？ | 制度、口径优先级、业务公理、合规红线、例外条款 | ✗ 行业空白 |
没有第三类的下场：Agent 知道客户说了什么，也知道怎么调 ERP——但不知道擅自调 ERP 是违规的。这正是「上下文越丰富，Agent 越敢越界」的根因。
Head-to-head
和千问办公 Enterprise Context 差在哪
不是替代，是接棒——它修完的路，我们跑最后一公里。
| 维度 | 千问办公 MyContext / Enterprise Context | 企业上下文工程 · FlyOntOS |
|---|---|---|
| 起点 | 企业的散落数据（聊天 · 文档 · 会议 · 审批） | 企业的制度 / 标准 / 口径 |
| 核心命题 | 「怎样才能让 Agent 听见企业」 | 「哪些运转是违规的」 |
| 产物形态 | 带置信度的工作档案（可查阅） | 带约束的语义契约（可执行） |
| ★ 事实冲突怎么办 | 三态合并：保留多条 + 降置信度 + 显式抛给人 | 按本体声明的口径优先级自动裁决 |
| ★ 置信度从哪来 | 重复出现的次数（数据驱动） | 门禁通过与否（规范驱动） |
| ★ 可追溯到 | 出处：哪次聊天 · 哪份文档 | 依据：条款 · 口径 · 责任人 |
| 版本演化 | 随数据流持续漂移 | 制度变更驱动的版本化基线 |
| 正确性保证 | 无形式化验证 | 四维门禁 + 黄金集 100% 自动回归 |
| 覆盖层位 | 认知 + 行动上下文（前两类） | 规范上下文（第三类） |
一句话：它让 Agent 听得见企业，我们让 Agent 守得住规矩。翻译给 CIO 听：前者解决「能不能答出来」，后者解决「答错了谁负责」。
Why Repetition ≠ Confidence
为什么「重复次数」不能当置信度
数据驱动的置信度有一个致命盲区。
⚠ 会议室三人成虎
MyContext 用「滑动时间窗持续聚合证据」：某个事实反复出现，重复本身转化为置信度信号。这套机制在多数情况下有效，但它有一个致命盲区——
反例：跨部门的口径讹传
财务在群里说「这批物料税率按 13%」→ 采购转述给仓储 → 仓储写进出库单 → 三个部门的五次会议都在复述。重复 12 次，置信度拉满。但实际政策是 9%，源头那句话本身就是错的。数据驱动的置信度，会把「三人成虎」算成「板上钉钉」。
规范驱动的置信度不关心被说了几遍。它只问一件事：这条信息，是否通过了《税务口径管理办法 v2.3》的约束校验？通过 → 置信。不通过 → 拦截，与重复次数无关。
Five-Step Pipeline
企业上下文工程：五道工序
纳 · 辩 · 束 · 裁 · 证——一条把制度变成契约的流水线。
纳 Ingest
①FlyWork 文档物料化：制度 / 标准 / SOP / 纪要 → 干净结构化知识。
辩 Disambiguate
②本体归一：同义词消歧、口径对齐、跨系统实体合并。
束 Constrain
③SHACL + SWRL：把「管理办法第 3.2 条」写成机器可执行约束。
裁 Adjudicate
④口径优先级仲裁：冲突不再抛给人，按契约自动定夺。
证 Verify
⑤四维门禁 + 黄金集回归：上下文变更必须通过才准上线。
前三道工序解决「接得进来」，④⑤ 解决「敢不敢用」。行业大部分玩家停在前三道。
OntOS Six Layers
OntOS 六层，各在上下文工程里干什么
规范上下文要落到 FlyOntOS 六层本体的每一层。
| 层级 | 层名 | 在上下文工程中的职责 |
|---|---|---|
| L1 | 核心业务本体 | 领域概念与静态常识底库——规范上下文的词汇表 |
| L2 | 桥接层 | 跨系统语义对齐：CRM 的「客户」是不是 ERP 的「客商」？等价类在此声明（工序②） |
| L3 | 能力本体 | 技能注册与路由——承接行动上下文，决定 Agent 能调用哪些动作 |
| L4 | 上下文本体 ★ 本栏目主战场 | 语义预算 · 钉住机制 · 长上下文调度——治理「装不下、跑了、串了」 |
| L5 | 记忆本体 | BDI 四维记忆：把被裁决过的结果沉淀为组织经验（工序④的留痕） |
| L6 | 质量本体 | 黄金集 + 100% 自动回归——上下文的合格证（工序⑤） |
原来 L4 只解决「上下文怎么装得下」。加上企业上下文工程后，它还要回答：「装进去的东西，凭什么可信。」
Existing Capabilities, Rearranged
不是新产品，是已有能力的合流
企业上下文工程 = 现有产品矩阵在上下文这条主线上的重新排兵布阵。
| 现有模块 | 在企业上下文工程中的角色 | 对应工序 |
|---|---|---|
| FlyWork（文档物料化） | 把 PDF / Word / Excel / 网页里的管理制度、技术口径、审批规则，转成可治理的结构化知识。没有这一步，第三类上下文无米下锅。 | ① 纳 |
| FlyOntOS 六层本体 | 规范上下文的载体。制度条款 → 本体约束 → 可执行公理。 | ②③ |
| 四维质量门禁（语义 · 逻辑 · 约束 · 性能） | 上下文上线前的强制检查站。任一维不通过，上下文不得进入 Agent 链路。 | ⑤ 证 |
| 100+ onto_* MCP 工具 | 上下文的存取、调用、溯源接口；把裁决结果以标准协议递给任意 Agent。 | 全链路 |
| 黄金集回归 | 制度一改，上下文就得重算？不用——跑一遍黄金集就知道有没有破坏存量语义。 | ⑤ 证 |
| RLVR 3.0（本体 × Agent × 强化学习） | 用户对裁决结果的采纳 / 驳回，持续回流为本体优化的奖励信号。 | 持续演化 |
| CAR 方法论 | Reason 定义「什么是合规答案」→ Construct 最小化建模 → Align 制度变更自动对齐。 | 方法学 |
Ontology Vendor Advantage
这活为什么本体厂商才能干
裁决、口径与责任，恰好都落在本体工程的能力圈内。
裁决必须形式化
「以 CRM 为准」这句话，人要看得懂，机器也要能执行。只有走到 SHACL / SWRL，裁决才不是一句注释。
不是配置项，是可执行的公理
跨系统口径是本体题
CRM 的「客户」、ERP 的「客商」、钉钉的「外部联系人」是不是同一个？这是等价类映射，不是数据清洗。
L2 桥接层，20+ 行业已验证
错了要有人负责
四维门禁 + 黄金集回归，让每条上下文都有可审计的合格证。出问题时能回到具体条款，不是一句「模型说的」。
口腔医保 100% 准确；标书审核 94.8% 匹配
Outcomes
可量化的收益
上了规范上下文，具体变好什么。
↓80%
需人工仲裁的冲突数
100%
裁决可追溯至条款
0
越权调用事故（前两类上下文兜不住的那类）
≤7 天
制度变更到上下文生效
1–7 天
整套方案交付周期
95%+
推理准确率（50+ 案例均值）
指标为典型项目口径，实际以客户现场黄金集回归结果为准。
Where to Start
最该先上的四类场景
判据很简单：出错就要担责的地方。
合规与审计
强监管解决：制度条款与业务事实冲突时的自动判定
裁决全程留痕，可回溯至条款号
#审计#留痕#SWRL
跨系统主数据口径
供应链解决：CRM / ERP / MES 三方客户与物料口径打架
等价类自动对齐，避免发错货
#主数据#L2桥接
多政策并行推理
医疗医保解决：31 省医保规则差异下的报销判定
已验证 100% 准确
#医保#多政策
标书与条款审核
法务合同解决：数百页招标文件的违规项识别
2 天 → 10 分钟，43+ 审查规则
#标书#43规则
Get Started
把你们公司的「口径」，写成 Agent 认得的规矩
把制度变成契约，让 Agent 守得住规矩。
20+ 行业 · 50+ 案例 · 1–7 天交付 · 95%+ 准确率 · 裁决可追溯至条款
已经在用钉钉 / 企微 / 飞书？我们可以接在其上下文之上，补齐规范层。