数据Agent的胜负手，藏在模型外面

过去一年，几乎每家数据平台厂商的发布会上都有一段'用自然语言查数'的Demo，流畅得让台下CTO们频频点头。但据多位接近头部数据团队的人士透露，这些团队自己评测数据Agent时，问的第一个问题从来不是'接的是哪个模型'，而是'两个指标口径打架的时候它听谁的'。答案大多让人皱眉。

这背后的核心判断是：数据Agent的竞争，模型已经同质化，真正拉开差距的是模型外面那一圈工程——harness。

🚗 引擎再强，没人开着一台发动机上班

Addy Osmani 在他关于 harness engineering 的综述里给过一个流传很广的比喻：一台汽车发动机，独自摆在车间支架上，动力强劲，但毫无用处。只有装上转向、刹车、油路、仪表盘和驾驶座，它才成为一辆车。没有人买一台发动机用来通勤。

AI模型就是那台发动机。它推理快、写查询快，但数据团队每天面对的是另一回事：业务方的口径有一百种理解，数仓里有三个'活跃用户'的定义，副本数据不能随便碰，报表错了要有人担责。把这些约束装上去的，就是 harness——模型读到的指令、允许调用的工具、能触碰的数据边界、步骤之间的记忆、工作必须通过的检查，以及必须由人来拍板的审批点。

一家做电商分析的平台团队曾经演示过典型翻车现场：分析师对着通用Agent问'上个月GMV是多少'，Agent自信地写了一条SQL、跑了、报了一个数。业务会上财务、运营、市场三方各执一词——因为公司内部对'GMV'至少有三种口径：含退款与否、含取消订单与否、按下单时间还是支付时间。模型没有错，是这套缰绳根本没装。

产业逻辑很清楚：当模型能力不再是瓶颈，可信度就成了稀缺品，而可信度是工程问题，不是模型问题。 谁先把 harness 做扎实，谁的Agent才能从Demo走向生产。

🧰 通用缰绳为什么不够：数据工作要加装五件套

你用的Agent工具出厂自带一套通用harness——通用的指令、通用的工具调用、通用的权限模型。写代码、做文档，够用。但数据工作有它特殊的刚性约束，需要自己加装五个部件，而且顺序很重要：

1. 一份它必须遵守的规则文件——哪些口径是权威定义、哪些表可以碰、哪些问题不属于它管；

2. 它必须引用的指标定义——每一个数字都要能追到一条官方口径，而不是模型自己的'常识'；

3. 对数据副本的只读权限——绝不给生产库写权限，不给原始敏感数据；

4. 一份简短的完成前检查清单——答案在'算完成'之前必须通过的那几条校验；

5. 一条'无解即上报'的规则——当没有任何定义能覆盖这个问题时，停下来问人，而不是编一个。

这五个部件拼在一起，构成了数据Agent区别于通用Agent的结构。用一张图看它们如何围绕模型工作：

产业逻辑在于：这五件套没有一件是'AI技术'，全是数据团队干了很多年的老活儿——数据字典、权限管理、数据质量校验、元数据治理。区别只在于，过去这些是给人看的文档和给人用的流程，现在要变成给模型读、模型必须执行的机器可用契约。这是数据治理从'合规成本'变成'AI基础设施'的转折点。

📊 信任的工程学：检查清单比模型参数重要

一位在金融行业做数据平台的朋友说过一个场景：审计部门追查一张口径存疑的报表，追到最后发现，这条分析链路里根本没有'人审'环节——分析师用了AI生成的查询，直接进了周报。事后追责，谁也说不清该找谁。

这正是 harness 里最容易被低估的两件事：检查清单和审批点。前者回答'这个答案够不够格被称为完成'——比如：结果行数是否合理、指标是否命中官方定义、异常值是否经过解释；后者回答'这一步要不要人来拍板'——比如涉及对外披露的数字、涉及跨部门口径变更的结论。

把市面上各类数据Agent方案放到这张图里看，差距就显形了：

右上角的方案未必模型最强，但它们把检查和审批焊进了流程。左下角的方案演示惊艳、上线即事故。决定那个数字能不能被信任的，从来是harness，多于模型。 这句话值得每个准备采购'AI数据分析'产品的团队写在评审文档第一页。

🗺️ 别一次装满：按公司阶段逐件加装

五件套不是一次性工程。按公司数据成熟度的阶段逐步加装，才是现实可行的路线：

起步期的公司，最重要的其实是前两件事：把口径写清楚，把规则立起来。这不需要任何AI投入，但决定了后面所有AI投入有没有意义。成长期的公司开始解决安全问题——只读副本和权限边界，这是数据安全团队最关心的一环。到了成熟期，'无解即上报'和人工审批点才真正落地，因为这时候Agent的产出已经直接进入决策链路，错误成本足够高，兜底机制必须存在。

值得注意的是，这条路线反过来读也成立：一家公司数据治理的水平，看它的数据Agent harness 做到第几步就知道了。 通用Agent一接上就翻车的团队，问题不在Agent，在自己连口径都没对齐。

💡 治理资产变现：harness 是下一个必争之地

把镜头拉远看，harness 工程的兴起，正好接上了中国数据行业过去十年的两条主线：数据中台建设和数据要素流通。中台时代留下的核心资产是指标体系和元数据，要素流通时代强调的是安全可信的消费方式。数据Agent的harness，恰好是这两条线在'AI消费数据'这个新场景下的汇合点。

用一张'问题—方案'图看这个交汇：

对厂商来说，这里的商业逻辑很直白：模型能力大家共享，harness能力是私有资产。BI厂商开始把Copilot往自家指标层上挂，指标平台厂商开始讲'Agent-ready metrics'的故事，云厂商把权限与审计能力包装成Agent安全组件。产品形态会变，但拼的都是同一层东西。

对甲方数据团队来说，harness意味着一个新的分工正在出现——过去招的是数仓工程师和BI工程师，现在需要一个既懂口径治理、又懂Agent行为约束的角色。据多位接近大型企业的观察，已经有团队把'给Agent写规则文件'列成了正式的排期任务，而不是某个工程师的业余尝试。

小结

数据Agent这场竞赛，台面上的叙事是模型能力，台面下的胜负手是harness：一份规则文件、一套可引用的指标定义、一个只读副本、一份完成前检查、一条无解即上报的规则。模型决定Agent能跑多快，harness决定你敢不敢把它的答案写进周报。可以预判的是，未来一两年，'harness工程'会从一篇文章里的概念，变成数据平台的标配产品模块和团队的标配岗位——而到时候回头看，最先跑通的那批团队，赢的不是模型，是缰绳。