Martin Fowler

Making Your Data Ready for Agentic AI

8.5内容质量
Making Your Data Ready for Agentic AI

TL;DR · AI 摘要

构建三层数据架构（信任基础/上下文/访问控制）是实现自主代理AI数据就绪的关键，需持续关注可观测性与治理。

核心要点

  • 数据契约需通过代码定义，采用Medallion架构确保代理操作合规
  • 自主代理无法识别数据质量问题，需实施'检疫模式'隔离异常数据
  • 知识图谱是构建上下文层的核心工具，可提升代理对业务概念的理解

结构提纲

按章节快速跳转。

  1. §数据消费者变革

    自主代理取代人类分析师成为主要数据使用者，需要全新数据准备范式

  2. ·AI就绪数据三要素

    信任基础层确保数据质量，上下文层赋予语义，访问层控制操作边界

  3. ›数据契约实践

    通过代码化数据契约和Medallion架构实现严格的数据质量控制

  4. ·可追溯性治理

    建立全链路审计机制，采用分阶段自主权模型确保合规操作

  5. ›上下文层构建

    利用知识图谱实现业务概念映射，通过指标代码化提升语义理解

  6. ·访问层设计

    定义读/写/执行三类数据访问原语，建立端到端的代理操作协议

思维导图

用一张图看清主题之间的关系。

查看大纲文本（无障碍 / 无 JS 友好）
  • AI就绪数据架构
    • 数据基础层
      • 数据契约
      • Medallion架构
    • 上下文层
      • 知识图谱
      • 指标代码化
    • 访问控制层
      • 三类数据原语
      • 端到端协议

金句 / Highlights

值得收藏与分享的关键句。

#AI#数据工程#架构设计#可观测性
打开原文

为自主代理 AI 做好数据准备

三十年来，我们为人类分析师构建数据系统，他们能提供背景信息、判断力和怀疑精神，以应对不完整或错误的数据。自主代理则不具备这些能力。它们会自信地根据所获得的任何信息采取行动。为了让数据具备 AI 就绪性，我们需要构建一系列层次：一个使数据可信的数据基础层、一个赋予数据正确含义的上下文层，以及一个支持并控制代理如何操作数据的访问层。在此过程中，我们需要持续关注可观测性，确保数据得到适当治理，并能够对决策过程中的使用情况进行可审计的追踪。

2026年8月27日

普拉莫德·萨达拉吉

普拉莫德是 Thoughtworks 的杰出工程师，负责北美地区数据工程与架构服务，帮助客户解决特别复杂的数据需求，这些需求需要新技术和方法。2000 年代初，他开发了基于版本控制的模式迁移技术，使关系数据库能够以进化方式设计。他撰写了五本软件开发书籍，包括《软件架构：艰难部分》和《数据库重构》。

普雷曼安德（普雷姆）·钱德拉塞卡拉南

普雷姆是 Thoughtworks 的市场技术总监，负责指导客户组合中的技术战略和交付，并带领团队做出复杂且高风险的工程决策。他始终保持亲力亲为，与所带领的团队一起设计和构建生产级系统。他目前的专注领域是 AI 如何增强软件开发生命周期，从架构和设计到编码、测试和运维，使开发人员能够更快地推进工作，而不会牺牲清晰度、安全性和可维护性。

企业架构

数据分析

生成式 AI

目录

  • 数据的使用者正在发生变化
  • “AI 就绪”当前的含义
  • 数据契约与质量：代理无法察觉劣质数据 代理将每个值视为真理 模式即法律：以代码形式实现数据契约 隔离模式 适用于代理的奖章架构 对非结构化数据应用相同规则 置信度阈值路由 从哪里开始
  • 可追溯性与治理：审计自主代理 审计缺口 代理血缘关系 监管的约束力是真实的 阶段化自主权 委派访问权限和即时凭证 从哪里开始
  • 上下文层：教导代理理解数据含义 你的代理不知道“收入”意味着什么 上下文层是什么度量即代码 同一个问题，截然不同的 SQL 代理如何使用它 从哪里开始 遍历领域模型：知识图谱
  • 从可搜索到可操作：面向代理的数据访问 你的代理可以读取，但无法行动 数据访问光谱 三个原语，一个协议 反模式：天真的 API 到 MCP 转换 能力声明的作用 检索到的文本提供信息，但从不设限 端到端：PO 支付场景 从哪里开始
  • AI 就绪数据栈
  • 谁拥有这一切？
  • 你处于什么位置？
  • 四个立即行动的事项

附录

  • 解释：人们用于语义层的术语

目前人们对代理框架、编排模式和协议充满热情。所有这些都很重要，但如果你跳过了数据层，几乎无法产生价值。在任何代理框架能够产生有用结果之前，你的数据必须以机器可以消费、信任并据此采取行动的形态存在。在本文中，我们将讨论数据需要具备怎样的形态，才能让智能代理从中获得价值。

我们已经投入大量时间构建面向人类消费者的数据架构。现在，我们将把这些架构交给一种截然不同的消费者，而大多数系统尚未为此做好准备。

您的数据消费者正在发生变化

过去三十年来，我们一直在为人类构建数据系统。仪表板、报告、分析师查询，所有设计都围绕着一个人坐在屏幕前进行。这有效，因为人类能带来大量隐含的上下文，并且有追踪缺失信息的求知欲。

人类分析师知道在您组织中"收入"的具体含义。他们知道该查询哪些表格，哪些需要避开。当数字看起来异常、总数过于圆整、日期落在公共假期或价格异常低廉时，他们能敏锐察觉。这种直觉正在完成大量隐性上下文和知识工作。

当数据看起来有问题时，人类会犹豫；而代理会继续采取行动。

代理系统不具备这些能力。它们无法依赖人们多年积累的部落知识和模式识别能力，因此需要显式化的上下文、实时访问权限和可信赖的质量保障。最关键的区别在于：当数据感觉不对时，人类会进行二次确认；而代理会自信地采取行动。这种行为差异构成了后续讨论的核心。

"AI就绪"现在必须意味着什么

对于人类消费者而言，数据只需足够好；分析师会处理其余部分。意义、合理性检查以及判断数字是否可信，这些都存在于人的大脑中。当相同数据交给代理时，所有隐性劳动必须转移到数据本身。这体现为五个属性，每个属性都是人类过去免费完成的某项工作的反面。

  • 可信：当一个人看到感觉不对的数字时会犹豫；而代理会直接采取行动。人类过去提供的信心必须被内置，因此数据必须在代理看到它之前就准确、最新且经过验证。
  • 上下文相关：一个人已经知道您的"收入"数字扣除了返利，并且知道您的财年从二月开始；而代理必须被明确告知这些信息。过去存在于某人脑海中的含义，现在必须在数据中显式化。
  • 可追溯：当一个人做决定时，之后可以解释原因；而代理在30秒内做决定时，除非实时捕获，否则推理过程会消失。您必须能够重建代理做了什么以及原因。
  • 受控：一个人的访问权限受其角色和判断限制；而代理的权限必须通过设计进行限制。访问权限必须被限定、控制并可审计。
  • 可操作：一个人查看仪表板后会采取行动；而代理必须能够直接执行操作。数据不能仅可读，还必须可操作。

所有五个要素都归结为同一个核心理念。它们都是人类过去无需思考就能完成的工作，现在被嵌入到数据本身中。如果遗漏任何一个，智能体将无法像人类那样优雅地降级，而是会自信地失败。

这些属性都无法自行形成。文章其余部分将通过四个主题展开，大致按照你应处理的顺序进行。

  • 数据契约与质量使数据可信。我们从这里开始，因为单个错误的事实会毒害所有构建在其上的层级。
  • 可追溯性与治理记录智能体采取行动的原因，并界定其可触及的范围，使数据可追溯且受管控。
  • 上下文层编码你的指标和实体的含义，使数据具备上下文信息。
  • 从可搜索到可操作使智能体能够查询实时系统并写回数据，使数据具备操作性。

我们将逐一探讨这些主题，并展示构建每个属性所需的条件。完成这四个主题后，五个属性将不再是抽象的目标，而是你可以工程化实现的要素，将普通数据转化为AI就绪数据。

数据契约与质量：智能体无法嗅到坏数据

人类对坏数据有嗅觉测试。当数字看起来不对、日期毫无意义或价格似乎错误时，他们会注意到。智能体则没有这种本能。正如Simon Willison所说，语言模型是轻信的，它们会相信被给予的任何内容并据此行动。如果给AI智能体一个错误值，它不会暂停思考，而是直接使用这个数字并产生一个自信却错误的答案。没有可信的数据，智能体AI的其他部分都无法正常运作，因此我们从这里开始。

智能体将每个值视为真理

考虑一个具体场景。一个定价智能体被要求提供产品X的当前价格。昨天，价格已从49.99美元更新为59.99美元。但智能体的数据源尚未刷新，仍然显示旧数值。

智能体毫不犹豫地检索到49.99美元，向客户报价，客户购买，公司每售出一个单位就损失10美元。智能体的每一步操作在技术上都是正确的，它完美地遵循了工作流程。问题在于它访问的数据。

最自信认为数据已准备就绪的领导者，却将数据就绪性列为最大的障碍。

一个人类销售代表会暂停：“等等，我们上周不是更新过这个吗？”他们会再次确认。他们拥有机构记忆，并能感知异常。智能体则没有这些能力。错误不会触发警告，而是悄无声息地在工作流程中蔓延。这并非罕见的边缘情况。根据Precisely和德雷塞尔大学LeBow商学院发布的《2026年数据完整性与AI就绪性报告》，对505位数据和分析领导者进行的调查中，87%的人认为其数据已准备好用于AI，但43%的人却将数据就绪性列为从AI中获取价值的最大障碍。这种信心与准备就绪之间的差距，正是组织层面的定价智能体问题——它确信自己正确，却实际上错误。另一项KPMG全球AI脉搏调查对2145位领导者进行的调查也指向了相同方向，近一半的高管现在认为AI的成本已超过其带来的好处。大多数企业距离上述场景只差一个过时的字段。

这颠覆了过去十年“无模式即灵活”的理念。对人类消费者而言，松散模式只是不便，但对AI代理来说，它们是危险的。通过Open Data Contract Standard（数据契约标准）定义的数据契约，即Data Contract CLI使用的格式（Thoughtworks技术雷达33推荐），明确设定了规则。一个product_pricing契约可能包含以下内容：

  • 具有严格逻辑类型的属性。
  • 价格必须大于零的质量规则。
  • 对货币进行质量检查，拒绝非USD、EUR或GBP的货币。
  • 关键性要求：新鲜度SLA（服务等级协议），规定定价数据必须在过去24小时内更新。

在Open Data Contract Standard中，该契约的示例如下：

code
apiVersion: v3.1.0
kind: DataContract
id: product-pricing
name: Product Pricing
version: 1.0.0
status: active
schema:
  - name: product_pricing
    physicalType: table
    properties:
      - name: product_id
        logicalType: string
        physicalType: varchar(64)
        required: true
        unique: true
        primaryKey: true
        primaryKeyPosition: 1
      - name: price
        logicalType: number
        physicalType: decimal
        required: true
        quality:
          - type: sql
            description: Every price must be greater than zero
            query: SELECT min({property}) FROM {object}
            mustBeGreaterThan: 0
      - name: currency
        logicalType: string
        physicalType: varchar(3)
        required: true
        quality:
          - type: sql
            description: Currency must be a supported ISO code
            query: SELECT count(*) FROM {object} WHERE {property} NOT IN ('USD', 'EUR', 'GBP')
            mustBe: 0
      - name: ingested_at
        logicalType: timestamp
        physicalType: timestamp
        required: true
slaProperties:
  # the rule that would have caught the stale-price scenario
  - property: latency
    value: 24
    unit: h
    element: product_pricing.ingested_at

执行过程涉及三个维度：

  • 模式执行：确保类型和约束被契约明确且严格遵守。
  • 新鲜度SLA：定义每个数据集可接受的最大陈旧程度。当代理实时响应时，夜间批量更新已不足以满足要求。SLA应绑定到数据最后一次成功加载的时间，而非值最后一次变化的时间，从而防止稳定数据被误判为陈旧，或停滞的流水线伪装成新鲜数据。
  • 质量门禁：在CI/CD中验证契约，失败时阻止部署。

请注意这种设计如何改变之前的定价场景——它通过设计防止了问题。如果定价数据在24小时内未更新，契约会在代理接触数据之前就被违反。

隔离模式

定义契约只是第一步。当数据违反契约时会发生什么？你需要一个断路器，这就是隔离模式。

流程如下：原始数据从源系统、API、数据库或流中到达，进入代理可访问的数据存储前，会通过契约验证网关，检查三项内容：是否符合模式、是否符合新鲜度SLA、是否通过质量规则？

如果三项均通过，数据将流入认证的、可供代理使用的层级；如果任一检查失败，数据将被隔离，路由到死信队列供人工审查，并触发警报。

劣质数据会被放入死信队列，永远无法到达代理。

关键在于代理永远看不到劣质数据。它不会受到过时价格或损坏嵌入向量的影响。在定价场景中，如果 ingested_at 时间戳超过 24 小时，就会违反数据协议，记录会被隔离。当被询问价格时，代理会说 "我没有当前定价数据"，而不是自信地引用错误数字。这是一种更优的失败模式。这属于数据架构的职责，而非模型的职责。更优秀的模型也无法拯救你免于劣质数据。

适用于代理的勋章架构

勋章架构是一种用于组织湖仓一体数据的分析型数据设计模式，由 Databricks 推广普及。

劣质数据会被隔离，但优质数据又去向何方？这正是勋章架构所要组织的内容，其前三个层级已被广泛采用：

  • 青铜层：原始、不可变的数据摄入层。保留所有数据以供审计追踪和血缘分析。
  • 白银层：经过验证和去重的层级。应用模式定义，强制执行数据协议，这也是隔离机制的落地层级。
  • 黄金层：经过认证的层级。这是语义模型所依赖的层级，访问权限受控，指标数据可被信任。

对于代理架构，增加第四个层级具有价值。如图中所示的自适应黄金层，代理不仅消费数据，还会对数据进行策展。它们会监控自身的查询模式，将高频组合的查询结果固化为数据仓库视图，这些视图基于实际使用情况构建。这并非空想。在 DataHub 的 CONTEXT 2025 大会上，苹果描述其代理作为数据目录的 "数字管家"，持续扫描元数据，标记数据缺口并提出更新建议。苹果的代理在策展目录；自适应黄金层则将这一模式应用于数据集本身。这是下一步的发展方向。虽然尚处早期阶段，但当代理的查询模式趋于稳定后，这值得尝试。

图 1：代理的勋章层级：数据从原始青铜层经验证的白银层流向认证的黄金层和代理策展的自适应黄金层，而代理仅被允许访问黄金层及以上层级。

青铜层和白银层面向人类，代理只能看到黄金层及以上数据

核心架构原则是代理应仅访问黄金层或以上层级。青铜层和白银层用于血缘追踪、调试和人工分析。向代理暴露原始或部分验证的数据会重新引入定价问题。

非结构化数据的相同规则

到目前为止，所有内容都像是表格数据：价格、货币、时间戳，但代理实际消费的数据中，大部分并非表格形式。它们是文档、维基、PDF 和支持工单，经过分块后嵌入向量存储以供检索。如果你的代理执行 RAG，这些就是它们运行的数据，需要同样的可信保障，尽管你无法在段落上写入 "价格 > 0" 这类约束。这些模式依然适用，只是质量维度发生了变化。

过时价格场景在此处有一个对应的孪生问题。政策文件被更新后，但向量索引未重新嵌入，导致代理检索到旧版本并自信地据此回答，这与过时价格场景的失败模式相同，只不过现在是嵌入信息而非数据行出现了问题。新鲜度SLA仍然适用，但需要明确时钟所衡量的具体内容——关键点不是内容上次修改的时间，而是索引最后一次成功重建的时间。24小时SLA意味着重新索引任务必须在过去24小时内完成，若未完成，即使内容表面未发生变化，索引也会被判定为过时并隔离，因为静默失败的索引器正是你无法判断是否发生问题的时刻。这一个心跳机制同时捕获了已更新但未被索引的文档，以及悄然停止的流水线。

合同条款从内容本身转移到了周边元数据中。你无法约束文本内容本身，但可以强制要求每个数据块必须携带来源、版本、时间戳和访问范围，并拒绝不符合要求的任何内容。这些元数据也使得后续检索过程可追溯、可治理。

质量门禁检查需要针对文本特性设计验证规则：拒绝空或截断的数据块，识别可能扭曲检索结果的近似重复文档，标记失败的提取操作和OCR垃圾数据，并监控嵌入信息的漂移。格式错误或空的嵌入信息会扭曲相似性搜索，因此永远不会进入存储库，原因与错误价格永远不会传递给代理相同——扭曲的索引会使代理自信地检索出错误内容。

无论是价格数据行还是嵌入段落，处理任务的本质是相同的。架构必须在代理察觉之前就嗅出问题所在。

置信度阈值路由

合同条款、隔离机制和勋章架构处理的是明确的案例。但还存在灰色地带——数据本身并非明显错误，但也不完全可信。这就是置信度阈值路由发挥作用的地方，它连接了完全自主与完全人工控制之间的过渡区域。

代理处理请求时会评估数据质量信号，检查的不仅是模型置信度，还包括数据层面的信号如新鲜度、完整性、一致性。当置信度达到或超过阈值（例如85%）时，代理可自主处理；低于阈值时则转交人工处理。阈值可根据使用场景进行配置，例如定价可能需要90%的阈值，而内部FAQ可能只需70%即可。

让我们最后一次回到定价场景。价格数据已过时三天，而新鲜度SLA要求24小时。SLA违规会自动将置信度推低至阈值以下，无论模型自身对答案的置信度有多高。代理应作出如下回应：

“我对这个价格的时效性不够自信。将请求转交给人工进行验证。”

数据质量信号应驱动阈值判断，而非仅依赖模型自身的置信度。

换句话说，数据质量信号应驱动阈值判断，而非仅依赖模型自身的置信度。模型可能对过时答案非常确定，但新鲜度SLA会覆盖这种错误的确定性。

困难之处在于如何将这些质量信号转化为单一评分，并与模型自身的置信度进行权衡。这是一个尚未解决的开放性设计问题。建议从硬性门禁机制开始，而非平滑的复合评分。任何合同或SLA违规都必须强制转人工处理，无论其他信号如何。待后续证明加权评分优于简单规则后，再引入加权评分机制。

从哪里开始

你不需要一次性构建所有内容，大多数团队也无法做到这一点。合同、隔离网关、勋章架构和置信度阈值路由一次性部署的难度很高。好消息是这些措施是可叠加的，每项措施都能单独降低风险，你可以随着时间推移逐步添加其余部分。从杠杆效应最高的措施开始，然后逐步扩展。

  • 为每个智能体接触的数据集定义新鲜度 SLA。同一数据集对不同消费者可能有不同的新鲜度要求，例如，用于仪表板的定价表可以接受夜间批次更新，但当报价智能体依赖它时可能需要接近实时的更新。
  • 实施隔离网关。在数据进入智能体可访问的存储之前，验证其是否符合合同。从风险最高的数据集开始，例如定价、库存和客户记录。
  • 从数据合同 CLI 开始。将合同治理引入 CI/CD 流程，以 YAML 格式定义合同，自动验证，部署失败时阻止部署。以对待 API 合同的严谨程度对待数据合同。
  • 添加置信度阈值路由。当质量信号低于阈值时，交由人工处理。初始设置可设为较高值（约 90%），随着信任建立和准确性跟踪，逐步调低阈值。

我们已经让数据变得可信。但当智能体基于这些数据自主行动时，谁在监督？

可追溯性与治理：自主智能体的审计

即使拥有完美的数据，自主行动仍会引发更复杂的问题：当监管机构询问智能体为何采取某项行动时，你是否能给出答案？传统系统会记录发生了什么，而自主系统必须解释为何如此。这种从“发生了什么”到“为何如此”的转变，正是治理变得困难的地方。

审计缺口

设想一家银行使用自主 AI 进行贸易融资，其中治理架构才是真正的创新点。

一个智能体处理信用证时，会检查 KYC 数据，确认客户不在制裁名单中，评估信贷条款，并在约 30 秒内批准 240 万美元的交易。六个月后，监管机构提出一个简单问题：“为何批准？”

传统审计日志可以告诉你发生了什么，但无法解释原因。

传统审计日志可以告诉你发生了什么，包括查询了哪些表、什么时间、由哪个服务账户操作。但它们无法解释原因。为何智能体在检查信贷条款前先检查了制裁名单？为何在存在轻微文件差异的情况下仍批准？它考虑了哪些替代方案并予以拒绝？这种“发生了什么”与“为何如此”之间的差距正是监管风险的来源，欧盟《人工智能法案》第 12 条要求高风险系统必须保留自动日志，正是为了在事后重建“为何如此”的原因。填补这一差距正是自主血统（agentic lineage）的作用。

自主血统

填补这一审计缺口的方法是自主血统（agentic lineage），它是传统数据血统的扩展。传统血统追踪访问了哪些数据源，而自主血统追踪智能体为何决定访问 X，因为它在数据源 Z 中发现了 Y。

具体到贸易融资场景，单个追踪代表处理信用证 LC-4892 的端到端工作流。在该追踪中，每个跨度（span）代表一个独立步骤：

  • 跨度 1：从合规数据库检索客户 KYC 数据，结果：已验证。
  • 跨度 2：通过 OFAC API 检查制裁名单，结果：无问题。
  • 跨度 3：根据策略引擎评估信贷条款，结果：在限制范围内。
  • 最终跨度：决策结果为“批准”，置信度评分为94%，并附有完整的推理链。

这正是监管机构所需要的。不是“代理在UTC时间14:32:07访问了合规数据库”，而是“代理首先检查了KYC，然后是制裁，然后是信用条款，并因三项检查均通过而批准”。追踪和跨度模型直接借鉴自分布式系统可观测性领域，因此工程师们已经通过Jaeger和Zipkin等工具熟悉了这种思维模型。对于代理等价物，Langfuse、Arize Phoenix和OpenTelemetry for AI是新兴的选择。这三项技术均出现在Thoughtworks技术雷达中：OpenTelemetry处于“采用”阶段，Langfuse处于“试用”阶段，Arize Phoenix处于“评估”阶段。

监管的约束力是真实的

这并非理论上的探讨。欧盟人工智能法案是目前最具体的法规。第12条要求高风险人工智能系统在其生命周期内自动记录事件，以便追踪其运行过程；第19条要求供应商至少保留这些记录六个月。违反这些记录保存义务将触发法案中等处罚层级，最高可达1500万欧元或全球年度营业额的3%，以较高者为准。对于大型企业而言，即使全球营业额的3%也可能达到数亿欧元。

第12条和第19条共同转化为对系统架构的三项义务：

  • 在系统生命周期内自动记录事件，记录内容需足以追踪其运行方式，而不仅仅是孤立的时间戳。
  • 至少保留这些记录六个月，这意味着可观测性基础设施必须支持长期存储。
  • 事后能够重建“原因”。法规要求记录日志，但要让这些日志回答监管机构的问题则取决于自身。这意味着必须捕获完整的推理链，包括参考了哪些数据源、应用了哪些逻辑、代理考虑并拒绝了哪些替代方案。

欧盟目前走在最前列，目前其他司法管辖区尚无类似法规。但你无需押注监管落地的地点就能理解这一点。无论早晚，总会出现需要解释代理为何采取特定行动的情况，无论是监管机构、审计人员、对决策提出异议的客户，还是你自己的团队试图调试问题。安全的假设不是某个特定法规即将出台，而是你无论如何都希望回答这个问题。一个无法解释的系统，就是一个无法完全信任、捍卫或修复的系统。

分阶段的自主性

了解需要审计追踪是一回事，安全地实施则是另一回事。你不会在第一天就部署一个拥有完全自主权的代理，就像不会给新员工无限制的访问权限一样。自主性是通过阶段逐步获得的：

| 阶段 | 代理行为 | 人类行为 | 监控方式 | |------------|--------------------------------------------------------------------------|--------------------------------------------------------------------------|--------------------------------------------------------------------------| | 影子模式 | 推荐操作 | 审核推荐并在适当情况下执行 | 所有推荐均被记录以跟踪随时间推移的准确性 | | 监督模式 | 准备操作并等待批准 | 审核操作并批准或拒绝 | 所有提议的操作和人类决策均被记录 | | 带防护措施的自主性 | 在定义的边界内行动（最佳方式是通过可逆性而非交易规模划定边界） | 定义防护措施 | 所有操作均被记录，异常情况触发警报 | | 完全自主性 | 执行所有操作 | 偶发检查（由其他代理和人类进行持续检查） | 由其他代理和人类进行持续检查 |

你不会在第一天就给新员工公司信用卡。他们从提交采购请求开始，逐步过渡到受监督的支出，最终才能获得有限额的信用卡。代理也应以同样的方式赢得信任。

在这条晋升阶梯上，每一步都应基于证据而非直觉。这意味着在每一步之前都要对代理进行测试，而不仅仅是观察其在生产环境中的表现。代理难以测试，因为它们具有非确定性、调用成本高，且通过具有真实副作用的工具进行操作。因此团队会通过模拟或重放工具并建模交互，使测试在CI环境中确定性运行。他们使用评估（evals）来评分代理的决策，而不是在每次运行时都调用实时服务。构建这种测试框架本身就是一种专业技能，但超出了本文讨论范围。

委托访问与即时凭证

随着代理获得自主性，问题变为：它们应拥有哪些权限？此处有三个安全模式最为关键。

  • 委托访问：当Alice要求代理检查她的账户时，代理应使用Alice的权限进行操作，而不是通过一个可以查看所有客户数据的广义服务账户。共享服务账户会破坏归属追踪。当监管机构询问"谁访问了该客户的数据？"时，"服务账户"几乎无法提供有用信息。通过委托访问，答案会是"Alice的代理，代表Alice，使用Alice的权限进行操作。"
  • 即时凭证：不要使用永不失效的持久API密钥，而是为每个具体任务发放短期令牌。代理需要检查制裁名单？为该特定客户发放一个仅限OFAC API读取访问的令牌，有效期五分钟。任务完成后令牌即失效。没有闲置凭证等待被窃取。
  • 最小权限：代理仅获得任务所需的最低权限。处理信用证不需要访问HR系统或营销数据。

这三个模式共同解决了当前许多代理部署中阻碍归属追踪和范围控制的挑战。

它们也防御了代理系统中最尖锐的安全风险。Simon Willison称之为"致命三联"，当代理同时具备访问私有数据的权限、接触不可信内容的暴露，以及对外通信的途径时，就会变得危险。将这三者结合，一个被污染的文档或网页可通过提示注入劫持代理，并悄无声息地窃取其能触及的任何内容。委托访问、即时凭证和最小权限会限制被劫持代理的可触及范围，打破这"致命三联"。稍后我们将再次针对同一问题进行第二次切割，彻底将检索文本排除在授权路径之外，使被污染文档根本无法授予任何权限。

在四个主题中，这个领域需要保持谨慎是正确的直觉。但要区分两个容易混淆的概念：自主性是分阶段获得的，因此没人期望你一次性全部授予。可观测性则从第一天起就应完整实现，无论自主性水平如何，因为事后添加到运行系统中会非常痛苦。你在上层构建的内容可以保持保守，但底层的监控系统必须始终完整。

  • 从第一天起就进行监控。在所有事项中，这应该是首先执行的步骤，因为部署后添加可观测性要困难得多。每个代理工作流都应为每个步骤（包括推理和参考的来源）发出带有跨度的追踪。此处的追踪模式已得到充分验证，因此应使用经过验证的工具（如 OpenTelemetry），而不是自行构建。
  • 以影子模式启动。风险最低，学习最多。代理提供建议，人类做出决定。在需要合规性审计之前，就先构建审计轨迹；在授予自主权之前，先衡量准确性。
  • 实现委托访问。代理继承调用用户的权限，并使用即时凭证，且凭证有效期窗口较短。不使用持久化令牌。
  • 构建可解释性。无论监管机构是否曾要求过，能够回答“为什么”的审计轨迹都能帮助你调试错误决策、捍卫正确决策，并信任系统到足以扩大其自主权。现在就将其构建进去，之后添加会困难得多。

语义层通过利用早期主题提供的可信数据和可审计操作，弥合了代理与人类分析师之间的机构知识差距。

上下文层：教导代理你的数据意味着什么

当代理成为数据的主要消费者时，语义层为AI代理提供了显式的上下文，这些上下文是人类分析师基于多年经验隐含携带的。

你的代理不知道“收入”意味着什么

问代理：“产品X在第三季度的收入是多少？”人类分析师清楚该怎么做，知道要查询哪张表，收入是毛利还是净利，以及第三季度在你的财政日历中对应什么。他们通过多年的机构知识、部落文档和Slack线程吸收了所有这些信息。

而代理完全没有这些信息。它不知道哪些连接将产品与订单与收入关联起来，也不知道你的财政日历从二月开始。缺少这些上下文时，代理要么胡编答案，要么放弃。语义层填补了这一空白，提供了业务领域的上下文。

上下文层是什么

语义层是一组对指标的声明性定义，说明收入是如何计算的，什么是活跃客户，数字代表什么。所有消费者都通过相同的定义，因此都能得出一致且准确的结果。但一个需要行动的代理不仅需要数字的定义，还需要知道这些事物是什么，以及可以对它们做什么。这涉及三个独立的定义体系，代理需要全部三个。

领域模型说明了存在什么。实体、它们的关系以及业务的含义规则：订单属于客户，活跃客户是指过去90天内购买的客户。它为代理提供了解读请求和规划的词汇表。领域模型仅被咨询，从不被执行；没有查询路径会通过它访问数据。

语义模型说明数字是如何计算的。指标和维度，每个都有一个版本化的公式，每次编译为相同的SQL，并在分析存储中运行。这是语义层在更精确名称下的定义，其目标是将正确性置于编译器中，而不是模型的猜测中。

能力模型定义了代理可以执行的操作。它是一组针对实时系统的精选操作，其中一些用于读取（检查支付状态、获取故障排除指南），另一些用于写入（发起退款）。每个操作都带有权限和所有者，执行的操作还带有前提条件和可逆性类别。

名词、数字和动词。它们共同构成了上下文层，它们的统一之处并非在于它们都与含义相关，因为能力模型显然并非如此。真正的原因是，每个元素都在版本控制中一次性声明了保证，而不是在每次请求时由模型重新推导。定义本身构成了这一层；当前的接口MCP只是通向这一层的门。

熟悉dbt的读者可能会提出异议，认为其语义模型已经声明了实体，那为何还要单独分离出领域模型？因为在指标层中声明的实体仅限于指标范围，而能力模型必须使用与语义模型相同的术语，否则两者会逐渐偏离。退款操作作用于与收入数字相同的客户。如果底层使用统一的术语，否则就会出现两个术语体系。

图2：上下文层包括实体和关系的领域模型、针对分析数据存储编译为SQL的指标语义模型，以及针对实时系统的受保护读取和操作的能力模型，三个模型之间都有溯源信号。领域模型没有向外箭头，因为它只是被咨询而非执行；其他两个模型都使用它的术语。仪表板和分析师访问语义模型；代理是首个需要同时使用三个模型的消费者，这也是本文讨论的转变点。

这三个模型都是源代码控制中的代码。它们会经过代码审查，在CI中进行测试，并在进入生产环境前逐步通过各个环境。当“收入”定义或退款规则发生变化时，只需在一个地方修改，变更就会传播到所有相关位置。代理从不直接访问底层数据；它们必须通过上下文层，该层既限制了它们可以请求的内容，也规范了它们可以执行的操作。

作为代码的指标

实际上，业务逻辑直接嵌入在定义中，例如 revenue = order_amount - discount_amount，而不是隐藏在BI工具或临时SQL视图中。代理接收到自然语言问题后，语义模型会将其解析为正确且受约束的SQL。代理不会猜测表名或连接路径；它使用定义。

此处的示例使用了dbt MetricFlow语法（dbt正处于从度量向指标优先规范迁移的过程中；此处显示的是广泛使用的格式，无论采用哪种方式，概念都保持一致）。Cube.js、Snowflake和Databricks都遵循类似的模式。工具的重要性不如将业务逻辑纳入版本控制代码的纪律性。

code
semantic_models:
  - name: orders
    model: ref('orders')
    defaults:
      agg_time_dimension: order_date
    entities:
      - name: order_id
        type: primary
      - name: customer_id
        type: foreign
    dimensions:
      - name: order_date
        type: time
        type_params:
          time_granularity: day
    measures:
      - name: revenue
        agg: sum
        expr: order_amount - discount_amount
        create_metric: true

相同的问题，截然不同的SQL

让我们通过一个示例来说明。向没有语义模型的代理询问“产品X的第三季度收入是多少？”时，它会猜测表名、使用错误的列、没有财政日历映射，并遗漏连接。

code
-- 在指标定义之前
SELECT SUM(amount)
  FROM sales_data
 WHERE product = 'Product X'
   AND quarter = 'Q3'

使用语义模型向代理提出相同的问题时，代理会被限制在正确的表、YAML定义中的净收入公式、正确的财政日历日期以及有效的连接路径。

code
-- 受指标定义约束
SELECT SUM(order_amount - discount_amount)
  FROM orders o
  JOIN products p
    ON o.product_id = p.id
 WHERE p.name = 'Product X'
   AND o.order_date
       BETWEEN '2025-07-01'
           AND '2025-09-30'

语义模型不会让代理变得更聪明，而是阻止它进行猜测。对于一个未被答案验证的代理来说，这才是关键。

代理如何使用它

单独使用语义模型时，定量问题的处理路径如下。从端到端来看，流程如下：代理发送自然语言问题（步骤1）。语义模型通过MCP（步骤2）查找指标定义、有效维度、连接路径和访问规则，然后在同一组件内生成受约束的SQL（步骤3）。数据仓库执行查询（步骤4）。结果带着完整的血缘元数据返回给代理（步骤5）。

图3：三条路径之一：通过语义模型回答定量问题。关于事物属性的问题会导向领域模型，而对实时系统的读取或操作则通过能力模型。

代理只能选择受管控的指标，而不会选择可能误读的原始表

语义模型限制了代理可以请求的内容。例如，dbt会动态显示仅适用于所选指标的维度，这可以防止代理生成听起来合理但错误的查询。而步骤5中的血缘元数据是之前提到的可追溯性的基础。上下文和可追溯性相互强化。

在上下文层中，最大的诱惑是先建模整个业务再发布任何东西。要抵制这种诱惑。从语义模型开始，因为价值集中在少数指标上，这些指标对不同团队有不同含义。让第一个代理用例设定范围，逐步扩展领域模型和实际需要的能力，而不是你想象中的能力。一个狭窄但正确的上下文层胜过一个庞大但半共识的上下文层。

  • 1. 找出你的冲突指标定义。大多数组织对其最重要的指标有多个定义，收入是典型的例子，包括毛利与净利、是否包含退货等变体。这些冲突是你最大的代理风险，也是你最快的胜利点。
  • 2. 选择工具，但专注于方法论。任何主流语义层工具都可以；重要的是背后的方法论，包括指标定义的版本控制、每个指标一个共识定义，以及代理通过该层进行查询，而不是直接访问原始模式。
  • 3. 让代理通过上下文层，而不是原始模式。代理应看到受管控的指标和维度，而不是原始表和连接。MCP是目前暴露该层的通用方式，dbt、Cube和AtScale都提供MCP服务器，但无论你如何连接，关键是抽象层，而不是协议。
  • 4. 进行对抗性测试。发现漏洞的最佳方式是进行对抗性测试，每个幻觉都指向一个缺失的定义。应修正定义而非提示词。不要试图一口吃掉整个海洋，先从第一个代理用例所需的指标开始。

遍历领域模型：知识图谱

语义模型在处理结构化指标查询（如“按地区划分的收入”）时表现出色。但某些代理任务需要在实体、事件和时间之间进行更复杂的关联推理。例如，考虑一个客户购买了产品X，随后在价格调整后流失的情况。这种固定跳数的关联属于普通连接操作。平面表处理不好的是那种在编写查询时无法预知深度的遍历操作，需要沿着关系链一直追踪直到找到目标。这就是领域模型的用武之地，涉及实体及其连接方式。

存储和遍历这种关系图谱的通用方式是知识图谱，这是领域模型的存储选择，而非需要额外构建的第四种组件。微软的GraphRAG通过社区检测处理传统RAG无法应对的抽象查询，Graphiti则构建了能够感知时间变化的知识图谱以应对事实演变。（两者在2026年Thoughtworks雷达中均被列为试用阶段技术。）语义模型仍然定义指标；图谱则承载着客户、产品、事件和决策随时间变化的关联。二者结合为代理提供了接近机构记忆的知识，这种知识通常需要新员工数月时间才能掌握。

现在代理已经拥有可信数据、治理机制和上下文信息。但它们真的能采取行动吗？

从可检索到可操作：面向代理的数据访问

当代理理解了数据且治理机制就位后，问题就转向了访问权限。代理如何获取数据并对其采取行动？答案不仅仅是“RAG”。这是一个完整的光谱，从检索、实时查询到受控的写回操作。整个光谱构成了能力模型，这是三大模型中的第三个，而写回端正是其安全机制发挥作用的地方。

你的代理可以阅读，但无法行动

举个例子，员工报告了一个采购订单（PO）问题。理想的代理应执行三个操作：检索相关故障排除指南，检查当前PO支付服务是否中断，必要时创建帮助台工单。

传统RAG（目前大多数组织部署的模式）仅能完成第一步。它搜索文档并检索内容，但无法查询实时监控系统检查服务状态，更不可能在ServiceNow或Jira中创建工单。这种可检索与可操作之间的差距正是本节讨论的主题，我们将通过PO场景进行详细说明。

数据访问光谱

这一框架源自微软的AI云采用框架，其将该模型正式定义为RAG + MCP-Read + MCP-Write。

  • 检索。RAG、向量搜索、文档查找。代理找到相关内容。目前大多数组织停留在这一阶段。
  • 实时查询。代理查询实时系统，检查服务状态，实时读取数据库。
  • 写回。最强大也最危险的层级。代理创建工单、更新记录、触发工作流。

光谱每上升一个层级，能力增强的同时风险也增加。PO场景正好覆盖了这三个层级：

  • 检索指南（检索）
  • 检查支付状态（实时查询）
  • 创建工单（写回）

转向代理AI需要同时具备这三个要素，而不仅仅是大多数团队已构建的检索功能。

MCP已成为连接这些层级的默认方式，其发展速度令人瞩目。但机制本身的重要性不如层级划分。关键在于将检索、实时读取和写回作为三个独立且受控的访问层级，无论你是通过MCP还是自有原生API暴露这些功能。

三个基本元素，一个协议

代理通过MCP（模型上下文协议）实现这些功能。其基本元素位于风险梯度上：资源（只读）是安全的，提示（Prompts）影响行为，工具（Tools）改变状态。该梯度直接映射到层级结构，资源对应检索，工具对应写回，这也是为什么安全路径是先暴露资源，仅在受控条件下逐步过渡到工具。在PO场景中，资源提供故障排除文档，提示指导分类处理，工具执行check_service_status()和create_support_ticket()。

反模式：幼稚的API到MCP转换

设计这些工具的方式与使用时机同样重要。常见的代价高昂的错误是将现有REST API逐字封装，使每个端点都变成工具。结果是工具泛滥，出现50个类似get_po_payment_status、create_ticket_po_payment、create_ticket_po_payment_network的工具。代理必须在50个几乎没有区别的工具中选择，而大型语言模型（LLMs）并不擅长这种选择；随着工具数量增加，准确性会急剧下降。Thoughtworks技术雷达因此将“幼稚的API到MCP转换”标记为HOLD。

更优方案是将相同功能暴露为少量精心设计的能力，配有丰富描述和参数化输入。check_service_status接收服务名称和位置，一个工具适用于所有服务和所有位置。create_support_ticket通过类别、优先级和描述进行参数化。描述足够详细，使LLM能准确判断何时使用哪个工具。

五到十个良好描述的业务能力几乎每次都会优于50个薄的API封装

原则是设计能力而非端点。五到十个良好描述的业务能力几乎每次都会优于50个薄的API封装。这一原则与协议无关，无论代理通过MCP、其他代理还是未来任何标准访问你的数据，使数据具备代理就绪特性的属性都相同：丰富描述、参数化访问、清晰架构。

能力声明的内容

丰富描述告诉代理何时使用某个能力。它不涉及代理是否有权限使用，或使用错误时会发生什么。这些是声明的其余部分。每个能力都携带权限（谁可以调用及以何种身份调用）和所有者（能力出错时负责的人）。执行能力的工具还携带两个额外属性。

先决条件是在执行操作前必须满足的条件，这些条件会在执行时实时检查当前状态，而非基于代理在其计划中早期读取到的任何信息。退款需要原始支付记录，且该支付尚未退款，金额必须在调用用户授权范围内。

可逆性是指一个操作可能造成的损害类型：完全可逆、通过某种补偿交易可逆但需付出代价，或不可逆。相比涉及的资金数额，这是判断安全自主性的更有效指标。你可以撤销的5万美元内部账本修正比无法追回的200美元外部账户支付更适合作为自动化操作。在之前分阶段自主性阶梯中，规则的限制条件原本是根据交易规模设置的，现在应优先根据可逆性设置，无论代理人在哪个阶段，所有不可逆操作都必须获得人工批准。

可逆性比交易规模更能预测安全自主性

这引出了一个关键问题：这些前提条件中的规则究竟来自哪里？因为大部分规则都以文字形式写在某处，比如退款政策、合同或合规手册中。

检索文本用于告知，而非限制

商业文件始终是企业记录规则的地方。但限制操作的规则不能在执行时才被阅读和解释。这些规则应在事前从文档中提取，由人工筛选后，以声明式前提条件的形式存储在能力模型中，并附有回溯到原文出处的链接。

执行操作时，代理仍可阅读非结构化内容（如投诉工单、合同条款）来决定建议方案。但只有声明式规则决定哪些操作被允许，这些规则会以确定性方式与实时状态进行比对。关键界限在于告知与限制之间：检索文本可以影响代理人的建议内容，并作为人工审批者的证据，但本身不具备直接授权操作的权限。

这一界限也具有安全属性。将检索文本排除在授权路径之外，意味着被污染的文档无法授予代理人原本没有的权限，这比仅仅限制被劫持代理人可触及范围的声明更强。这不是万能的防御，因为注入的文本仍可能影响代理人的建议，而人工审批者看到伪造证据时可能也会通过。它消除的是文档直接授权操作的路径，中间没有任何人。

出处链接确保声明在文档变动时仍保持诚实。此处的承诺要格外谨慎。检测文档是否变更很容易；判断变更是否使从中推导出的前提条件失效则需要判断，而非简单比对差异。链接带来的价值是审查队列：当出处变动时，所有推导出的规则会被标记，由人工重新核查，这与将新鲜度SLA绑定到索引上次重建时间而非内容上次变更时间的思路一致。

当没有声明覆盖相关情况时，代理人不会根据对政策的解读自行发挥。它会升级处理。这是之前在不同场景中提到的硬性限制，与任何合同或SLA违约都必须由人工处理而非降低评分的直觉一致。未声明的情况会将代理人降级为监督模式，而非自主模式。

提取和筛选是一个与其他流水线类似的流程，需要指定负责人、执行周期，并有人处理审查队列。这将在后续章节中详细讨论，因为这些流程无法自我维持。

端到端：PO支付场景

在三个层级都就位后，我们最初提到的PO问题能够端到端地运行：代理检索故障排除指南（只读资源），检查实时支付状态（读取工具），并提交工单（写入工具），所有操作都在一个工作流中完成。

图4：一个代理，三个层级：检索、实时查询，然后写回，合并成一个响应。

如果人工处理，员工需要排队等待，解释问题，让支持代理查看监控仪表板，然后创建工单。现在代理能够在一次操作中完成所有这些步骤。

安全的实现方式是循序渐进地跨越层级，而不是直接跳到写回操作。大多数团队目前都处于检索层级——这是风险最低的只读层级。真正的危险在于写回操作。因此要循序渐进地提升。明确每个用例的需求，首先暴露只读访问权限，最后再添加写回功能，且仅在能够记录每项操作之后。

  • 1. 映射数据访问层级。选取代理的三个主要用例，分类每个用例所需的操作类型：检索、实时查询或写回。大多数缺口都出现在实时查询和写回层级。
  • 2. 设计能力而非端点。将现有API分组为5-10个描述清晰的业务能力。丰富的描述至关重要，因为这是LLM决定调用哪个工具的依据。
  • 3. 从MCP资源开始。只读访问是风险最低的切入点。将知识库、配置数据和文档作为资源暴露。只有在治理机制就绪后，才升级到工具层级。
  • 4. 从第一天起就进行监控。在部署任何具有写入权限的代理之前，记录每个工具调用的详细信息：触发者、调用内容、时间以及关键信息——代表谁发起的。这为可追溯性和治理部分的审计追踪提供数据支持。

AI就绪的数据栈

我们现在已经完整地讨论了四个主题：建立数据可信度的契约、使数据有意义且可操作的上下文层、使代理能够操作数据的访问模式，以及使这些操作可审计的可观测性。单独来看，它们似乎像是可以独立组建的四个工作流。但它们并非独立。它们相互构建，构建顺序至关重要。

图5：AI就绪的数据栈：自底向上构建的三个依赖层级，从第一天起可观测性贯穿所有层级。

依赖关系自底向上延伸。你无法对不可信的数据赋予意义，因此上下文层必须建立在可信数据基础上。没有这些意义的约束，你无法安全地让代理操作数据，因此访问层级必须建立在上下文层之上。跳过其中任何一层，所有上层结构都会崩溃。这正是许多代理AI项目停滞不前的原因。它们直接跳到代理访问，而没有构建底层基础。可观测性则不同。它不是作为第四个层级堆叠在顶部，而是与所有三个层级并行运行。每一层从处理实际工作开始就必须具备可追溯性和可审计性。信任检查、语义查询、代理操作，所有内容在生产环境中都必须可解释，而不是等到你有空进行监控时才考虑。此外，将可观测性添加到正在运行的系统中比从一开始就构建要困难得多。无论哪种方式，都要从第一天起就将其集成到系统中。

谁来负责所有这些？

该架构还有一个图中无法绘制的依赖项。每一层都会生成必须保持一致的产物：数据契约、指标定义、访问范围、可观测性追踪。产物不会自我维护。没有所有者的契约会与它描述的源数据逐渐失去同步。没有所有者的“收入”定义会重新分裂成你刚刚整合的三个冲突版本。没有所有者的访问范围会悄然扩大，直到再次成为通用服务账户。技术是必要的，但正是运营模式确保其诚信。

使这一切可行的纪律是将数据视为产品。每个数据集、契约和指标都有命名所有者、已发布契约和SLA，以及版本化生命周期，就像API一样。你不会总是知道每个消费者，对于公开或广泛共享的数据，你根本无法做到这一点，这正是契约重要的原因——它是未知消费者构建的稳定承诺，而弃用策略则是你在不破坏它们的前提下进行更改的方式。当product_pricing契约在凌晨2点阻止部署时，有人要为此负责。当财务和销售部门对“收入”存在分歧时，有人负责决策。当新代理请求访问权限时，有人负责审核访问范围。这些问题不是基础设施问题，而是所有权问题，没有工具能替你回答。

一个无人负责、逐渐偏离的无主数据集被人类消费者发现后会绕开它。代理以机器速度和规模消费它，并以同样速度传播错误。消费者越快、越自主，你越无法承担没有所有者的数据。

你处于什么位置？

在决定构建什么之前，先定位自己。根据以下信号对每个属性进行评分，所有信号均来自上述主题。

属性

人类时代

转型中

代理就绪

可信

松散模式，无新鲜度SLA；质量依赖分析师发现数字异常

关键数据集上有契约；质量检查但未在CI/CD中强制执行

契约以代码形式强制执行，每个消费者有新鲜度SLA，代理存储前进行隔离，代理仅读取Gold数据（表和嵌入）

上下文相关

指标定义存在于BI工具、SQL和人们的脑海中；人类提供上下文

部分指标以代码定义，但定义仍存在冲突，代理可能仍访问原始模式

Git中的上下文层：领域模型中的实体和关系，每个指标一个语义定义，精选能力集；代理通过该层路由，永不访问原始模式

可追溯

日志显示某人查询了什么及何时查询；原因存在于分析师脑海中

部分代理工作流有追踪；推理记录不一致

每个代理工作流发出包含跨度、推理和来源的追踪；任何决策的“原因”均可重建

受控

人们通过自己的角色访问数据；系统共享广泛服务账户

代理在范围广但长期有效的粗粒度凭证上运行

按用户委托访问，即时凭证，最小权限；致命三重路径已关闭

运营

无代理对数据采取行动；人们查看仪表板并手动采取行动

代理通过RAG检索；实时读取正在出现；写回功能处于实验或未受控状态

通过精心设计的能力实现三层；写回功能通过分阶段自主性和监控进行控制

不要平均处理这些行，因为堆栈是按依赖顺序排列的，你的准备程度受限于最薄弱的基础层。即使上下文层完美无缺，但如果它建立在不可信的数据之上，仍然无法使代理就绪。找到最薄弱的那行，这就是下一步投资的方向。

开始的四个方向

每个主题都有其自身的起点。将这些视为工作本身的操作清单。以下四个方向是开始的切入点。第一个方向——从第一天起就开始进行监控——并不是构建顺序中的步骤，而是与所有其他工作并行运行的持续性操作，因此它排在首位且永不停止。其他三个方向则从堆栈底部向上构建，因为你的准备程度取决于最薄弱的基础层。其中杠杆效应最高的单次行动是构建上下文层，因为上下文层对准确性的提升效果比更大模型更显著，但只有在底层数据可被信任后才能产生回报。逐步构建至这一层。

  • 从第一天起就开始进行监控。这不是构建顺序中的步骤，而是贯穿所有步骤的持续性操作。从一开始就为每个工作流添加追踪和跨度，因为可观察性比后期添加要难得多，你希望拥有能够回答“为什么”的审计追踪，以应对今天的调试和明天的监管审查。
  • 全面约束。确保数据新鲜度的SLA，严格执行模式规范，隔离不良数据。这是其他所有内容的基础，代理无法嗅出不良数据，因此数据架构必须代为检测。
  • 上下文优先于模型。一旦数据可被信任，构建上下文层是能带来最高回报的举措。仅凭其语义模型就能说明问题：在AtScale的文本到SQL基准测试中，使用语义层后，同一模型的准确率从原始模式的不足20%跃升至92.5%以上。
  • 读取优先于写入。从MCP资源（只读）开始，只有在治理机制到位后才逐步升级到工具（可写）。分阶段获得自主权：先通过影子模式，再通过监督模式，最后在具备防护机制的情况下实现完全自主。

当代理成为你数据的主要消费者时，你的数据架构就演变为AI架构。

我们将在即将出版的O'Reilly书籍《Data Architecture for Software Architects》中深入探讨这些内容，以及围绕它的更广泛的操作和分析数据架构决策。

致谢

感谢Martin Fowler鼓励我们基于在多个会议上所做的系列演讲，撰写关于这个主题的文章。我们还想感谢Rebecca Parsons、Kevin Hartman、Paul Hammant、Arun Srinivasan、Swapnil Phulse、Brian Smith、Ramanathan Santhanam、Cameron Casher和Mark Taylor为我们提供了全面的审阅和可操作的评论，帮助改进本文。

与行业中的大多数事物一样，我们使用了AI辅助来帮助研究、组织和格式化我们写作的某些部分。

重大修订

2026年8月27日：发布