flowchart LR
subgraph S[企业数据源]
S1[ERP / CRM]
S2[MES / 设备事件]
S3[工单系统]
S4[文档与多媒体]
S5[身份与策略]
end
subgraph P[数据供应链]
P1[批量 / CDC / 事件 / API]
P2[原始证据与标准化]
P3[实体、有效时间与领域语义]
end
subgraph C[开放上下文层]
C1[目录、术语与领域]
C2[契约、质量与血缘]
C3[所有权、策略与状态]
end
subgraph D[数据产品与表示]
D1[设备售后上下文]
D2[文档 / 案例索引]
D3[指标、关系与反馈]
end
subgraph G[Agent 数据访问层]
G1[结构化 API]
G2[混合检索]
G3[规则与业务工具]
G4[策略、审批与审计]
end
A[售后助手与工单体验]
E[评估、业务结果与运营]
S --> P --> D --> G --> A --> E
C -.语义与可信度.-> P
C -.发现、权限与契约.-> D
C -.工具上下文与策略.-> G
E --> P
E --> C
21 案例：目标架构与关键 ADR
本章产出： 山城精工的现状与目标架构、端到端数据流、组件责任和四份关键架构决策记录。
本章继续使用虚构案例。目标架构不以具体厂商 Logo 为中心，而以能力与责任为中心。每个组件都要回答：输入是什么、输出是什么、服务到什么程度、谁负责、失败后如何影响用户。架构图若不能支持这些问题，只是一张技术海报。
21.1 现状架构
山城精工当前系统按部门建设，形成多个垂直烟囱。ERP、MES、CRM、工单和设备平台各有账号与数据模型；文档库以文件夹和文件名管理版本；报表平台通过夜间同步聚合部分结构化数据；专家经验留在个人笔记和群聊。
现状的主要断点是：
- 设备、客户和零件标识缺少跨域映射；
- 文档与设备型号、版本和有效期关系不稳定；
- 质量和血缘停在数仓，未覆盖文档索引与 Agent；
- 权限在各系统单独执行，跨源组合缺少统一目的；
- Agent 试验直接读取副本，端口、版本与 SLO 不明确；
- 工单结案没有形成可审核反馈。
这些断点决定目标不是新建一个更大的数据仓库，而是建立数据产品、上下文层与受控 Agent 服务。
21.2 目标架构
该图中的实线是主要数据与任务流，虚线表示上下文控制。元数据不在流程之外做展示，而是进入处理、产品和访问决策。
21.3 源与采集
设备与客户主数据按小时增量同步，配置变化通过 CDC 或领域事件分钟级进入，工单每日同步并在结案时发送事件，设备告警通过事件流，文档发布触发解析，库存和权限在请求时调用权威服务。
每条入口保留源标识、事件时间、采集时间、模式版本、分类和运行水位。原始证据受控保存以支持重放，重复、乱序和删除有明确处理。采集凭据使用独立最小权限身份。
责任：源系统团队负责权威记录和变化通知，数据供应链团队负责采集、对账与恢复，业务所有者负责语义冲突。
21.4 标准化与领域处理
标准化层建立企业设备、客户、零件标识映射，统一单位与时间，保留来源值和置信状态。领域层形成设备配置历史、型号适用关系、工单故障分类和售后指标。
无法自动匹配的数据进入隔离队列，由数据运营和业务专家处理。人工确认结果保存来源和有效期，不直接覆盖原证据。处理规则版本化，可从原始层重放。
该层使用湖仓或等价能力保存历史快照，为分析、评测与审计提供可重现数据。当前低延迟查询不直接扫描湖仓，而由产品端口服务。
21.5 文档与知识处理
手册经过文件校验、版面解析、OCR、结构恢复和分块；块保留标题路径、页码、文档版本、适用型号、有效日期、权限和解析质量。关键词与向量索引并行，支持混合召回。
历史工单只有在最终原因和处置经过确认后进入案例索引，自由文本先脱敏。旧版或撤回文档停止召回，但原版本按审计规则保留。索引记录源摘要、分块与 Embedding 版本，能够增量更新和删除。
首期使用轻量实体关系连接设备、型号、零件、手册和案例；当影响分析成为主要需求时再评估图数据库。
21.6 上下文层
上下文层采集技术资产、模式、任务、血缘和运行状态，并由领域团队维护术语、指标、所有权、适用范围、数据产品和契约。质量结果与事件连接到消费端口。
Agent 请求某任务时，上下文层返回可使用的数据产品、工具、字段说明、质量和策略，而不是把全部元数据塞进提示。平台可借鉴 OpenMetadata 的开放实体与 API 思想，将数据产品、契约、质量、血缘、策略和领域连接起来(OpenMetadata Contributors, 不详)。
上下文层自身由平台团队运营，领域语义归售后业务，安全策略归安全团队，数据产品经理负责消费反馈和优先级。
21.7 数据产品层
“设备售后上下文产品”是首期核心。内部组合结构化事实、文档索引与规则，外部只发布稳定端口：
- 设备上下文 API；
- 适用资料与确认案例检索；
- 保修和库存权威工具；
- 工单草稿工具；
- 反馈事件与运营指标。
每个端口有版本、身份、模式、SLO、质量、错误和降级。Agent 不直连原始表或向量集合。派生缓存和索引不是权威事实，结果包含更新时间和来源。
21.8 Agent 访问与编排
用户从工单进入，身份和任务上下文传给 Agent。编排器先识别设备，取得可用工具和策略，再调用结构化 API 与检索。证据融合后生成结构化诊断，进行模式、引用和安全校验。
只读与写操作分离。首期允许检索、建议和创建工单草稿；草稿由工程师预览确认。库存锁定、合同修改、外部承诺和设备控制不在工具白名单。工具使用幂等、超时、限流与审计，凭据不进入模型。
依赖失效时按层降级：上下文不完整则澄清，文档索引陈旧则跳转正式库，库存超时则不承诺，模型不可用则保留传统工单流程。
21.9 评估与反馈
每次任务保存外部可验证轨迹：身份、数据和规则版本、检索证据、工具调用、结构输出、人工修改、审批和业务结果。敏感内容按策略保存。
离线评测分层运行，线上观察数据健康、任务质量、流程价值、风险与成本。结案结果经过审核后进入案例候选，不能由模型输出自动反哺。严重错误和越权触发工具或范围冻结。
21.10 关键 SLO 与责任
| 能力 | SLO 方向 | 负责人 | 失败模式 |
|---|---|---|---|
| 采集 | 数据年龄、对账、恢复 | 数据供应链 | 陈旧、缺失、重复 |
| 实体与语义 | 匹配、有效期、冲突 | 数据产品/业务 | 错设备、错口径 |
| 文档索引 | 覆盖、版本、可追溯 | 知识处理团队 | 漏召回、旧资料 |
| 上下文层 | 可用、完整、策略同步 | 平台/治理 | 误选工具、状态未知 |
| Agent 工具 | 延迟、权限、幂等 | 服务团队 | 越权、重复、超时 |
| 任务闭环 | 正确、采用、业务结果 | 产品/售后 | 错误建议、无价值 |
21.11 ADR-001：首期采用组合检索，不建全域图谱
背景： 主要问题是手册和案例检索，同时需要设备、型号和零件适用关系。
选项： 纯向量、混合检索、完整知识图谱。
决定： 关键词与向量混合检索，加结构化实体过滤和轻量关系。
理由： 编码与错误码需要精确匹配，自然语言需要语义召回；首期关系范围有限，全域图谱成本不匹配。
后果： 团队要维护适用元数据与评测；复杂多跳能力有限。
复审： 当关系型问题占比或因关系缺失导致的失败连续达到阈值时评估图谱。
21.12 ADR-002：库存与权限采用请求时权威查询
背景： 状态变化快，错误承诺风险高。
选项： 每日同步、事件缓存、请求时 API、缓存加最终确认。
决定： 可用短缓存支持体验，但每次显示带查询时间；未来执行动作前必须权威确认。权限每次请求判定。
后果： 增加下游依赖和延迟，需要超时降级；换来更确定状态。
复审： 当 API SLO 无法满足或调用成本成为主要瓶颈时，评估事件状态与双重确认。
21.13 ADR-003：Agent 不直接访问数据库
背景： 物理模式复杂，权限和业务规则分散。
选项： 自由 SQL、只读语义查询、任务级 API 与工具。
决定： 生产任务只使用数据产品端口；受控分析可通过语义查询。
后果： 需要建设接口，但获得稳定契约、最小权限、质量与审计。
复审： 探索场景增加时，可扩展沙箱语义查询，不放开生产库。
21.14 ADR-004：首期只到建议与草稿
背景： 业务希望自动预留备件，但首期错误和运营证据不足。
决定： 开放 L0 查询、L1 建议和 L2 草稿，所有提交由人确认。
后果： 自动化收益有限，但能够观察人工修订并控制失败半径。
复审： 连续多个评估周期达到质量、采用、风险和成本门槛后，单独评审可逆动作。
21.15 部署与演进
开发、评测和生产环境隔离，生产数据按分类使用。模型、索引、提示、工具和契约独立版本，发布采用影子和小流量。关键服务可回滚，原始证据与反馈有备份和恢复。
架构不是一步到位。首期复用现有基础设施，只建设目标任务必要能力；第二个场景出现后再提炼共享实体、检索、评测和工具平台。避免以“平台化”为由推迟闭环，也避免复制首期内部实现。
21.16 本章交付物：可评审架构包
完整架构包包括现状断点、目标能力图、数据流、信任边界、数据产品端口、SLO 与负责人、失败降级、成本估算、威胁模型、评估链和 ADR。图中每个箭头都应说明身份、模式、时间、权限和重试。
这样的目标架构展示的不只是技术广度，而是把业务、数据、Agent、治理和组织责任连接起来的能力。它能够解释为什么这么设计、失败在哪里、何时需要演进，这正是高级数据架构岗位必须承担的判断。
21.17 容量、成本与恢复补充
目标架构还应给出容量假设，而不是等上线后才核算。团队要估计日任务数、平均检索块、模型调用、文档增量、事件峰值和审计保留，并为试点与扩量分别测算。成本看板按成功任务归集，能够区分模型、检索、API、计算和人工审核。
恢复设计按能力分级：原始证据与契约需要可靠备份，索引可从源重建，缓存可丢弃，反馈与审批记录必须保留。定期演练源端中断、索引损坏、模型切换和区域故障，确认降级路径真的能被用户理解和使用。
容量与恢复并非上线后的运维附录，它们会反向影响架构选择。若团队无力维护复杂流状态，就采用更简单的时效方案；若索引重建需要数日，就改进分区、快照与并行版本。高级架构必须同时设计正常路径和失败后的企业运行方式。