- 采访者：PythonMiao
- 受访者：祝威廉（InfiniSynapse 联合创始人）
- 时间：2026 年 7 月 22 日
- 本文根据访谈逐字稿整理成文，在不改变原意的前提下做了删节与校订。
提到"AI 数据分析师"，大多数人脑子里浮现的是一个聊天框：丢进去一个问题，吐出来一张图表。
祝威廉不这么看。作为 InfiniSynapse 联合创始人，过去两年他的主要精力都放在这个产品上——一个从"AI 数据分析师"出发、一路往下长的东西。
这场对话有三条主线。
第一条是产品：为什么单独一个 Agent 做不成数据分析师？InfiniSynapse 往下长出了分析语言、执行引擎和记忆体系，这三层各自解决什么问题？
第二条是生意：为什么他们不再把宝押在"卖订阅给终端用户"上，而是转身去服务做应用的开发者？
第三条是差异：面对 Cortex Analyst、Genie、Fabric Data Agent，他们怎样用存储中立、语言中立的中间层，以及 GA360 的 harness 压缩案例，说明自己的位置？
本期看点：
- 一次真实的分析请求，如何从一条 SSE 长连接，一路走到图文并茂的 PDF 报告；
- 结果凭什么可信：小步快跑，加一张可视化的数据血缘树；
- 财务和销售对"营收"的定义打架时，记忆如何"先确认、再沉淀"；
- 客户画像的转变：从订阅用户到应用开发者，一个 to 小B 的生意；
- 计价方式：账号数为主、项目交付为辅，推理用企业自己的模型；
- 相对云厂商 Data Agent：存储中立、语言中立，以及跨源联邦计算怎么做；
- InfiniSQL 模板如何把 1713 行分区表查询压到 52 行；
- 为什么现在愿意接受采访：企业部署、赛事应用，以及"数据分析应用"的下一步。
一、单独一个 Agent，是不够的
**PythonMiao：**我们来聊聊 InfiniSynapse 是怎样从"AI 数据分析师"走向一套完整的数据基础设施的。这个变化听起来很大，能不能先讲讲：为什么要做这个延伸？
**祝威廉：**提到"AI 数据分析师"，很多人想到的可能只是一个 Agent。但我们认为单独一个 Agent 是不够的，所以一直在往下延伸。
第一是分析语言。既然要做数据分析，我们就为它做了配套的 InfiniSQL——一门专为数据分析设计的语言。
第二是执行引擎。语言需要引擎来支撑，解决不同数据源的接入和混合计算问题。
第三是记忆体系。有了语言和引擎之后，我们还希望这个分析师是个性化的、有记忆的。我们做了一个 Context/Hub 模块，把分析师和人的所有交流沉淀到企业、沉淀到组织里。用户会发现它越用越聪明，每一次对齐都有沉淀、有记录。这背后是我们比较强的第四代 RAG 技术。
综合起来，它实际上是一套覆盖 Agent → 分析语言 → 执行引擎 → 记忆体系 的数据基础设施。在此之上我们还提供 API，提供类似扣子（Coze）那样的应用界面；最近也在举办赛事，鼓励开发者开发应用——应用里需要数据分析师能力时，直接对接 InfiniSynapse 就可以。
二、一次分析请求，是怎么走完全程的
架构讲完，PythonMiao 把问题落到了一次真实请求上：从应用界面进来的一个问题，究竟经历了什么？
**PythonMiao：**我们拿一次真实的数据分析请求走一遍：它从应用界面进入之后，如何依次经过服务端、运行时、InfiniSQL 或 RAG，最终把结果和记忆写回工作空间？
**祝威廉：**具体是这样的。用户输入一个问题后，前端会开辟一条 SSE 流式长连接到我们这边，Agent 接收后开始处理任务。
第一步，小步探索。处理过程中，Agent 会生成很多条 InfiniSQL 语句进行探索，交给引擎去执行。
第二步，中间结果由引擎记住。每一步产生的中间结果，引擎会以命名表的形式记下来。Agent 只要看到表的结果，下一步就可以直接引用这张表继续迭代——这就是我们说的 Agent 友好的语言。
第三步，知识库补齐上下文。过程中如果涉及用户偏好、指标定义、表的业务信息，Agent 可以到知识库里去获取。
第四步，自我验证。得到结果之后，Agent 会先做一轮自我验证。
第五步，生成交付物。最后按用户要求交付。如果用户要 PDF 报告、表格或者 Word，Agent 会调用我们开发的大约四个转换工具来完成，格式很漂亮、图文并茂，最终把结果回传给应用端。
业务 App / BFF（表单、鉴权、业务编排）
→ InfiniSynapse Server API（SSE 长连接 + 任务接口）
→ Agent Runtime（规划、推理、工具调用）
→ InfiniSQL + 跨源执行引擎（中间表可复用）＋ InfiniRAG（口径、偏好）
→ 任务工作区（Markdown、图表、PDF、Word 等交付物）
→ 回传应用端呈现
我们提供的 API 不只是发起任务，还可以做控制——比如指定使用什么模型。也支持租户与子账户：你在我们这里注册一个租户后，可以通过 API 创建子账户，实现用户之间的隔离。所以对应用开发者是非常友好的。
三、凭什么相信结果
应用开发者接入的不只是一个返回文本的聊天接口，而是一套能执行计算、复用中间结果并交付正式文档的多租户分析服务。接下来的问题是可信度。
**PythonMiao：**当 Agent 做跨源计算、反复引用中间表，并声称已经"自我验证"时，系统究竟依据什么标准判断结果可以交付？
祝威廉：AI 在我们的基础设施上做分析，是小步快跑的。举个例子：要基于多张表得到一个计算结果时，它是探索式地往前走的。我们提供了一个可视化的数据血缘界面，你可以看到 AI 在不断做抽象——基于原来的两三张表得到一张新表，这张新表又和另一张抽象出来的表组合出下一张新表，不断抽象，最终展开成一棵树状结构，走到最后的结果。
这样设计的好处有三个。
一是每一步都足够简单。每一步有明确的目标和预期结果，AI 不太会犯大的逻辑错误，人来验证也非常方便。
二是错误主要不在计算。目前很少遇到计算层面的问题，偏差一般出在对用户定义（口径）的理解上——这正是靠知识库来弥补的。
三是人做宏观的二次校验。AI 终究会有和人一样的问题——它以为自己是对的时候，自己是查不出错误的。但因为整个过程被拆得很简单，人只需要看一遍宏观的数据脉络是怎么展开的，就能快速做二次校对；细节里基本很难出错。
所以可信度并不建立在"AI 永远不会错"上，而是把复杂分析拆成可追溯的小步骤，让人能快速校验整条数据脉络。
一次任务完成后，工作区里能看到完整的交付物文件：
四、两个部门口径打架，记忆怎么沉淀
**PythonMiao：**如果两个部门对同一个指标有不同定义，系统如何判断该采用哪套口径，并避免一次错误纠正被沉淀成组织记忆、影响后续分析？
**祝威廉：**不同部门的口径确实可能不一样，比如财务和销售对"第一季度营收"的定义就常常不同。典型过程是这样的。
先是发现。财务的人来用系统，他对数字是有敏感度的——如果系统给的是销售口径，他很容易看出数据不对。
然后是纠正。这时只要告诉 AI 正确的定义，比如"打进我们账户的钱才算营收"。AI 发现自己被人纠正了，就意味着此前和人没有对齐、信息不够。
最后是确认后沉淀。AI 会主动触发一次对齐沉淀，由财务的同事确认这个对齐是否正确。确认无误后，才把它沉淀到组织记忆里，去影响后续的分析。
另外，我们所有的对话其实都可以通过知识库召回。哪怕某次聊过的事情最终没有被沉淀进 Hub，也可以通过全局记忆召回，确保你之前提过的事情这一次依然有效。定义、偏好这类沉淀，具体做法都是这样。
五、没被确认的对话，会不会污染别人的分析
记忆被分成了两层：经过确认的组织知识，和仍可被检索的历史对话。PythonMiao 追问了后者的边界。
**PythonMiao：**在企业场景里，未经确认的个人对话如果也能被全局召回，系统怎样控制它的权限和可信度，避免错误口径或敏感信息影响其他人的分析？
**祝威廉：**首先，未经确认的信息不会进入我们的 Hub。其次，在召回历史对话时，从上下文能看出一条信息当时是被肯定还是被否定的：如果明显错了、用户直接否定或者放弃了，或者没有得到用户肯定的答复，我们就不会使用这条数据，AI 也能够识别。因为我们的召回是基于第四代 RAG 知识库实现的，召回的准确率和智能水平非常高，一般不会出现你说的这个问题。
**PythonMiao：**如果把"通常不会出问题"变成企业可验收的指标，你们现在用怎样的可复跑测试，衡量正确记忆被召回、错误记忆不污染答案的能力？
祝威廉：就像刚才说的，我们在这个体系里已经引入了用户确认这个机制。这套机制可以确保：用户确认过的内容，一定可以被召回，而且满足用户需求。这个问题我们也可以从发展的角度去看，不一定只讨论这一点。
六、客户画像变了：从订阅用户，到做应用的开发者
聊完产品，话题转向生意。这也是整场访谈里，祝威廉给出的信息量最大的一段回答。
**PythonMiao：**随着 InfiniSynapse 从单一的 AI 数据分析师扩展到数据引擎、组织记忆、API 和应用分发，你们今天最核心的付费客户画像，和最初相比发生了什么变化？
**祝威廉：**这个问题非常好。AI 时代商业模式和用户行为的变化非常快。
五六个月前，我们认为核心用户画像是普通的订阅用户——像订阅其他 AI 工具一样，按月或按年付费；企业有需求时，则通过项目制或订阅制购买。
到今天，情况变了。随着 Claude Code 这类产品的发展，以及大厂对自家 AI 应用的强烈补贴，你很难再靠"帮用户分析一个 Excel"这类场景卖订阅——已经订阅了那些产品的用户，不太会再订阅你。而真正要分析数据的用户一般在企业里，企业数据很难被授权给外部访问，必须在企业内独立部署才能真正使用和分析。
所以我们最终决定：核心群体是做应用的开发者。他们做应用去服务自己的企业客户或 C 端客户，我们把能力（API）提供给他们。
逻辑很简单——你做应用时，不会因为要用数据库就自己开发一个数据库；同样，需要数据分析能力时，也不应该自己从头开发一套。我们希望未来所有需要数据分析能力的应用都直接使用我们：SaaS 是默认形态，需要私有化部署我们也提供支持。这样我们就变成了一个 to 小B 的模式。
七、账号数为主，项目交付为辅
**PythonMiao：**在这套 B2B2C 模式里，你们准备把收费锚定在哪个价值单位上，才能既覆盖推理和私有化成本，又让开发者随着业务增长愿意长期付费？
**祝威廉：**先说成本：推理我们依然采用企业内部自有的模型来完成，不提供推理模型的部署和服务——用企业已有的就好；如果企业不介意使用第三方模型服务，那也可以。
关于长期付费，我们的认知是：企业终究有一个过程，他们希望快速验证一件事情的可行性、看它是否真的能帮到自己的业务。在这个阶段，用我们的产品是很好的选择。如果他们验证之后发现收益确实非常大，并且愿意投入开发力量自己做一套类似的体系，我们也是 OK 的。
一个商业模式未必要覆盖企业的全生命周期——能帮到每一个企业的每一次探索、或者让某个业务真正落地，我觉得就已经足够好了。
**PythonMiao：**那具体到成交方式：账号、调用量、项目交付、私有化授权、业务结果，核心计价单位是什么？
**祝威廉：**仔细算的话是两点。
第一，核心计价单位是账号数。对能接受账号制的客户，按企业里有多少人用来定价；也有一部分是项目制，走项目交付。不同业务形态会采用不同的计价方式，但账号数会是主流。
第二，效果必须胜出。最终用户会不会买单，归根到底还是看业务结果——我们的分析效果一定要比其他所有 Agent 产品好，否则很难回答"用户为什么买你，而不是自研或用第三方"。
八、和 Cortex / Genie / Fabric 比，差在哪一层
**PythonMiao：**面对 Cortex Analyst、Genie、Fabric Data Agent 这些成熟参照，如果只能选一个独立、可复跑的测试，你们会用什么结果证明 InfiniSynapse 的优势？
**祝威廉：**直接做一对一对比其实很难。换一个角度会更清楚。
Cortex Analyst、Genie 分别和 Snowflake、Databricks 自家产品绑定，底层也更贴近自家数仓。Fabric Data Agent 相对更靠中间层一些——可以同时连多种地方的数据做联合分析——但仍然主要停在这一层。
InfiniSynapse 的选择不同：存储是中立的。你可以用我们的存储，也可以不用；直接做联邦计算也可以。真正难、也真正有价值的事情，往往不是"所有数据都已经在一个仓里"，而是数据散落在不同角落，你还要找到它们之间的关联，并且算得出来。比如把网页或互联网上抽出来的表格信息，和业务数据库里的数据做关联分析——这体现的是我们不太区分底层数据源，更接近一种存储中立的分析底座。
其次是中间的 InfiniSQL：它本身也是语言无关的，不绑定某一种数据库方言，而是提供一层对 Agent 友好的中间语言。
九、1713 行压成 52 行：压的是查询表达，不是原始数据
**PythonMiao：**那能不能用 GA360 那个从 1713 行归约到 52 行的案例，具体说明 59.4:1 的字节压缩是怎样实现的，又保留了哪些分析信息？
祝威廉：这个案例来自我们跑过的一个 GA360 / Spider 类任务。数据里有大量分区表——规模太大，没法塞进一张表，只能按天切开。可一旦要对最近一年做处理，就可能要关联 365 张表，语句会变得又长又淡：哪怕上下文窗口已经到百万 token，一条 SQL 也可能占掉相当大的比例，而且很难在 Agent 层面做压缩。
所以我们觉得应该在语言层做 context：让 InfiniSQL 更简单，同时表达更多含义。做法是引入类似模板的能力，用简单的循环把重复结构压进去，又不削弱表达能力。加了这一层之后，原生 SQL，以及带变量的 InfiniSQL，都可以跑在我们的引擎上，从而实现很高的压缩比——那个案例本身就是分区表带来的几千行重复。
**PythonMiao：**所以这里压缩的不是原始数据，而是 Agent 需要生成和理解的查询表达：用循环与模板替代数百张分区表上重复的 SQL，再交给引擎执行。那在 59.4:1 这个数字之外，你们怎样验证 52 行版本与 1713 行原始 SQL 在结果上完全等价？
**祝威廉：**因为最后执行结果是一致的。设计上，引擎会在语法层先做一次展开，展开后的表达和原生 SQL 保持一致，所以底层执行结果也一定一致。
十、两个彼此隔离的数据源，JOIN 怎么做
**PythonMiao：**再往前一步，在两个彼此隔离、原始数据又不能集中搬运的数据源之间做 JOIN 时，InfiniSynapse 具体怎样完成这次联邦计算？
**祝威廉：**底层引擎本身就能做跨源计算。它把不同数据库当成不同的数据源，按需要去拉取数据；但对单库和多库，优化策略不一样。
单库：如果只连一个数据源，我们会尽量把计算全部下推到底层。而且因为 InfiniSQL 鼓励小步语句——不必让 AI 一次性写出非常复杂的大 SQL——多条小语句最终可以等价于一条复杂查询，既减轻 Agent 的写作负担，又能完整下推。
多库：会尽可能让计算沉到底层数据源；最后需要融合的结果再拉取过来。数据不是完全堆在内存里，也会落盘。语义上仍然等于 SQL 的 JOIN 语义，而不是传统那种"先把数据全搬过来，再写一段代码做统计和融合"。下推本身属于引擎优化，我们也搭配了 Agent 的智能识别，让下推效果更好。
十一、为什么现在愿意聊：部署、赛事，以及"数据分析应用"
**PythonMiao：**你为什么现在想聊 InfiniSynapse？这里面真正让你在意的变化是什么？
**祝威廉：**主要是因为产品已经在十几个企业里做过部署验证；同时我们最近在办 Vibe Coding 大赛，已有二十多个应用接入、以 InfiniSynapse 为底座。我觉得打磨得差不多了，可以真正面向市场。
大家还可以关注我之前提的一个概念：泛数据分析应用。它实际上是把分析能力从企业带到普通市场——你可以很快给你的用户提供一个分析师，帮他完成日常购物、选专业、填志愿这类生活决策。普通人生活里的许多选择，其实都可以用这种分析师能力来辅助。
**PythonMiao：**那你们把一个应用认定为"真正接入并验证通过"的最低标准是什么，而不是只完成报名、填写地址或跑通一次演示？
**祝威廉：**标准可以宽一点：真正把应用创建出来并接通、跑过测试，或者已经直接提供给终端用户使用，我认为这些都算。
**PythonMiao：**假设一年后再回看，哪一个可量化的结果会让你确信"数据分析应用"已经从比赛和演示走向真实市场？
**祝威廉：**非常感谢。这个问题，让我们一起来期待。
InfiniSynapse 体验入口：国内站 app.infinisynapse.cn，国际站 app.infinisynapse.com；开发者 API 与更多信息见官网 www.infinisynapse.cn。Vibe Coding 大赛作品见 比赛作品长廊。