你的 Coding Agent 有多大价值，取决于它对你的数据了解多少 | 技术实践
点击查看原文>
2026 年，智能体将在企业级应用中取得哪些实质性突破？点击下载《2026 年 AI 与数据发展预测》白皮书，获悉专家一手前瞻，抢先拥抱新的工作方式！
大多数数据工程师都试过把一个 Coding Agent 指向自己的 SQL，然后得到一些“看起来有用”的结果。样板代码变少了，搭架子更快了，信号很明确：Agents 和数据工作天然是契合的。
但很快就会出现一种更难描述的挫败感，它不像幻觉那样明显，也不只是因为查询写错了。Agent 生成出来的内容从表面上看没问题，语法正确、风格也符合惯例，但它并不真正适合你的实际环境。它不知道哪些表是生产表，哪些 Schema 是受治理的，也不知道你的 RBAC 结构是什么样。结果就是：你拿到了一份还得继续人工重塑的代码，它离真正可用还差很远。
问题不在模型本身，而在于 Agent 运行时脱离了让数据工作变得“具体”的上下文。
Coding Agents 天生适合做数据工作
它们带来的价值是真实存在的。数据工程里有大量模式化工作：流水线脚手架、增量转换逻辑、重复性的 SQL join、遵循固定套路的迁移脚本。一个好的 Coding Agent 能够很快消除这些摩擦。
那些本来花在搭脚手架而不是做设计上的时间，正是 Agents 最适合接手的成本。现在已经从中获得明显收益的团队，并没有判断错方向。
在数据栈里，“上下文”到底意味着什么
这个词经常被泛化使用，但在数据工作里，它有非常具体的含义。你的数据栈是有“立场”的：它依赖特定 SQL 方言；它的 Schema 结构里埋着命名约定；它还包含平台特有对象，比如 Dynamic Tables、Snowflake Tasks 或 Snowpark stored procedures。一个不了解这些的 Agent，并不会总是生成“错误答案”，但它生成的往往只是“通用答案”。
你当然可以通过 Prompts 人工补上下文：贴一段 Schema 描述，给几个示例查询，顺便解释一下平台约束。但这意味着，这些信息需要你手工维护，并持续伴随 Agent 一起更新。每一次 Schema 变化、每增加一张表、每出现一个新平台特性，你都得重新把这些东西喂进去。它确实能工作，但那本质上是“伪装成 AI 工作的集成工作”。
大多数人直到出问题才会意识到：治理才是最关键的一层
真正最重要、也最晚暴露出来的缺口，就在这里。数据治理，包括数据脱敏策略（masking policies）、行级访问控制策略（row access policies）和基于角色的访问控制（RBAC）角色层级，对一个脱离平台运行的 Agent 来说几乎是不可见的。于是它会在完全不知道这些约束存在的前提下生成代码。
数据工程师使用通用智能体时，完全可能生成一条能够成功编译、通过代码审查并上线生产环境的查询，却在最后才发现：这条查询访问了当前角色本不应该看到的数据，或者绕过了一项专门用于保护该字段的脱敏策略。从智能体自身掌握的信息来看，它并没有犯错。它只是根本无从得知这些限制。
有些知识无法靠注入解决
模式（Schema）上下文可以添加到提示词中，治理上下文则更难处理。但还有第三层知识更加棘手：了解平台本身的运行方式。
查询 ACCOUNT_USAGE 时，有一些至关重要的特定模式——应该使用哪些视图、如何连接这些视图，以及哪些字段存在数据延迟。SYSTEM$CLASSIFY 有特定的输出格式，也有明确的适用场景GET_LINEAGE 要求以特定顺序传入参数，而它返回的结果也必须结合平台自身的语义来解读。这些知识并不难学，但一个仅凭通用知识工作的智能体，并不了解它们在你当前账户和平台版本中的具体情况。
任务越依赖特定平台，你就越需要在以下两种选择之间权衡：要么自己构建上下文层，要么接受那些看似合理、实则并不完全准确的答案。
这才是平台原生智能体真正解决的问题
前面提到的三个缺口——需要手动维护的上下文、智能体无法感知的治理规则，以及只能靠近似推断获得的平台知识，并不会因为你换用了更强大的模型就自然消失。只有当智能体直接构建在平台内部时，这些问题才会得到根本解决。
Snowflake 的 CoCo 正是围绕这一需求设计的。它以你实际使用的 Snowflake 角色运行，因此，脱敏策略和行访问策略并不是需要智能体主动理解和推理的约束，而是它所在执行环境的一部分。上下文问题也随之大幅减轻，因为 CoCo 可以直接查询你的目录、检查模式，并在你的账户中运行 SQL。你不必把表结构塞进提示词里，CoCo 可以自行读取。
平台使用能力方面的缺口也会得到弥补，因为 CoCo 内置了数据团队日常任务所需的技能，包括查询 ACCOUNT_USAGE、通过 GET_LINEAGE 追踪数据血缘、使用 SYSTEM$CLASSIFY 进行个人身份信息（PII）分类、分析成本以及诊断工作负载。这些并不是简单的提示词模板，而是针对 Snowflake 特定 API 和查询模式构建的结构化工作流。
最终，你可以把时间花在真正的问题上——设计数据管道、编写数据转换逻辑，或者审计治理策略——而不必反复搭建脚手架，让通用智能体先获得足够的背景信息，才能开始帮助你。
无论采用哪种方式，这套脚手架都必须存在。区别在于，使用平台原生智能体时，已经有人替你把它搭建好了。
如果你已经在使用 Snowflake，正在评估编码智能体究竟适合参与哪些工作；或者你正在比较，哪一种编码智能体更值得用于数据任务，那么 CoCo 值得了解：
https://docs.snowflake.com/en/user-guide/cortex-code/cortex-code
点击链接立即报名注册：Ascent-Snowflake Platform Training-China，更多 Snowflake 精彩活动请关注专区
本文来源：InfoQ