8 数据源、采集与变化捕获
本章产出： 企业数据源地图、采集策略矩阵，以及从源端责任到失败恢复的设计检查表。
AI 应用看到的企业世界，首先由采集层决定。源端没有被捕获的变化，模型无法知道；采集时丢失的业务语义，后面很难凭空恢复；错误复制的敏感信息，则可能在索引、缓存和提示上下文中留下多份副本。因此，采集并不是把数据“搬进来”的管道工程，而是企业上下文第一次被选择、解释和约束的地方。
在传统数仓项目中，团队往往从结构化业务表开始。Agent 的任务边界更宽：它既需要订单、设备和库存等事实，也需要合同、手册、图像和录音中的知识；既需要历史结果，也需要此刻状态；既要读取系统记录，也要理解专家为何做出某个判断。数据源地图必须跨越数据库、事件、文档、SaaS、日志和人工知识，而不能把“非结构化数据”简单归入一个杂项。
8.1 先建立数据源地图
数据源盘点不应只列系统名称。对每个来源至少记录业务所有者、技术所有者、权威对象、更新方式、变化频率、数据量、敏感等级、保留要求、关键消费者和已知质量问题。更重要的是，说明它在目标任务中扮演什么角色。
| 来源类型 | 典型内容 | 主要难点 | 常见采集方式 |
|---|---|---|---|
| 交易数据库 | 客户、订单、设备、库存 | 源端负载、事务一致性、模式变化 | 批量、CDC、只读 API |
| SaaS 应用 | CRM、工单、协作记录 | API 限流、权限映射、字段定制 | API 拉取、Webhook |
| 文档与多媒体 | 手册、合同、图片、录音 | 版本、版面、OCR、适用范围 | 文件事件、对象存储同步 |
| 事件与设备流 | 告警、状态、用户行为 | 乱序、重复、迟到、峰值 | 消息总线、流式采集 |
| 日志与可观测数据 | 应用日志、审计、链路 | 体量、敏感字段、短时价值 | 日志代理、流式汇聚 |
| 人工知识 | 专家经验、例外规则 | 隐性语境、真实性、持续维护 | 访谈、结构化表单、审核发布 |
山城精工的售后助手需要 ERP 中的设备与备件、MES 中的出厂配置、CRM 中的客户合同、工单系统中的维修历史、设备平台中的告警、文档库中的手册和公告。源地图还要标明：设备主身份以哪个系统为准，现场换件记录由谁维护，库存“可承诺量”由哪项业务服务计算，手册适用型号和生效日期在哪里保存。只有系统名没有这些解释，数据接得越多，冲突可能越多。
8.2 根据变化性质选择采集方式
批量、CDC、事件和 API 没有天然优劣。选择标准是业务允许的数据年龄、源端能力、变更语义、恢复要求和总成本。
8.2.1 批量同步
批量适合变化较慢、允许小时或天级延迟、可以按稳定切片读取的数据。它实现简单、易于重放，适合历史工单、每日产品目录和低频参考表。风险在于全量扫描给源库带来压力，基于更新时间的增量可能漏掉删除和回补，跨表快照也未必一致。设计时应明确水位、分区、删除表示、校验和补数流程。
8.2.2 变更数据捕获
CDC 从数据库日志捕获插入、更新和删除，适合需要较低延迟且不能反复扫描源库的交易数据。它保留变化顺序，却不自动提供完整业务语义：一次订单更新可能由多个表事件组成，日志中的技术删除也可能代表业务归档。CDC 管道要处理初始快照与增量切换、事务边界、模式变更、重复消费和断点恢复，并避免把源库内部结构直接固化为外部契约。
8.2.3 业务事件流
业务事件表达“发生了什么”，例如设备发生告警、工单已结案、备件已锁定。它比原始表变化更接近领域语义，也更适合驱动实时 Agent 流程。前提是事件有稳定标识、发生时间、生产者、模式版本和幂等规则。不要把消息队列里的任何消息都称为业务事件；一个缺少所有者和语义的 JSON，只是另一种形式的耦合。
8.2.4 API 与 Webhook
当数据来自 SaaS 或只能通过业务服务访问时，API 是现实选择。API 可以封装权限和业务规则，但需要处理分页、限流、游标失效、令牌轮换、字段扩展和服务波动。Webhook 能降低轮询延迟，却仍要设计漏通知后的对账。对于库存、价格和权限等强业务语义，调用权威服务往往比复制底层表更可靠。
8.2.5 文件与对象存储事件
文档、图像、录音和批量交换文件通常通过对象存储进入。文件到达并不等于可用：需要验证格式、完整性、病毒与恶意内容，提取元数据，识别版本和语言，再进入解析流程。大文件上传要避免读到未完成对象；相同文档的重传应使用内容摘要去重；删除和撤回应沿索引、缓存和备份传播。
8.3 新鲜度从任务倒推
“我们需要实时数据”通常不是一个完整需求。应先问：数据变旧多少会导致错误判断，错误的损失是什么，系统是否能够利用更低延迟。
山城精工的设备基础信息可按小时同步，维修手册在正式发布后数分钟内完成索引即可，已结案工单可以每日处理；但当前告警、备件可用状态和工单锁定必须更及时。即便库存通过事件更新，Agent 在作出建议时仍应调用权威查询确认，因为事件缓存与最终业务动作之间可能再次变化。
新鲜度指标至少区分源端年龄和管道延迟。某条库存记录五分钟前进入平台，不代表它只旧了五分钟；源系统可能一天没有成功更新。数据服务应暴露“业务事件时间、采集时间、处理时间和当前时间”，让消费者判断是否超出任务允许范围。
8.4 处理重复、乱序和迟到
分布式采集不能假设事件只来一次且顺序完美。网络重试会产生重复，分区并行会改变顺序，离线设备会在恢复后补发旧事件。处理策略应在设计中明确：
- 为事件设置全局或领域内唯一标识；
- 以业务实体和版本号判断新旧，而非仅依赖到达时间；
- 对写入采用幂等键，重复执行不产生额外业务影响；
- 为迟到数据设置容忍窗口和更正机制；
- 保留原始记录，派生状态可以重算；
- 对无法自动决定的冲突进入隔离区，而非静默覆盖。
例如同一设备的固件版本从两个系统到达，一个记录事件时间较新但来源可信度较低。架构不能只用“最后写入获胜”，应按业务权威、事件时间和确认状态形成冲突规则，并把异常暴露给数据所有者。
8.5 模式变化是正常事件
源系统增加字段、修改枚举、调整嵌套结构或改变含义不可避免。真正危险的不是变化，而是变化没有被发现和沟通。采集层应保留模式版本，检测新增、删除和类型变化，并根据兼容性采取自动接受、告警或阻断。
技术兼容不代表语义兼容。字段仍是字符串，但“状态=A”的含义发生变化，自动模式检查不会发现。因此关键数据要有数据契约，规定字段、语义、质量、刷新、所有者和变更通知。生产者变更前进行契约检查，消费者通过血缘和依赖分析了解影响。对于破坏性变化，应提供并行版本和迁移窗口。
文档也存在模式。标题、章节、表格、适用型号、版本和生效日期构成文档结构；扫描件质量和版式变化会影响解析。文档发布流程应生成稳定文档标识与版本，而不是把文件名当主键。
8.6 在采集入口实施安全与最小化
数据进入 AI 链路后可能被复制到湖仓、搜索索引、向量库、缓存、评测集和日志。越晚识别敏感数据，清理成本越高。采集时应执行分类、标签和最小化：目标任务不需要的个人信息不采集，需要但不应进入模型的字段通过受控工具查询，可脱敏的内容在进入下游前处理。
采集凭据应使用独立服务身份和最小权限，避免共享管理员账号。网络链路加密，落地数据按分类加密和隔离。日志不得记录令牌、完整提示或敏感返回。数据驻留、跨境和保留规则要随数据传播，不能在复制后丢失。
对于文档和人工上传，还要防范提示注入与恶意内容。采集系统应区分“文档中的业务内容”和“对 Agent 的指令”，外部文本不能因此获得系统权限。来源可信度、审核状态和适用范围应成为检索过滤条件。
8.7 可重放比“永不失败”更现实
采集系统一定会失败：源端停机、网络中断、令牌过期、格式异常、消费者积压。可靠设计不是假设永不失败，而是能够发现、隔离、恢复和证明恢复完整。
每条管道应有水位与延迟监控、记录数和摘要对账、失败队列、重试策略、断点和运行手册。原始层尽量保留不可变输入与采集元数据，便于在解析规则修正后重放。重放必须保持幂等，并区分首次到达与历史回补，避免触发重复通知或业务动作。
恢复目标也应分级。设备告警链路可能要求分钟级恢复，历史文档索引可以在数小时内补齐。对关键管道定期演练凭据失效、消息积压、模式破坏和区域故障，远比只观察“任务成功”仪表盘可靠。
8.8 采集成本要按价值核算
低延迟 CDC、全量日志、高清多媒体和频繁 API 拉取都会增加源端、网络、存储与运维成本。数据“以后也许有用”不是无限保留的理由。路线图应按目标任务选择采样、压缩、冷热分层、保留周期和更新频率。
评估一种采集策略时，至少计算连接器和授权成本、源端影响、传输与存储、解析计算、失败运维以及下游复制。更重要的是计算每个成功任务所需成本。如果某类日志几乎从不参与诊断，却占据大部分索引开销，就应降低粒度或改为按需查询。
8.9 山城精工的采集策略
首期可以采用组合方案：
| 数据对象 | 方式 | 目标时效 | 关键控制 |
|---|---|---|---|
| 设备与客户主数据 | 增量批处理 | 小时级 | 主键映射、删除对账 |
| 出厂及变更配置 | CDC 或业务事件 | 分钟级 | 顺序、版本、冲突隔离 |
| 手册与服务公告 | 对象事件 | 发布后分钟级 | 文档版本、适用范围、撤回 |
| 历史工单 | 每日批处理 | 日级 | 结论审核、个人信息脱敏 |
| 当前设备告警 | 事件流 | 秒至分钟级 | 重复、乱序、设备时钟 |
| 备件状态 | 权威 API + 短缓存 | 查询时确认 | 超时降级、不作库存承诺 |
| 用户和权限 | 身份服务查询 | 请求时 | 最小权限、审计 |
这张表体现的不是技术时髦程度，而是任务风险：长期事实适合稳定同步，实时状态接近事件，强事务信息在行动前回到权威服务确认。
8.10 本章交付物：采集设计清单
一个可以进入架构评审的采集方案，应对每个数据源说明：
- 业务对象、权威来源和所有者；
- 采集目的、允许延迟与消费场景；
- 全量、增量、CDC、事件或 API 的选择理由；
- 唯一标识、时间语义、删除、重复、乱序和回补处理；
- 模式版本、契约、兼容规则和变更通知；
- 敏感分类、凭据、驻留、脱敏和保留；
- 对账、水位、告警、失败隔离、重试和重放；
- 源端、网络、存储、解析和运维成本；
- 停止采集和安全删除的条件。
采集层的成熟，不在于连接器数量，而在于企业能否解释每一份上下文为什么进入、来自何处、何时有效、谁可以使用、失败后如何恢复。只有入口可靠，后面的语义、检索和 Agent 服务才有可能建立可信闭环。