上一章说了，Data Agent 的壁垒在底下的分析语言和引擎。这一章钻进这层壁垒内部，拆一句到处都在讲、但很少有人讲清楚的黑话：「结构化 + 非结构化融合分析」。
先翻译两个词。结构化数据就是表格——一行一行、一列一列，数字和短文本，SQL 能算的那种。非结构化数据就是表格之外的一切：PDF 合同、聊天截图、Word 文档、会议纪要。企业的真实信息，大头其实在后者。
所谓「融合分析」，不是一个玄乎的新技术，其实是三种实实在在的形态。搞清楚这三种，这句黑话就再也唬不住你。
形态一：把文档抽成表，交给 SQL 算
第一种：把 PDF、截图、Word 这些非结构化资料抽成表，交给 SQL 算。
逻辑很朴素：SQL 是几十年磨出来的、算表格最可靠的工具，那就别跟它抢活——大模型只负责把「不是表的东西」变成「表」。一百份 PDF 合同，让模型逐份读，抽出「甲方、金额、期限、违约条款」填进一张表；抽完之后，「哪个客户违约风险最高」这种问题，SQL 一秒钟算完，一行都不会错。
分工原则：模型干它擅长的「读懂」，引擎干它擅长的「算准」。模型不碰算术，引擎不碰阅读。
形态二：把企业的「规矩」召回，绑进判断链
第二种更微妙：把企业的口径、规则、经验这些文档知识召回，绑进数据分析的判断链里。
什么叫「口径」？举个例子：「活跃用户」这个词，市场部定义为「月登录一次」，产品部定义为「周使用三次」。同一个词，两套规矩。裸模型算「活跃用户有多少」时，它根本不知道你们公司用哪套规矩，只会猜一个，还猜得理直气壮。
形态二做的事：分析开始前，先把相关的公司文档（口径定义、业务规则、历史经验）检索出来，垫在模型的判断底下。模型算之前先「读了员工手册」，答案自然按公司的规矩来。这一步就是第三章说的「context 组织」在数据领域的具体化——企业的隐性知识，不组织好递给模型，就等于不存在。
形态三：表里的长文本，用大模型 UDF 按行处理
第三种最容易被忽略：表里本来就有的长文本字段，用大模型 UDF 按行处理，产出的还是一张表。
UDF（用户自定义函数）是 SQL 里的老机制：你可以在查询里调用一个函数，对每一行做自定义处理。传统 UDF 只能写死板的规则，比如「把字符串转大写」。现在函数体可以是一次大模型调用——对十万条客服记录逐条调用模型判断「这条是投诉还是咨询」，结果写回新的一列。
注意这个形态的美感：进去是一张表，出来还是一张表。模型被规训成了计算引擎内部的一个零件，处理完一百万行文本之后，下游的 SQL 该怎么算还怎么算。AI 没有颠覆数据分析的流水线，它是作为一个新的「零件型号」插进了老流水线。
大白话：三种形态一句话总结——文档变表（模型读、SQL 算）、规矩垫底下（先读员工手册再答题）、模型当函数（按行处理表里的文本，出来还是表）。共同原则只有一个：让模型干阅读的活，让引擎干算术的活，别让它们串岗。
为什么这三种形态是壁垒
回头看第九章：这三种形态，每一种都要引擎和分析语言原生支持才行——文档抽取要接得上表、知识召回要绑得进查询计划、UDF 要在引擎内部高效调度模型调用。这就是为什么它是「Agent 之下的壁垒」：换个模型，三种形态照旧运转；没有这层引擎，模型再聪明，也只能干第一种里的「读」，后面两头都接不上。
下一章把视野拉回来：不是所有领域的 Agent 都需要这么厚的底座。有的 Agent 几乎是裸的模型在跑——这种差异本身，就是一张有价值的地图。