如何在 Snowflake 中构建自主 AI Agent？

在监督下自动调查工单、提出变更并执行运维操作的代理

最近，有人问我是否可以在 Snowflake 中构建自主 AI 代理。不是那种用来询问企业数据问题的助手。而是那种可以被赋予像“自动解决我们的支持工单”这样任务的系统。

我的回答是可以，但我想通过亲手构建一个来证明这一点。本文描述了构建此类系统所用的过程、模式和 Snowflake 功能。

首先，“自动解决支持工单”是什么意思？阅读工单并解释问题？向请求者询问缺失的信息？更改表记录？重启失败的进程？那么，由谁来决定代理何时拥有足够的证据去做这些事情？

如今，团队花费数小时处理服务工单。最好的情况是编写提示来排查问题；最坏的情况是编写 SQL 查询并手动查看日志。如果代理能够自主且可靠地完成这些任务，就能为公司释放真正的工程产能。

Snowflake 在这个用例中处于特别有利的位置，我会解释原因，让我们先介绍一些概念。

是什么让代理具有自主性？

典型的对话式 AI 代理在聊天 UI 中以用户驱动的循环运行：我提问，它检索证据，然后我决定下一步做什么。它一路上可能会使用多种工具。它可以高度代理化，但并不承担持续性的运维职责。

自主运维代理被委派一个有界目标。一个新支持工单、一个监控事件或一个计划任务都可以启动代理工作。它可以自主选择下一步，使用工具，检查结果，并在没有人指定每个中间指令的情况下继续。聊天窗口中的答案不再是唯一的输出。结果可能是一条更正后的记录、一个澄清请求，或者一个已经完成调查的升级。

代理框架：将推理与工作流分离

在自主代理系统中，将两个循环分开是很有用的。

这个 内循环是推理。一个代理框架负责编排这个循环。Snowflake Cortex Agents开箱即用地提供了该框架，包括工具调用、代码执行和响应生成，因此我不需要自己构建或运维编排循环、运行时或沙箱基础设施。

这个 外循环是运维工作流：识别工作、加载状态、调用代理、持久化结果，并在人工输入或批准后恢复。外循环几乎总是标准的 worker。Snowflake App Runtime可以将此逻辑与你的数据一起托管，直接访问表、仓库和安全控制，并且无需配置基础设施、配置凭据或管理 Docker。

这种分离还能让普通工作远离推理循环。检查一个新工单是否具有特定类别不需要 LLM。对于一个含义模糊的工单描述，使用 RAG 来选择相关的运行手册则可能需要。

付诸实践：Snowflake 中的代理式工单运维系统

让我们深入细节。从高层来看，该系统由一个以代理为核心的工单运维 Web 应用组成。我希望代理处理数据团队可能收到的典型工单，例如更正付款日期的请求、检查失败的数据摄取批次是否可以重放，或调查传入数据中的模式不匹配。

我的目标之一是展示一系列有用的代理结果：请求更多信息、向人类提出受控变更，或带着证据升级。

以下是每个组件负责的内容。

• 应用框架负责任务分发。这是完全在 Snowflake 中运行的 App Runtime（Next.js）后端。它跟踪新工单，并在有需要调查的内容时调用代理。它还处理人工审批决策。
• Cortex Agents 负责调查。应用程序提供工单和相关工作流上下文。代理选择要检索哪些证据，参考运行手册，并返回诸如 NEEDS_INFO、NEEDS_APPROVAL 或 ESCALATED 之类的操作。
• 语义视图定义结构化数据上下文。我通过语义视图公开工单和运维上下文。当这些数据源在 Snowflake 中可用时，同样的方法可以公开受治理的指标、日志或其他结构化数据。
• Cortex Search 检索运维指导。系统为运行手册建立索引，这样代理就可以检索相关流程，而不是在每个提示中搜索整个文档库来寻找答案。Cortex Search在这里大放异彩。在底层，它结合了向量搜索、关键词查找和语义重排序。这些运行手册描述了何时询问、行动或升级。在生产环境中，其归属、新鲜度和版本也应成为设计的一部分。
• MCP 将代理连接到工单系统。我使用 Jira MCP 让代理读取最新的工单上下文并发布评论。这是一个外部集成，通过 OAuth 拥有自己的授权边界。另一个服务管理平台可以通过适当的连接器或 API 来承担这个角色。
• 存储过程使代理的操作范围保持狭窄。为了让演示保持简单，我给代理提供了一个工具，用于一项有限的业务操作：更新表中的付款日期。一旦记录了所需的批准，它就可以自主执行该更改。在生产环境中，我会公开一小组与允许的运行手册操作一致的专用操作。多个运行手册可以共享同一个操作。每个操作都应强制执行权限、验证输入和业务规则、检查任何所需的批准，并防止重复执行，同时留下结果的审计跟踪。
• Snowflake 表保存工作流状态。票据快照和重要标志（例如人工审批是待处理还是已批准）会记录在一张标准的 Snowflake 表中。如果事务量需要完整的 OLTP 替代方案，Snowflake Postgres 可以承担这一角色。

端到端工作流：一个周一早晨的工单

现在是周一上午 10 点。财务部门的某个人为数据团队开了一张工单：

财务标记 BOOKING-018 上的付款日期不正确。它显示为 22/04/2026，但应该是 20/05/2026。有人能更正一下吗？谢谢。

如上所述，应用运行时（外循环）找到该工单并将其发送给 agent 进行调查。

agent 检查该工单：它有一个预订参考号和两个日期，足以进行调查，但并不等于可以更改任何内容的绿灯。它通过语义视图检查该预订，检索付款日期 runbook，并通过 MCP 将其发现作为工单评论发布。

我们能检查 agent 是如何推理的，以及向应用 harness 发送回了什么响应吗？当然可以。Snowflake 会公开所有 trace 供管理员检查。

在 agent 响应中，我们可以看到让外循环能够判断：“好，agent 正在请求人工审批”的 JSON。

与此同时，agent 回复工单报告人，添加一条评论，提供指导和后续步骤。

在后台，agent 的提案作为一条表记录存储。一旦人工操作员批准该提案，应用就会带着 action ID 再次调用 agent。agent 再次做 LLM 最擅长的事：对工单进行推理并决定最佳下一步。在这种情况下，它会检查审批标志，调用存储过程（工具）更新记录，并在工单中写入一条评论说明更改了什么。

数据团队用于 agent 监督的 UI 控制平面

正如 Cortex Agents 可以在几分钟内创建一样，得益于 CoCo（例如 /snowflake-apps Build me a control plane for a ticketing agentic....），一个漂亮的控制平面 Web 应用也可以完全在 Snowflake 上构建和部署。

控制台 UI 显示 agent 队列、提议的更改和一般活动。人工操作员可以看到哪些需要信息、哪些需要审批、哪些已升级。他们可以暂停轮询或重试某张工单，而不必猜测后台进程在做什么。

在提高自主性之前我会衡量什么

Cortex Agent 评估提供针对数据集的批量测试，包括答案正确性、逻辑一致性和自定义指标。这让团队可以评估的不只是一段答案。这里重要的是：agent 是否选择了合适的工具并正确使用了它？

对于这个工作流，我会用有代表性的工单构建一个回归集，包括缺失引用、冲突指令、不支持的操作和目标记录已更改的情况。使用隔离数据和模拟写入工具运行它，这些工具记录预期更改，但不更新外部系统。评估会执行 agent；它们并不是自动无害地 dry run 一个有副作用的workflow。

Agent 可观测性提供规划、工具调用、响应和时序的实时 trace。将这些 trace 与工单和 action ID 关联起来，以端到端跟踪一个运营结果。trace 解释 agent 尝试了什么；action ledger 记录业务系统实际提交了什么。两者结合起来有助于区分是推理问题，还是数据、工具或交付失败。

这个反馈循环就是我扩大自主性的方式：先证明某一类工单可行，确定其失败率和处理成本，然后有意识地扩大其权限。

为什么不在 Snowflake 之外构建这一切？

你完全可以在 Snowflake 之外构建这一切。托管在你自己的服务器上的外部 worker 可以调用不同模型的 API，你必须为两个或更多模型提供商（例如 Claude 和 OpenAI）管理 API key 和合同以实现故障转移保护，通过 API/MCP 查询 Snowflake 和工单系统，而这还只是让你起步。

然而，调用模型是容易的部分。你仍然需要模型/工具编排、上下文管理、检索、身份、相关场景下的执行隔离、trace、评估和成本归因。

对于以数据为中心的工作流，Snowflake 将你需要的一切整合在一起。工作重心转向定义运营契约，而不是构建周边平台。我在本文中提到了一些能力，如 Cortex Agents、Cortex Search、Semantic Views 和 App Runtime。话虽如此，最近宣布的一些其他有用补充会完善这一架构：

• 托管代码执行： Cortex Agent 代码执行工具，可以在隔离沙箱中运行 Python，用于计算和处理工具结果。当调查需要的不仅仅是检索时，这很有用（这并不是用不受限制的生成代码替换经过检查的业务操作的理由）。
• 受治理的模型访问： Cortex AI Gateway，目前处于预览阶段，提供 MCP/Tool 治理、原生记录的完整多步骤 trace 和 span，并且总体而言，它是 Snowflake 新的统一企业 Agent 控制平面，用于模型推理。
• 经济性方面有更多选择： 动态模型路由和额外的开放权重模型，旨在将任务复杂度与合适的模型成本匹配。开放模型包括 DeepSeek-V4-Flash 和 GLM-5.3。

下一步：从你想要消除的手工工作开始

举例说明，如果你的团队每周收到 20 张符合条件的工单，每张目前需要一小时工程工作，将其减少到 15 分钟的审核和异常处理，将节省 每张工单净 45 分钟。这大约是 每四周回收 7.5 个工程日。

收集同样证据的时间更少，交接更少，重复请求的解决速度更快。为什么不试一试呢？

从一个重复出现的工单类型和一份运维手册开始。避免试图在第 1 天就“自动化整个支持台”。创建一个 Cortex Agent，暴露一个小型工具面，并给你的团队一个他们可以信任的控制平面。让证据来证明下一层次的自主性是合理的。

总结一下。是的，自主代理可以在 Snowflake 中构建。让这种方法引人注目的是，该平台不仅支持所有前沿模型，还支持围绕代理的工作：受治理的上下文、托管的执行能力、评估、观察，以及让人们保持控制的应用。

我希望你觉得这篇文章有用。现在我很想知道：你在你的组织中构建过自主代理吗？什么起了作用，什么坏了，什么让你说：“也许我们让人类留在那个循环里吧”？我很想听听你的故事。

你能在 Snowflake 中构建自主 AI 代理吗？ 最初发表于 Snowflake Builders Blog: Data Engineers, App Developers, AI, & Data Science 在 Medium 上，人们通过突出显示并回应这个故事来继续对话。