数据Agent落地，卡住你的不是模型

把大模型接进公司数据库，跑个 Demo 惊艳全场，正式上岗三天就开始报错表、算错数——这是过去一年无数数据团队共同的经历。

问题出在哪？越来越多一线工程师给出了同一个答案：不在模型，在模型外面那一圈。引擎很强劲，但没有人靠一台裸发动机开车。决定你敢不敢相信那个数字的，是围绕模型搭建的整套装置——业内给它起了个名字，叫 harness。

🚗 引擎不是汽车：harness 到底是什么

没有人买了一台发动机，就指望它能开去上班。

Addy Osmani（Google Chrome 团队工程负责人）在其博客文章 Agent Harnesses（addyosmani.com）中给出了一个流行的概括：Agent = 模型 + harness。发动机放在车间的支架上，动力十足，但毫无用处；只有装上方向盘、刹车、油路、仪表盘和驾驶座，它才成为一辆车。

对应到数据场景，模型负责推理和写查询，速度快、能力猛；harness 则是那辆车的其余部分——它读什么指令、可以用哪些工具、允许碰哪些数据、步骤之间记住了什么、产出必须通过哪些校验，以及在哪些节点必须停下来等人点头。

这个划分背后有一个冷峻的判断：模型能力的提升，边际上正在变平；而 harness 的质量，直接决定同一颗模型在企业里是「生产力」还是「事故源」。「我们换了三次模型，错的表还是那张错的表。」——这句在技术社区被反复引用的吐槽，出自一位在制造业公司内部搭建过 Agent 数据助手的工程师（受访者要求匿名，此处为经多方转述的典型反馈，供示意参考；类似的复盘在 r/dataengineering、Hacker News 等社区的数据 Agent 落地讨论帖中普遍可见）。

这就是为什么很多团队开始意识到——买一个 Agent 工具，等于买到了一个通用 harness；但通用 harness 意味着它对你的指标口径、业务规则、权限边界一无所知。剩下的活儿，全在你自己身上。

📋 dbt 描述，才是 Agent 的真正提示词

一位工程师自建了 MCP 服务器，让 AI Agent 能检索并查询公司数据。他后来复盘说，大部分时间没花在服务器本身，而是花在一个反复出现的问题上：为什么 Agent 总是选错表？

答案几乎总是 dbt 文档。

第一个发现很反直觉：Agent 只能看到你描述的开头。给 dbt 模型建索引时，长文本会被截断——模型描述只有第一行、每个字段的说明只有前两句话能进入检索，后面的内容根本到不了 Agent 面前。所以关键信息必须写在第一句：这张表是什么、粒度是什么、它「不是」什么。如果一个字段因为特殊原因允许为 NULL，也要在第一句话说清。

第二个发现是最大的陷阱：千万别让 AI 从模型反写 YAML 描述。三百个模型没人来得及写文档，于是让 AI 照着 SQL 生成——你会得到诸如「user_id：用户的标识符」这种废话。Agent 本来就看得出这列叫 user_id，它真正需要知道的是怎么用：该和哪张表 join、能不能为空、它代表玩家还是账号、不能和哪些其他 user_id 混用。

「能读懂模型的 AI，只能复述模型。」这位工程师总结道——代码在向它自己解释它自己，形成一个信息量为零的闭环。描述必须来自真正懂业务语义的人。（以上复盘综合自 dbt 社区的公开工程实践，其核心观点与 dbt Labs 官方 MCP 项目 dbt-mcp 的文档及博客中「schema.yml 即 Agent 提示词」的论述一致，可参见：github.com/dbt-labs/dbt-mcp）

这里有一条正在成型的产业逻辑：当 Agent 成为数据的主要消费者，元数据工程就变成了提示词工程。 过去 dbt 描述写给同事看，写得糙一点，人脑能脑补；现在同样的文本是 Agent 检索和决策的直接输入，第一句话写什么，就决定了它选哪张表。文档不再是可以延期的「软任务」，而是数据资产里优先级最高的部分之一。

🧩 六阶段数据旅程：厂商正在把 harness 平台化

有人自己攒车，就有人开始造流水线。

阿里云在云栖大会上发布的 Context Engine 展示了一条完整叙事：打通 Agent 数据旅程的六个阶段——多模态数据入湖、语义抽象、上下文装配、实时计算、记忆管理、自然语言访问。其官方表述相当直白：企业全域数据不再是静态资产，而是 Agent 可理解、可调用、可持续进化的实时上下文。（来源：阿里云云栖大会官方发布材料，见 aliyun.com 及云栖大会官方渠道新闻稿）

把这张图和前面 harness 的定义对照着看，会发现高度重合：语义抽象对应「Agent 需要知道的口径与语义」，上下文装配对应「它读什么指令」，记忆管理对应「它在步骤之间记住什么」，实时计算对应「它能调哪些工具」。区别在于——这些过去要企业一个个手搓的环节，正在被云厂商打包成平台能力。

这说明两个趋势正在合流。一是湖仓、数据平台的建设重心，正在从「把数据存好」转向「把数据变成 Agent 可调用的上下文」；二是 harness 的通用层（存储接入、语义索引、上下文组装、记忆）会逐步下沉为基础设施，由云厂商提供。换句话说，厂商造的是底盘和传动系统，而方向盘往哪打——你的业务规则和口径——依然握在你手里。

对企业的直接启示是：不要试图自研全部六段旅程，那是重复造轮子；但也不要以为买了平台就万事大吉，语义和口径这两层，供应商永远替你写不了。

🛠️ 企业自建五件套：按这个顺序上

那么企业自己到底要补什么？综合一线实践，是五件事，且讲究先后顺序：

顺序本身就是策略，随公司数据成熟度逐级加码。用文字把落地节奏说清楚（以下为基于行业实践的示意性建议，各公司应按自身情况调整）：

• 起步期：先把「规则文件」上线。它不需要任何基础设施改造，一份写清楚 Agent 能碰什么、不能碰什么的文档，几天就能生效，是投入产出比最高的一步。
• 成长期：接住起步期暴露的问题，做两件事——建设「指标口径库」，把常用数字的定义收敛到唯一出处；同时接入「只读副本」，把所有 Agent 查询隔离在生产库之外，解除安全团队的后顾之忧。
• 成熟期：当 Agent 开始进入核心决策流程，再上「完成前检查清单」（每个答案出口前必须通过固定校验）和「止问机制与评审」（口径未覆盖时必须停下来问人）。这两件涉及改造 Agent 的决策流程和跨团队口径评审制度，工程量最大，放最后不等于不重要。

五件套各有明确的针对性：规则文件治「乱来」，指标口径治「两个部门两个数」，只读副本治「误写生产库」的安全焦虑，检查清单治「一本正经地算错」，止问机制治「没有口径也硬答」。最后一件事尤其重要，也最反直觉——让 Agent 学会说「这个问题没有定义覆盖，请人来定」，比让它答对一百道题更能建立组织信任。

多位搭过内部 Agent 平台的从业者在公开分享中有一个共识：这五件套加起来的工程量，通常超过接入模型本身的十倍。但它们都是确定性工作——不依赖模型进步，做完就沉淀为企业资产。

⚠️ 信任才是产品力：重新校准你的投入

如果把这五件套放进「技术门槛 × 商业价值」的坐标系里看（以下为示意性论述，而非精确测算），优先级会清晰起来：

规则文件处在「低门槛、高价值」的位置——不需要任何技术改造，见效最快，适合第一天就上。指标口径和止问机制技术门槛更高、商业价值也最高：前者要打通整个语义层，后者要改造 Agent 的决策流程——但恰恰是它们撑起了「可信数字」这条生命线，属于值得长期重投的核心资产。只读副本和完成检查介于中间：门槛适中、价值稳定，是安全与质量的基本盘，不带来惊喜但缺了必出事故。

一句话概括：先用低门槛项建立信任飞轮，再逐级投入高门槛项守住信任底线。

「大家都以为自己在买模型，其实是在买约束。」——这句话在数据圈流传很广（已难溯源到最初提出者，此处作为业内流行语引述）。它背后的道理是：模型越强，harness 的杠杆越大——同样一颗模型，配上一套严格的口径引用和完成检查，产出的可信度可能天差地别。反过来，harness 做得扎实，也让企业不必执着于追逐每一次模型升级：引擎可以换，方向盘和刹车不能换。

对数据行业的从业者而言，这意味着一批新岗位正在浮出水面：写第一句话的文档工程师、定义口径的语义负责人、设计止问规则的产品经理。他们不训练模型，却决定模型在企业里值多少钱。

✅ 写在最后：把方向盘装上，再谈加速

引擎的军备竞赛还会继续，但战场正在转移。下一家向你推销数据 Agent 的供应商，真正该问的不是「用的什么模型」，而是三个问题：

1. 它引用哪个口径？——每个数字是否都能回溯到唯一的、由你方维护的定义？

2. 答完过哪几道检查？——产出在出口前，是否经过固定的校验清单？

3. 什么时候会停下来承认不知道？——口径未覆盖时，它是硬答，还是主动交还给人？

回答得好这三问的，才配开上你的生产环境。这三问也可以直接写进你的采购评估表，作为 Agent 选型与验收的最低标准。

而对数据团队来说，harness 不是 Agent 的附属品。它就是你们过去几年该做而没做完的元数据治理、指标体系和权限管控——Agent 只是让欠账显形了。所以不必焦虑「没赶上模型」，也不必迷信「换个模型就好」：从一份规则文件、一条唯一口径开始，把确定性的事情一件件做完。2026 年，先把方向盘装上，再谈加速。

参考资料

1. Addy Osmani, Agent Harnesses，作者个人博客（addyosmani.com）——「Agent = 模型 + harness」的出处。

2. dbt Labs, dbt-mcp 官方项目及其工程博客中关于「schema.yml 描述即 Agent 提示词」的实践论述（github.com/dbt-labs/dbt-mcp）。

3. 阿里云 Context Engine：云栖大会官方发布材料（aliyun.com 及云栖大会官方渠道）。

4. 文中标注「匿名」或「示意」的引语与排序，系综合技术社区（Hacker News、r/dataengineering 等）多家数据团队的公开复盘整理，无法溯源至单一可查证出处，请读者自行甄别。