Agent 不会怀疑
脏数据
人看到异常数字会停下来，Agent 往往会照常执行。系统必须接住人原本会有的这次停顿：先拦住不可信的数据，明确 Agent 能做什么，再在执行前按确定规则复查条件。
人会怀疑，Agent 会照常执行
人类分析师看到异常数字，通常会停下来，补充业务语境、翻查资料、找相关人员确认，再判断这个数字是否可信。Agent 不会自然完成这些动作。只要系统把一个值交给它，它就可能把这个值当作事实，继续分析、决策，甚至触发后续操作。
人看到不对劲的数据会停下来；Agent 会照常执行。
据原文强调句转述 · Pramod Sadalage、Prem Chandrasekaran两位作者把 Agent-ready data 概括为五项要求。过去，人往往会顺手核对含义和权限，也会留意异常情况，系统不用单独处理这些判断。现在，这些判断必须变成机器能执行的规则。漏掉任何一项，Agent 都可能在没有察觉的情况下把错误继续传下去。
五项要求落在一套三层架构上。底层是数据地基（data foundation），提供经过合约校验的可信数据；中间是上下文层（context layer），统一业务对象、指标算法和可执行能力；上层是访问层（access layer），决定 Agent 能检索什么、实时查询什么，以及能执行哪些写操作。可观测性（observability）从第一天起贯穿三层。
后面的工程问题可以归纳为四条主线：用数据合约设置质量硬门槛，用治理与追踪回答 Agent 为什么作出某个决定，用上下文模型统一业务含义，再把访问从可检索推进到可行动。原文说这个顺序是刻意的，先从数据合约开始，因为一个错值会污染建在它上面的每一层。
数据合约先把坏数据拦在门外
两位作者引用长期研究 LLM 应用失效模式的 Simon Willison 的说法：语言模型是轻信的（gullible）：别人递给它什么，它就相信什么，并据此继续执行。一个错值进入工作流后，Agent 不会停下来追问，只会自信地给出错误答案。
人会多一道判断
人类销售可能会想起上周刚调过价，于是停下来查另一张表、确认更新时间，或找业务负责人核实。
错误安静地传下去
Agent 既不了解过往业务情况，也没有发现异常的直觉。错误不触发犹豫，会沿工作流一路传到报价、库存或付款。
商品价格已经从 $49.99 调到 $59.99，Agent 连接的数据源却没有刷新，仍然返回旧值。它于是按 $49.99 报价，客户下单，每售出一件少收 $10。整个工作流都执行正确，错误只在于输入数据已经过期。
作者认为，许多组织就像前面的定价 Agent：对自己的数据很有信心，实际情况却并非如此。KPMG Global AI Pulse 调查了 2,145 名管理者，也指向同一方向。接近半数高管认为，AI 的成本已经超过收益。前面的错误定价场景，可能只需要一个过期字段就会发生。
原文给出的办法是数据合约。它把数据结构（schema）、质量规则和新鲜度要求（freshness SLA）写成一份可以纳入版本管理、可以在 CI/CD 流程里自动检查的契约。新鲜度要求规定数据或索引最久可以多久不刷新。作者主张严格执行数据结构约束。过去，宽松的结构对人类使用者可能只是不方便；对会自动采取后续动作的 Agent，它可能直接带来业务风险。
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: 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这份合约检查三件事。第一，字段类型和其它结构是否符合合约要求。第二，数据是否在规定时间内成功刷新。这里要看的是最后一次成功加载的时间，不是某个业务值最后变化的时间。这样，长期不变但仍然有效的值不会被误判为过期，已经卡住的数据管道也无法假装一切正常。第三，发布流程自动执行这些检查，不通过就拦住部署。
这套设计可以避免前面的错误定价场景：数据没有在 24 小时 内刷新，Agent 看到它之前，系统就会判定合约违约。这时 Agent 应回答自己没有当前的定价数据，而不是自信地报出错误价格。作者说这是更好的失败方式，也是数据架构的问题；更强的模型无法弥补错误输入。
Databricks 推广的奖牌式架构（medallion architecture）回答了通过校验的数据应该去哪里。Bronze 层保存原始数据，方便审计和追查来源；Silver 层负责校验、去重和隔离问题数据；Gold 层只放经过认证、可以放心使用的数据，语义模型也以这一层为基础。作者还建议为 Agent 增加一层 Adaptive Gold：Agent 根据真实查询模式，把经常一起使用的数据预先整理成更高效的数据集。
Apple 已经把数据目录数字管家（digital stewards）投入生产。在 DataHub 的 CONTEXT 2025 峰会上，Apple 介绍这类 Agent 如何持续扫描目录元数据、标出缺口并提出更新建议。Apple 的实践针对的是数据目录；Adaptive Gold 把同一种主动维护方式延伸到数据集本身。作者明确说明，后者仍是外推。
同一套规则也适用于文档、wiki、PDF 和工单。它们进入检索系统前，会被切成许多文本片段（chunk），系统再为这些片段建立向量索引。这里的“过期价格”可能变成另一种错误：政策文档已经更新，索引却没有重建，Agent 仍然检索到旧版本。24 小时 的 SLA 表示索引重建任务必须在过去 24 小时 内成功运行过。超过时限，就要把索引视为过期并隔离。
文档合约主要检查每个文本片段的附带信息。每个 chunk 都必须标明来源、版本、时间和访问范围，缺一项就拒收。系统还要拒绝空白或被截断的片段，识别近乎重复的文档，标出抽取失败或 OCR 产生的乱码，并监控向量表示是否随着时间或模型变化而偏移。无论输入是一行价格，还是一段已建立向量索引的文字，系统都要在 Agent 使用之前发现问题。
85%，定价可能要求 90%，内部 FAQ 可能以 70% 为界。怎样把多种信号合成一个分数，仍是开放问题。作者建议先用简单的硬规则：只要违反合约或 SLA，就直接转人工；加权评分以后再加。作者给出四项起步工作，并强调它们要叠加使用，每一项都能降低风险。
为每个 Agent 数据集规定刷新时限
同一份数据集，不同消费者可以有不同的新鲜度要求。定价表给仪表盘看，夜间批量或许足够；给报价 Agent 用，可能需要接近实时。
先隔离问题数据，再让 Agent 访问
从定价、库存、客户记录这些风险最高的数据集开始。
从 Data Contract CLI 起步
这款按 ODCS 校验合约的命令行工具已进入 Thoughtworks 技术雷达第 33 期。合约写成 YAML，在 CI/CD 中自动校验，失败就拦住部署。对待数据合约应当和对待 API 合约一样严格。
低于置信阈值就转人工
初始阈值设高一点，约 90%，等系统积累了可信的准确率数据，再逐步下调。
审计要能回答为什么，而不只是发生了什么
即使数据完全可信，自主行动仍然带来一个更难的问题。作者用贸易融资构造了一个示例：Agent 核对 KYC 数据、确认客户不在制裁名单、评估信用条件，随后批准一笔 $2.4 million 的交易，全程约 30 秒。6 个月 后，监管者问这笔交易为什么获批。
传统审计日志只能回答“发生了什么”：访问过哪些表、发生在什么时间、使用了哪个服务账号。它无法解释为什么先查制裁名单再看信用条件，为什么在文档有一处小瑕疵的情况下仍然批准，也看不到哪些备选方案曾被否决。Agent 决策链（agentic lineage）就是为了补上这个“为什么”。它借用了分布式系统的追踪方式：一条 trace 代表一次完整工作流，其中每一步叫作 span。
verifiedclearwithin limits94% 置信分监管者需要的不是「Agent 在 14:32:07 UTC 访问了合规数据库」，而是「Agent 先检查 KYC，再查制裁名单，然后评估信用条件，三项通过后批准」。分布式追踪工具 Jaeger 和 Zipkin 已经让工程师熟悉了这套心智模型；对应到 agentic 场景，原文列出 Langfuse、Arize Phoenix 和面向 AI 的 OpenTelemetry，并转述了它们在 Thoughtworks 技术雷达上的位置：OpenTelemetry 为 Adopt，Langfuse 为 Trial，Arize Phoenix 为 Assess。这是作者转述的雷达定级，不是本站的产品推荐。
这两项规定给架构设计提出三项要求：事件要在整个生命周期内自动记录，记录的信息要足以追溯运行过程，不能只有几个孤立时间戳；日志至少保存 6 个月，可观测基础设施因此要支持长期存储；系统还要能事后重建决策过程和理由，因为法律强制要求的只是日志，让日志真正回答监管者的问题是系统建设者的责任。对大型公司而言，即使是全球营业额的 3% 也可能达到数亿量级。
他们对法规范围给了一个克制的判断：欧盟目前走得最前，其它司法辖区还没有完全类似的法律，但系统迟早需要回答 Agent 为什么这样做，提问者可能是监管者、审计师、对决定有异议的客户，也可能是排查故障的内部团队。安全的假设不是某条法律必然到来，而是团队无论如何都会需要这个答案。系统如果无法解释，人们就难以充分信任它，也无法为它辩护或修复它。
自治权不会在第一天就交给 Agent，而要靠证据逐步取得。原文把它划成四个阶段，每个阶段同时规定人做什么、以及必须记下什么。
| 阶段 | Agent | 人 | 监控 |
|---|---|---|---|
| Shadow Mode | 提出建议 | 复核建议，认为合适就执行 | 全部建议入日志，用于长期跟踪准确率 |
| Supervised | 准备好动作，等待批准 | 复核动作，批准或拒绝 | 全部待批动作和人的决定入日志 |
| Autonomous with guardrails | 在既定边界内执行，边界最好按可逆性划、而不是按交易金额划 | 定义护栏 | 全部动作入日志，异常触发告警 |
| Full autonomy | 执行全部动作 | 抽查 | 持续监控，由其它 Agent 和人共同完成 |
这套路径像培养新员工。公司不会在入职第一天就把信用卡交给新人。新人先提交采购申请，再获得有人监督的支出权限，最后才拿到设有限额的卡。Agent 也要用测试结果证明自己可以进入下一阶段，不能只靠生产环境中的观察。为了让测试可以稳定复现，团队会模拟或回放工具与模型交互，再用评测程序自动打分，避免每次都调用线上服务。
Agent 获得一定自治权后，还要限制它代表谁、能访问什么。第一，委托访问让 Agent 继承发起人的权限，并明确记录它代表谁，而不是所有任务共用一个宽权限服务账号。第二，即时凭证只为当前任务签发短时、窄范围的令牌。例如查制裁名单时，令牌对 OFAC API 只有只读权限，只能查询这个客户，并在 5 分钟 后失效。第三，最小权限保证处理信用证的 Agent 无法访问无关的 HR 系统或市场数据。
Simon Willison 把这种组合称为 lethal trifecta：Agent 能访问私有数据，会接触不可信内容，还能向外发送信息。一份被投毒的文档或网页可能通过 prompt injection 操纵 Agent，再把它拿到的数据发出去。委托访问、短时凭证和最小权限会缩小 Agent 被操纵后能够触及的范围，从而拆开这三个条件。
shadow mode 起步，在审计线索成为合规要求之前把它建好；上线委托访问与过期窗口很短的凭证，不保留长期令牌；按「能够被解释」的目标建设，因为一条答得出「为什么」的审计线索，正是让团队敢于放宽自治的依据。上下文层要说明三件事：有什么、怎么算、能做什么
问 Agent「Product X 的 Q3 收入是多少？」人类分析师知道该查哪张表、收入按毛收入还是净收入计算、Q3 在企业自定的财务日历里对应哪段时间。Agent 没有这些背景，它不知道怎样通过 join 把商品连到订单和收入，也不知道企业的财年从二月开始。缺少语境时，它只能编出答案，或者放弃回答。
语义层填补的是这个缺口：把指标怎么算集中声明一次，让所有消费者使用同一份定义。但作者接着把这件事又往前推了一层。一个会行动的 Agent 不只需要知道数字怎么定义，它还要知道业务里存在什么，以及自己可以做什么。这是三套彼此独立的声明。
域模型
说「存在什么」。实体、关系和业务含义规则：一个订单属于一个客户，活跃客户是过去九十天内买过东西的客户。
它只供查阅、不被执行，没有任何通向数据的查询路径经过它。
语义模型
说「数字怎么算」。每个指标一条版本化公式，每次都编译成同一份 SQL，并在分析库上运行。
它要做的是把正确性放进编译器，而不是放在模型的猜测里。
能力模型
说「Agent 可以做什么」。它包含一组经过挑选、面向实际业务系统的操作，有的读（查付款状态、取排障指南），有的写（发起退款）。
每项都要声明权限与负责人；会改变状态的操作还要声明 preconditions 与 reversibility class。
三套模型分别对应名词、数字和动词：业务里有什么，指标怎么算，Agent 能做什么。它们的共同点是把规则集中定义一次，放进版本控制，而不是让模型每次收到请求都重新猜。作者用一句话概括：定义才是这一层的核心，MCP 之类的接口只是入口。
熟悉 dbt 的人可能会问：这个把指标定义写成代码的数据转换工具，它的 semantic_models 已经声明了实体，为什么还要单独建立域模型。原文的回答是，指标层里的实体只服务于指标，范围仍被限定在指标计算内；而能力模型必须和语义模型使用同一套词汇，否则两者会逐渐脱节。他给的理由很具体：一笔退款所指的客户，必须和收入指标所统计的客户采用同一定义。两套模型要共享同一套业务词汇。
三套模型都是源码管控下的代码，经过 code review、在 CI 中测试，再按环境逐级进入生产。收入定义或退款规则一变，只改一个地方，变化就传播到所有使用者。业务逻辑直接写成 revenue = order_amount - discount_amount，而不是藏在某个 BI 工具或临时 SQL 视图里。
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例子用的是 dbt MetricFlow 当前广泛使用的写法。MetricFlow 是 dbt 用来声明语义模型和指标的组件。dbt 正在从 measures 迁移到以指标为先的规范，但两种写法承载的概念一致；Cube.js、Snowflake 和 Databricks 也采用类似模式。作者强调，具体工具不如统一的工程约束重要：业务逻辑要写进版本控制的代码。同一个问题在有无语义模型时，会产生完全不同的 SQL。没有语义模型，Agent 会猜表名和字段，可能用错收入列，遗漏财务日历映射，也可能漏掉必要的 join。
-- Before metric definition
SELECT SUM(amount)
FROM sales_data
WHERE product = 'Product X'
AND quarter = 'Q3'加入语义模型后，查询会使用正确的表、净收入公式和 join 路径，日期范围也会按照企业的财务日历计算。
-- Constrained by metric definition
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'语义模型没有让 Agent 变聪明，只是让它不再猜。对于一个可能不加核对就按答案行动的 Agent，这一点更重要。
dbt 的做法是动态只呈现与所选指标相关的维度，防止 Agent 生成听起来合理、实际却错误的查询。第五步返回的血缘元数据，又成为前一节可追溯性的基础，语境和可追溯性由此相互增强。
作者提醒，不要一开始就试图为整个业务建模。先从最容易产生争议的指标入手，例如收入到底是毛收入还是净收入、是否包含退货。让第一个 Agent 用例决定范围，一个窄而完整的上下文层，胜过一个范围很大却只做了一半的模型。工具可以选 dbt、Cube 或 AtScale。MCP 只是入口，关键是所有查询都经过同一层定义。对抗测试发现 Agent 猜错时，应补上缺失的定义；只改提示词不能补齐语境。
域模型、知识图谱和本体是什么关系
这套词汇还没有完全定型，同一批工件常被不同市场术语指代。经典意义上的语义层，从 Business Objects 到后来的 LookML 和 Cube，往往把实体、关系和指标打包在一起，因此很多人至今仍用「语义层」指代整件事。把界线划得更清，是因为 Agent 让这些差异开始影响实际治理。
这里使用“模型”而不是“层”，因为每一部分都是一组定义，不是一层基础设施。工具也沿用这种叫法，例如 dbt 使用 semantic_models。还有一份厂商中立的语义模型规范，最初来自 Open Semantic Interchange 倡议，现在已成为 Apache Ossie。
域模型也有几个常见别名。把其中的实体和关系存成图，得到的就是知识图谱。领域驱动设计称它为域模型，其中的 Bounded Context 则提醒，没有单一模型能够覆盖整个企业。追求一份全企业统一的规范模型通常只是幻影，各业务域有自己的模型，再按 Data Mesh 所描述的方式联邦治理。
市场上更常见的名字是 ontology，中文叫“本体”。它与这里的域模型指向同一类工件，用来明确描述共享概念。RDF、OWL 和 SHACL 是常见的机器可读表达方式。严格来说，本体只负责描述，不负责执行动作。Palantir Foundry Ontology 把对象、属性、关系和 Agent 可以采取的动作打包在一起；Databricks Genie Ontology 则在受治理的指标定义之上维护公司概念之间的关系。两位作者选择把动作单独放进能力模型，因为读取和写入的风险不同，需要分开治理。
还有一条落地经验：这些定义通常不必从零手写。系统可以先从现有表结构、术语表和实际查询中生成初稿，再由人整理完善。
2026 年两者在 Thoughtworks 技术雷达上都处于 Trial。分工仍然清楚。语义模型定义指标，图记录客户、商品、事件和决定之间跨时间的关系。两者合在一起，为 Agent 提供组织长期积累的业务语境。这些知识通常需要一名新人花几个月才能逐渐掌握。
从检索到执行，风险逐档上升
作者构造了一个采购订单场景。一名员工报告 PO 付款问题，理想的 Agent 会取出相关排障指南、查询付款服务当前是否正常、必要时创建一张服务台工单。多数组织已经部署的传统 RAG 只能完成第一件事，无法查询实时监控系统，也不能在 ServiceNow 或 Jira 中创建工单。
这套框架来自微软的《AI 云采用框架》，把访问分成三档。第一档是检索（RAG），Agent 只能查文档。第二档是实时查询（MCP-Read），Agent 可以查看正在运行的系统、服务状态和数据库实时数据。第三档是写回（MCP-Write），Agent 可以创建工单、修改记录或触发工作流。每升一档，能力更强，风险也更高。真正能行动的 Agent 需要具备三档能力，不能只停留在文档检索。
MCP 正在成为连接这三档的常用方式，但治理边界比协议本身更重要。无论底层用 MCP 还是自有 API，文档检索、实时读取和写回都应分开授权。MCP 的 Resources 是只读内容，风险最低；Prompts 用来约束行为；Tools 可以改变系统状态。因此，通常应先开放只读的 Resources，治理到位后再开放 Tools。
| 设计方式 | 暴露面 | Agent 面临的选择 |
|---|---|---|
| 把每个 REST endpoint 一对一包成工具 | 50 个 | 名字像 get_po_payment_status、create_ticket_po_payment、create_ticket_po_payment_network，含义相近、上下文不足；作者说 LLM 不擅长这种选择，工具数量增加后准确率明显下降 |
| 设计成业务能力 | 5–10 个 | check_service_status 接服务名和位置，一个工具覆盖所有服务与位置；create_support_ticket 用类别、优先级和描述参数化，描述详细到足以让 LLM 判断何时调用 |
Thoughtworks 技术雷达因此把“把每个 API 端点直接包装成 MCP 工具”列入 HOLD。作者主张设计少量完整的业务能力，而不是把端点原样搬过去。5 到 10 个描述清楚、参数明确的能力，通常比 50 个单薄的 API 包装更容易让 Agent 选对。这个原则与协议无关：无论入口是 MCP、另一个 Agent，还是未来的新标准，都需要清楚的描述、参数和数据结构。
三档都到位后，采购订单场景可以在一次工作流中完成。换成人工流程，员工需要排队、解释问题，等支持人员查看监控面板，然后才能得到一张工单。作者给出四项起步工作：把最靠前的三个用例逐个归类为检索、实时查询还是写回，多数缺口会出现在后两档；把现有 API 归并成 5–10 个描述清楚的业务能力；从 MCP Resources 这个只读入口开始，治理到位后再升级到 Tools；在部署任何带写权限的 Agent 之前，记录每次工具调用由谁触发、调用了什么、发生在何时，以及 Agent 代表谁调用。
真正执行前，再检查一次权限和条件
能力模型会为每项操作写明权限和负责人。会改变系统状态的操作，还要写清两个边界：执行前必须满足哪些条件，以及操作出错后能不能撤销。
这些前置条件必须在动作真正执行时，根据业务系统的最新状态重新检查。Agent 规划任务时看到的状态，到执行时可能已经变化，不能继续作为授权依据。Agent 可以提出动作，但它自己生成的计划不能证明执行条件已经满足。
作者认为，可逆性比交易金额更适合界定自治边界。
内部账务调整
金额更大，但存在明确的反向操作，即使出错也能退回去，因此可能更适合在护栏内自动执行。
对外付款
金额更小，却可能在资金离开系统后无法追回。不可逆动作无论处于哪个自治阶段，都必须经过人工批准。
可逆性比交易金额更能预测安全的自治。
据原文强调句转述 · 前一节自治阶梯以交易金额划界，作者更主张按可逆性划按可逆性分类，动作可以直接回滚、需要付出成本才能补偿，或完全不可逆。每项操作原本就要声明权限和负责人，前置条件与可逆性是在此基础上增加的两道边界。与金额大小相比，可逆性更适合用来划定自治范围。规则通常来自退款政策、合同和合规手册，提前转成结构化条件，再由确定性代码检查系统的当前状态。
检索文本可以影响建议，不能授予权限
系统先从政策、合同或操作手册中提取候选规则，再交给人审核。审核通过后，规则才会成为操作的正式前置条件，并保留指向原始段落的来源链接。执行时，只有这些结构化规则能打开授权闸门。
按照这一设计，Agent 执行任务时仍可以读取投诉记录、合同条款和政策说明，并据此形成判断或建议。这些文本能够影响它建议采取什么动作，也能作为证据交给人类审批人；动作是否获准则由已经声明并审核过的结构化规则决定，而且系统必须在执行当下用确定性代码检查当前状态是否满足规则。
原文同时说清了这条边界管到哪里。它保证检索内容不能绕过 capability 中已经声明的授权条件，作者说这条保证比「缩小被操纵 Agent 能触及的范围」更强，因为一份被投毒的文档从此不能直接给出授权。但被污染或恶意修改的文档仍可能误导 Agent 作出错误建议，也可能欺骗人类审批人，因此不能构成完整的 prompt-injection 防御。它阻断了文档未经人工审核就直接授予权限的做法。
文档变化后，系统可以自动发现差异，并找出哪些前置条件可能受到影响。它可以顺着来源链接生成复核队列，把相关规则交给负责人。但文档含义是否真的改变、结构化条件是否需要更新，仍要由人判断。来源链接能帮助定位问题，不能代替判断。
现有声明规则未覆盖的动作转入 supervised 阶段处理，由人作出批准决定。Agent 可以整理证据、说明建议和待确认事项，但不能直接从政策文本中推导出新的授权。这里沿用第 02 节的处理原则：遇到未声明的情形就转人工，而不是继续自动执行。
先让数据可信，再补足语境，最后开放写操作
数据合约让数据可信，上下文层让数据有明确含义，也能支撑动作，访问模式让 Agent 能够读取或修改数据，可观测性让整个过程可以被追溯、被审计。原文指出，单看这四个主题，它们像是可以分头推进的工作流，但它们并不独立，而是相互叠加，建设顺序也有明确要求。
依赖关系自下而上。无法信任的数据也无法承载可靠的含义，因此上下文层必须建立在可信数据之上；没有上下文层提供的含义和约束，也无法安全地允许 Agent 行动，因此访问层又建立在上下文层之上。跳过其中任何一层，上面的能力都会失去支撑。作者认为，这正是许多 agentic AI 项目卡住的原因：它们直接从 Agent 访问开始，却没有先建好下面的地基。
可观测性并不是压在最上面的第四层。它与三层并行，并贯穿整个栈。每一层从处理真实工作的第一天起就必须可被追溯、可被审计，可信校验、语义查询和 Agent 动作都要能在生产环境里被解释清楚，而不是等系统运行后再补装仪表。往一个已经运转的系统里补装可观测性，远比从一开始就建进去困难。两条路径最终都指向同一个结论：第一天就接入。
图中没有画出的另一条依赖是所有权。每一层都会产生需要长期维护的规则或定义，而它们不会自动保持准确。
作者认为，技术只是基础，日常运营方式才决定这套体系能否长期可靠。核心做法是“把数据当产品运营”（data as a product）：每个数据集、合约和指标都要有明确负责人、公开的合约与 SLA，以及版本化的生命周期，就像维护一个 API。组织不可能认识所有数据消费者，因此更需要用合约提供稳定承诺，并用弃用政策说明如何替换旧合约而不破坏下游系统。
所有权最终要落到具体的人。当 product_pricing 合约在凌晨两点拦下一次部署时，要有人对此负责；财务和销售无法就「收入」达成一致时，要有人负责作出决定；一个新的 Agent 申请访问权时，也要有人负责确定范围并复核。作者把这些归为所有权问题，工具无法代替组织作答。人类消费者遇到一份无人管理、不断漂移的数据集，往往能察觉异常并绕开它；Agent 会以机器的速度和规模消费这些数据，再以同样的速度把错误传下去。
在决定先建设什么之前，可以先判断组织目前处在哪个阶段。下面这张表按五项要求列出三个阶段的典型信号。
| 属性 | 人的时代 | 过渡中 | Agent-ready |
|---|---|---|---|
| Trusted | schema 松散，没有 freshness SLA；质量依赖分析师看出某个数字不对 | 少数关键数据集有合约；质量有检查，但没在 CI/CD 中强制 | 合约作为代码被强制执行，freshness SLA 按消费者分别设定，进入 Agent 存储前先隔离，Agent 只读 Gold，表和 embedding 都算 |
| Contextual | 指标定义散落在 BI 工具、SQL 和人脑里，语境由人补上 | 部分指标已写成代码，但定义仍有冲突，Agent 仍可能碰到 raw schema | 上下文层进 Git：域模型里的实体与关系、每个指标一份语义定义、一组经过挑选的能力；Agent 走这一层，从不走 raw schema |
| Traceable | 日志显示某人查过什么、什么时候查的；为什么留在分析师脑子里 | 部分 Agent 工作流有 trace，推理记录不一致 | 每条 Agent 工作流都发出带 span、推理和来源的 trace，任何决定的「为什么」都可重建 |
| Governed | 人按各自角色访问数据，系统之间共享宽权限 service account | Agent 使用范围受限、但长期有效且粒度粗的凭证 | 按用户委托访问、just-in-time 凭证、最小权限，lethal trifecta 的路径已封 |
| Operational | 没有 Agent 对数据行动，人读完仪表盘再手工处理 | Agent 通过 RAG 检索，实时读取开始出现，写回还在试验或未受治理 | 三档都通过设计良好的 capability 提供，写回受分阶段自治和观测约束 |
agent-ready。下一步应先补最弱的基础项。前面各节都提供了各自的起步点，那些是完成单项工作的战术清单。下面四项回答的是整个栈应该从哪里开始。可观测性贯穿所有步骤，因此排在第一位，并在后续阶段持续运行；其余三项按栈的依赖从下向上展开。作者认为，在单项建设中，上下文层带来的收益最大，因为补足语境比换用更大的模型更能提高准确率。底层数据可信之后，这项收益才会出现。
第一天就建立可观测性
可观测机制要从头到尾持续运行。每条工作流从一开始就记录 trace 和 span，因为补装远比内建困难，而系统需要一条能回答「为什么」的审计线索，今天用于排查，明天用于应对监管审查。
万物皆合约
落实 freshness SLA，严格执行 schema，并隔离坏数据。这是其余能力赖以建立的地板：Agent 无法察觉坏数据，数据架构必须代替它完成这项判断。
语境优先于模型
作者引用的是 AtScale 自己发布的 text-to-SQL 评测：同一个模型面对 raw schema 时准确率不到 20%，加入语义层后达到 92.5% 以上。AtScale 也是原文在上下文层那一节列举的语义层工具厂商之一。
先读后写
从只读的 MCP Resources 起步，只在治理能力到位后再升级到能执行写操作的 Tools。自治分阶段获得：先 shadow mode，再 supervised，最后才是在护栏约束下自治。
当 Agent 成为数据的主要消费者，数据架构本身就成为 AI 架构。
Pramod Sadalage · Prem Chandrasekaran · 两位作者说会在即将出版的 O'Reilly 图书《Data Architecture for Software Architects》里更深入地讨论这些内容