Snowflake CoWork Automations 架构与执行模型深度解析

深入解析 Snowflake 如何将自然语言问题转化为任务引擎上定期执行的代理计算。

引言

Snowflake CoWork Automations（2026年8月公共预览）引入了一种新的调度原语：代理任务与执行固定 SQL 语句或存储过程的传统 Snowflake 任务不同，代理任务按定期计划触发完整的 Cortex Agent 运行——包括 LLM 编排、多工具推理、SQL 生成和响应综合。

本博客自底向上剖析该系统：权限模型、执行流水线、驱动每次运行的 Cortex Agent API 机制，以及对大规模管理治理的数据平台团队的影响。

代理任务原语

核心上，自动化是一个带有变体的 Snowflake 任务。传统任务执行确定性 SQL：

CREATE TASK my_etl_task
  WAREHOUSE = analytics_wh
  SCHEDULE = 'USING CRON 0 9 * * 1 America/Los_Angeles'
AS
  INSERT INTO summary SELECT ... FROM raw_data;

而代理任务则调用 Cortex Agent API，并带有持久化的自然语言指令。执行是非确定性的——编排 LLM 每次运行都基于当前数据状态重新规划工具使用。

EXECUTE AGENT TASK 权限

这是一个新的账户级全局权限，用于控制谁可以创建和运行代理任务。它不同于现有的 EXECUTE TASK 和 EXECUTE MANAGED TASK 权限：

默认授予 PUBLIC 意味着账户中的每个用户都可以开箱即用地创建自动化。这是一个刻意的入门选择——也是注重安全的团队应首先评估的事项：

-- Restrict to specific roles
REVOKE EXECUTE AGENT TASK ON ACCOUNT FROM ROLE PUBLIC;
GRANT EXECUTE AGENT TASK ON ACCOUNT TO ROLE ANALYTICS_USERS;
GRANT EXECUTE AGENT TASK ON ACCOUNT TO ROLE DATA_SCIENTISTS;

与 EXECUTE TASK（需要具有 MANAGE GRANTS 的角色，通常是 ACCOUNTADMIN）不同，EXECUTE AGENT TASK 通过 BCR-2349 添加到了 PUBLIC，并提供了从 2026 年 7 月 30 日开始的退出窗口。希望退出的管理员应该从 2026 年 7 月 30 日开始执行撤销——在 8 月 3 日至 5 日公共预览推出之前。

执行架构

每次自动化运行都遵循多层执行路径：

┌────────────────────────────────────────────────────────────────────┐
│ LAYER 1: TASK SCHEDULER                                            │
│ Standard Snowflake task engine (cron-based)                        │
│ Frequency: hourly | daily | weekly | monthly                       │
│ Billing: Standard task execution credits                           │
└────────────────────────────┬───────────────────────────────────────┘
                             │ fires on schedule
                             ▼
┌────────────────────────────────────────────────────────────────────┐
│ LAYER 2: CORTEX AGENT API (POST /api/v2/.../agents/{name}:run)     │
│                                                                    │
│ ┌────────────────────────────────────────────────────────────────┐ │
│ │ ORCHESTRATION LOOP                                             │ │
│ │                                                                │ │
│ │  ┌─────────┐    ┌───────────┐    ┌──────────────────────┐      │ │
│ │  │  PLAN   │───▶│ USE TOOLS │───▶│ REFLECT & RESPOND   │      │ │
│ │  │         │    │           │    │                      │      │ │
│ │  │ Parse   │    │ Analyst   │    │ Evaluate results     │      │ │
│ │  │ request,│    │ Search    │    │ Loop or finalize     │      │ │
│ │  │ select  │    │ Code Exec │    │ Generate summary     │      │ │
│ │  │ tools   │    │ UDFs/SPs  │    │ + chart spec         │      │ │
│ │  └─────────┘    └───────────┘    └──────────────────────┘      │ │
│ │       ▲                                    │                   │ │
│ │       └────────────────────────────────────┘                   │ │
│ │              (iterates until resolved)                         │ │
│ └────────────────────────────────────────────────────────────────┘ │
│                                                                    │
│ Models: claude-4-sonnet, claude-opus-4-*, openai-gpt-5.*,          │
│         gemini-3.5-flash, llama3.3-70b (auto-selected or explicit) │
│                                                                    │
│ Budget constraints: seconds + tokens (configurable per agent)      │
└────────────────────────────┬───────────────────────────────────────┘
                             │ produces response
                             ▼
┌────────────────────────────────────────────────────────────────────┐
│ LAYER 3: THREAD PERSISTENCE + EMAIL DELIVERY                       │
│                                                                    │
│ - Creates new conversation thread per run                          │
│ - Stores full response (text + tables + Vega-Lite chart specs)     │
│ - Generates time-limited token for email deep-link                 │
│ - Delivers: AI summary, key metrics, link to full thread           │
│ - Results encrypted at rest                                        │
│ - Run history retained for 2 months (TTL)                          │
└────────────────────────────────────────────────────────────────────┘

Cortex Agent 运行 API 详解

当任务触发时，内部会执行等效的以下 REST 调用：

POST /api/v2/databases/{db}/schemas/{schema}/agents/{name}:run
Content-Type: application/json
Authorization: Bearer <user_token>

{
  "messages": [
    {
      "role": "user",
      "content": [
        {
          "type": "text",
          "text": "<original automation instruction>"
        }
      ]
    }
  ],
  "stream": false
}

响应模式（非流式）返回：

{
  "role": "assistant",
  "content": [
    { "type": "thinking", "thinking": { "text": "..." } },
    { "type": "tool_use", "tool_use": { "type": "cortex_analyst_text_to_sql", ... } },
    { "type": "tool_result", "tool_result": { "content": [{ "type": "json", "json": { "result_set": {...} } }] } },
    { "type": "text", "text": "Based on the data, revenue increased 12% week-over-week..." },
    { "type": "chart", "chart": { "chart_spec": "<vega-lite-json>" } }
  ],
  "metadata": {
    "usage": {
      "tokens_consumed": [
        {
          "model_name": "claude-4-sonnet",
          "input_tokens": { "total": 4200, "cache_read": 1800, "uncached": 2400 },
          "output_tokens": { "total": 850 },
          "context_window": 200000
        }
      ]
    }
  }
}

关键观察：

1. 思考内容块描述了 LLM 的推理——调用哪些工具，如何分解问题，输出是否足够。
2. 编排过程是迭代的。代理可以首先调用 Cortex Analyst 工具，意识到需要 Cortex Search 的上下文，也调用它，综合等。整个过程在预算限制（orchestration.budget.seconds 和 orchestration.budget.tokens）内重复。
3. 图表是 Vega-Lite 规范。data_to_chart 工具提供完整的 Vega-Lite JSON，然后可视化在电子邮件和 CoWork 会话中。这意味着图表是可重现和版本化的。
4. 令牌使用是模型特定且细粒度的。元数据将输入令牌分为缓存（cache_read）和未缓存。

工具执行链

每次自动化运行可以调用多个工具。以下是代理解析它们的方式：

Cortex Analyst (Text-to-SQL)

代理将自然语言问题传递给 Cortex Analyst，它会：

1. 根据语义视图定义（度量、维度、关系、筛选器）解析实体
2. 使用语义视图的 JOIN 图和度量计算生成 SQL
3. 对用户的仓库执行 SQL
4. 返回带有类型化列元数据的 ResultSet

// Tool result from Cortex Analyst
{
  "tool_use_id": "toolu_abc",
  "type": "cortex_analyst_text_to_sql",
  "content": [{
    "type": "json",
    "json": {
      "sql": "WITH __cte AS (SELECT ...) SELECT region, SUM(revenue) ...",
      "query_id": "01b23c45-...",
      "verified_query_used": true,
      "result_set": {
        "resultSetMetaData": {
          "numRows": 5,
          "rowType": [
            { "name": "REGION", "type": "VARCHAR" },
            { "name": "TOTAL_REVENUE", "type": "NUMBER", "precision": 38, "scale": 2 }
          ]
        },
        "data": [["APAC", "4250000.00"], ["EMEA", "3800000.00"], ...]
      }
    }
  }],
  "status": "success"
}

verified_query_used: true 标志表明 Analyst 匹配了语义视图的 VQR（已验证查询库）中的黄金/已验证查询，提供了置信度信号。

Cortex Search（非结构化检索）

如果问题需要文档上下文（例如，“退款升级的政策是什么？”），代理调用 Cortex Search 并动态选择过滤器：

{
  "tool_spec": {
    "type": "cortex_search",
    "name": "policy_search"
  }
}

结果附带引用元数据（search_result_id、doc_id、doc_title），这些元数据作为注释附加到最终文本响应中。

自定义工具（UDF/存储过程）

自动化继承底层代理配置的任何自定义工具。它们在仓库上下文中执行：

{
  "tool_resources": {
    "forecast_model": {
      "type": "function",
      "execution_environment": {
        "type": "warehouse",
        "warehouse": "ML_WH"
      },
      "identifier": "ANALYTICS.ML.RUN_FORECAST"
    }
  }
}

这意味着自动化可以在每次计划的执行中触发 ML 推理、调用外部 API（通过外部访问集成）或运行任意业务逻辑。

安全模型：每一层的调用者权限

安全模型是最重要的架构决策。代理任务在整个堆栈中执行调用者权限：

User's Role ──┬── Task Scheduling: EXECUTE AGENT TASK privilege
              ├── Agent Invocation: USAGE on agent object
              ├── Cortex Analyst: SELECT on semantic view → SELECT on base tables
              ├── Cortex Search: USAGE on search service
              ├── Custom Tools: USAGE on UDF/SP → inherits SP's rights model
              └── Warehouse: USAGE on assigned warehouse

对治理团队的影响：

1. RBAC 传播是自动的。如果用户的某个角色失去了对语义视图背后表的 SELECT 权限，则下次自动化执行将遵守该权限——Analysis 工具将失败或返回部分数据。
2. 行访问策略和屏蔽策略按用户执行。两个不同的用户对同一问题拥有自动化，可能根据每个用户的行访问策略上下文获得不同结果。
3. 不存在提权攻击的可能性。与所有者权限的存储过程相反，无法访问通过交互式查询无法访问的数据。
4. 审计日志。自动化发出的所有 SQL 都会记录在 SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY 中，以自动化所有者的用户身份。

单次自动化运行的成本剖析

单次自动化运行在多个维度产生成本：

对于每周生成一份含图表的3表报告的典型自动化：

• 约4,000–8,000个输入令牌（问题+语义视图上下文+工具结果）
• 约500–1,500个输出令牌（摘要+图表规范）
• 1次仓库查询（几秒到几分钟，取决于复杂度）
• 调度触发的标准任务计费

关键成本洞察：每次自动化运行都是一次完整的代理运行。没有“轻量”模式。编排LLM每次从头重新推理，这保证了新鲜度，但也意味着令牌成本随自动化数量和频率线性增长。

平台团队的操作模式

模式1：分级访问控制

-- Tier 1: Power users get full automation capability
GRANT EXECUTE AGENT TASK ON ACCOUNT TO ROLE POWER_ANALYSTS;
-- Tier 2: Regular users interact with CoWork but can't schedule
REVOKE EXECUTE AGENT TASK ON ACCOUNT FROM ROLE PUBLIC;
-- (They can still use CoWork interactively, just not create automations)

模式2：监控自动化蔓延

由于自动化创建任务，你可以通过标准任务可观测性来监控它们：

-- Find respective agent task and its schedule
SELECT *
FROM SNOWFLAKE.ACCOUNT_USAGE.TASK_HISTORY
WHERE name like '%AGENT_TASK%'
AND scheduled_time > DATEADD('day', -7, CURRENT_TIMESTAMP());

模式3：邮件投递的域验证

管理员可以通过DNS TXT记录验证整个电子邮件域，而不是逐用户验证。这使该域内所有用户在整个组织中获得已验证邮件状态，消除了个人验证流程的入门障碍。

模式4：主动选择退出

对于变更管理严格账户：

-- Run BEFORE the BCR takes effect to prevent default PUBLIC grant
REVOKE EXECUTE AGENT TASK ON ACCOUNT FROM ROLE PUBLIC;

这是幂等的——在BCR之前或之后运行都会产生相同结果。

比较自动化架构

执行的非确定性是关键权衡。你获得了模式弹性和自然语言友好性，但放弃了可重现性保证。完全相同的自动化在多次运行中对相同数据可能生成略有不同的摘要，因为LLM的推理过程可能变化。

线程模型与状态管理

每次自动化实例都会启动新的对话线程。上述设计决策确保：每个实例可以使用其线程ID引用

1. 点击邮件链接打开新上下文，不携带任何对话历史
2. 通过邮件链接进行后续查询会在特定实例的线程内发起新回合
3. 线程历史保留2个月后TTL过期
4. 线程保存代理生成的所有内容：思考路径、使用的工具/返回结果、文本、表格（表示为带类型信息的ResultSet）和图表（Vega-Lite规范）。

已知限制和差距（预览版）

缺乏编程API是平台团队最大的差距。目前你无法：

• 通过Terraform/Pulumi创建自动化
• 对自动化定义进行版本控制
• 跨组织批量管理自动化
• 将自动化生命周期集成到CI/CD中

结论

计划型代理推理是CoWork Automations为Snowflake带来的新计算范式。它不是带格式的定时查询，而是LLM循环的整体编排，每次都重新规划、重新执行和重新综合任务。平台所有者必须决定的关键问题包括：

1. EXECUTE AGENT TASK是否应保留在PUBLIC中还是立即加以限制
2. 如何衡量自动化产生的令牌使用量和仓库费用
3. 非确定性执行模式是否足以满足目标用例
4. 如何处理当前缺乏编程生命周期管理的问题

Cortex Agent API、按调用者权限执行、线程持久化和Vega-Lite渲染都很出色。限制主要在于预览版的操作层面。

Snowflake CoWork Automations于2026年8月6日进入公共预览（BCR-2349）。正式发布前功能可能发生变化。代理编排的令牌成本按Snowflake服务消耗表计费。

关于我：

你好！我是Riya Khandelwal，Snowflake数据超级英雄，在Azure、Snowflake和Databricks方面拥有实践经验，我专注于设计、构建和优化数据管道、ETL工作流和企业级数据仓库解决方案。

我持有13多项超云认证，覆盖Azure、IBM、AWS和Snowflake，这赋予我多云视角和构建既可扩展又面向未来的解决方案的能力。

除了技术工作，我喜欢分享知识并简化数据工程社区的高级概念。我经常撰写关于Azure、Snowflake、数据仓库和数据工程新兴趋势的文章。

✨ 关注我的Medium以获取Azure和数据工程的最新信息，我会将技术主题分解为实用的现实见解。

Riya Khandelwal - Medium

在LinkedIn上加入我，我定期为76K+人撰写流行话题。

https://www.linkedin.com/in/riyakhandelwal/

查看我更多关于Snowflake的文章——敬请期待更多Snowflake见解和实际用例。

• Snowflake CoWork：代理数据智能技术深度解析
• Snowflake的三级可观测性成熟度框架

深度解析：Snowflake CoWork Automations——架构、执行模型和代理任务…最初发布在Snowflake Builders Blog: Data Engineers, App Developers, AI, & Data Science上的Medium，人们在讨论和回应这个故事。