用 Snowflake Cortex Agents 释放结构化数据的最大价值 ｜ 技术实践
2026 年，智能体将在企业级应用中取得哪些实质性突破？点击下载《2026 年 AI 与数据发展预测》白皮书，获悉专家一手前瞻，抢先拥抱新的工作方式！ 我们正身处数据专业人员的一个非凡时代。有史以来，真正的自助式分析终于触手可及——业务用户只需使用自然语言提问，即可直接从数据中获得准确、且受监管的答案。无需手动编写 SQL，无需反复点选筛选器，更不必面对积压已久的仪表板需求。这一切，仅需一个能够理解上下文、跨数据源进行推理并即时交付洞见的智能体即可实现。 生成式 AI 已让这一愿景成为现实，但其成功与否，取决于数据团队如何设计这些智能体的架构。速度、准确性与安全性，是不可妥协的底线。而 Snowflake 为实现这三重目标提供了坚实基础。我与同事 Bryan Mutell 已协助众多客户在 Snowflake 上构建智能体应用。本文基于我们的实践经验，分享行之有效的架构与设计模式。我们将聚焦结构化数据——这是 BI 工作负载的主干，也是最快入手的起点。您将在文中找到实用的经验法则，并厘清常见的认知误区，从而交付用户真正信赖且实际使用的应用。 如果你刚入门，以下是你首先需要了解的 Snowflake 生成式 AI 核心功能： Snowflake Intelligence 架构 Snowflake Intelligence 是一个开箱即用的对话式界面，允许业务用户直接针对 Snowflake 数据进行提问、创建图表并执行操作。在底层，它通过 Cortex 智能体路由查询。关于架构的可视化讲解，请参阅 Jeff Hollan 主持的 BUILD 会议; Snowflake Intelligence Cortex 智能体 是编排层，负责分解用户请求，选择合适的工具（Cortex Analyst、Cortex Search、自定义工具），并以自然语言返回结果； Cortex Analyst 是自然语言转 SQL 引擎。它利用 语义视图 -一种将业务概念和指标映射到物理表的模式级对象 -针对你的数据模型生成准确的 SQL，且无幻觉问题； Cortex Search 是一项高性能模糊搜索服务，供智能体用于查找特定的字面量（例如，杂乱的产品名称）以及查询非结构化文档。针对结构化数据，你可以将 Cortex Search 与语义视图搭配使用，以提高在高基数（High-Cardinality）字段（如产品 ID、工单号或电子邮件地址）上的 SQL 准确性； 自定义工具允许智能体执行诸如发送电子邮件或运行存储过程等操作。由于这些功能由 Snowflake 的用户自定义函数和存储过程提供支持，你几乎可以将任何逻辑或语言包装为智能体的能力。相关示例请参考此 Snowflake Labs 代码仓库。 尽管直接着手构建智能体及其工具颇具吸引力，但在面向生产环境进行开发之前，仍需投入时间进行系统规划。参考 Snowflake 发布的《构建 Cortex 智能体最佳实践》指南，以下为若干行之有效的经验原则： 从明确的目标出发，使其与实际终端用户的业务行为相契合。用户需要做出哪些决策？他们期望智能体回答哪些问题？建议与相关利益方协作，定义 20 至 50 个代表真实工作流的“黄金问题”； 保持范围的聚焦。避免试图构建一个无所不知的通用型智能体；实践证明，最成功的智能体往往是那些专注于特定领域、具备高价值的专业型智能体； 将使用场景映射到相应工具。在确定黄金问题之后，将每个问题映射至回答该问题所需的具体数据。在实践中，这通常意味着为每个主要主题领域（例如，支持工单、销售管道、营销活动）建立一个语义视图； 极简原则至关重要。智能体应仅拥有实现其目标所必需的工具访问权限。多余的工具不仅会引入信息噪音，也会增加智能体选错工具的概率。 制定好计划后，开发工作流程大致如下。您需要自下而上构建智能体：首先从数据结构与质量入手，然后建立语义视图和工具，最后完成智能体配置： 第一步：准备、清洗和结构化您的数据。与商业智能报表一样，智能体应用高度依赖干净、建模良好的数据。在智能体应用中，脏数据或结构混乱的数据会变得尤为明显。您目前在商业智能工具中已呈现的数据，正是让智能体与数据对话的理想候选对象； 第二步：设置 Cortex Search 服务。 如果您计划使用高基数（约 10 个以上不同取值）字段，请进行此项设置。您完全可以后续再回来创建这些服务，但如果已预先知道需要在包含大量不同字符值的列上运行查询，建议提前设置好； 第三步：为 Cortex Analyst 设置语义视图。 这通常是工作量最大的一步，但语义视图自动导航功能可以通过摄取现有元数据（例如 Tableau 工作簿和 SQL 查询，后续还将支持更多数据源）显著提升构建速度； 第四步：配置自定义工具（如使用）。例如，用于触发工作流或调用业务操作系统的工具； 第五步：创建并配置 Cortex 智能体本身。 此步骤设置非常直观-您只需在用户界面中进行几分钟的连线操作，即可将语义视图、搜索服务和各类工具整合在一起。 开发工作流 完全支持搭建更为复杂的多智能体工作流。您可以设置一个“CEO”智能体来统筹调度一系列子智能体，让它们各自处理特定领域的任务。具体实现方法请参阅此指南。 多智能体架构示意图 来源：https://www.snowflake.com/en/developers/guides/multi-agent-orchestration-snowflake-intelligence/ 语义视图可以说是面向结构化数据的智能体应用中最重要的组成部分，因为它在业务问题与物理表之间起到了桥梁作用。遵循以下几项设计原则将大有裨益。 从用例入手。此前，您已明确了智能体的能力范围。现在需要识别该范围内的具体用例，并将其与底层数据源对齐。这些用例通常会映射到各自独立的语义视图； 将每个语义视图视为一个单一、内聚的业务领域。一个实用的判断标准是：如果一位人工分析师会说“那是另一个仪表盘”，那么该内容可能就属于一个独立的语义视图； 在同一个语义视图中包含多张表也是可以的，前提是它们属于同一领域且经常被组合查询，即使它们的指标看起来略有不同。例如，在“客户互动”领域，您可能会将网站分析、邮件营销和移动应用使用数据结合在一起：底层的表和度量值虽然不同，但查询的问题是相通的（例如：“各渠道、地区、细分市场的互动趋势如何？”），因此将它们放在一起是有意义的； 当智能体使用某个语义视图时，该语义视图的完整定义会作为上下文发送给模型。此时并非内容越多越好——请将每个视图控制在约 10 张表或更少，以减少干扰信息并限制幻觉现象的产生。 用例 -数据源 -语义视图映射关系 语义视图是连接物理数据与智能体代最终用户发起查询之间的转换层。其构建基础是逻辑表，这些表对应客户、订单或供应商等业务实体。逻辑表建立在物理表或视图之上，通过共享键的联结关系定义表间关联，从而支持跨实体的分析。 逻辑表包含以下核心元素： 事实：指代细粒度的行级基础度量值。它们描述单笔交易中的“量值”细节（例如单项价格或数量）。用户通常不会直接查询事实数据，但它们是构建指标体系的原始素材； 指标：此处用于定义关键绩效指标（KPI）。指标通过聚合运算（求和、平均值、计数）将事实数据转化为业务衡量标准。通过指标设定可实现“单一事实版本”的强制统一—例如，若“净收入”始终定义为 SUM(gross_revenue * (1 - discount))，在此处一次性定义后，智能体与用户将始终获得一致的计算结果； 维度：提供“何人、何事、何地、何时”的上下文信息。维度是分类属性字段（如区域、产品品类、财季），供用户用于过滤与分组指标数据； 命名过滤器：封装常见 WHERE 条件的可复用业务规则（例如“仅活跃客户”或“排除测试数据”），确保智能体能在跨指标与查询中一致性地应用相同的数据范围限定。 从智能体获取答案的准确性，在很大程度上取决于底层数据的准备质量。在我们与客户的合作过程中，测试阶段几乎总会暴露出数据质量或建模方面的问题。这完全在意料之中！随着数据被正式投入使用，其质量和结构会不断改进。您此刻在数据准备上投入的时间，日后将带来丰厚回报——它能大幅减少在语义视图层面进行修复、采用权宜之计或添加自定义指令的需求，从而避免视图变得更加难以维护。 数据准备原则： 清洗与标准化数值。规范大小写、修剪多余空格，并对代码和枚举值进行标准化处理（例如，将"US"、"USA"或"United States"统一为一种格式），确保数据在进入模型之前就已达成一致； 对齐数据类型与单位。 使用正确的数据类型（日期即为日期类型，数字即为数字类型），并标准化单位与时区（例如，始终以基准货币存储金额，以协调世界时 UTC 存储时间戳）； 使用稳定、一致的键。确保主键在各表之间具有唯一性和一致性，避免同一业务实体存在多个互相冲突的标识符； 优先采用维度建模（星型模式）。以清晰定义的粒度（例如，订单、工单、理赔申请）构建明确的事实表，并将其关联至共享的维度表（客户、供应商、产品）。此举能让连接操作对分析人员和 Cortex Analyst 都保持简单且可预测； 倾向使用宽表、非规范化表。在上述维度结构中，应将明确的业务概念展现为列（例如 total_revenue、units_sold），而非使用通用的 metric_name / metric_value 键值对或深层嵌套的 JSON 结构； 将转换逻辑向上游推送。若需从原始或非结构化数据中衍生类别、标志或评分（例如情感分析、工单主题、标准化原因代码），请将其固化为表中的列，而不要在生成 SQL 时进行动态计算。这能同时提升准确性与降低延迟； 显式处理缺失及脏数据。确定空值及异常值的处理策略（使用默认值、“未知”分类或直接排除），并在数据管道中统一应用这些规则； 去重并对账记录。在将数据向下游暴露之前，移除重复行并解决冲突记录（例如，一个客户存在多个活跃地址的情况）； 移除重复及易产生误导的列。针对每个业务概念或实体，仅保留单一可信的列（例如，唯一的一个 customer_id、一个 order_date、一个 order_type），并删除已弃用或易混淆的备选列。如果分析师经常问“我该用哪一列？”，请在数据暴露给智能体之前将其清理干净； 使层级关系显式化。使用清晰的、符合业务习惯的层级字段（例如 region、country、state、city）或结构良好的维度表（含父子键）来表示层级关系。避免将层级关系隐藏在通用代码或自由文本中；若分析师需在脑内解码层级结构，智能体同样会感到困惑。 拥有干净、一致且结构良好的源数据，您的语义模型—以及依赖它的智能体—将更有可能产出准确、值得信赖的答案。 实用提示： Cortex Code 是 Snowflake 新推出的智能体编程助手，它能极大加速数据探索、清洗与标准化的进程。只需向 Cortex Code 说明你正在为语义建模准备数据，它便会提供优化建议并自动生成数据转换逻辑。 Cortex Code 用户界面已集成至 Workspaces 精心构建的语义视图对于智能体的成功运行至关重要，因为它决定了用户的问题如何被转化为 SQL 查询。这项工作看似繁重——事实也确实如此——但 Snowflake 提供了高度的自动化支持，可帮助你以最小的阻力创建语义视图。 尽可能使用语义视图自动驾驶(Semantic View Autopilot) 语义视图自动驾驶(SVA)能够显著缩短开发时间。它会摄取现有的元数据（例如 Tableau 仪表板和 SQL 查询），并自动提出以下建议： 应将哪些物理对象纳入语义视图； 应展示哪些列； 如何定义数据关系； 初步的指标与维度设定。 你仍需对输出结果进行审查和优化，但 SVA 为你提供了一个坚实的基础起点，让你无需从零开始面对空白画布。 利用语义视图自动驾驶 使用 Cortex Code 语义视图技能。Cortex Code 是另一款强大的语义视图加速器。目前，使用它的最佳方式是通过 Cortex Code CLI 所捆绑的语义视图技能。该技能提供了一个引导式工作流，用于创建、审计、调试和优化 Snowflake 语义视图。你只需向 Cortex Code CLI 说明需要在语义视图的创建、验证或优化方面获得帮助，它便会自动调用该技能，并提供相应的建议与代码推荐； 若现有元数据不足，请从小处着手。如果起步时缺乏足够的元数据，请克制住将物理表或视图中的每一列都包含进来的冲动。请记住：所有这些元数据都会作为上下文发送给大语言模型以生成 SQL。数量庞大但命名不佳或相似的字段会增加混淆和产生幻觉的风险。建议仅包含报表实际所需的列，待发现明显缺口时再进行迭代补充； 主动启用样本值和描述。在使用 Cortex Analyst 用户界面时，请保留添加样本值和描述的默认选项。这两者都能显著提高自然语言转 SQL 的准确率。请将生成的描述视为草稿：检查其正确性，并调整措辞，使其与业务词汇体系保持一致； 利用同义词将现实用语映射到严格的列名。使用同义词将用户实际谈论数据的方式—包括行业术语、缩写、俚语甚至“不规范的表达”—映射到底层字段。由于现代大语言模型已能较好地处理通用语言，SVA 不再自动生成同义词。因此，请专注于在语义视图的列级别捕获你的专有词汇。这样一来，当用户向智能体询问“按品牌查看 BAGL”时，查询将正确使用 BEGINNING_ACCOUNT_BALANCE，并按 PARTNER_GROUPING_NAME 进行分组； 对高基数文本字段使用 Cortex Search。如果你的语义视图包含高基数、非数值型字段（例如产品名称、SKU、工单 ID 或邮件主题），请使用 Cortex Search 服务为其提供后台支持。这可以防止 Cortex Analyst 使用模糊条件或通配符进行猜测，从而显著提升针对这些字段的查询准确性。一条实用的经验法则是：如果唯一值过多，无法通过样本值有效捕获，或者这些值频繁变动，就应在其上部署 Cortex Search； 仅在语义视图层级使用自定义指令来控制 SQL 逻辑。通过语义视图中的自定义指令，您可以精准控制 SQL 的生成方式。例如，明确说明“绩效”“流失率”或“财年”等术语的具体含义，或指定用于定义某一业务概念的列。请利用自定义指令来编码应始终生效的业务规则及边缘情况处理逻辑。 语义视图中的自定义指令：用于 SQL 生成与业务逻辑； 智能体层面的自定义指令：用于路由、编排和回复风格，不涉及 SQL 行为。 清晰区分二者有助于避免信号冲突，并使行为调试更加简便。 针对关键路径投入精力建立已验证查询。 已验证查询对 SQL 准确性和响应延迟均有重要影响。当用户问题与某条已验证查询匹配时，Cortex Analyst 可跳过 SQL 生成步骤，直接复用经过审查的查询。在以下场景中，请优先使用已验证查询： 高频提问及核心仪表板查询； 逻辑复杂且精细、不希望模型每次都“重新摸索”的查询； 对正确性要求极高的查询（如监管或财务报告类场景）。 随着时间积累，一套精心筛选的已验证查询库将成为智能体强大的安全防护网和性能加速器。此外，语义视图的自动导航功能还会根据用户实际提出的问题，自动推荐新的候选已验证查询，帮助您持续加固关键路径。 再次强调——再怎么强调也不为过——已验证查询对于达成准确性和速度目标至关重要，请务必予以重视。 测试语义视图。 在逐步构建语义视图的过程中，Cortex Analyst 界面提供了内置的演练环境，方便您观察问题如何映射为 SQL 并查看生成的结果。您可以使用“解释数据集”功能快速生成一些示例问题以开始测试，同时请务必回顾您在规划阶段收集的核心测试问题。 Cortex Analyst 演练环境 在数据和语义视图就绪后，配置智能体本身的操作相对轻量，仅需调节少数几个参数旋钮。 模型选择。 在大多数情况下，应将编排模型设置保持为 AUTO。Snowflake 会自动将任务路由至最合适的模型。 为确保您的账户能够使用最高质量的模型，建议在账户级别启用 Cortex 跨区域推理，示例如下： 利用以下指令告知智能体其身份定位以及应当与不应当执行的操作： 智能体身份与范围界定（避免范围蔓延：明确该智能体的职责范畴及其边界）； 领域上下文与目标受众（例如，面向财务计划分析师还是支持部门经理）； 高阶业务规则与护栏机制（例如，“不得暴露个人身份信息级别的数据”，“严禁修改生产数据”）； 工具选择指引（例如，“针对政策类问题，优先使用 Cortex Search；针对指标查询，则使用 Cortex Analyst”）； 领域特定工作流（例如，“当被要求汇总当前预算状态时，必须包含迄今为止的实际支出、预测值以及与计划的偏差”）。 以下内容用于控制智能体的回复方式： 回复风格（简洁与详尽、高层摘要与分析级细节之间的选择）； 数据格式与呈现（表格与纯文本的选择、适时使用图表、计量单位与数值取整规则）； 错误与边界情况处理（数据缺失、不完整或超出预期范围时的回复策略）。 不应置于智能体层级的内容：为避免冲突与调试难题，请注意： 不要在智能体级指令中包含 SQL 逻辑或列级业务规则。此类规则应归属于语义视图（定义、指标、命名过滤器、语义视图自定义指令）； 不要粘贴试图重述所有数据规则的冗长“系统提示词”。保持智能体指令聚焦于作用范围、工具路由与回复风格；让语义层与已验证查询来编码具体的数据行为。 此时，您已设计好语义视图、智能体并微调了自定义指令。最后一步是确保您能够观察智能体的行为，并调试诸如回答不准确、响应迟缓等问题。 推荐的心理模型如下： Snowsight 中的“监控”标签页 →针对单个智能体，提供易于阅读的追踪信息，用于日常调试； AI 可观测性事件表 →提供底层遥测数据，您可使用 SQL 进行查询、与其他数据关联，并用于构建仪表盘或自定义分析。 上述两种方式均由同一底层的 AI 可观测性事件管道提供支持。 对于每个 Cortex 智能体，Snowsight 中的用户界面都会提供一个监控面板，Snowflake 会在此处展示按线程分组的对话历史记录。对于每个线程，您都可以看到一个跨度追踪树，其中显示了 LLM 规划、工具执行（Cortex Search、Cortex Analyst、网络搜索）、SQL 执行与图表生成，以及最终响应的生成过程。 智能体监控选项卡中的线程详情 这是着手调试错误答案以及通过查看哪个跨度耗时最长来排查慢查询的绝佳起点。 在监控界面背后，Snowflake 会将遥测数据写入您账户中的一个专用事件表： 表名： SNOWFLAKE.LOCAL.AI_OBSERVABILITY_EVENTS. 每一行都是一个事件或跨度，包含： TIMESTAMP、START_TIMESTAMP、RECORD_TYPE（EVENT 或 SPAN）， TRACE 和 SCOPE 元数据， RECORD（按信号类型固定的字段）， RECORD_ATTRIBUTES（JSON 属性，如智能体名称、线程 ID、令牌数、模型、状态）， VALUE（部分记录类型的负载内容）。 以下是一个示例查询，该查询会解析 RECORD_ATTRIBUTES 并返回智能体的执行情况，包括日期、用户、智能体名称、问题、答案以及执行时间： 示例查询结果 如需检索更多信息，请让 Cortex Code 协助更新此查询。 要了解您在 Cortex 智能体和 Snowflake Intelligence 上的支出情况，请从以下两个 ACCOUNT_USAGE 视图入手： SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AGENT_USAGE_HISTORY —直接的 Cortex 智能体 API 调用； SNOWFLAKE.ACCOUNT_USAGE.SNOWFLAKE_INTELLIGENCE_USAGE_HISTORY —来自 Snowflake Intelligence 的使用情况。 你可以通过如下查询将这些表联合起来，并按天汇总每个智能体的每日用量： 在此基础上，你可以调整过滤条件和分组维度（例如时间窗口、虚拟仓库、用户等），以匹配你追踪成本的具体方式。 安全通常是团队询问 AI 智能体时的首要问题，这理所应当。在 Snowflake 中，Cortex 智能体完全运行在现有的安全与治理边界内，并以调用者的身份执行操作，而非作为一个独立的超级用户运行。 概括来说： 智能体继承现有的基于角色的访问控制 -智能体只能查看和查询该用户角色已有权限访问的对象（数据库、模式、表、视图、语义视图）。它无法通过“提示词”来获取更多权限； 行访问策略和数据脱敏策略仍然生效 -策略在查询引擎层面强制执行，结果在送达模型之前即已完成过滤。因此，即使用户请求“所有的原始值”，受限的行依然不可见，脱敏列也依旧保持脱敏状态； 所有活动均记录在案 -每一次智能体交互均可通过监控界面、AI 可观测性事件表以及 ACCOUNT_USAGE 视图进行追踪。这为你提供了完整的审计跟踪信息，包括谁问了什么、访问了哪些数据以及产生了多少费用。 本文侧重于架构与数据建模，而非深入探讨安全模式。若想进一步了解 Snowflake 上 AI 智能体的加固策略，推荐阅读我的同事 Michael van Meurer 的文章《致命三要素：为何你的 AI 智能体可能是安全漏洞》（The Lethal Trifecta: Why Your AI Agent Could Be a Security Liability）以及 Medium 上关于 Snowflake 智能体安全的相关文章。 Cortex 智能体使得在结构化数据之上构建对话层成为可能，但真正的核心仍取决于基础要素：整洁的数据模型、强大的语义层、严密的治理机制，以及在平台层（而非仅靠提示词）落实的安全管控。 以下是对关键建议的总结： 从真实的业务工作流和“黄金问题”出发，围绕这些用例严格限定智能体的范围与工具边界； 确保底层数据经过建模和清洗，达到可接受的质量标准。若在此环节存在问题，Cortex Code 可充当高效的加速器，用于重构数据管道、暴露问题并统一数据模式； 投入精力构建高质量的语义视图，并辅以经过验证的查询及 Cortex Search 服务，以保障回答的准确性和响应速度； 将智能体配置定位为轻量级的编排层，用于控制范围、路由及回复风格，而非在配置中重新嵌入 SQL 逻辑。SQL 行为与业务规则应保留在语义层内； 保持智能体精简且受到严格治理。仅为每个智能体授予其实际所需的语义视图、搜索服务及工具访问权限，并依托 Snowflake 的 RBAC、行级访问策略与数据脱敏，在数据层落实最小权限原则； 借助 Snowsight 追踪记录、AI 可观测性事件以及 ACCOUNT_USAGE 视图，监控智能体的行为与成本，并根据实际使用情况进行迭代优化。 身处数据领域，这是一个令人振奋的时代。遵循上述模式，你将能够交付用户真正信赖的智能体化商业智能体验，并使数据团队在生产环境中实现从容运维。 点击链接立即报名注册：Ascent - Snowflake Platform Training - China，更多 Snowflake 精彩活动请关注专区。结构化数据智能商业分析的核心 Snowflake 构建模块
Cortex 智能体核心设计原则：提前规划
智能体开发工作流程
语义视图的核心设计原则
将语义视图映射至用例
理解语义视图结构
为语义视图准备数据
创建语义视图的最佳实践
请注意以下重要区别：
智能体配置选项
ALTER ACCOUNT SET CORTEX_ENABLED_CROSS_REGION = 'ANY_REGION';--ORALTER ACCOUNT SET CORTEX_ENABLED_CROSS_REGION = 'AWS_US, AZURE_US';智能体级指令（编排/行为约束）。
智能体级响应指令（回复格式控制）
监控智能体执行
在测试与开发过程中使用监控选项卡进行调试
查询事件表以进行深入分析与报告
SELECT DATE(TIMESTAMP) AS DATE, RESOURCE_ATTRIBUTES['snow.user.name']::STRING AS USER_NAME, RECORD_ATTRIBUTES['snow.ai.observability.object.name']::STRING AS AGENT_NAME, RECORD_ATTRIBUTES['snow.ai.observability.agent.thread_id']::STRING AS THREAD_ID, TRACE['trace_id']::STRING AS TRACE_ID, RECORD_ATTRIBUTES['ai.observability.record_root.input']::STRING AS QUESTION, RECORD_ATTRIBUTES['ai.observability.record_root.output']::STRING AS ANSWER, ROUND(RECORD_ATTRIBUTES['snow.ai.observability.agent.duration']::NUMBER / 1000, 2) AS EXECUTION_TIME_SECFROM SNOWFLAKE.LOCAL.AI_OBSERVABILITY_EVENTSWHERE RECORD_ATTRIBUTES['snow.ai.observability.object.name']::STRING = '<YOUR_AGENT>' AND RECORD['name']::STRING = 'AgentV2RequestResponseInfo'ORDER BY TIMESTAMP DESC;
监控智能体成本
SELECT AGENT_NAME, DATE_TRUNC('day', START_TIME)::DATE AS DAY, COUNT(*) AS CALLS, SUM(TOKEN_CREDITS) AS TOTAL_CREDITS, ROUND(AVG(TIMESTAMPDIFF('millisecond', START_TIME, END_TIME)) / 1000, 2) AS AVG_LATENCY_SECFROM ( SELECT AGENT_NAME, START_TIME, END_TIME, TOKEN_CREDITS FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AGENT_USAGE_HISTORY UNION ALL SELECT AGENT_NAME, START_TIME, END_TIME, TOKEN_CREDITS FROM SNOWFLAKE.ACCOUNT_USAGE.SNOWFLAKE_INTELLIGENCE_USAGE_HISTORY)WHERE START_TIME >= DATEADD(day, -7, CURRENT_TIMESTAMP()) AND AGENT_NAME IS NOT NULLGROUP BY 1, 2ORDER BY DAY DESC, TOTAL_CREDITS DESC;
Cortex 智能体的安全与治理
结论
