flowchart BT
I[基础设施 Ready<br/>算力·存储·网络·弹性·成本]
D[数据工程 Ready<br/>采集·处理·建模·批流·服务]
C[上下文 Ready<br/>元数据·语义·质量·血缘·契约·记忆]
A[Agent Ready<br/>检索·工具·MCP·权限·评估·反馈]
I --> D --> C --> A
3 从基础设施 Ready 到 Agent Ready
3.1 为什么需要分层成熟度模型
企业讨论 AI Ready 时，经常出现“各说各话”。基础设施团队认为算力、存储和网络已经就绪；数据团队认为数据已经进入湖仓；治理团队认为目录和质量平台已经上线；应用团队却仍然无法让 Agent 稳定回答业务问题。每个团队的陈述可能都正确，冲突来自他们描述的是不同层次。
成熟度模型的价值不是给企业一个漂亮分数，而是建立共同语言：当前场景卡在哪一层，上一层是否提供了稳定前提，下一层还需要什么能力。分层还能够避免把所有问题都交给同一个平台解决。存储性能不能替代业务语义，元数据目录不能替代低延迟服务，模型评估也不能修复错误源数据。
本书将能力划分为四层：
图自下而上表达依赖，但不意味着企业必须建设完一层再进入下一层。实际项目通常围绕场景纵向切出一条最小路径：使用已有基础设施，接入少量关键数据，补齐必要上下文，构建受控 Agent，再根据运行反馈加强共性能力。成熟度模型用于识别缺口，不用于制造瀑布式大工程。
3.2 第一层：基础设施 Ready
基础设施层回答“数据和 AI 工作负载能否稳定、经济地运行”。它包括计算、存储、网络、资源调度、容灾、监控和成本管理。训练、批量向量化、在线检索和 Agent 推理具有不同资源特征，不能用一个峰值性能指标概括。
训练和大规模数据处理偏向吞吐，在线推理和检索更关注尾延迟与并发，文档解析可能具有突发性，Agent 工作流则会跨越多个服务并放大单次请求成本。架构需要区分热、温、冷数据，考虑数据移动成本、缓存、索引构建和多租户隔离。华为 AI-Ready 数据基础设施参考架构强调围绕 AI 数据全生命周期组织存储、网络和算力，是观察这一层的有价值视角 (Huawei Technologies Co., Ltd. 2024年)。
基础设施 Ready 的判断不能停留在“资源已经购买”。至少需要回答：
- 目标工作负载在峰值和故障情况下是否满足容量与延迟？
- 数据进入计算环境时是否出现昂贵复制和跨区传输？
- 敏感数据是否在允许的区域和介质中处理？
- 资源是否可以观测到单场景、单团队和单请求成本？
- 基础组件发生故障时是否存在降级和恢复目标？
对中小企业而言，第一层的原则通常是优先利用云服务和现有平台，避免为尚未验证的场景预建大规模集群。真正的成本不只是资源单价，还包括维护人员、升级、监控和故障恢复。
3.3 第二层：数据工程 Ready
数据工程层回答“现实变化能否被稳定地转化为可消费数据”。它覆盖源系统接入、批量采集、CDC、事件流、清洗、建模、文档解析、存储组织、数据服务和运行可观测。
这一层的核心不是把数据集中到一个位置，而是形成可重复的数据供给。一个脚本能够把手册导入向量库，只能证明技术可行；生产能力还需要处理增量更新、删除、重复、解析失败、版本回退和索引一致性。一条 SQL 能查询库存，也不等于具备稳定服务；需要定义输入、超时、权限、缓存和错误返回。
数据工程 Ready 的关键对象是数据流和服务等级。每条关键数据路径应当知道源头、处理步骤、目标、频率、延迟、失败重试和责任人。结构化与非结构化数据要采用不同处理方式，但最终都需要稳定标识和版本。文档被切分成 Chunk 后，必须保留与原文、章节、版本和权限的关系；事件进入流系统后，要处理乱序、重复与回放；表发生模式变化时，要评估下游契约。
在“山城精工”案例中，手册每天同步和解析，设备状态通过事件流进入，库存通过受控 API 请求时查询，历史工单每小时增量更新。四条路径没有强行统一成一种实时机制，却共同满足售后任务的决策窗口。
3.4 第三层：上下文 Ready
上下文层回答“数据是否能被正确理解和信任”。这是传统数据平台与 AI 数据系统之间最容易被低估的层次。
人类使用数据时会依赖大量背景知识。Agent 如果只连接数据库或文档库，得到的是结构与内容，不是企业含义。上下文层把技术元数据、业务语义、质量、血缘、所有权、使用、分类、政策、数据契约、数据产品和组织记忆连接起来，使消费者知道一个资产是什么、由谁负责、从哪里来、当前状态怎样以及允许如何使用。
OpenMetadata 的模式优先设计为这一层提供了工程参照。其数据产品模式不只包含资产集合，还包含生命周期、可见性、优先级、输入输出端口和 SLA；数据契约模式包含结构、质量、安全、刷新频率、最大延迟和使用条款；知识图把资产、术语、质量测试、血缘、所有者和政策连接起来 (OpenMetadata Contributors, 不详)。重要的不是复制字段，而是理解一个原则：上下文也应当被建模、版本化、查询和治理。
上下文 Ready 需要避免“目录坟场”。如果描述只在项目上线时填写一次、质量告警与资产脱节、血缘无法覆盖关键链路、术语没有负责人，Agent 读取到的只是过期上下文。上下文必须进入运行时：搜索排序参考认证与质量，检索结果携带来源和版本，工具调用读取权限策略，变更事件触发影响分析，事故修复沉淀为可复用记忆。
3.5 第四层：Agent Ready
Agent 层回答“数据和上下文能否在受控条件下形成判断与行动”。它包括身份传递、意图解析、检索与查询编排、工具和 MCP、上下文预算、提示策略、结构化输出、审批、审计、评估、反馈和人工接管。
这一层不能被简化为“接入大模型”。Agent 会根据任务选择数据源和工具，因此必须知道每个工具的能力、输入、输出和风险。读取和写入要分开，确定性查询与概率生成要分开，低风险建议与高风险行动要分开。工具返回错误时，Agent 不应把缺失结果编造成成功答案；证据冲突时，应显式表达并请求人判断。
MCP 为模型使用工具和上下文提供了标准化接口方向。OpenMetadata MCP 允许助手检索元数据、查看血缘、理解契约和质量上下文，并执行受到认证与权限约束的操作 (OpenMetadata Contributors, 不详)。但协议标准化不等于治理自动完成：工具暴露范围、用户身份委托、最小权限、速率限制和审计仍要由企业设计。
Agent Ready 的成熟标志是团队能够解释一次输出怎样形成。给定某条回答，可以追溯用户身份、模型和提示版本、检索查询、召回来源、质量与权限过滤、工具输入输出、最终生成和后续反馈。给定一次自动动作，可以知道谁授权、执行什么、是否幂等、结果如何以及如何回滚。
3.6 五级成熟度
在四层之外，可以用五个等级描述某个场景的纵向成熟度。
L0：不可见。 数据分散，依赖个人寻找；没有稳定路径和负责人。AI 试验使用手工导出。
L1：可连接。 关键数据可以被采集或查询，原型能够跑通；但语义、质量和权限主要依赖人工。
L2：可理解。 关键数据有描述、所有者、术语、质量和基础血缘；服务接口开始稳定，回答可以引用来源。
L3：可运营。 数据产品有 SLA、契约、监控和变更流程；Agent 有权限、审计、评估、降级与反馈闭环，能够在限定用户中生产运行。
L4：可规模化。 多场景复用共性上下文和服务，领域团队能够自助建设，平台提供标准与策略，价值、风险和成本可以组合管理。
等级不是按采购数量判断。某企业部署了完整平台，但关键术语无人负责，可能仍停留在 L1；另一家企业只用少量托管服务，却围绕一个场景形成稳定契约、评估和反馈，可以达到 L3。
3.7 层间关口与典型失败
从基础设施进入数据工程层的关口，是工作负载能否被稳定承载和观测。典型失败是原型依赖个人机器，索引任务抢占在线资源，成本无法归属。
从数据工程进入上下文层的关口，是数据是否拥有稳定标识、版本和责任。典型失败是表和文档虽然接入，却无法判断版本、所有者和业务含义。
从上下文进入 Agent 层的关口，是上下文能否在运行时被机器使用。典型失败是目录中有质量和权限信息，Agent 检索时却不读取；用户在门户能看到血缘，回答却无法引用来源。
从生产运行进入规模化的关口，是能力能否被第二个场景复用。典型失败是第一个场景由大量硬编码维持，新增数据源或用户群就必须重写，平台团队成为所有需求瓶颈。
设置关口的目的不是阻止发布，而是让风险透明。低风险场景可以用人工补偿跨过某些缺口，高风险动作则需要严格门槛。例如 L1 的知识库可以供内部专家辅助查询，但不应直接控制生产设备。
3.8 成熟度评估方法
评估应以“场景—数据域—能力层”为单位。先明确场景和关键任务，再列出每项任务依赖的数据产品，最后在四层中寻找缺口。不要对整个企业给出一个平均分，因为平均值会掩盖关键链路的短板。
每个评分都要附证据。声称“质量成熟”，应提供规则覆盖、通过率、事故和响应数据；声称“权限可控”，应展示身份传递、策略和审计；声称“可评估”，应提供评估集、线上指标和反馈记录。没有证据的高分只是共识幻觉。
评估结果应产生三类行动：必须在上线前补齐的门槛、可以通过人工补偿暂时接受的风险、值得沉淀为共性平台的能力。三类行动对应不同优先级和投资方式。
3.9 从纵向切片开始
对于“山城精工”，第一阶段不建设全企业知识图谱，而是选择售后诊断纵向切片：
- 基础设施层复用现有云资源，单独监控解析、检索和推理成本；
- 数据工程层接入手册、工单、设备主数据和库存服务；
- 上下文层补齐产品型号、手册版本、故障码术语、来源、质量和权限；
- Agent 层提供带引用的诊断建议，库存只读，备件预留必须人工确认；
- 反馈记录工程师采纳、修改、转人工和最终解决情况。
这条切片达到 L3 后，企业再将文档版本、产品实体、检索评估和权限过滤复用到销售支持或质量分析场景。平台能力由真实复用需求长出来，而不是在需求出现前一次设计完毕。
3.10 本章产物：四层成熟度卡
每个场景可以形成一张评审卡：
| 层次 | 当前证据 | 目标状态 | 上线门槛 | 可接受补偿 | 共性建设 |
|---|---|---|---|---|---|
| 基础设施 Ready | 容量、延迟、成本、恢复记录 | ||||
| 数据工程 Ready | 数据流、SLA、失败与版本 | ||||
| 上下文 Ready | 语义、质量、血缘、契约、所有者 | ||||
| Agent Ready | 工具、权限、审计、评估、反馈 |
最终讨论不应停在“我们处于 L2”，而要落到具体判断：“因为库存接口没有稳定时效和错误语义，第一阶段不能自动预留；我们暂时采用只读查询与人工确认，同时在六十天内建立服务契约。”成熟度模型只有转化为决策和路线，才真正有价值。