Agentic × InfiniSQL — 为什么它们天然契合

Agentic 范式的本质是多次调用工具、渐进式探索。InfiniSQL 的 load → select ... as → select ... as 管道式设计，与这一范式形成了精确的结构对齐。

Agentic 循环 × InfiniSQL 同构

Agentic 范式有三个精确特征：多步工具调用、状态累积、动态决策。InfiniSQL 的语言设计与这三个特征一一对齐。

⚡

调用工具

执行 InfiniSQL 语句

📋

获取结果

as newTable

🗂️

状态累积

Session 具名表

🧠

动态决策

Agent 规划下一步

Agentic Loop

每一步都产出具名表

Agentic 范式

Agent 调用工具

发起一次数据操作请求

工具返回结果

获得数据、结构或统计信息

结果进入上下文

成为后续调用可引用的状态

Agent 决策下一步

根据数据现实动态规划方向

→

InfiniSQL 对应

执行一条 InfiniSQL 语句

load / select / connect

结果注册为具名表

select ... as newTable

表在 Session 全局可引用

自动状态管理，无需变量追踪

根据数据生成下一条查询

LLM 只需知道“有哪些表”

8 步 Agentic 探索实录

观察 Agent 如何使用 InfiniSQL 进行渐进式数据探索。每一步产出的具名表自动出现在右侧 Session 面板中，可被后续步骤直接引用。

InfiniSynapse Agent — Agentic 数据探索

STEP 1 — 感知环境

用户让我分析销售数据。第一步，我需要了解当前有哪些数据表可用，以及它们的结构。先列出所有表。

!show tables;

📄 发现 5 张表：orders、products、regions、inventory、promotions

STEP 2 — 理解数据结构

orders 表看起来最核心。在写任何查询之前，我需要知道它有哪些字段、什么类型，避免盲目猜测。

!desc orders;

📋 字段：order_id (INT), customer_id (INT), region (VARCHAR), amount (DECIMAL), order_date (DATE), status (VARCHAR)

STEP 3 — 试探性取样

有 region 和 amount 字段，可以分析区域销售。但先别急着聚合——我先取几条样本数据看看，确认数据质量和实际值的范围。

select * from orders limit 10
as orders_sample;

👀 数据正常，amount 范围 ¥200–¥58,000，region 包含华东/华北/华南/西南/西北，无明显脏数据

STEP 4 — 维度聚合

样本数据确认没问题。现在按region 分组聚合，看各区域的订单量和总金额。这是最常见的分析起点——先看整体分布，再定位异常。

select region, count(*) as cnt, sum(amount) as total
from orders group by region
as region_summary;

⚠️ 华东区 total = ¥12.8M，是第二名华北 ¥4.2M 的 3 倍！订单量占比仅 28%，但金额占比 52%。这个异常值得深入。

STEP 5 — 异常下钻

华东区金额异常偏高。可能是少数大额订单拉高了均值。我需要看华东区的具体订单明细，按金额降序排列，找到那些大额订单。Session 里已有 region_summary，现在再切一张新表。

select * from orders where region='华东'
order by amount desc limit 20
as east_china_detail;

🔍 前 20 笔订单金额在 ¥28,000–¥58,000 之间，customer_id 高度集中在 5 个客户。需要了解这些客户的属性——但客户表不在当前数据源。

STEP 6 — 动态接入新数据源

要分析这些大额客户的特征，需要客户维度数据。客户表在另一个数据源——云端 PostgreSQL 上。我可以直接用 connect + load 把它接入当前 Session，和已有的 east_china_detail 做 JOIN。

connect jdbc where
url="jdbc:postgresql://cloud/analytics"
and driver="org.postgresql.Driver"
as pg_cloud;

load jdbc.`pg_cloud.customers`
as customers;

✅ 云端 PostgreSQL 已接入 Session。customers 表包含 customer_level、industry、city 等字段。现在可以跨源 JOIN 了。

STEP 7 — 跨源关联

现在 Session 里同时有 MySQL 的 east_china_detail 和 PostgreSQL 的 customers。直接LEFT JOIN——把客户等级和行业信息关联上，看看大额订单是不是集中在特定等级的客户。

select e.*, c.customer_level, c.industry
from east_china_detail e
left join customers c on e.customer_id = c.id
as east_with_customer;

🔗 跨源 JOIN 完成（MySQL × PostgreSQL）。20 条记录中，18 条成功匹配客户信息。发现大额订单客户均为 VIP 或 SVIP。

STEP 8 — 得出结论

数据已经很清晰了。最后一步：按customer_level 分组统计，量化不同等级客户的贡献差异。引用 east_with_customer 即可，前面所有探索结果都在 Session 里。

select customer_level,
avg(amount) as avg_amount,
count(*) as order_count
from east_with_customer
group by customer_level
order by avg_amount desc
as final_insight;

✅ 分析完成 — SVIP 均单价 ¥52,300 是普通客户 ¥12,400 的 4.2 倍。华东区金额异常的根本原因：SVIP 客户集中在华东，且客单价远超其他等级。

Session 表空间

所有表在 Session 内持久存在，可被任意后续语句引用。

Python 编程 vs InfiniSQL 查询

同样是 Agentic 多步探索，两种工具语言的结构性差异决定了完全不同的效果上限。

Python / pandas

Agent 当程序员

✕状态脆弱 — DataFrame 变量在代码块间不天然共享，LLM 须记住所有变量名，易冲突、易遗忘
✕错误面大 — 涉及 API 调用、类型处理、异常捕获，bug 类型多样且难以自我修复
✕内存天花板 — 数据必须拉到内存做 merge，32GB 沙箱下百万行即卡顿
✕一次性代码 — 每次对话的中间结果无法沉淀，探索资产不可复用
✕认知负担重 — 几百个 pandas API + 参数组合，LLM 选择空间爆炸

InfiniSQL

Agent 当分析师

✓天然状态累积 — 每条 select ... as 自动注册具名表，Session 全局可见，无需变量管理
✓极低错误率 — 声明式语句 + 强约束语法 + 为 LLM 设计的错误提示，Agent 几乎不出错
✓分布式引擎 — 跨源 JOIN 在引擎层完成，计算下推到数据源，无内存瓶颈
✓探索即资产 — 所有具名表持续存在，随时可回顾和复用之前的探索成果
✓认知负担极低 — 几个关键字 + 标准 SQL，LLM 训练数据天然覆盖

10%

Python 每步错误率

10 步全对概率仅 35%

~2%

InfiniSQL 每步错误率

10 步全对概率 82%

5×

探索链条可拉长倍数

更深入的分析洞察

七维对齐总览

InfiniSQL 的每一个语言特性，都精确回应了 Agentic 范式的一个核心需求。

Agentic 需求	传统方式的困境	InfiniSQL 的设计
多步调用	每步输出无统一管理方式	`select ... as` 自动注册具名表
状态共享	变量命名空间冲突、易遗忘	Session 级表空间，全程持久可见
动态数据源	需要预配置连接库和 ETL	`connect` + `load` 即时注册
低错误率	API 多、类型复杂、异常频发	极简语法 + 强约束 + LLM 友好提示
自我纠错	修改代码 → 重跑全流程	一条新 `select` 即可覆盖
大规模数据	单机内存瓶颈（32GB）	分布式引擎 + `directQuery` 计算下推
跨源融合	拉数据到内存 → merge → OOM	语言层原生跨源 JOIN

InfiniSQL 不是又一个 SQL 方言——它是一门为 Agentic 工具调用范式量身定制的数据探索语言。它没有试图让 Agent 成为更好的程序员，而是让 Agent 成为更好的分析师。