让你的数据为智能体 AI 做好准备

当前，人们对智能体框架、编排模式和协议充满热情。这些都很重要，但如果跳过数据层，几乎没有任何东西能够带来价值。在任何智能体框架产生有用成果之前，你的数据必须具备机器能够消费、信任并据此采取行动的形式。本文将讨论，为了让智能体式 AI 从数据中获取价值，你的数据需要是什么样子。There's a lot of excitement right now about agent frameworks, orchestration patterns, and protocols. All of it matters, but almost none of it delivers value if you skip the data layer. Before any agent framework can produce useful outcomes, your data has to be in a shape that a machine can consume, trust, and act on. In this article, we discuss what your data needs to look like for agentic AI to derive value from it.

我们已经花费了相当多的时间，为人类消费者构建数据架构。我们即将把这些架构交给一种截然不同的消费者，而它们中的大多数还没有准备好应对这一点。We've spent quite a bit of time building data architectures for the human consumer. We're about to hand those architectures to a very different kind of consumer, and most of them aren't ready for it.

您数据的使用者正在发生变化The consumers of your data are changing

三十多年来，我们一直在为人类构建数据系统。仪表板、报告、分析师查询——所有这些都围绕着坐在屏幕前的人来设计。事实证明这行得通，因为人类拥有海量的隐性背景信息，也有足够的好奇心去向身边的人追查自己所缺失的信息。For over three decades, we've been building data systems for humans. Dashboards, reports, analyst queries, all of it designed around a person sitting in front of a screen. And it worked, because humans bring an enormous amount of implicit context, along with the curiosity to track down whatever they're missing from the people around them.

人类分析师知道“收入”在你所在的具体组织中意味着什么。他们知道该查询哪些表、避开哪些表。他们会注意到某个数字看起来不对劲、某个总额出奇地整齐、某个日期恰逢公共假日，或某个价格似乎过低。这种直觉实际上完成了大量无形的上下文理解和知识工作。A human analyst knows what “revenue” means in your particular organization. They know which tables to query and which ones to avoid. They notice when a number looks off, when a total is suspiciously round, when a date falls on a public holiday, or when a price seems too low. That instinct is doing a large amount of invisible context and knowledge work.

智能体对此一无所获。它们无法依赖人们多年积累的部落知识和模式识别能力，因此需要明确的上下文、实时访问权限，以及值得信赖的质量。而最关键的区别在于：当数据感觉不对时，人类会再次核查；智能体却会自信地据此采取行动。本次讨论的其余部分正是围绕这一行为差异展开的。Agents have none of it. They can't lean on the tribal knowledge and pattern recognition people accumulate over years, so they need context made explicit, access in real time, and quality they can rely on. And the difference that matters most is this: when the data feels wrong, a human double-checks; an agent confidently acts on it. That behavioral gap is what the rest of this discussion is built around.

如今“AI-ready”必须意味着什么What “AI-ready” has to mean now

对于人类消费者而言，数据只需足够好即可；剩下的工作由分析师完成。数据的含义、合理性检查，以及判断某个数字是否值得信任，都存在于人的头脑中。当同样的数据交给代理时，所有这些隐性的工作都必须转移到数据本身。这体现为五项属性，每一项都是人类过去无偿完成的某种工作的反面。For a human consumer, the data only had to be good enough; the analyst did the rest. The meaning, the sanity check, and the judgment about whether a number could be trusted all lived in a person's head. When the same data is handed to an agent, every bit of that implicit labor has to move into the data itself. That shows up as five attributes, each the flip side of something a human used to do for free.

• 值得信赖：人会在感觉不对的数字前停下来；代理却会据此采取行动。过去由人提供的那份信心，如今必须内置其中，因此数据在交给代理查看之前，必须准确、及时且经过验证。
  Trusted: a person pauses at a number that feels wrong; an agent acts on it. The confidence a human used to supply has to be built in, so the data must be accurate, fresh, and validated before the agent ever sees it.
• 上下文信息：某人知道你的“收入”数字已经扣除了退货，并且你的财年从二月开始；而代理必须同时获知这两点。过去存在于某人脑中的含义，必须在数据中明确表达出来。
  Contextual: a person knows your “revenue” figure already has returns taken out, and that your fiscal year starts in February; an agent has to be told both. Meaning that used to live in someone's head has to be made explicit in the data.
• 可追溯性：当一个人做出决定时，事后可以解释自己为什么这么做；而当代理在 30 秒内做出决定时，除非在决策发生的同时将推理过程记录下来，否则这些理由就会消失。你必须能够重构代理做了什么，以及它为什么这么做。
  Traceable: when a person decides, they can explain why afterward; when an agent decides in 30 seconds, that reasoning is gone unless you capture it as it happens. You have to be able to reconstruct what the agent did and why.
• 受治理：人的访问权限受其角色和判断力约束；而智能体的访问权限必须在设计层面加以限制。访问权限必须明确范围、受到控制并可审计。
  Governed: a person's access is bounded by their role and their judgment; an agent's has to be bounded by design. Access must be scoped, controlled, and auditable.
• 操作性：一个人读取仪表板后会采取行动；而智能体必须能够执行相应的操作。数据不能只是可读，还必须具备可操作性。
  Operational: a person reads a dashboard and then goes and does something; an agent has to be able to do the something. The data can't just be readable, it has to be actionable.

这五点归根结底都是同一个理念。每一点都是人类过去无需思考便会完成的工作，而如今却被转移到了数据本身中。漏掉任何一点，智能体就无法像人一样优雅地降级，而是会自信地失败。All five come down to the same idea. Each is a job humans used to do without thinking, now pushed into the data itself. Miss one, and the agent won't degrade gracefully the way a person would. It fails confidently.

这些属性都不会自行建立。本文其余部分将围绕四个主题展开，大致按照你应当着手处理它们的顺序进行。None of these attributes builds itself. The rest of the article works through four topics that do, roughly in the order you should tackle them.

1. 数据契约与质量让数据值得信赖。我们从这里开始，因为一个错误的事实会污染其上构建的每一层。
   Data Contracts and Quality makes data Trusted. We start here, because a single wrong fact poisons every layer built on top of it.
2. 可追溯性与治理记录代理采取行动的原因，并界定其可访问的范围，从而使数据具备可追溯性并受到治理。
   Traceability and Governance records why an agent acted and bounds what it can reach, making data Traceable and Governed.
3. 上下文层对指标和实体的含义进行编码，使数据具备上下文。
   The context layer encodes what your metrics and entities mean, making data Contextual.
4. 从可搜索到可执行，让代理查询实时系统并写回数据，使数据实现运营化。
   From Searchable to Actionable lets agents query live systems and write back, making data Operational.

我们将一次讨论一个主题，展示构建每个属性所需的工作。完成全部四项后，这五个属性就不再是抽象的目标，而会变成你可以通过工程手段实现的东西，将普通数据转化为适用于 AI 的数据。We'll take them one topic at a time, and show what it takes to build each attribute in. Work through all four, and the five attributes stop being abstract goals. They become something you can engineer, turning ordinary data into AI-ready data.

数据契约与质量：智能体无法嗅出糟糕的数据Data Contracts and Quality: Agents Can't Smell Bad Data

人类有一种能够识别糟糕数据的直觉。他们会注意到某个数字看起来不对、某个日期毫无意义，或者某个价格似乎有误。而智能体没有这种本能。正如 Simon Willison 所说，语言模型很容易轻信，它们会相信别人提供的一切，并据此采取行动。给 AI 智能体输入一个错误的值，它不会停下来思考，只会使用这个数字，并生成一个自信却错误的答案。没有可信的数据，智能体式 AI 的其他一切都无法运作，因此我们就从这里开始。Humans have a smell test for bad data. They notice when a number looks off, when a date makes no sense, or when a price seems wrong. Agents have no such instinct. As Simon Willison puts it, language models are gullible, they believe whatever they are handed and act on it. Feed an AI agent a wrong value, and it won't pause to wonder, it will use the number and produce a confident, wrong answer. Without trusted data, nothing else in agentic AI works, so this is where we begin.

代理会将每个值都视为真实情况Agents treat every value as truth

考虑一个具体场景。有人向定价代理询问产品 X 的当前价格。昨天，价格已从 49.99 美元更新为 59.99 美元。但代理的数据源尚未刷新，仍然显示旧价格。Consider a concrete scenario. A pricing agent is asked for the current price of Product X. Yesterday, the price was updated from $49.99 to $59.99. But the agent's data source hasn't refreshed, it still shows the old number.

代理毫不犹豫地提取了 49.99 美元，向客户报价，客户购买了，而公司每售出一件产品就亏损 10 美元。代理采取的每一步在技术上都是正确的。它完美地遵循了工作流程。问题出在它访问的数据上。The agent doesn't hesitate, it retrieves $49.99, quotes the customer, the customer buys, and the company loses $10 on every unit sold. Every step the agent took was technically correct. It followed its workflow perfectly. The data it accessed was the problem.

一个人工销售代表会停下来：“等等，我们不是上周才更新过这个吗？”他们会再次核查。他们拥有组织记忆，也能凭直觉察觉哪里不对劲。而智能体两者都没有。错误不会触发警告，而是悄无声息地在整个工作流中层层蔓延。这也不是罕见的极端情况。在《2026年数据完整性与人工智能就绪度现状报告》中，Precisely 与德雷塞尔大学 LeBow 商学院调查了 505 位数据与分析领域的领导者，其中 87% 认为自己的数据已为人工智能做好准备，但仍有 43% 的人将数据就绪度列为从中获得价值的最大单一障碍。这种信心与就绪度之间的差距，就是组织层面的 pricing agent：自信满满，却判断错误。KPMG 另一项针对 2,145 位领导者开展的《全球人工智能脉搏调查》也指向同一结论：如今，近半数高管认为人工智能的成本已经超过其收益。大多数企业距离上述情景，仅差一个过时字段。A human sales rep would have paused: “Wait, didn't we update this last week?” They'd double-check. They have institutional memory and a feel for when something's off. The agent has neither. Errors don't trigger warnings; they cascade silently through the workflow. And this isn't a rare edge case. In the 2026 State of Data Integrity and AI Readiness report, Precisely and Drexel University's LeBow College of Business surveyed 505 data and analytics leaders, of whom 87% believed their data was ready for AI, yet 43% named data readiness as the single biggest barrier to getting value from it. That gap between confidence and readiness is the organization-level version of the pricing agent, sure of itself and wrong. A separate KPMG Global AI Pulse survey of 2,145 leaders points the same way, with nearly half of executives now seeing AI's costs exceed its benefits. Most enterprises are one stale field away from the scenario above.

Schema 即法律：将数据契约代码化Schema is law: data contracts as code

那么，如何防止 AI 代理访问错误或过时的数据？答案是数据契约：将架构视为法律，而不是礼貌性的建议。So how do you prevent AI agents from accessing bad or stale data? The answer is data contracts, treating schema as law, not a polite suggestion.

这扭转了长达十年之久的“无模式更灵活”思维：对于人类使用者而言，宽松的模式仅仅是不便；而对于 AI 代理而言，它们却很危险。数据契约采用开放数据契约标准编写，这是 Data Contract CLI 所使用的格式（Thoughtworks 技术雷达第 33 期也推荐该格式），并明确规定了相关规则。一个 product_pricing 契约可能会规定：This reverses a decade of “schemaless is flexible” thinking, for human consumers, loose schemas are merely inconvenient, while for AI agents, they're dangerous. A data contract, written in the Open Data Contract Standard, the format the Data Contract CLI uses (and recommended in Thoughtworks tech radar 33), defines the rules explicitly. A product_pricing contract might specify:

• 具有严格逻辑类型的属性。
  Properties with strict logical types.
• 价格必须大于零的质量规则。
  A quality rule that price must be greater than zero.
• 一项货币质量检查，拒绝所有非 USD、EUR 或 GBP 的货币。
  A quality check on currency that rejects anything outside USD, EUR, or GBP.
• 关键在于，根据新鲜度 SLA，定价数据必须在过去 24 小时内刷新过。
  Critically, a freshness SLA, pricing data must have been refreshed within the last 24 hours.

在开放数据契约标准中，该契约如下所示。In the Open Data Contract Standard, that contract is shown below.

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

执行体现在三个维度上。Enforcement happens along three dimensions.

• 模式强制执行确保类型和约束得到遵守，并由契约明确规定。
  Schema enforcement ensures types and constraints are respected and made explicit by the contract.
• 新鲜度 SLA 定义了每个数据集可接受的最大陈旧程度；当代理需要实时作答时，仅靠夜间批量更新是不够的。应根据数据上次成功加载的时间来设定 SLA，而不是根据某个值上次发生变化的时间，这样既不会将稳定不变的数据误判为陈旧，也不会让停滞的流水线伪装成数据仍然新鲜。
  Freshness SLAs define the maximum acceptable staleness per dataset, nightly batch updates aren't enough when an agent answers in real time. Key the SLA to when the data was last successfully loaded, not when a value last changed, so that steady data isn't flagged as stale and a stalled pipeline can't masquerade as fresh.
• 质量门禁会在 CI/CD 中验证契约，验证失败时阻止部署。
  Quality gates validate contracts in CI/CD, blocking deployments when they fail.

请注意，这会改变之前的定价场景，并且从设计上杜绝了这种情况。如果定价数据在 24 小时内没有刷新，那么在代理看到数据之前，合同就已经被违反了。Notice how this changes the earlier pricing scenario, it prevents it by design. If the pricing data hasn't been refreshed in 24 hours, the contract is violated before the agent ever sees the data.

隔离模式The quarantine pattern

定义契约是一回事。当数据违反契约时会发生什么？你需要一个断路器，而这就是隔离区模式。Defining a contract is one thing. What happens when data violates it? You need a circuit breaker and that's the quarantine pattern.

流程如下。原始数据从源系统、API、数据库和数据流中到达。在进入代理可访问的数据存储区之前，它会经过一个契约验证门，检查三项内容：是否符合架构、是否满足新鲜度 SLA，以及是否通过质量规则？The flow works like this. Raw data arrives from source systems, APIs, databases, streams. Before it enters the agent accessible data store, it passes through a contract validation gate that checks three things, does it match the schema, is it within the freshness SLA, and does it pass the quality rules?

如果它通过全部三项检查，就会进入经过认证、可供智能体使用的层级。如果其中任何一项未通过，它就会被隔离，转入死信队列供人工审核，并触发警报。If it passes all three, it flows into the certified, agent ready tier. If it fails any one of them, it's quarantined, routed to a dead letter queue for human review, with alerts fired.

关键在于，智能体根本看不到错误数据。它不会因过时的价格或损坏的嵌入向量而受到污染。在定价场景中，如果 ingested_at 时间戳早于 24 小时前，就意味着违反了契约，该记录会被隔离。因此，当被问及价格时，智能体会说：“我没有当前的定价数据”，而不是信心十足地报出错误数字。这是一种好得多的失败模式。而且，这项工作应该由数据架构来完成，而不是交给模型。更好的模型无法帮你挽救糟糕的数据。The point is that the agent never sees the bad data. It doesn't get poisoned by stale prices or corrupted embeddings. In the pricing scenario, if the ingested_at timestamp is older than 24 hours the contract is violated and the record is quarantined, so when asked about the price the agent says, “I don't have current pricing data” rather than confidently quoting the wrong number. That is a far better failure mode. And it's a job for the data architecture, not the model. A better model won't rescue you from bad data.

面向智能体的 Medallion 架构Medallion architecture for agents

奖章架构是一种用于在湖仓中组织数据的分析型数据设计模式，由 Databricks 推广开来。A medallion architecture is an analytical data design pattern for organizing data in a lakehouse, popularized by Databricks.

有问题的数据会被隔离，但优质数据会流向何处？这正是奖章架构所要组织管理的内容，而它的前三个层级已经相当成熟：Bad data gets quarantined, but where does the good data go? That's what the medallion architecture organizes, and its first three tiers are well established:

• 青铜层：原始、不可变的数据摄取。保留所有内容，以便审计追踪和数据溯源。
  Bronze: raw, immutable ingestion. You keep everything for audit trail and lineage.
• Silver：已完成验证和去重。已应用架构，数据契约得到强制执行，隔离区模式就位于此处。
  Silver: validated and deduplicated. Schema is applied, data contracts are enforced, and this is where the quarantine pattern lives.
• 黄金标准：已认证。这是语义模型编译所依据的标准，访问权限受控，指标值得信赖。
  Gold: certified. This is what the semantic model compiles against, access is governed, and metrics are trusted.

对于代理式架构而言，还值得增加一个有用的第四层级：自适应黄金层（Adaptive Gold）。在这一层中，代理不再是被动的数据消费者，而是成为数据整理的主动参与者（如下图所示）。它们会监控自身的查询模式，识别经常访问的数据组合，并具体化经过优化的数据集，实际上是根据真实使用情况构建属于自己的数据仓库视图。代理可以主动整理数据，而不只是读取数据——这一理念已经投入生产。在 DataHub 的 CONTEXT 2025 峰会上，Apple 描述了代理充当其数据目录的“数字管家”，持续扫描元数据、标记缺口并提出更新建议，将被动的文档转变为主动的治理伙伴。Apple 的代理负责整理目录；而自适应黄金层则将同样的主动整理模式应用于数据集本身。最后这一步虽属于推演，但只是从某项已经运行的实践出发所做的适度延伸。For agentic architectures, there's a useful fourth tier worth adding: Adaptive Gold where agents become active participants in data curation rather than passive consumers (shown in the figure below). They monitor their own query patterns, identify frequently accessed combinations, and materialize optimized datasets, effectively building their own warehouse views based on real usage. The idea that agents can actively curate data, rather than only read it, is already in production, at DataHub's CONTEXT 2025 summit, Apple described agents acting as “digital stewards” of its data catalog, continuously scanning metadata, flagging gaps, and proposing updates, turning passive documentation into an active governance partner. Apple's agents curate the catalog; Adaptive Gold points that same active-curation pattern at the datasets themselves. That last step is an extrapolation, but a modest one from something already running.

图 1：代理的数据奖章层级：数据从原始青铜层流经已验证的白银层，再到认证的黄金层和由代理整理的自适应黄金层，而代理只能访问黄金层及以上层级。Figure 1: Medallion tiers for agents: data flows from raw Bronze through validated Silver to certified Gold and agent curated Adaptive Gold, while agents are restricted to Gold and above.

关键架构原则是，代理只能访问 Gold 层级或更高级别的数据。Bronze 和 Silver 层级用于数据溯源、调试和人工调查。向代理暴露原始或仅经过部分验证的数据，会让定价问题卷土重来。The key architectural principle is that agents should only access Gold tier or above. Bronze and Silver exist for lineage, debugging, and human investigation. Exposing raw or partially validated data to agents invites the pricing problem back in.

非结构化数据同样适用这些规则The same rules for unstructured data

到目前为止，一切看起来都像是表格、价格、货币和时间戳，但代理所消费的大多数内容并不是表格数据，而是文档、Wiki、PDF 和支持工单；这些内容会被切分并嵌入向量存储，以便检索。如果你的代理使用 RAG，那么它们运行所依赖的就是这些数据。尽管你无法在一段文字上写下“价格 > 0”这样的约束，但这些数据同样需要具备可信性保障。相关模式仍然适用，只是质量维度发生了变化。Everything so far has looked like a table, prices, currencies, timestamps, but most of what agents consume isn't tabular. It's documents, wikis, PDFs, and support tickets, chunked and embedded into a vector store for retrieval. If your agents do RAG, this is the data they run on, and it needs the same trust guarantees, even though you can't write price > 0 on a paragraph. The patterns carry over, only the quality dimensions change.

这里也存在与陈旧价格相对应的情况。政策文档得到更新，但向量索引没有重新嵌入，因此智能体检索到旧版本，并据此自信地作答；这与陈旧价格导致的故障相同，只不过现在陈旧的是嵌入，而不是数据行。新鲜度 SLA 同样适用，但必须准确说明时钟衡量的是什么：关键不在于内容上次更改的时间，而在于索引上次根据其数据源成功重建的时间。24 小时 SLA 意味着重新索引作业必须在最近 24 小时内完成；如果没有完成，索引就应被视为陈旧并隔离，即使表面上看似没有任何变化，因为索引器静默失败时，恰恰无法判断是否发生了变化。这一次心跳检查同时捕获了已更新但尚未建立索引的文档，以及悄然停止运行的管道。The stale-price scenario has a twin here. A policy document gets updated, but the vector index isn't re-embedded, so the agent retrieves the old version and answers confidently from it, the same failure as the stale price, only now it's an embedding rather than a row. The freshness SLA carries over, but be precise about what the clock measures, the point isn't when the content last changed, it's when the index was last successfully rebuilt against its sources. A 24-hour SLA means the re-indexing job must have completed within the last 24 hours, if it hasn't, the index is stale and quarantined even when nothing appears to have changed, because a silently failed indexer is exactly when you can't tell whether something did. That one heartbeat catches both the updated but unindexed document and the pipeline that quietly stopped.

契约从内容转移到了周围的元数据上。你无法约束散文式文本，但可以要求每个内容块都带有来源、版本、时间戳和访问范围，并拒绝不符合要求的内容。也正是这些元数据，让后续的检索具备可追溯性并受到治理。Contracts move from the content to the surrounding metadata. You can't constrain the prose, but you can require that every chunk carry a source, a version, a timestamp, and an access scope, and reject anything that doesn't. That metadata is also what makes retrieval traceable and governable later.

质量门禁会执行适合文本的检查，拒绝空块或被截断的块，捕捉会使检索结果产生偏差的近重复文档，标记提取失败和 OCR 垃圾内容，并监测嵌入漂移。格式错误或为空的嵌入会扭曲相似性搜索，因此绝不会进入存储库；道理与错误价格绝不会传给代理相同，扭曲的索引会让代理自信地检索出错误内容。Quality gates get checks suited to text, reject empty or truncated chunks, catch near-duplicate documents that skew retrieval, flag failed extractions and OCR garbage, and watch for embedding drift. A malformed or empty embedding warps similarity search, so it never reaches the store, for the same reason a bad price never reaches the agent, a warped index makes the agent retrieve confidently wrong content.

无论数据是一行定价信息，还是嵌入其中的段落，处理工作都完全相同。架构必须在代理发现问题之前，就嗅出其中的不妥。Whether the data is a priced row or an embedded paragraph, the job is identical. The architecture has to smell what's bad before the agent does.

置信度阈值路由Confidence-threshold routing

契约、隔离区和奖章架构能够处理明确的情况。但还存在一个灰色地带：有些数据并非明显错误，却也不完全值得信任。这正是置信度阈值路由发挥作用的地方，它在完全自主与完全人工控制之间架起了桥梁。Contracts, quarantine, and the medallion architecture handle the clear cases. But there's a gray area, data that isn't clearly bad, but isn't fully trustworthy either. That's where confidence-threshold routing comes in, bridging full autonomy and full human control.

代理处理请求并评估数据质量信号，不仅检查模型置信度，还会检查数据层面的信号，例如新鲜度、完整性和一致性。如果置信度达到或超过阈值（比如 85%），代理就会自主继续处理；低于该阈值时，代理会转交人工处理。阈值可根据具体用例进行配置，例如定价可能要求 90%，而内部常见问题解答达到 70% 即可。The agent processes a request and assesses data quality signals, and checks not just model confidence, but data-level signals like freshness, completeness, and consistency. If confidence is at or above the threshold (say 85%), the agent proceeds autonomously. Below it, the agent defers to a human. The threshold is configurable per use case, for example, pricing might demand 90%, while an internal FAQ is fine at 70%.

让我们最后再回到定价场景。价格数据已经过时三天，而新鲜度 SLA 要求不得超过 24 小时。无论模型本身对答案多么有信心，违反 SLA 都会自动使置信度评分降至阈值以下。代理应通过介入人工来回应：Let's return to the pricing scenario one last time. The price data is three days stale; the freshness SLA says 24 hours. The SLA violation automatically drives the confidence score below the threshold, regardless of how confident the model itself feels about its answer. The agent should respond by pulling a human in:

我不确定这个价格是否为当前价格。正在转交人工进行核实。“I'm not confident this price is current. Routing to a human for verification.”

换句话说，数据质量信号应当决定阈值，而不只是依赖模型自身的置信度。模型可能对一个过时的答案深信不疑，但新鲜度 SLA 优先于这种错误的确定性。In other words, data quality signals should drive the threshold, not just the model's own confidence. A model can be sure of a stale answer, and the freshness SLA overrides that misplaced certainty.

难点在于将这些质量信号转化为单一分数，并将其与模型自身的置信度进行权衡。这是一个尚未解决的开放性设计问题。先采用硬门槛，而不是平滑的综合评分。任何合同或 SLA 违约都会强制转交人工处理，无论其他信号如何。之后再加入加权评分，但前提是你能够证明它优于那条简单规则。The hard part is turning those quality signals into a single score and weighing it against the model's own confidence. That's an open design problem, not a solved one. Start with a hard gate rather than a smooth composite. Any contract or SLA breach forces a human, regardless of how the other signals look. Add weighted scoring later, and only once you can show it beats that simple rule.

从哪里开始Where to start

你不必一次性构建所有这些，而且大多数团队也做不到。要一口气建立契约、隔离门、奖章架构和置信度阈值路由，需要投入大量工作。好消息是，这些措施可以逐步叠加，每一项都能独立降低风险，你还可以随着时间推移逐层加入其余措施。先从杠杆效应最高的举措入手，再逐步扩展。You don't have to build all of this at once, and most teams can't. Contracts, quarantine gates, a medallion architecture, and confidence-threshold routing are a lot to stand up in one go. The good news is that they're additive, each one lowers risk on its own, and you can layer in the rest over time. Begin with the highest leverage moves and expand from there.

1. 为智能体接触的每个数据集定义新鲜度 SLA。同一数据集针对不同使用者可能有不同的新鲜度要求，例如，供仪表板使用的定价表按夜间批处理更新即可，但当报价智能体依赖该数据集时，可能需要近乎实时的更新。
   Define freshness SLAs for every dataset agents touch. The same dataset can have different freshness requirements per consumer, such as a pricing table that's fine on nightly batches for a dashboard may need near real time updates when a quoting agent depends on it.
2. 实施隔离门控。在数据进入代理可访问的存储之前，根据契约进行验证。首先处理风险最高的数据集，例如定价、库存和客户记录。
   Implement quarantine gates. Validate against contracts before data enters agent accessible storage. Start with your highest risk datasets such as pricing, inventory, customer records.
3. 从 Data Contract CLI 开始。将契约治理纳入 CI/CD，以 YAML 定义契约，自动进行验证，并在验证失败时阻止部署。以对待 API 契约同等严格的标准来管理数据契约。
   Start with the Data Contract CLI. Bring contract governance into CI/CD, define contracts as YAML, validate automatically, block deployments on failure. Treat data contracts with the same rigor you'd give an API contract.
4. 添加置信度阈值路由。当质量信号低于某个阈值时，转交人工处理。初始值设高一些（约 90%），随着信任度的建立和准确率的跟踪，再逐步下调。
   Add confidence threshold routing. When quality signals drop below a threshold, defer to a human. Start high (around 90%) and adjust downward as you build trust and track accuracy.

我们已经让数据变得可信。但当智能体基于这些数据自主行动时，谁在监督？We've made data trustworthy. But when agents act autonomously on that data, who's watching?

可追溯性与治理：审计自主代理Traceability and Governance: Auditing Autonomous Agents

即使数据完美无缺，自主行动仍会引出一个更棘手的问题：当监管机构询问代理为何采取某项行动时，你能回答吗？传统系统记录发生了什么，而智能代理系统必须解释为什么这么做。这种从“是什么”转向“为什么”的变化，正是治理变得困难的地方。Even with perfect data, autonomous action raises a harder question, when a regulator asks why the agent did what it did, can you answer? Traditional systems record what happened. Agentic ones have to explain why. That shift, from what to why, is where governance gets hard.

审计缺口The audit gap

设想一家银行将智能体 AI 应用于贸易融资，其中真正的创新在于治理架构。Picture a bank running agentic AI for trade finance, where the governance architecture is the real innovation.

一名代理处理一份信用证。它检查 KYC 数据，核实客户不在制裁名单上，评估信用条款，并在大约 30 秒内批准一笔 240 万美元的交易。六个月后，监管机构提出了一个简单的问题：“为什么批准了这笔交易？”An agent processes a letter of credit. It checks KYC data, verifies the customer isn't on a sanctions list, evaluates the credit terms, and approves a $2.4 million transaction, all in about 30 seconds. Six months later, a regulator asks a simple question, “Why was this approved?”

传统审计日志可以告诉你发生了什么、查询了哪些表、在什么时间、由哪个服务账户执行。但它们无法告诉你为什么。为什么代理会先检查制裁名单，再查看信贷条款？为什么在存在轻微文档不一致的情况下仍然批准了？它考虑并拒绝了哪些替代方案？“是什么”与“为什么”之间的鸿沟正是监管风险产生的地方，而《欧盟人工智能法案》第12条要求高风险系统保留自动日志，正是出于这一原因，以便事后重建“为什么”。弥合这一鸿沟，正是代理式溯源的作用所在。Traditional audit logs can tell you what happened, which tables were queried, at what time, by which service account. What they can't tell you is why. Why did the agent check the sanctions list before the credit terms? Why did it approve despite a minor documentation discrepancy? What alternatives did it consider and reject? The gap between “what” and “why” is where regulatory risk arises, and the EU AI Act's Article 12 requires high-risk systems to keep automatic logs for exactly this reason, so the “why” can be reconstructed after the fact. Closing that gap is what agentic lineage is for.

智能体谱系Agentic lineage

弥合这一审计缺口的方法是采用智能体式血缘，这是传统数据血缘的延伸。传统血缘追踪访问了哪些来源，而智能体式血缘则追踪智能体为何决定访问 X，因为它在来源 Z 中发现了 Y。The way to close this audit gap is agentic lineage, an extension of traditional data lineage. Where traditional lineage tracks which sources were accessed, agentic lineage tracks why the agent decided to access X, because it found Y in source Z.

具体来说，在贸易融资案例中，单条追踪记录代表处理信用证 LC-4892 的端到端工作流。在该追踪记录中，每个跨度都是一个独立步骤：Concretely, for the trade finance case, a single trace represents the end-to-end workflow of processing letter of credit LC-4892. Within that trace, each span is an individual step:

• 跨度 1：从合规数据库检索客户 KYC 数据，结果：已验证。
  Span 1: retrieved customer KYC data from the compliance database, result: verified.
• 跨度 2：通过 OFAC API 检查了制裁名单，结果：无异常。
  Span 2: checked the sanctions list via the OFAC API, result: clear.
• Span 3：根据策略引擎评估了信用条款，结果：在限额范围内。
  Span 3: evaluated credit terms against the policy engine, result: within limits.
• 最终片段：决策为 APPROVE，置信度得分为 94%，并附有完整的推理链。
  Final span: the decision, APPROVE, with a 94% confidence score and the full reasoning chain attached.

这正是监管机构所需要的。不是“代理于 14:32:07 UTC 访问了合规数据库”，而是“代理先检查了 KYC，然后检查制裁名单，接着检查信贷条款，并因三项全部通过而批准”。trace 和 span 模型直接借鉴自分布式系统可观测性，因此工程师已经能从 Jaeger 和 Zipkin 等工具中理解这一思维模型。对于代理系统对应的方案，Langfuse、Arize Phoenix 和面向 AI 的 OpenTelemetry 正逐渐成为主流选择。这三者都出现在 Thoughtworks 技术雷达上：OpenTelemetry 位于 Adopt，Langfuse 位于 Trial，Arize Phoenix 位于 Assess。This is exactly what a regulator needs. Not “the agent accessed the compliance database at 14:32:07 UTC” but “the agent checked KYC first, then sanctions, then credit terms, and approved because all three passed.” The traces and spans model is borrowed directly from distributed systems observability, so engineers already understand the mental model from tools like Jaeger and Zipkin. For the agentic equivalent, Langfuse, Arize Phoenix, and OpenTelemetry for AI are the emerging choices. All three feature on the Thoughtworks Technology Radar, OpenTelemetry at Adopt, Langfuse at Trial, and Arize Phoenix at Assess.

监管措施确实有实际约束力The regulatory teeth are real

这不是理论上的练习。《欧盟人工智能法案》是目前最具体的法规。第12条要求高风险人工智能系统在其整个生命周期内自动记录事件，以便追溯其运行情况；第19条要求提供商至少保留这些日志六个月。违反这些记录保存义务将落入该法案的中等处罚档次，最高可处以1500万欧元或全球年度营业额的3%，以较高者为准。对于大型企业而言，即使是全球营业额的3%，也可能达到数亿欧元。This isn't a theoretical exercise. The EU AI Act is the most specific regulation on the books. Article 12 requires high-risk AI systems to automatically log events over their lifetime so their operation can be traced, and Article 19 requires providers to keep those logs for at least six months. Breaching these record-keeping obligations falls in the Act's middle penalty tier, up to €15 million or 3% of global annual turnover, whichever is higher. For a large company, even 3% of global turnover runs into the hundreds of millions.

综合第 12 条和第 19 条，你的架构需要承担三项义务：Together, Articles 12 and 19 translate into three obligations for your architecture:

• 自动记录系统整个生命周期中的事件，足以追踪其运行方式，而不仅仅是孤立的时间戳。
  Automatically log events across the system's lifetime, enough to trace how it operated, not just isolated timestamps.
• 至少保留这些日志六个月，这意味着你的可观测性基础设施必须能够处理长期存储。
  Retain those logs for at least six months, which means your observability infrastructure has to handle long-term storage.
• 能够在事后重构“为什么”。法律要求保留日志；让这些日志能够回答监管机构的问题，则是你的责任。这意味着要记录完整的推理链条、查阅过哪些来源、应用了什么逻辑，以及代理评估并拒绝了哪些替代方案。
  Be able to reconstruct the “why” after the fact. The law mandates the logs; making them answer a regulator's question is on you. That means capturing the full reasoning chain, which sources were consulted, what logic was applied, and which alternatives the agent weighed and rejected.

欧盟走在最前面，而目前还没有其他司法管辖区制定出与之完全相同的法律。但要理解这一点，并不需要押注于监管最终会走向何方。迟早会有某种因素迫使你回答：代理为什么会做出它所做的事情？这个因素可能是监管机构、审计师、对某项决策提出异议的客户，也可能只是你自己的团队试图调试某个问题。稳妥的假设不是某项特定法律即将出台，而是无论如何，你都会希望回答这个问题。一个无法解释的系统，就是一个你无法完全信任、辩护或修复的系统。The EU is furthest ahead, and for now no other jurisdiction has a law quite like it. But you don't have to bet on where regulation lands to see the point. Sooner or later something will force the question of why an agent did what it did, whether that's a regulator, an auditor, a customer disputing a decision, or just your own team trying to debug one. The safe assumption isn't that a particular law is coming, it's that you'll want to answer that question regardless. A system you can't explain is one you can't fully trust, defend, or fix.

分阶段自主性Staged autonomy

知道需要审计跟踪是一回事；安全地推行这一方案则是另一回事。你不会在第一天就部署一个拥有完全自主权的代理，就像你不会把不受限制的访问权限交给一名刚入职的新员工一样。自主权需要分阶段逐步获得：Knowing you need audit trails is one thing; rolling this out safely is another. You don't deploy an agent with full autonomy on day one, any more than you'd hand a brand new employee unrestricted access. Autonomy is earned in stages:

你不会在新员工入职第一天就把公司的信用卡交给他们。他们会先从采购申请开始，逐步过渡到受监督的支出，最终凭借表现赢得一张设有额度限制的信用卡。智能体也应当以同样的方式赢得信任。You wouldn't give a new hire the corporate credit card on day one. They start with purchase requests, graduate to supervised spending, and eventually earn a card with limits. Agents should earn trust the same way.

沿着这条阶梯晋级，应该以证据为依据，而不是凭直觉。这意味着在每一步之前都要测试智能体，而不能只在生产环境中观察它。智能体很难测试：它们具有非确定性，调用成本高，并且会通过工具执行具有真实副作用的操作。因此，团队会对工具和模型交互进行模拟或回放，让测试能够在 CI 中确定性地运行。他们通过评估（evals）为智能体的决策打分，而不是每次运行都调用线上服务。构建这套测试工具链本身就是一门独立的学问，超出了本文的讨论范围。Promotion up this ladder should turn on evidence, not a hunch. That means testing an agent before each step, not only watching it in production. Agents are hard to test. They're nondeterministic, costly to call, and act through tools with real side effects. So teams mock or replay the tool and model interactions so tests run deterministically in CI. They score the agent's decisions with evals rather than calling live services on every run. Building that harness is a discipline of its own, and beyond the scope of this article.

委派访问权限和即时凭据Delegated access and just-in-time credentials

随着智能体获得更高的自主性，问题就变成了：它们应当拥有哪些权限？这里最重要的是三种安全模式。As agents earn autonomy, the question becomes, what permissions should they hold? Three security patterns matter most here.

• 委托访问：当 Alice 要求代理检查她的账户时，代理应使用 Alice 的权限进行操作，而不是通过一个能够查看所有客户数据的宽泛服务账户。共享服务账户会破坏归属追踪。当监管机构询问“谁访问了这位客户的数据？”时，回答“服务账户”几乎没有提供任何有用信息。借助委托访问，答案是“Alice 的代理代表 Alice 行事，并使用 Alice 的权限。”
  Delegated Access: When Alice asks the agent to check her account, the agent should act with Alice's permissions, not through a broad service account that can see every customer's data. Shared service accounts destroy attribution. When a regulator asks “who accessed this customer's data?”, “the service account” tells you almost nothing. With delegated access, the answer is “Alice's agent, acting on Alice's behalf, with Alice's permissions.”
• 即时凭证：不要使用永不过期的持久性 API 密钥，而应针对每项具体任务签发短期令牌。代理需要检查制裁名单？为该特定客户签发一个限定为 OFAC API 读取权限的令牌，有效期五分钟。任务完成后，令牌即会过期。不再有长期有效的凭证闲置在那里，等待被入侵。
  Just-in-time Credentials: Instead of a persistent API key that never expires, issue a short-lived token for each specific task. The agent needs to check the sanctions list? Issue a token scoped to OFAC API read access for that specific customer, valid for five minutes. When the task completes, the token expires. No standing credentials sitting around waiting to be compromised.
• 最小权限：代理只能获得任务所需的最低访问权限。处理信用证无需访问人力资源系统或营销数据。
  Least Privilege: The agent gets the minimum access the task requires. Processing a letter of credit doesn't need reach into HR systems or marketing data.

总之，这三种模式共同解决了归因和范围界定方面的挑战，而这些挑战削弱了许多当前的智能代理部署。Together, these three patterns address the attribution and scope challenges that undermine many current agentic deployments.

它们还可以防范智能体系统中最尖锐的安全风险。Simon Willison 将其称为“致命三要素”：智能体一旦同时具备访问私有数据、接触不可信内容以及对外通信的能力，就会变得危险。将这三者结合起来，单个被投毒的文档或网页就能通过提示注入劫持智能体，并悄悄窃取其能够访问的任何内容。委派式访问、即时凭证和最小权限会缩小被劫持智能体的可访问范围，从而打破这一三要素。之后，我们还会针对同一问题采取第二道防线：完全将检索到的文本排除在授权路径之外，这样被投毒的文档从一开始就无法授予任何权限。They also defend against the sharpest security risk in agentic systems. Simon Willison calls it the lethal trifecta, an agent turns dangerous the moment it holds all three of access to private data, exposure to untrusted content, and a way to communicate externally. Put those together and a single poisoned document or web page can hijack the agent through prompt injection and quietly exfiltrate whatever it can reach. Delegated access, just-in-time credentials, and least privilege shrink how much a hijacked agent can reach, breaking the trifecta. Later we add a second cut at the same problem, keeping retrieved text out of the authorisation path entirely, so that a poisoned document cannot grant a permission in the first place.

从哪里开始Where to start

在这四个主题中，这是唯一一个放慢脚步才是正确直觉的主题。但要区分两件容易混为一谈的事情。自主权是分阶段赢得的，因此没人期望你一次性全部授予。可观测性则完全不应分阶段实施。无论自主权处于什么水平，都应从第一天起以完整强度接入，因为事后再将其改造到一个正在运行的系统上会非常痛苦。你在其上构建的功能可以有意保持保守；但底层的监测埋点不能如此。Of the four topics, this is the one where going slowly is the right instinct. But separate two things that are easy to conflate. Autonomy is earned in stages, so nobody expects you to grant it all at once. Observability is not staged at all. It goes in from day one, at full strength, whatever the autonomy level, because retrofitting it onto a running system is painful. What you build on top can stay deliberately conservative; the instrumentation underneath cannot.

• 从第一天起就进行埋点。这里所有事项中，这是最应该优先做的，因为部署后再添加可观测性要困难得多。每个智能体工作流都应输出包含各步骤 span 的 trace，其中包括推理过程和查阅的来源。这里的追踪模式已经十分成熟，因此应采用经过验证的工具（如 OpenTelemetry），而不是自行构建。
  Instrument from day one. Of everything here, this is the one to do first, adding observability after deployment is far harder. Every agent workflow should emit traces with spans for each step, including reasoning and sources consulted. The tracing pattern here is well established, so lean on a proven tool (like OpenTelemetry) rather than building your own.
• 从影子模式开始。风险最低，学习最多。智能体提出建议，由人类做决定。在合规需要审计追踪之前先建立它，并在授予自主权之前衡量准确性。
  Start in shadow mode. Lowest risk, highest learning. Agents recommend, humans decide. You build the audit trail before you need it for compliance and measure accuracy before granting autonomy.
• 实现委派访问。代理继承调用用户的权限，并使用具有较短过期窗口的即时凭据。不使用持久令牌。
  Implement delegated access. Agents inherit the invoking user's permissions and use just-in-time credentials with short expiry windows. No persistent tokens.
• 以可解释性为目标进行构建。无论监管机构是否曾提出要求，能够回答“为什么”的审计追踪，才能让你调试错误的决策、为正确的决策辩护，并充分信任系统，从而扩大其自主权限。现在就将其接入，因为事后再添加会困难得多。
  Build to be explainable. Whether or not a regulator ever asks, an audit trail that answers “why” is what lets you debug a bad decision, defend a good one, and trust the system enough to widen its autonomy. Wire it in now, it's far harder to add later.

语义层弥合了代理与人类分析师之间的机构知识鸿沟，建立在前述主题所提供的可信数据和可审计操作之上。Semantic layers bridge the institutional knowledge gap between agents and human analysts, building on trusted data and auditable actions provided by the earlier topics.

上下文层：教会智能体了解你的数据含义The Context Layer: Teaching Agents What Your Data Means

语义层为 AI 代理提供了必要的明确上下文，使其能够成为数据的主要使用者；而人类分析师则凭借多年的经验，将这些上下文隐含地掌握在脑海中。Semantic layers provide the explicit context AI agents need when they become the primary consumers of data, context that human analysts carry implicitly, based on years of experience.

你的代理不知道“收入”是什么意思Your agent doesn't know what “revenue” means

问一个智能体：“产品 X 第三季度的收入是多少？”人类分析师确切知道该做什么、查询哪张表、收入指的是毛收入还是净收入，以及第三季度对应你们财年日历中的哪个时间段。他们通过多年的机构知识、内部文档和 Slack 讨论，逐渐掌握了所有这些信息。Ask an agent, “What was Q3 revenue for Product X?” A human analyst knows precisely what to do, which table to query, whether revenue means gross or net, what Q3 maps to in your fiscal calendar. They absorbed all of it over years of institutional knowledge, tribal docs, and Slack threads.

代理对此一无所知。它不知道哪些连接将产品、订单和收入关联起来，也不知道你的财务日历从二月开始。缺少这些上下文时，它要么凭空编造答案，要么放弃回答。语义层填补了这一空白，提供业务领域上下文。The agent has none of it. It doesn't know which joins connect products to orders to revenue, or that your fiscal calendar starts in February. With that context missing, it either hallucinates an answer or gives up. The semantic layer fills that gap, supplying the business-domain context.

上下文层是什么What the context layer is

语义层是一组关于指标的声明式定义：收入如何计算、什么是活跃客户，以及这些数字代表什么。每个使用者都遵循相同的定义，因此都能得出一致且准确的结果。但能够采取行动的代理需要的不仅仅是数字的定义。它还需要知道各类事物是什么，以及可以对它们执行哪些操作。这是三组彼此独立的定义，而代理需要这三者。A semantic layer is a set of declarative definitions of your metrics, how revenue is calculated, what an active customer is, what the numbers mean. Every consumer goes through the same definitions, so they all derive consistent, accurate results. But an agent that acts needs more than definitions of numbers. It needs to know what the things are, and what it may do to them. Those are three separate bodies of definition, and an agent needs all three.

领域模型说明了什么是存在的：实体、实体之间的关系，以及业务的含义规则——例如，订单属于某位客户；活跃客户是指在过去九十天内购买过商品的客户。它为代理提供了理解请求并据此制定计划所需的词汇。它只被查阅，从不执行；任何访问数据的查询路径都不会经过它。The domain model says what exists. Entities, their relationships, and the meaning rules of the business: an order belongs to a customer, an active customer is one who purchased in the last ninety days. It gives the agent the vocabulary to interpret a request and plan against it. It is consulted, never executed; no query path to data runs through it.

语义模型说明数字是如何计算的。指标和维度各自对应一个带版本的公式，每次都编译成相同的 SQL，并针对分析型存储运行。这就是更准确名称下的语义层，其职责是将正确性放入编译器，而不是依赖模型的猜测。The semantic model says how the numbers are computed. Metrics and dimensions, one versioned formula each, compiled to the same SQL every time and run against the analytical store. This is the semantic layer under a more exact name, and the job is to put correctness in the compiler rather than in the model's guess.

能力模型规定了代理可以执行的操作。它是一组经过整理、针对实时系统的操作，其中有些是读取操作（检查付款状态、获取故障排除指南），有些是写入操作（发起退款）。每项操作都带有权限和负责人信息，而会实际执行的操作还会带有前置条件和可逆性类别。The capability model says what the agent may do. A curated set of operations against live systems, some that read (check payment status, retrieve a troubleshooting guide) and some that write (issue a refund). Each carries permissions and an owner, and the acting ones carry preconditions and a reversibility class as well.

名词、数字和动词。它们共同构成上下文层，将它们 объединять起来的并不是它们都与含义有关，因为能力模型显然并非如此。而是每一个都是一个声明保证的位置：保证在版本控制中声明一次，而不是由模型在每次请求时重新推导。定义才是这一层；接口（目前是 MCP）只是那扇门。Nouns, numbers, and verbs. Together they are the context layer, and what unites them is not that they are all about meaning, because the capability model plainly is not. It is that each one is a place where a guarantee is declared once, in version control, instead of being worked out afresh by the model on every request. The definitions are the layer; the interface, MCP today, is just the door.

使用 dbt 的读者可能会提出异议：它的语义模型已经声明了实体，为什么还要将领域模型单独抽离出来？因为在指标层内部声明的实体，其作用域仅限于指标，而能力模型必须使用与语义模型相同的词汇来编写，否则二者就会逐渐偏离。退款所作用的客户，与收入数值统计的客户是同一个。底层只能有一套词汇，否则就会变成两套。A reader who works with dbt will object that its semantic models already declare entities, so why separate the domain model out. Because entities declared inside the metrics layer are scoped to metrics, and the capability model has to be written in the same vocabulary as the semantic one or the two drift apart. A refund acts on the same customer the revenue figure counts. One vocabulary underneath, or you get two.

解读：人们用于描述语义层的术语Explainer: the words people use for semantic layers

这些术语都尚未形成定论，而且这些词常常让人困惑。经典的语义层（Business Objects，后来还有 LookML 和 Cube）将实体和关系与指标捆绑在一起，因此许多人至今仍用“语义层”来指代整个体系。我们之所以划分得更明确，是因为智能体让这些区别变得至关重要。对于其中的各个部分，我们也使用“模型”而不是“层”这一说法，因为每个部分都是一组定义，而不是基础设施中的一个层级；此外，工具本身也是这样称呼它们的：dbt 声明 semantic_models，而开放语义互操作倡议（Open Semantic Interchange initiative）制定的厂商中立规范（如今称为 Apache Ossie）就是语义模型规范。None of this vocabulary is settled, and the words trip people up. The classic semantic layer (Business Objects, then LookML and Cube) bundled entities and relationships in with the metrics, so plenty of people still use “semantic layer” for the whole thing. We draw sharper lines because agents make the distinctions matter. We also say “model” rather than “layer” for the parts, because each is a body of definitions rather than a tier of infrastructure, and because that is what the tools call them: dbt declares semantic_models, and the vendor-neutral specification that came out of the Open Semantic Interchange initiative, now Apache Ossie, is a semantic model specification.

领域模型还有其他称谓。将其实体和关系存储为图，就得到知识图谱。在领域驱动设计中，它被称为领域模型，而其中的限界上下文提醒我们，没有任何单一模型能够涵盖整个企业。追求一个规范模型通常只是海市蜃楼；每个领域都有自己的模型，并以 Data Mesh 所描述的联邦式方式进行治理。The domain model goes by other names. Store its entities and relationships as a graph and you have a knowledge graph. Domain-driven design calls it a domain model, and its Bounded Context is the reminder that no single model covers the whole enterprise. Chasing one canonical model is usually a mirage; each domain has its own, governed the federated way Data Mesh describes.

市场名称是本体，而它本身就是同一个产物。这一概念的谱系比当前这波热潮所暗示的更为悠久：它是对共享概念化的正式、明确的规范，其中 RDF、OWL 和 SHACL 构成了形式化机制。严格来说，本体负责描述，而不负责执行。两款已投入市场的产品将这一概念进一步延展。Palantir 的 Foundry Ontology 将其对象、属性和链接与代理可以对它们采取的操作配对；Databricks 的 Genie Ontology 则将公司的概念构成的一张实时图谱置于其受治理的指标定义之上。Palantir 的形态与我们的形态之间唯一真正的区别在于，它将操作也一并纳入其中。我们将操作分开处理，因为写入路径所承载的风险不同于读取路径，因而也适合按照自身的规则单独进行治理。The market name is ontology, and it is the same artefact. It has a longer pedigree than the current wave suggests: a formal, explicit specification of a shared conceptualization, with RDF, OWL, and SHACL as the formal machinery. Strictly, an ontology describes and does not act. Two shipping products stretch it further. Palantir's Foundry Ontology pairs its objects, properties, and links with the actions an agent may take on them, and Databricks' Genie Ontology puts a living graph of a company's concepts on top of its governed metric definitions. The one real difference between Palantir's shape and ours is that it bundles the actions in. We keep them separate, because the write path carries different risk from the read path and benefits from being governed on its own terms.

你通常不会从头开始编写这些内容。最强大的实现会基于现有资源进行引导，包括表结构、术语表以及人们实际查询的方式，并让人类在此基础上进行整理，而不是要求任何人手工编写全部内容。You mostly don't write any of this from scratch. The strongest implementations bootstrap from what you already have, table structures, glossaries, and how people actually query, and let humans curate on top, rather than asking anyone to write the whole thing by hand.

图 2：上下文层：一个描述实体与关系的领域模型、一个针对分析存储编译为 SQL 的指标语义模型，以及一个针对实时系统执行受保护读取和操作的能力模型，三者均带有溯源信号。领域模型没有指向外部的箭头，因为它是供查询参考而非执行的；另外两个模型均使用其词汇编写。仪表板和分析师能够访问语义模型；代理是首个需要使用全部三个模型的使用者，而这正是本文所讨论的转变。Figure 2: The context layer: a domain model of entities and relationships, a semantic model of metrics compiled to SQL against the analytical store, and a capability model of guarded reads and actions against live systems, with provenance signals across all three. The domain model has no arrow out because it is consulted rather than executed; the other two are written in its vocabulary. Dashboards and analysts reach the semantic model; agents are the first consumer to need all three, which is the shift this article is about.

这三个模型都是源代码管理中的代码。它们要经过代码审查，在 CI 中接受测试，并在进入生产环境之前逐步通过各个环境。当“收入”的定义或退款规则发生变化时，只需在一个地方进行修改，变更就会传播到所有地方。代理永远不会直接访问底层数据；它们会通过上下文层，而上下文层会约束并治理它们可以请求的内容以及可以执行的操作。All three models are code in source control. They go through code reviews, get tested in CI, and progress through environments before reaching production. When the definition of “revenue” or the rule on refunds changes, you change it in one place and it propagates everywhere. Agents never reach the underlying data directly; they go through the context layer, which constrains and governs both what they can ask for and what they can do.

指标即代码Metrics as code

在实践中，业务逻辑就存在于定义本身中：revenue = order_amount - discount_amount，而不是被埋藏在 BI 工具或临时 SQL 视图里。代理接收自然语言问题，语义模型会将其解析为正确且受约束的 SQL。代理不会猜测表名或连接路径，而是使用这些定义。In practice, the business logic lives right in the definition, revenue = order_amount - discount_amount, not buried in a BI tool or an ad hoc SQL view. The agent receives a natural language question, and the semantic model resolves it to correct, constrained SQL. The agent doesn't guess table names or join paths; it uses the definition.

这里的示例使用 dbt MetricFlow 语法（dbt 正在从 measures 迁移到以 metrics 为先的规范；此处展示的是广泛使用的形式，但无论采用哪种方式，这一概念都成立）。Cube.js、Snowflake 和 Databricks 都遵循类似的模式。相比工具本身，更重要的是将业务逻辑纳入版本控制代码的规范。The examples here use dbt MetricFlow syntax (dbt is mid-migration from measures to a metrics-first spec; the widely-used form is shown here, and the concept holds either way). Cube.js, Snowflake, and Databricks all follow similar patterns. The tool matters less than the discipline of getting business logic into version controlled 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 却截然不同Same question, very different SQL

让我们来看一个例子。向一个没有语义模型的代理询问“产品 X 的第三季度收入是多少？”，它会猜测表名，使用错误的列，没有财务日历映射，并且遗漏连接。Let's consider an example. Ask “What was Q3 revenue for Product X?” of an agent without a semantic model, and it guesses at table names, uses the wrong column, has no fiscal-calendar mapping, and misses the join.

-- Before metric definition
SELECT SUM(amount)
  FROM sales_data
 WHERE product = 'Product X'
   AND quarter = 'Q3'

使用语义模型提出同样的问题，并将代理限制在正确的表、YAML 定义中的净收入公式、正确的财务日历日期以及有效的连接路径上。Ask the same question with a semantic model, and the agent is constrained to the correct table, the net-revenue formula from the YAML definition, the right fiscal-calendar dates, and the valid join path.

-- 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'

语义模型不会让代理变得更聪明，而是阻止它猜测。对于一个未经核查就根据答案采取行动的代理来说，这才是关键。The semantic model doesn't make the agent smarter. It stops it from guessing. For an agent that acts on the answer unchecked, that's what matters.

代理如何使用它How agents use it

单独来看语义模型，即一个定量问题所经历的路径。端到端来看，流程如下。代理发送一个自然语言问题（步骤 1）。语义模型通过 MCP 查找指标定义、有效维度、连接路径和访问规则（步骤 2），然后生成受约束的 SQL（步骤 3），这两个步骤都在同一组件内完成。数据仓库执行查询（步骤 4）。结果连同完整的血缘元数据返回给代理（步骤 5）。Take the semantic model on its own, the path a quantitative question travels. End to end, the flow looks like this. The agent sends a natural-language question (step 1). The semantic model looks up metric definitions, valid dimensions, join paths, and access rules, via MCP (step 2), then generates constrained SQL (step 3), both inside the same component. The data warehouse executes the query (step 4). The result flows back to the agent with full lineage metadata (step 5).

图 3：三条路径之一：通过语义模型回答定量问题。关于事物是什么的问题会进入领域模型，而针对实时系统的读取或操作则通过能力模型进行。Figure 3: One of the three paths: a quantitative question answered through the semantic model. Questions about what things are go to the domain model, and reads or actions against live systems go through the capability model.

语义模型限制了代理可以请求的内容。例如，dbt 会动态呈现适用于所选指标的维度，从而防止代理生成听起来合理但不正确的查询。而第 5 步中的血缘元数据则是我们前面讨论的可追溯性的基础。上下文与可追溯性相互强化。The semantic model constrains what the agent can ask for. dbt's, for instance, dynamically surfaces only the dimensions applicable to the selected metrics, which prevents the agent from generating plausible sounding but incorrect queries. And that lineage metadata in step 5 is the foundation for the traceability we covered earlier. Context and traceability reinforce one another.

从哪里开始Where to start

面对上下文层，一个常见的诱惑是在交付任何东西之前先把整个业务建模出来。请抵制这种诱惑。先从语义模型入手，因为价值集中在少数几个指标上，尤其是那些存在争议、对不同团队有不同含义的指标。让你的第一个智能体用例来界定范围，并据此扩展领域模型和它实际需要的能力，而不是扩展那些你能想象出来的能力。一个狭窄但正确的上下文层，胜过一个庞大却仅达成部分共识的上下文层。The temptation with a context layer is to model the whole business before you ship anything. Resist it. Start with the semantic model, because the value is concentrated in a handful of metrics, the contested ones that mean different things to different teams. Let your first agent use case set the scope, and grow the domain model and the capabilities it actually needs rather than the ones you can imagine. A narrow, correct context layer beats a sprawling, half-agreed one.

• 1. 找出相互冲突的指标定义。大多数组织对最重要的指标都有多个定义，收入就是典型例子，存在毛收入与净收入、计入退货与不计入退货等不同口径。这些冲突是智能体面临的最大风险，也是你最快可以取得成效的地方。
  1. Find your conflicting metric definitions. Most organizations have several definitions for their most important metrics, revenue being the classic, with its gross vs net, with or without returns variations. Those conflicts are your biggest agent risk and your quickest win.
• 2. 选择一个工具，但要专注于规范。任何主流的语义层工具都可以；关键在于其背后的规范：将指标定义纳入版本控制，每个指标只有一个统一认可的定义，并让代理通过该层进行查询，而不是直接查询原始架构。
  2. Pick a tool, but focus on the discipline. Any mainstream semantic layer tool will do; what matters is the discipline behind it, metric definitions in version control, one agreed definition per metric, and agents querying through the layer, not the raw schema.
• 3. 通过上下文层路由代理，绝不要直接使用原始架构。代理应看到受治理的指标和维度，而不是原始表和连接关系。如今，MCP 是公开这一层的通用方式，dbt、Cube 和 AtScale 都提供 MCP 服务器；但无论你采用何种连接方式，这一原则都成立——关键在于抽象层，而不是协议。
  3. Route agents through the context layer, never the raw schema. The agent should see governed metrics and dimensions, not raw tables and joins. MCP is the common way to expose the layer today, and dbt, Cube, and AtScale all ship MCP servers, but the principle holds however you connect, the point is the abstraction, not the protocol.
• 4. 进行对抗性测试。发现漏洞的最佳方式是进行对抗性测试；每次幻觉都指向一个缺失的定义。修正定义，而不是提示词。不要一开始就试图面面俱到，先从你的第一个智能体用例所需的指标入手。
  4. Test adversarially. The best way to find gaps is adversarial testing, every hallucination points to a missing definition. Fix the definition, not the prompt. And don't boil the ocean, start with the metrics your first agent use case needs.

遍历领域模型：知识图谱Traversing the domain model: knowledge graphs

语义模型非常适合处理结构化指标查询，例如“各地区的收入是多少”。但有些智能体任务需要在实体、事件和时间之间进行更丰富的关系推理。设想这样一位客户：他购买了产品 X，随后因价格变更而流失。像这样固定跳数的查询只是普通的连接操作。扁平表难以应对的是深度在编写查询时尚且未知的遍历：沿着关系链不断追踪，直到找到所要查找的内容。这正是领域模型的用武之地——实体，以及它们之间如何连接。The semantic model shines for structured metric queries such as “what was revenue by region.” But some agent tasks demand richer relationship reasoning across entities, events, and time. Consider a customer who bought Product X, then churned after a pricing change. A fixed number of hops like that is an ordinary join. What flat tables handle badly is traversal whose depth you don't know when you write the query, following a chain of relationships until you find what you are looking for. That is the domain model's territory, the entities and how they connect.

存储和遍历这类映射的常见方式是知识图谱，它是领域模型的一种存储选择，而不是需要额外构建的第四种东西。Microsoft 的 GraphRAG 使用社区检测来处理传统 RAG 无法处理的抽象查询，而 Graphiti 则构建具备时间感知能力的知识图谱，以应对不断演变的事实。（截至 2026 年，两者在 Thoughtworks Radar 上均处于 Trial 阶段。）语义模型仍然定义指标；图谱则承载客户、产品、事件和决策之间随时间变化的联系。二者结合起来，为智能体提供了近似组织记忆的能力——这类知识通常需要新员工数月才能掌握。The common way to store and traverse that map is a knowledge graph, which is a storage choice for the domain model rather than a fourth thing to build. GraphRAG from Microsoft uses community detection to handle abstract queries that traditional RAG can't, and Graphiti builds temporally aware knowledge graphs for evolving facts. (Both sat at Trial on the Thoughtworks Radar as of 2026.) The semantic model still defines the metrics; the graph carries the connections between customers, products, events, and decisions over time. Together they give agents something close to institutional memory, the kind of knowledge that would take a new hire months to absorb.

现在，智能体拥有可信的数据、治理机制和上下文。但它们真的能够采取行动吗？Now agents have trusted data, governance, and context. But can they actually act?

从可搜索到可执行：面向智能体的数据访问From Searchable to Actionable: Agent-Ready Data Access

一旦代理理解了你的数据，并且治理机制到位，问题就转向访问：代理如何获取数据并对其采取行动？答案不只是“RAG”，而是一整套能力范围，从检索、实时查询，到受控的回写操作。整个范围就是能力模型——三者中的第三个，而回写端正是其防护机制发挥作用的地方。Once agents understand your data and governance is in place, the question shifts to access. How do agents reach the data and act on it? The answer is more than “RAG”. It's a full spectrum, from retrieval, to real-time queries, to controlled write-back actions. That whole spectrum is the capability model, the third of the three, and the write-back end is where its guardrails earn their keep.

你的代理可以读取，但无法执行操作Your agent can read, but it can't act

我们来看一个例子。一名员工报告了一个 PO（采购订单）问题。理想的代理应完成三件事：检索相关的故障排除指南，检查 PO 付款服务当前是否宕机，并在需要时创建一个帮助台工单。Let's take an example. An employee reports a PO (purchase order) issue. An ideal agent would do three things, retrieve the relevant troubleshooting guide, check whether the PO payment service is down right now, and create a help desk ticket if needed.

传统 RAG 是大多数组织已经部署的模式，但它只能完成第一步：搜索文档并检索内容。它无法查询实时监控系统来检查服务状态，更无法在 ServiceNow 或 Jira 中创建工单。可搜索与可执行之间的差距，正是本节最后一个主题，我们将使用 PO 场景对此进行详细说明。Traditional RAG, the pattern most organizations have deployed, only does step one. It searches documents and retrieves content. It can't query a live monitoring system to check service status, and it certainly can't create a ticket in ServiceNow or Jira. That gap between searchable and actionable is the subject of this final topic, and we will use the PO scenario to elaborate.

数据访问频谱The data access spectrum

这种表述源自微软的 AI 云采用框架，该框架将其正式定义为 RAG + MCP-Read + MCP-Write。This framing comes from Microsoft's Cloud Adoption Framework for AI, which formalizes it as RAG + MCP-Read + MCP-Write.

1. 检索。RAG、向量搜索、文档查找。代理会找到相关内容。如今大多数组织都处于这一阶段。
   Retrieval. RAG, vector search, document lookup. The agent finds relevant content. Most organizations live here today.
2. 实时查询。代理查询实时系统、检查服务状态，并实时从数据库读取数据。
   Real-Time Query. The agent queries live systems, checks service status, reads from databases in real time.
3. 回写。功能最强大、也最危险的层级。代理会创建工单、更新记录并触发工作流。
   Write-Back. The most powerful and most dangerous tier. The agent creates tickets, updates records, triggers workflows.

沿着这一光谱逐步提升，每一步都会增加能力，也会增加风险。PO 场景可以清晰地对应到这三个层级。Each step up the spectrum adds capability, and risk. The PO scenario maps cleanly across all three.

• 检索指南（检索）
  Retrieve the guide (Retrieval)
• 检查支付状态（实时查询）
  Check payment status (Real-Time Query)
• 创建工单（回写）
  Create the ticket (Write-Back)

向智能体式 AI 的转变需要这三者全部具备，而不仅仅是大多数团队已经构建的检索能力。The shift to agentic AI requires all three, not just the retrieval most teams have built.

MCP 很快成为连接这些层级的默认方式，其崛起速度令人瞩目。但机制本身不如边界划分重要。关键在于将检索、实时读取和回写维持为彼此独立且经过审慎治理的访问层级，无论是通过 MCP 还是你们自己的原生 API 来提供这些能力。MCP has quickly become the default way to wire these tiers up, and its rise has been remarkably fast. But the mechanism matters less than the demarcation. What counts is keeping retrieval, real-time reads, and write-back as separate, deliberately governed levels of access, whether you expose them through MCP or your own native APIs.

三个原语，一种协议Three primitives, one protocol

代理通过 MCP（模型上下文协议）实现所有这些功能。其原语处于一条风险梯度上：Resources（只读）是安全的，Prompts 塑造行为，而 Tools 会改变状态。这条梯度与各层级直接对应：Resources 用于检索，Tools 用于写回，因此安全的路径是先开放 Resources，再仅在治理机制下逐步启用 Tools。在 PO 场景中，Resources 提供故障排除文档，Prompt 引导分诊，而 Tools 执行 check_service_status() 和 create_support_ticket()。Agents reach all of this through MCP, the Model Context Protocol. Its primitives sit on a risk gradient, Resources (read-only) are safe, Prompts shape behavior, and Tools change state. That gradient maps straight onto the tiers, Resources to retrieval and Tools to write-back, which is why the safe path is to expose Resources first and graduate to Tools only under governance. In the PO scenario, Resources serve the troubleshooting docs, a Prompt guides triage, and Tools run check_service_status() and create_support_ticket().

反模式：天真地将 API 转换为 MCPAntipattern: naive API-to-MCP conversion

工具的设计方式与何时使用它们同样重要。一个常见且代价高昂的错误，是将现有的 REST API 一对一地封装起来，让每个端点都变成一个工具。结果就是工具泛滥：50 个工具，名称类似于 get_po_payment_status、create_ticket_po_payment、create_ticket_po_payment_network。这样一来，代理就必须在这 50 个几乎难以区分、上下文信息又很少的工具中做出选择，而 LLM 并不擅长这一点；随着工具数量增加，准确率会急剧下降。Thoughtworks 技术雷达正是出于这个原因，将“天真地将 API 转换为 MCP”列为 HOLD。How you design those Tools matters as much as when you reach for them. The common, costly mistake is to take existing REST APIs and wrap them one-to-one, so every endpoint becomes a tool. The result is tool sprawl, 50 tools with names like get_po_payment_status, create_ticket_po_payment, create_ticket_po_payment_network. The agent then has to choose among 50 barely-distinguished tools with little context, and LLMs are bad at that; accuracy drops sharply as the tool count climbs. The Thoughtworks Tech Radar put “naive API-to-MCP conversion” on HOLD for exactly this reason.

更好的方法是将相同的功能封装为少量设计良好、描述丰富且输入参数化的能力。check_service_status 接受服务名称和位置作为参数，一个工具即可适用于所有服务和所有位置。create_support_ticket 则使用类别、优先级和描述作为参数。其描述足够详细，LLM 能够据此判断何时使用每项能力。The better approach exposes the same functionality as a handful of well-designed capabilities with rich descriptions and parameterized inputs. check_service_status takes a service name and location, one tool for all services and all locations. create_support_ticket is parameterized with category, priority, and description. The descriptions are detailed enough for the LLM to know when to reach for each one.

原则是设计能力，而不是端点。五到十个描述完善的业务能力，几乎总能胜过五十个单薄的 API 封装。而且这一原则与协议无关：无论代理是通过 MCP、另一个代理，还是通过未来出现的任何标准访问你的数据，使其适合代理使用的特性都是相同的：丰富的描述、参数化访问和清晰的架构。The principle is to design capabilities, not endpoints. Five to ten well described business capabilities will outperform 50 thin API wrappers almost every time. And this principle is protocol-agnostic, whether an agent reaches your data through MCP, through another agent, or through whatever standard comes next, the properties that make it agent-ready are the same, rich descriptions, parameterized access, clear schemas.

能力所声明的内容What a capability declares

丰富的描述会告诉代理何时应当调用某项能力。但它并未说明代理是否获准这样做，也未说明出错时会发生什么。这些内容属于声明的其余部分。每项能力都包含权限信息：谁可以调用它，以及以谁的身份行事；还包含一个所有者，即在它出现异常时负有责任的人。具有执行作用的能力还会额外包含两项内容。A rich description tells the agent when to reach for a capability. It says nothing about whether the agent is allowed to, or what happens if it is wrong. That is the rest of the declaration. Every capability carries permissions, who may invoke it and acting as whom, and an owner, the person accountable when it misbehaves. The ones that act carry two more.

前置条件是指在操作可以继续之前必须成立的条件，应在执行操作的那一刻针对实时状态进行检查，而不是针对代理在其计划中较早读取的内容进行检查。退款需要存在一笔尚未退款的原始付款，且金额不得超过调用用户获授权的额度。Preconditions are the conditions that must hold before the action may proceed, checked against live state at the moment of acting rather than against whatever the agent read earlier in its plan. A refund needs an original payment, not yet refunded, within the amount the invoking user may authorise.

可逆性是指某项操作可能造成的损害类别：能够干净利落地撤销、可以通过某种补偿性交易付出代价后撤销，或是不可逆的。与涉及的金额相比，这是预测自动化是否安全的更有用指标。一笔可以撤回的 50,000 美元内部账簿更正，比一笔无法追回的 200 美元外部账户付款更适合自动化。前文分阶段的自主性阶梯将防护措施与交易金额挂钩；相比之下，应优先将其与可逆性挂钩，并规定无论代理已达到哪个阶段，不可逆操作都必须经过人工批准。Reversibility is the class of damage the action can do: cleanly reversible, reversible at a cost through some compensating transaction, or irreversible. This is the more useful predictor of safe autonomy than the money involved. A $50,000 internal ledger correction you can back out is a safer thing to automate than a $200 payment to an external account you cannot claw back. Where the staged autonomy ladder earlier keys its guardrails to transaction size, prefer keying them to reversibility, and let irreversible actions require human approval whatever stage the agent has reached.

这就引出了一个问题：这些前置条件中的规则究竟从何而来？因为其中大多数规则都以散文形式写在某个地方，比如退款政策、合同或合规手册中。Which raises the question of where the rules in those preconditions come from, because most of them are written down in prose somewhere, in a refund policy, a contract, a compliance manual.

检索到的文本用于提供信息，而不是进行门控。Retrieved text informs, it never gates

业务文档仍然是业务记录其规则的地方。但限制某项操作的规则不应在执行操作的当下才被读取和解释。应提前从这些文档中提取规则，由人工进行整理，并将其作为已声明的前置条件存储在能力模型中，同时为每条规则保留指向其来源段落的链接。Business documents remain where the business writes its rules down. But a rule that gates an action must not be read and interpreted at the moment of acting. Rules are extracted from those documents ahead of time, curated by a human, and stored as declared preconditions in the capability model, each with a link back to the passage it came from.

在执行操作时，智能体仍可能读取非结构化内容（例如投诉工单或合同条款），以确定应提出什么建议。只有已声明的规则决定哪些操作是被允许的，并且这些规则会针对实时状态进行确定性检查。边界在于提供信息与实施门控之间的区别。检索到的文本可以影响智能体的建议，并作为人类审批者的证据，但它本身绝不具备授权执行操作的权力。At action time the agent may still read unstructured content, a complaint ticket, a contract clause, to work out what to propose. Only the declared rules decide what is permitted, and they are checked deterministically against live state. The boundary is between informing and gating. Retrieved text can shape what the agent suggests and serve as evidence for a human approver, but it never carries the authority to authorise the action itself.

这一边界同样是一项安全属性。将检索到的文本从授权路径中移除，意味着被投毒的文档无法赋予代理它原本不具备的权限；这比单纯缩小被劫持代理能够触及的范围，是更强的论断。但这并非完整的防御，因为注入的文本仍可能影响代理提出的内容，而看到伪造证据的人类审批者也可能直接放行。它所移除的是这样一条路径：文档直接为该操作授权，中间没有任何人或环节进行干预。That boundary is also a security property. Removing retrieved text from the authorisation path means a poisoned document cannot grant an agent a permission it did not already have, which is a stronger claim than merely shrinking what a hijacked agent can reach. It is not a complete defence, because injected text can still influence what the agent proposes, and a human approver shown fabricated evidence may wave it through. What it removes is the path where the document authorises the action directly, with nobody in between.

溯源链接让声明在文档发生变动时仍然保持可信。这里要谨慎承诺。检测文档是否发生变化很容易；但要判断这种变化是否使从文档中推导出的前置条件失效，则是一种判断，而不是简单的差异比对。这个链接所带来的价值，是形成一个审查队列：当源文档发生变化时，标记出需要人工重新检查的派生规则。这与将新鲜度 SLA 的计时起点设为索引上次重建的时间，而不是内容上次看似发生变化的时间，遵循的是同一种思路。The provenance link is what keeps the declarations honest as the documents move underneath them. Be careful what you promise here. Detecting that a document changed is easy; knowing that the change invalidated a precondition derived from it is a judgement, not a diff. What the link buys you is a review queue, the derived rules flagged for a human to re-check when their source moves, in the same spirit as keying a freshness SLA to when the index was last rebuilt rather than to when the content last appeared to change.

如果没有任何声明涵盖当前情况，代理不会根据自己对政策的理解擅自处理，而是升级上报。这是前文在另一种场景中提到的硬性门槛，也是同一种本能：任何合同或 SLA 违约都必须转交人工处理，而不是仅仅降低评分。对于未声明的情况，代理会降级为受监督模式，而不是转为自主运行。Where no declaration covers the situation, the agent does not improvise from its own reading of policy. It escalates. This is the hard gate from earlier in a different setting, the same instinct that says any contract or SLA breach forces a human rather than a lower score. An undeclared case degrades the agent to supervised, not to autonomous.

提取与整理和其他流程一样，也需要负责人、固定节奏，以及负责清理审核队列的人。这是后文某一节的主题，因为这些工作都不会自行维持。Extraction and curation is a pipeline like any other, and it needs an owner, a cadence, and somebody who clears the review queue. Which is the subject of a later section, because none of this maintains itself.

端到端：PO 付款场景End to end: the PO payment scenario

三层架构全部就绪后，我们在本节开头提出的 PO 问题便可端到端地运行：代理在单一工作流中检索故障排除指南（只读 Resource）、检查实时支付状态（读取数据的 Tool），并提交工单（写入数据的 Tool）。With all three tiers in place, the PO issue we opened the section with runs end to end, the agent retrieves the troubleshooting guide (a read-only Resource), checks the live payment status (a Tool that reads), and files a ticket (a Tool that writes), all in a single workflow.

图 4：一个代理，三个层级：检索、实时查询，然后回写，整合为单个响应。Figure 4: One agent, three tiers: retrieval, real-time query, then write-back, combined into a single response.

如果手动完成，员工需要排队等候、说明问题、让支持代理检查监控仪表板，然后创建工单。现在，代理可以一次性完成所有这些操作。Done manually, the employee would wait in a queue, explain the issue, have a support agent check the monitoring dashboard, and get a ticket created. The agent is now able to do all this in one pass.

从哪里开始Where to start

安全的进入方式是逐级攀升，而不是一步跳到回写。大多数团队已经处于检索阶段，也就是风险最低的只读层。真正的危险在于回写。因此，要逐步赢得进入更高层级的资格。梳理每个用例的需求，先开放只读访问，最后再添加回写功能，而且只有在你能够记录每一项操作之后才这样做。不要因为一个能够采取行动的智能体令人兴奋，就急于跳过那些确保行动安全的步骤。The safe way in is to climb the tiers, not leap to write-back. Most teams already live in retrieval, the read-only tier where risk is lowest. Write-back is where the real danger sits. So earn your way up. Map what each use case needs, expose read-only access first, and add write-back last, only once you can log every action. Don't let the thrill of an agent that can act rush you past the steps that make acting safe.

• 1. 梳理你的数据访问层级。选取三个最重要的智能体使用场景，并将每个场景所需的能力归类为检索、实时查询或回写。大多数缺口都存在于实时查询和回写方面。
  1. Map your data access tiers. Take your top three agent use cases and classify what each needs, retrieval, real-time query, or write-back. Most gaps live in real-time query and write-back.
• 2. 设计能力，而不是端点。将现有 API 归类为 5–10 个描述清晰的业务能力。丰富的描述很重要，LLM 会据此决定调用哪个工具。
  2. Design capabilities, not endpoints. Group existing APIs into 5–10 well-described business capabilities. Rich descriptions matter, they're what the LLM uses to decide which tool to call.
• 3. 从 MCP Resources 开始。只读访问是风险最低的切入点。将知识库、配置数据和文档作为 Resources 暴露出来。只有在治理机制到位后，才逐步采用 Tools。
  3. Start with MCP Resources. Read-only access is the lowest risk entry point. Expose knowledge bases, config data, and documentation as Resources. Graduate to Tools only once governance is in place.
• 4. 从第一天起就进行监控记录。在部署任何具有写入权限的代理之前，记录每次工具调用、触发者、调用的内容、调用时间，以及最关键的：代表谁执行。这些记录将构成“可追溯性与治理”部分中的审计轨迹。
  4. Instrument from day one. Before deploying any agent with write access, log every tool invocation, who triggered it, what was called, when, and critically, on whose behalf. This feeds the audit trail from the Traceability and Governance section.

面向 AI 的数据栈The AI-ready data stack

我们现在已经逐一讲完了四个主题：让数据值得信赖的契约、让数据变得有意义且可执行的上下文层、使代理能够对数据采取行动的访问模式，以及让这些行动可审计的可观测性。单独来看，它们似乎是四条可以分别配备人员的工作流。但实际上并非如此。它们相互依赖，而且构建顺序十分重要。We've now walked through all four topics, contracts that make data trusted, a context layer that makes it meaningful and actionable, access patterns that let agents act on it, and observability that makes those actions auditable. Treated separately, they look like four work streams you could staff independently. But they aren't independent. They build on one another, and the order in which they're built matters.

图 5：AI 就绪型数据栈：自下而上构建的三个相互依赖层，并从第一天起贯穿所有层的可观测性。Figure 5: The AI-ready data stack: three dependent layers built bottom-up, with observability cutting across all of them from day one.

这些依赖关系是自下而上运行的。你无法为不可信的数据赋予意义，因此上下文位于基础层。没有这种意义来约束智能体，你就无法安全地让它们采取行动，因此访问权限位于上下文之上。跳过其中任何一层，上面的所有内容都会崩溃。这正是许多智能体 AI 项目陷入停滞的原因。他们直接跳到智能体访问权限，却没有先构建底层基础。 可观测性则不同。它不是堆叠在顶层的第四层，而是与这三层并行运行。从处理实际工作开始，每一层都必须具备可追踪性和可审计性。信任检查、语义查询、智能体的行动——所有这些都必须在生产环境中可解释，而不是等到你有空为其添加监控时才去处理。相比于从一开始就内置可观测性，将其事后改造到一个正在运行的系统上也要困难得多。无论如何，都应从第一天起就将其接入系统。The dependencies run bottom-up. You can't attach meaning to data you can't trust, so context sits on the foundation. You can't safely let agents act without that meaning to constrain them, so access sits on context. Skip either of those and everything above it collapses. That's exactly why so many agentic AI programs stall. They jump straight to agent access without building the foundation underneath. Observability is different. Rather than a fourth tier stacked on top, it runs alongside all three. Every layer has to be traceable and auditable from the moment it handles real work. The trust checks, the semantic queries, the agent's actions, all of it has to be explainable in production, not whenever you get around to instrumenting it. It is also much harder to retrofit onto a running system than to build in from the start. Either way, you wire it in from day one.

这一切归谁所有？Who owns all this?

这套技术栈还有一个图表无法绘制的依赖。它的每一层都会产出一个必须保持准确的产物：数据契约、指标定义、访问范围或可观测性追踪。产物不会自行维护。没有负责人的契约会逐渐偏离它所描述的源头。没有负责人的“收入”定义，会重新分裂成你刚刚整合的三个相互冲突的版本。没有负责人的访问范围会悄然扩大，直到再次变成一个长期存在的服务账户。技术是必要条件，但真正让它保持诚实可靠的是运营模式。The stack has one more dependency the diagram can't draw. Every layer in it produces an artifact that has to be kept true, a data contract, a metric definition, an access scope, an observability trace. Artifacts don't maintain themselves. A contract with no owner drifts out of sync with the source it describes. A definition of “revenue” with no owner forks back into the three conflicting versions you just consolidated. An access scope with no owner quietly widens until it's a standing service account again. The technology is necessary, but it's the operating model that keeps it honest.

让这项工作得以开展的纪律，是把数据视为一种产品。每个数据集、契约和指标都有明确的负责人、已发布的契约和 SLA，以及版本化的生命周期，就像 API 一样。你不可能始终知道每个消费者是谁；对于公开或广泛共享的数据，这更是不可能，而这正是契约重要的原因：它是未知消费者赖以构建的稳定承诺，而弃用策略则让你能够在不破坏它们的情况下进行变更。当 product_pricing 契约在凌晨两点阻止部署时，有人对此负责。当财务和销售对“收入”的定义产生分歧时，有人负责作出决策。当新的代理请求访问权限时，有人负责确定权限范围并进行审核。这些都不是基础设施问题，而是所有权问题，没有任何工具会替你回答这些问题。The discipline that makes this work is treating data as a product. Each dataset, contract, and metric has a named owner, a published contract and SLA, and a versioned lifecycle, the same way an API does. You won't always know every consumer, and for public or broadly shared data you can't, which is precisely why the contract matters, it's the stable promise unknown consumers build on, and a deprecation policy is how you change it without breaking them. When the product_pricing contract blocks a deployment at 2 a.m., someone is accountable for it. When finance and sales disagree on “revenue,” someone owns the decision. When a new agent asks for access, someone owns the scope and reviews it. These aren't infrastructure questions; they're ownership questions, and no tool answers them for you.

一个无人负责、不断漂移的数据集，其人工使用者会察觉问题并加以规避。代理则以机器的速度和规模使用它，并同样快速地传播错误。你的数据使用者越快、越自主，就越无法承受没有负责人的数据。A human consumer of an unowned, drifting dataset notices and works around it. An agent consumes it at machine speed and scale, and propagates the error just as fast. The faster and more autonomous your consumers, the less you can afford data without an owner.

你持什么立场？Where do you stand?

在决定构建什么之前，先明确自己的定位会有所帮助。根据以下信号对每项属性进行评分；这些信号均取自上述主题。Before deciding what to build, it helps to locate yourself. Score each attribute against the signals below, all drawn from the topics above.

不要对各行取平均值，因为该技术栈是按依赖关系排序的；你的就绪程度受最薄弱的基础层限制，一个完美的上下文层建立在不受信任的数据之上，仍然不具备智能体就绪条件。找到最薄弱的一行，下一笔投入就应该放在那里。Don't average the rows, because the stack is dependency ordered, your readiness is capped by your weakest foundational layer, a flawless context layer sitting on untrusted data is still not agent ready. Find your weakest row, and that's where the next investment goes.

四件需要开始着手的事情Four things to start on

每个主题都有各自的切入点。把这些切入点当作实际工作中的战术检查清单。以下四项就是起点。第一项是从第一天起就进行埋点，它不是构建顺序中的一步，而是与其他所有工作并行进行，这也是它排在第一位且永不停歇的原因。其余三项则从技术栈底层向上构建，因为整体的准备程度取决于最薄弱的基础层。其中，单项杠杆效应最高的是上下文层，因为上下文对准确性的提升超过更大的模型所能带来的提升；但只有当其底层数据值得信赖时，它才能真正发挥作用。逐步构建到这一层。Each topic came with its own starting points. Treat those as tactical checklists for the work itself. The four below are where to start. The first, instrumenting from day one, isn't a build-order step. It runs alongside everything else, which is why it comes first and never stops. The other three build from the bottom of the stack up, because you're only as ready as your weakest foundational layer. The highest-leverage single move among them is the context layer, since context moves accuracy further than a bigger model does, but it only pays off once the data beneath it can be trusted. Build up to it.

1. 从第一天起就进行埋点。这与其说是流程中的一个步骤，不如说是贯穿所有步骤的一项常量。从一开始就在每个工作流中加入 traces 和 spans，因为事后补充可观测性要比一开始就构建困难得多；同时，你也会需要能够回答“为什么”的审计轨迹，以便今天进行调试，明天应对监管机构。
   Instrument from day one. This isn't a step in the sequence so much as a constant that runs under all of them. Put traces and spans in every workflow from the start, because observability is far harder to retrofit than to build in, and you'll want audit trails that answer “why” for debugging today and regulators tomorrow.
2. 为一切建立契约。新鲜度 SLA、严格的架构强制执行、对坏数据进行隔离。这是其他一切赖以建立的基础；代理无法嗅出坏数据，因此数据架构必须替他们嗅出问题。
   Contract everything. Freshness SLAs, strict schema enforcement, quarantine for bad data. This is the floor the rest stands on, agents can't smell bad data, so the data architecture has to smell it for them.
3. 上下文优先于模型。一旦数据值得信赖，构建在其之上的上下文层就是回报最高的投入。仅其语义模型本身就足以说明这一点：在 AtScale 的文本转 SQL 基准测试中，使用同一模型时，准确率从原始架构下的不到 20% 提升到了借助语义层后的 92.5% 以上。
   Context over models. Once the data can be trusted, a context layer is the highest-return thing you can build on top of it. Its semantic model alone carries the point: in AtScale's text-to-SQL benchmark, accuracy jumped from under 20% on the raw schema to over 92.5% with a semantic layer, on the same model.
4. 先读后写。先从 MCP Resources（只读）开始，只有在治理机制到位后，才逐步使用 Tools（写入）。分阶段逐步获得自主权：先是影子模式，然后是监督模式，最后是在防护措施下实现自主运行。
   Read before write. Start with MCP Resources (read-only) and graduate to Tools (write) only with governance in place. Earn autonomy in stages, shadow mode, then supervised, then autonomous with guardrails.

当智能体成为你们数据的主要消费者时，你们的数据架构就会成为你们的 AI 架构。When agents become the primary consumers of your data, your data architecture becomes your AI architecture.

我们将在即将出版的 O'Reilly 著作《面向软件架构师的数据架构》中，对所有这些内容，以及围绕它的更广泛的运营和分析数据架构决策，进行更深入的探讨。We go much deeper on all of this, and on the broader operational and analytical data architecture decisions around it, in our forthcoming O'Reilly book, Data Architecture for Software Architects.