Operating the Ontology Control Plane: A Practitioner’s Guide to the Last Mile运营本体控制平面：实践者指南之最后一公里
The tips and tricks presented here are built on the work developed and shared by Tianxia Jia and Steve Mitchener in a series of articles published here on Medium.这里提出的技巧建立在 Tianxia Jia 和 Steve Mitchener 开发并分享的工作之上，这些工作以一系列文章的形式发布在 Medium 上。
The AI Context ChallengeAI 上下文挑战
Agents and AI have been around long enough that we now recognize the last mile isn’t an agentic protocol or a better frontier model — it’s context. Meaningful context.智能体和 AI 已经存在了足够久，我们现在认识到最后一公里不是智能体协议，也不是更好的前沿模型——而是上下文。有意义的上下文。
I’ve spent the last year building AI agents on Snowflake — real ones, for real customers across gaming, media, betting, sports, adtech, and martech. I kept hitting the same wall. You can spin up a Cortex Agent in 5 minutes. You can point it at a semantic view and get text-to-SQL running by lunch.过去一年，我一直在 Snowflake 上构建 AI 智能体——真正的智能体，面向游戏、媒体、博彩、体育、广告技术和营销技术领域的真实客户。我一直遇到同样的障碍。你可以在 5 分钟内启动一个 Cortex Agent。你可以将它指向语义视图，并在午饭前让 Text-to-SQL 跑起来。
When users transition from simple deterministic questions like “How many titles had sales yesterday?” to more nuanced ones like “How many first-time subscribers do we have for a given publication?” — agents start to struggle. Verified queries only get you so far. The reason agents struggle is that the definition of what “active” means may not be as simple as a clean metric name like ACTIVE_USERS. It may require additional conditional elements that are context-specific based on that user’s perspective. A finance user may define it differently from a salesperson or an engineer.当用户从简单确定性问题（例如“昨天有多少标题产生了销售？”）转向更细微的问题（例如“对于特定出版物，我们有多少首次订阅者？”）时，智能体开始吃力。经过验证的查询也只能帮你到这里。智能体吃力的原因在于，“活跃”的定义可能并不像 ACTIVE_USERS 这样干净的指标名称那么简单。它可能需要额外的条件要素，这些要素会因用户视角不同而具有上下文特定性。财务用户可能与销售人员或工程师的定义不同。
Context matters, and converting it into structured data to guide an agent is critical. Think of it as fine-tuning a frontier model without the training run — you get domain-aware reasoning through metadata instead of model weights.上下文很重要，将其转换为结构化数据以指导智能体至关重要。可以把它想象成无需训练运行即可微调前沿模型——你可以通过元数据而非模型权重获得领域感知推理。
Standing on Shoulders站在巨人的肩膀上
At Snowflake we have great talented engineers and architects. Two of them — Tianxia Jia (1) and Steve Mitchener (2) — have developed a body of work I’ve used as a foundation. I encourage you to review their articles as they provide key elements of the architecture I started from.在 Snowflake，我们有优秀且才华横溢的工程师和架构师。其中两位——Tianxia Jia (1) 和 Steve Mitchener (2)——开发了一系列成果，我将其作为基础。我鼓励你阅读他们的文章，因为它们提供了我所采用架构的关键要素。
Here are the foundational design patterns:以下是基础设计模式：
- **Business and regulatory meaning exists today and can be formalized for agentic use in the form of a taxonomy and an ontology.****业务和监管含义如今已经存在，并且可以以分类体系和本体的形式形式化，以供智能体使用。**
- A **taxonomy** is a way to sort things into categories — a labeled filing cabinet or tree. It answers: “Where does this belong?”**分类体系**是一种将事物分类的方式——一个带标签的文件柜或树。它回答：“这属于哪里？”
- An **ontology** is a model of what things are and how they relate — meaning plus rules. It answers: “What is this thing, how is it connected to other things, and what can we infer from that?”**本体**是对事物是什么以及它们如何关联的模型——含义加规则。它回答：“这是什么事物，它如何与其他事物连接，以及我们可以从中推断出什么？”
A simple example:简单示例：
- **Taxonomy**: Sports → Baseball → Pitch Types → Fastball**分类体系**：运动 → 棒球 → 投球类型 → 快速球
- **Ontology**: A pitcher throws a pitch. A four-seam fastball is a type of pitch. A pitch has velocity and movement. A player belongs to a team. If someone throws pitches for a team, they have a player/team relationship.**本体**：投手投出一次投球。四缝线快速球是一种投球。投球具有球速和移动轨迹。球员属于一支球队。如果某人为一支球队投球，那么他就具有球员/球队关系。
- **A layered architecture evolved from the bottom up enables additive capabilities.** Layered semantic views demonstrate this concept cleanly.**自下而上演进的分层架构能够实现可叠加的能力。** 分层语义视图清晰地展示了这一概念。
- **The knowledge graph makes it possible to understand the true scope of what a thing is.** Nike may be — depending on the situation — a brand, a supplier, a partner, or a customer. The knowledge graph makes it possible to clearly understand what it is for a particular business and ensure answers reflect this correctly.**知识图谱使理解某事物真实范围成为可能。** Nike 可能——视情况而定——是一个品牌、供应商、合作伙伴或客户。知识图谱能够清楚理解它在特定业务中是什么，并确保答案正确反映这一点。
- **It is possible to automate a significant part of this process in Snowflake** and develop a standardized approach reusable across all departments in an organization.**可以在 Snowflake 中自动化这一流程的重要部分**，并开发一种可在组织所有部门复用的标准化方法。
The core insight is that layering ontology metadata on top of raw data dramatically improves agent accuracy and reasoning performance — which is equally important as we try to optimize cost in an increasingly tokenized way of working. In Tianxia’s article on the Enterprise AI Control plane powered by Snowflake (6) the main takeaway is that as you add the knowledge graph data along with the degrees of connection you are able to visibly expand on the types of questions the agent can answer.核心洞察是，将本体元数据叠加在原始数据之上会显著提高智能体准确性和推理性能——在我们试图在日益按 token 计费的工作方式中优化成本时，这一点同样重要。在 Tianxia 关于由 Snowflake 支持的企业 AI 控制平面的文章 (6) 中，主要结论是：随着你加入知识图谱数据以及连接程度，你能够明显扩展智能体可以回答的问题类型。
Before, you were limited to simple quantitative e.g., how many units sold to now be able to answer more nuanced questions that depend on being able to traverse the data in novel ways.过去，你只能处理简单的定量问题，例如卖出了多少件；现在则能够回答更细微的问题，这些问题依赖于以新颖方式遍历数据。
The research is sound and the architecture is elegant. What I’ve done is develop a series of visual tools to implement the methodology and extend it where necessary to support enterprise teams who need a hands-on implementation to understand who needs to do what and when.研究扎实，架构优雅。我所做的是开发一系列可视化工具来实施该方法，并在必要时加以扩展，以支持需要动手实施方案、了解谁需要在何时做什么的企业团队。
In addition, this aligns with a clear takeaway from Snowflake’s testing with CoCo: it required fewer iterations and fewer agent turns by a significant margin in testing against other AI Coding Agents as well as had higher accuracy and lower latency this is across the board whether you use Snowflake CoWork Agents or build the solution in CoCo. (9),(7),(8)此外，这与 Snowflake 对 CoCo 测试得出的明确结论一致：在与其他 AI 编程智能体对比测试中，它需要的迭代次数和智能体轮次显著更少，并且具有更高准确性和更低延迟；无论你使用 Snowflake CoWork Agents 还是在 CoCo 中构建解决方案，都是如此。(9),(7),(8)
Skills are great, but especially as teams begin to embrace AI, they need to see and touch during the learning phase to achieve an innate understanding of how the data connects and what they’re building. This informs how you approach design and development of future data marts to make this work even easier going forward.技能固然很好，但尤其是当团队开始拥抱 AI 时，他们在学习阶段需要看得见、摸得着，才能对数据如何连接以及他们正在构建什么形成直观理解。这会指导你如何设计和开发未来的数据集市，使今后的这项工作更加容易。
This article is for the people who build, test, and operate AI agents — not the end users consuming the answers. If you’re an engineer, architect, QA lead, or the person responsible for proving your AI actually works, this is for you.本文面向构建、测试和运行 AI 智能体的人——而不是消费答案的最终用户。如果你是工程师、架构师、QA 负责人，或负责证明你的 AI 确实有效的人，本文就是为你准备的。
The Ontology Suite本体套件
The tools are designed to enable technical and business teams to collaborate together, capture information, and collectively build the necessary context to seed agents. Organizations today may already have some of this instrumented using tools like Alation or Atlan. This solution doesn’t replace that information — it assumes you’ll create an integration to load that data into the model as part of onboarding.这些工具旨在让技术团队和业务团队协作、捕获信息，并共同构建智能体所需的初始上下文。如今，组织可能已经使用 Alation 或 Atlan 等工具对其中部分内容进行了采集。该解决方案不会取代这些信息——它假定你会创建一个集成，作为接入流程的一部分将该数据加载到模型中。
The answer became three products:最终形成了三个产品：
- Ontology Studio — a visual admin tool for building and managing the ontologyOntology Studio — 用于构建和管理本体的可视化管理工具
- Graph Viewer — a canvas-based visualization of the resulting knowledge graph, and your validation gate before generating semantic viewsGraph Viewer — 基于画布的结果知识图谱可视化，也是生成语义视图之前的验证关口
- Knowledge Agent Platform — a single app that connects all your AI capabilities and lets you prove the answers are right before anyone sees them. This isn’t for the business user asking questions — that’s Snowflake CoWork. This is for the operational team that needs confidence before shipping.Knowledge Agent Platform — 一个统一应用，连接你所有的 AI 能力，并让你在任何人看到答案之前验证答案是正确的。这不是给提问的业务用户使用的——那是 Snowflake CoWork。这是给需要在发布前获得信心的运营团队使用的。
This article introduces all three and goes deepest on Studio. The Graph Viewer and Knowledge Agent Platform will be discussed in more detail in a separate article.本文介绍所有三个产品，并最深入介绍 Studio。Graph Viewer 和 Knowledge Agent Platform 将在另一篇文章中更详细讨论。
Three Context Layers (Not Five)三个上下文层（不是五个）
Tianxia’s architecture has five layers. While correct, it can be hard to hold them all in your head simultaneously. I reorganized the same concepts into three that map to how people actually think about their data:Tianxia 的架构有五层。虽然正确，但很难同时将它们全部记在脑中。我将相同概念重新整理为三层，使其对应人们实际思考数据的方式：
Meaning (WHY) —The business team’s territory. What are our domains? What questions do we need answered? What are our business rules? In Snowflake terms: ONT_DOMAIN_SCOPE, ONT_KNOWLEDGE_FACT, ONT_BUSINESS_QUESTION. The business metadata that may or may not be formally captured in MDM systems or wikis. This is the actual Ontology.含义（WHY）——业务团队的领域。我们有哪些领域？我们需要回答哪些问题？我们的业务规则是什么？用 Snowflake 术语来说：ONT_DOMAIN_SCOPE、ONT_KNOWLEDGE_FACT、ONT_BUSINESS_QUESTION。这些业务元数据可能已经、也可能尚未在 MDM 系统或 Wiki 中被正式捕获。这才是真正的本体。
Shape (WHAT) — The architect’s territory. What are our entity classes? How do tables map to concepts? What are the relationships? In Snowflake terms: ONT_CLASS, ONT_PROPERTY, ONT_RELATION_DEF, ONT_RULE. Most of this gets bootstrapped automatically from INFORMATION_SCHEMA — the expectation is that much of it will come directly from your data models or MDM tooling.形态（WHAT）——架构师的领域。我们有哪些实体类？表如何映射到概念？关系是什么？用 Snowflake 术语来说：ONT_CLASS、ONT_PROPERTY、ONT_RELATION_DEF、ONT_RULE。其中大部分会从 INFORMATION_SCHEMA 自动初始化——预期其中许多内容会直接来自你的数据模型或 MDM 工具。
Substance (WHERE) — Mostly automated. Once you’ve defined the Meaning and Shape, the system builds a knowledge graph (KG_NODE, KG_EDGE), resolves entities across tables (ONT_CANONICAL_ENTITY, ONT_CROSSWALK), and generates the views that semantic models and agents consume. This is the actual Taxonomy.实质（WHERE）——大部分自动化。一旦定义了含义和形态，系统会构建知识图谱（KG_NODE、KG_EDGE），跨表解析实体（ONT_CANONICAL_ENTITY、ONT_CROSSWALK），并生成语义模型和智能体使用的视图。这才是真正的分类体系。
The goal of this structure is twofold:这个结构的目标有两个：
- Enable business and technology teams to collaborate together to capture critical information and observe the impact it has visually on agent performance.让业务和技术团队能够协作捕获关键信息，并以可视化方式观察它对智能体性能的影响。
- Make it easy to trace where things are happening with visual tooling.借助可视化工具，轻松追踪各环节发生的位置。
A 7 Step Workflow7 步工作流
Through a simple guided UI, the team can collaborate together to get everything they need into a single place.通过简单的引导式 UI，团队可以协作将所有需要的内容集中到一个地方。
Step 1 — Introspect (Shape): Point it at a database and schema. The system reads INFORMATION_SCHEMA, creates ontology classes from table names, maps every column as a property. PK/FK constraints on standard Snowflake tables are informational metadata, so you can use them to capture relationships as well as pull them from INFORMATION_SCHEMA. In addition, sample values and AI-generated descriptions fill in anything missing a comment. If you have existing MDM sources, you can feed that data in. Introspection gives you a starting point, but defining domains, linking classes, and attaching facts is deliberate manual work — you’re encoding knowledge that lives in people’s heads.第 1 步——自省（形态）：将其指向一个数据库和模式。系统读取 INFORMATION_SCHEMA，根据表名创建本体类，并将每一列映射为属性。标准 Snowflake 表上的 PK/FK 约束是信息性元数据，因此你可以使用它们来捕获关系，也可以从 INFORMATION_SCHEMA 拉取它们。此外，示例值和 AI 生成的描述会填补任何缺少注释的内容。如果你已有现有 MDM 来源，可以输入该数据。内省为你提供起点，但定义领域、链接类以及附加事实是需要刻意手动完成的工作——你正在把存在于人们头脑中的知识编码进去。
Step 2 — Domains (Meaning): The business team registers their domains — “Media Buying,” “Audience Strategy,” “Campaign Analytics.” Each domain gets linked to the schemas it covers. This is a high-level conversation with a stakeholder designed to capture how they think about their business.第 2 步——领域（含义）：业务团队注册其领域——“媒体购买”、“受众策略”、“活动分析”。每个领域都会链接到它所覆盖的模式。这是与利益相关方进行的高层对话，旨在捕获他们如何看待自己的业务。
Step 3 — Business Questions (Meaning): For each domain, the business team adds the questions they actually need answered. “What’s our average CPM by audience segment?” “Which campaigns are underperforming against KPI?” These questions drive everything downstream. Among other things, they help draw out terminology and concepts that need to be better understood.第 3 步——业务问题（含义）：对于每个领域，业务团队添加他们真正需要回答的问题。“我们按受众细分的平均 CPM 是多少？”“哪些活动未达到 KPI？”这些问题驱动下游的一切。除此之外，它们还有助于梳理出需要更好理解的术语和概念。
Step 4 — Classes and Facts (Meaning): Classes define the areas. An example is “Audience.” This may be used by many domains (Brand, Client, Campaign). Even if linked to a Campaign, a Brand or Client view may still want to understand it. Facts are organizational DNA — tribal knowledge, things meaningful to that company that may have a different meaning elsewhere. One of my favorite examples is “Active Users.” There are probably a million different definitions of what that means, even within a single organization.第 4 步——类和事实（含义）：类定义范围。例如“受众”。它可以被许多领域（品牌、客户、活动）使用。即使它链接到活动，品牌或客户视图可能仍希望理解它。事实是组织 DNA——组织内部知识，是对该公司有意义、但在别处可能有不同含义的事物。我最喜欢的例子之一是“活跃用户”。即使在同一组织内，它的含义也可能有上百万种不同定义。
Step 5 — Build Knowledge Graph (Substance): Build the graph from your definitions. Resolve entities across tables. Run inference rules (inverse relations, transitive closure, property chains). Validate constraints. The knowledge graph is more than a visual representation — it makes it easy for people to visualize data in a way they understand conceptually. Tables and SQL are awesome to some folks, but most people visually “see” data in terms of flow: Amazon → Prime Day → Toaster Oven → 1-Day Shipping — not DIM_COMPANY → DIM_MARKETING_EVENT → DIM_STOCK_ITEM → DIM_SHIPPING_OPTIONS → FACT_ORDER → FACT_ITEM.第 5 步——构建知识图谱（实质）：根据你的定义构建图谱。跨表解析实体。运行推理规则（反向关系、传递闭包、属性链）。验证约束。知识图谱不止是可视化表示——它让人们能够以概念上理解的方式可视化数据。表和 SQL 对一些人来说很棒，但大多数人从流程角度在视觉上“看见”数据：Amazon → Prime Day → 烤箱 → 一日达配送——而不是 DIM_COMPANY → DIM_MARKETING_EVENT → DIM_STOCK_ITEM → DIM_SHIPPING_OPTIONS → FACT_ORDER → FACT_ITEM。
Only when the graph looks correct visually should you move to semantic view generation. The viewer is your quality gate — it surfaces missing relationships, orphaned entities, wrong join granularity, and temporal mismatches that would otherwise become silent agent failures in production.只有当图谱在视觉上看起来正确时，才应进入语义视图生成。查看器是你的质量关口——它会揭示缺失关系、孤立实体、错误的连接粒度和时间不匹配，否则这些问题会在生产环境中变成静默智能体故障。
One of the most critical decisions when building your knowledge graph is what gets included and what doesn’t. In my demo I have all entities but only a sample of underlying data. In production, only high-value entities that are slowly changing should participate. Even if you bring across low-value entities for visual demonstration, make sure you don’t use them to inform agent routing decisions.构建知识图谱时，最关键的决策之一是哪些内容纳入、哪些不纳入。在我的演示中，我包含所有实体，但只包含底层数据的样本。在生产中，只应纳入高价值且缓慢变化的实体。即使为了视觉演示引入低价值实体，也要确保不用它们影响智能体路由决策。
In Snowflake, you can use dynamic tables to refresh the knowledge graph on a regular cadence.在 Snowflake 中，你可以使用动态表按固定周期刷新知识图谱。
Step 6 — Generate Views and Semantic Views: The system generates normalized views consumed by semantic views, as well as the semantic view YAML at each bake-off level — L1 through L4 — so you can deploy different flavors and benchmark which one your agent performs best with. One click deploys all levels.第 6 步——生成视图和语义视图：系统生成由语义视图使用的规范化视图，以及每个对比评估级别的语义视图 YAML——L1 到 L4——这样你可以部署不同变体，并基准测试你的智能体与哪一个配合效果最好。一键部署所有级别。
Step 7 — Activate Agent: The Knowledge Agent platform discovers the new semantic views, registers them as tools, and starts routing questions and running evaluations to determine which agent performs with the greatest consistency.第 7 步——激活智能体：Knowledge Agent Platform 发现新的语义视图，将它们注册为工具，并开始路由问题并运行评估，以确定哪个智能体表现最一致。
What I Added That Wasn’t in the Research我在研究中未包含的新增内容
The visual here encompasses a blend of ideas Steve wrote about for regulated industries combined with the layers from Tianxia’s work. The tooling I’ve built demonstrates how you can deliver this easily and securely, all within the Snowflake perimeter. No additional tooling required.这里的可视化包含 Steve 为受监管行业撰写的一组想法，并结合了 Tianxia 工作中的层级。我构建的工具展示了如何轻松且安全地在 Snowflake 边界内交付这一点。无需额外工具。
Visual Administration. Tianxia’s approach is CLI and CoCo skills. Powerful for engineers, opaque for everyone else. Ontology Studio is a web UI with wizards, editors, progress tracking, and inline documentation. A business analyst can register domains and add knowledge facts without writing SQL. This extends to the Knowledge Graph and the Agent Administration where you can do everything you need in a click style manner.可视化管理。Tianxia 的方法是 CLI 和 CoCo 技能。对工程师来说功能强大，对其他人来说难以理解。Ontology Studio 是一个带有向导、编辑器、进度跟踪和内联文档的 Web UI。业务分析师无需编写 SQL 即可注册领域并添加知识事实。这延伸到知识图谱和智能体管理，你可以在那里以点击式方式完成所有需要做的事。
Observability. In Snowflake all the minutia is captured all the time in a variety of system tables. The observability suite brings together all of these various tables into a single place so you easily see what can be tracked. There are entire 3rd party products dedicated to this quest for others who don’t have the clean integration that we support natively.可观测性。在 Snowflake 中，所有细枝末节都会持续捕获在各种系统表中。可观测性套件将这些不同的表汇集到一个地方，让你轻松看到可以跟踪什么。对于那些没有我们原生支持的简洁集成的其他方，市面上甚至有完整的第三方产品专门致力于这一目标。
Business Context Layer. ONT_KNOWLEDGE_FACT captures the tribal knowledge — “whale means $100+ spend,” “exclude test accounts from campaign metrics,” “Q4 data has a known gap in attribution.” These facts get indexed in a Cortex Search service and used for RAG retrieval during agent conversations. The agent doesn’t just query your data — it understands the caveats.业务上下文层。ONT_KNOWLEDGE_FACT 捕获组织内部知识——“whale 表示花费 100 美元以上”、“将测试账户排除在活动指标之外”、“Q4 数据在归因方面存在已知缺口”。这些事实会被索引到 Cortex Search 服务中，并在智能体对话期间用于 RAG 检索。智能体不只是查询你的数据——它还理解这些限定条件。
Testing & Evaluations. An area I spent extensive time working on was developing automated testing rigs for the agents. This covers a variety of different ways my customers are testing. Single prompt A/B testing, single multiple standardized testing, multiple agent standardized testing across multiple runs and most importantly evaluations. Adding in Ground Truth tests, LLM as a judge and a degree of repeatable automated testing so that you can say you trust your agent.测试与评估。我花了大量时间工作的一个领域是为智能体开发自动化测试框架。这涵盖了我的客户正在使用的多种不同测试方式。单提示词 A/B 测试、单个与多个标准化测试、跨多次运行的多智能体标准化测试，以及最重要的评估。加入 Ground Truth 测试、LLM 作为评审以及一定程度的可重复自动化测试，这样你才能说你信任自己的智能体。
The Thin Metadata Layer轻量元数据层
The entire ontology control plane is ~28 metadata tables and a handful of stored procedures sitting alongside your existing data in the same Snowflake account. No new infrastructure. No external services. No graph database. No vector store you have to manage.整个本体控制平面由约 28 个元数据表和少量存储过程组成，与现有数据一起位于同一个 Snowflake 账户中。无需新基础设施。无需外部服务。无需图数据库。无需你管理的向量存储。
Your data stays where it is. By adding a thin layer of connective tissue — bridging business knowledge, physical structure, and agent tools — so that when someone asks “show me our whale customers by campaign,” the agent actually knows what they mean and no matter how many times you ask the same question, it gives the same answer.你的数据保持在原处。通过添加一层薄薄的连接纽带——桥接业务知识、物理结构和智能体工具——这样当有人问“按活动向我展示我们的高价值客户”时，智能体真正知道他们的意思，并且无论你问多少次同样的问题，它都会给出相同答案。
Where This Goes Next接下来会走向哪里
For now, the takeaway is simple: the research works. The methodology is proven. But methodology alone doesn’t ship. Somebody has to build the tools that make it practical for the people who actually own the data and the business context. That’s what I’ve been doing.目前，结论很简单：研究有效。方法已经得到验证。但仅有方法无法交付。必须有人构建工具，让真正拥有数据和业务上下文的人能够实际使用它。这就是我一直做的事情。
If you’re building AI agents on Snowflake and your accuracy is stuck in the single digits, you don’t need a better model. You need an ontology.如果你在 Snowflake 上构建 AI 智能体，而准确率卡在个位数，你不需要更好的模型。你需要一个本体。
References参考资料
- The most Complex Data problems I encounter are never really about data. Steve Mitchener.我遇到的最复杂数据问题从来都不是真正关于数据的问题。Steve Mitchener。
- Ontology on Snowflake Part 1: — Overview and Data Model. Tianxia Jia.Snowflake 上的本体 第 1 部分：— 概述和数据模型。Tianxia Jia。
- Ontology on Snowflake Part 2 :— Semantic Models. Tianxia Jia.Snowflake 上的本体 第 2 部分：— 语义模型。Tianxia Jia。
- Ontology on Snowflake Part 3 — AI Powered Intelligence. Tianxia Jia.Snowflake 上的本体 第 3 部分——AI 驱动的智能。Tianxia Jia。
- Ontology on Snowflake From Architecture to Deployment with a Cortex Code Skill. Tianxia Jia.Snowflake 上的本体：从架构到使用 Cortex Code Skill 部署。Tianxia Jia。
- The Enterprise Ontology Control Plane on Snowflake. Tianxia Jia.Snowflake 上的企业本体控制平面。Tianxia Jia。
- Snowflake Blog Post: — Cortex Code CLI Expands towards supporting any data anywhere.Snowflake 博客文章：— Cortex Code CLI 扩展以支持任何地方的任何数据。
- Snowflake Blog Post: — Snowflake CoCo: The Coding Agent Built for Data Now Available Where You Work.Snowflake 博客文章：— Snowflake CoCo：为数据打造的编程智能体，现已在你工作的地方可用。
- Snowflake Blog Post: — Smarter, Faster and Snowflake-Native: Real-Time Text2SQL Behind Snowflake Intelligence.Snowflake 博客文章：— 更智能、更快且 Snowflake 原生：Snowflake Intelligence 背后的实时 Text2SQL。
