北京
一个领域工程师应该能直接问助手：“存储欧盟 IBAN 的列适用哪个敏感级别？”然后从实时生效的 LakeFormation 策略里得到答案，而不是去翻某个人 2023 年最后编辑过的维基页面。
这句话写起来容易，真正做到却难得多。有意思的不是模型能回答这个问题，而是答案从哪里来，以及当模型不该回答时，是什么阻止了它。
从语义层到目录层
这是《Fabric + Mesh on AWS》的姊妹篇。作者在 7 月底写下那句话时，原文第三节只留了一个前向指针，没有落地页：“这个本体下一步应该得到的是一个通过 MCP 暴露的目录工具……这是自然的下一步，但参考实现里还没有。”
这篇文章就是那句话背后的设计。工具仍未构建，下文会标明哪些部分是协议、哪些是模式、哪些两者都还不是。
模型上下文协议（MCP）在写作期间已经走了很远。以下内容全部对照 2026-07-28 修订版核对，并且刻意标注修订日期：一篇关于协议的文章，标注自己的时效比假装永恒更有用。
为什么是目录，而不是仓库
当有人说“让智能体查询我们的数据”时，第一反应往往是对着数据湖做文本转 SQL。但第二部分第七节已经论证过为什么这是错误的接口：针对受治理数据湖的原始 SQL 对智能体消费者不安全，而在其之上的类型化语义 API 才能让问题在不产生幻觉的情况下被回答。
那只是其中一层——语义层，让 monthly_recurring_revenue 对每个消费者都意味着同一件事。这篇文章讲的是另一层，两者很容易混淆。语义层回答关于数字的问题：上个季度 30 天欺诈召回率是多少？目录回答关于数据本身的问题：存储欧盟 IBAN 的列适用哪个敏感级别？谁拥有 claims 域？这个角色可以读取它吗？
这些都无法从数据湖里查询到。它们是关于数据集的元数据，而不是数据集里的数据——LakeFormation 的 LF 标签、所有权记录、授权表达式、描述符——治理账户里四个 API 背后的四个存储，只能通过控制台或 Terraform 访问。
工具对抗的是猜测，不是脚本
一个意志坚定的工程师可以手工拼出答案，没有助手也并非不可能。但这是错误的反事实。没有人会在下午 4 点 40 分给表加列时写一个四 API 联查——他们会从旁边的列复制标签，或者在 Slack 里问，得到某人对 3 月某个决定的记忆。
这个工具对抗的是猜测，不是脚本。而且“存储欧盟 IBAN”在任何情况下都不是一个查找键：没有任何记录以这个短语归档，所以回答意味着把非正式描述与已经分类的列进行匹配——这是第七节的问题，不是 SQL 的问题。
目录问题不是权限更紧的查询。它是针对不同存储提出的不同问题。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
