崔京把大模型比作风筝：风给它升力，但线必须攥在人手里。在 AskTable，这条“线”被拆成三段——人机协同的指挥棒、Scope 限定的护栏、任务拆解的流水线；Agent 只负责可验证的代码与图表，计算与决策权仍留在人手中。于是，财务月报这类高敏场景既能享受 10 倍效率，又保持 99% 以上准确率。下一步，他要把这根“线”做成可持续进化的知识链，让企业的每一次判断、每一次修正，都变成 Agent 下一次起飞的更强风场。
在2026年1月16-17日北京AgenticAISummit超级智能体系统架构大会上，崔京老师会在现场分享打造沉浸式的 Vibe Analyzing 体验——AI 驱动的数据分析新交互的话题，介绍基于 Agent 技术的AskTable是如何重构了数据分析交互，并带来连续、直观的分析体验。以下是会前采访，提前了解崔京老师的演讲思路。
1. 您提到“AI 的创造力必须被引导，而非放任”，那么在 AskTable 中，您是如何通过技术手段为 AI 划定‘创造力边界’，确保数据分析结果既具创新性又高度准确的？能否结合具体技术实现（如代码生成、验证机制）举例说明？
崔京：我们一直强调，AI 的创造力必须被引导，而不是放任。一个很形象的比喻是放风筝：风可以把风筝吹上天，但如果没有人适时牵引和调整，风筝既飞不久，也飞不高。现在的 AI 应用也是一样，AI 很强大，但它需要人在关键节点给它方向和边界。
在 AskTable 里，为了让 AI 在数据分析中既有创造力又不失准确性，我们做了几层技术和产品上的设计。
第一层是产品机制上的“人机协同”。在 AskTable 的产品设计中，我们其实经历了一个根本性的思维转变。过去做产品，变量只有一个，就是用户，所以会强调「以用户为中心」。但现在的产品世界里，除了用户，还有一个新的变量——AI。AI 不是工具栏上的一个按钮，它也是有思考有行动的“角色”。也因此，传统的“以用户体验为中心”需要升级成“以用户牵引为中心”的设计方法：用户不再是操作执行者，而是一个指挥家、思考者、引导者；AI 则是能力被放大的执行体。
第二层是技术上的边界控制。我们会明确限定 AI 的 Scope，例如它能用哪些数据表、哪些字段、可以引用的数据范围，以及报告生成必须遵循的内容结构。例如在底层提示里，我们会告诉模型：“你只能使用这三张表；报告必须包含四个部分”；甚至会给出示例框架。通过这些结构化的约束，AI 的自由度被压缩在一个安全区间内，幻觉概率会显著降低。
第三层是把大问题拆成小任务，让 AI 只做它擅长的部分。一句“帮我做个用户增长看板”的需求，如果直接交给 AI，非常容易跑偏。我们会复盘人工流程，把整个工作拆成多个步骤：理解需求、写 SQL、清洗数据、生成可视化、排版输出。然后把这些可标准化的步骤全部 AI 化，让 AI 专注在可自动化的任务上，剩下需要业务判断的部分交给人。这种方式不仅重构了传统分析流程，也让 AI 的创造力更可控。
通过以上这三层设计——人机协同、Scope 限定、任务拆解——AskTable 实现了一个非常重要的目标：让 AI 成为数据分析师的能力放大器，而不是一个不可控的“自动化生成器”。在清晰边界之内，AI 的创造力可以最大化释放；超出边界的部分，则通过机制与验证来确保准确性。
立即报名参会
2. AskTable 的 Agent 技术架构如何支撑‘Vibe Analyzing’的沉浸式体验？在‘AI 数据画布’的实时交互中，Agent 如何协调自然语言理解、SQL 生成与可视化渲染的多步骤任务？
崔京：当我们谈到 AskTable 的 Vibe Analyzing，其实谈的是一种“沉浸式思考”——用户像在画布上与数据即时对话，而不是在等待一段黑箱式的计算结果。要支撑这种体验，我们在 Agent 技术架构上做了三层关键设计。
第一层是实时性。
沉浸来自节奏，而节奏来自速度。无论是自然语言理解、SQL 推理，还是图表渲染，我们都要求 Agent 分阶段、实时地把思考反馈给前端——不是“等全部算完再告诉你”，而是“我现在理解到哪一步，你立即就能看见”。
用户的探索思路不能被中断，这也是为什么我们优先追求低延迟，而不是盲目追求炫技式的大模型特效。
第二层是原子化的任务组织。
在 AskTable 的 Canvas 上，每一个 Node 对应的是一个“原子 Agent”，它只负责一个明确、可控的子任务：理解问题、生成 SQL、做清洗、跑统计、渲染图表等。
我们并不希望几个 AI 自行生成庞杂的协作链条；相反，我们把它拆成“人类可审阅”的碎片化步骤。原子化带来的好处是：可靠性高、可追踪性强，用户永远知道现在是哪一步在工作，而不是面对一个不可控的黑盒。
第三层是可组合性。
当所有输出都以“原子块”的形式存在，用户就可以像搭积木一样，把多个 Node 组合成一个新的上下文，让 Agent 在此基础上继续推理。
也就是说，一个图表既是屏幕上的可见元素，也是 AI 的输入语境。用户可以选择多个节点，把它们组合成一段新的“思考链”，让 Agent 继续分析、生成更深层的洞察。这也是为什么我们把 Canvas 视作一种“可视化的 Context Engineering”。用户不是在使用工具，而是在构造 AI 理解世界的方式。
总结来说，AskTable 的 Agent 架构并不是在追求“让 AI 代替人工作”；它在追求的是“让人类与 AI 在同一个思维画布上共创”。实时性维持沉浸、原子化确保可靠、可组合性释放创造力——三者一起，让 Vibe Analyzing 成为可能。
3. 传统 BI 工具常因数据模型复杂、查询逻辑僵化导致用户体验割裂，而 AskTable 通过 Agent 重构了交互流程。您认为 Agent 技术相比传统规则引擎或固定看板的核心突破点是什么？
崔京：传统的 BI 工具通常遵循一条固定流程：原始表 → 构建数据模型 → 创建固定看板。
也就是说，在用户开始使用之前，所有模型、指标、报表都必须提前设计好、搭建好。这种方式本质上是繁琐的，也是缺乏灵活性的，因为一旦业务变化或用户提出新的问题，原有看板往往无法满足，还需要重新建模、重新出报表。
AskTable 采用的是完全不同的范式：原始表 → Agent 即时生成。用户在问问题的当下，Agent 才根据原始表自动生成所需的 SQL、图表和分析结果。无论用户想查什么，只要数据表存在，就能即时得到答案。这种“用的时候才生成”的能力，是 Agent 技术相较于传统规则引擎或固定看板最大的不同，也是它的核心突破点。
这种范式的转变，也带来了数据权限管理方式的变化。过去只需要对已经生成好的看板或报表设置权限，本质上是对“产出物”设置权限。而现在的生成式看板是即时生成的，无法对还没产生的产出物预设权限，因此权限必须前移——回到更上游的原始表层面去管理。
总结来说，Agent 的突破点在于即时生成带来的灵活性。
立即报名参会
4. 在央国企、金融等对数据安全要求极高的场景中，AskTable 如何平衡 Agent 的自动化决策与人工干预（如专家定义指标）？是否存在‘人机协同’的标准化流程或评估体系？
崔京：在央国企、金融这些对数据安全和准确性要求极高的场景中，AskTable 始终坚持自动化与人工干预并重的原则，并在不同产品中形成了清晰的“人机协同”路径。
在 AI 引擎（一个以结构化数据为中心的智能体平台）里，我们为客户建立了一套标准化的前置流程。
首先，数据专家会定义数据表和字段的含义，也就是元数据，让 AI 充分理解数据本身；
其次，业务专家会定义业务术语与偏好，使 AI 能按照企业内部的语境理解问题；
然后，数据专家会做必要的评测，确认 AI 的回复逻辑和输出符合业务要求。
这些动作都是事前完成的，并且已经在产品中被设计成一套固定流程。通过这套前置校准机制，确保了 AI 在业务人员真正使用时可以简单、顺滑，不会给终端用户增加额外成本。
而在 AI 画卷（一个面向数据分析师的 AI 应用）中，人机协同的比例会显著提高。
分析师需要在使用过程中参与关键环节的判断，例如：
当 AI 自动生成 SQL 时，人需要检查 SQL 的逻辑；
当 AI 执行 SQL 并返回数据时，人需要确认数据是否合理；
每一个 AI 动作的末端都有一个人工确认点，确认无误后才进入下一步的数据处理、可视化或分析环节。这种协作机制确保了在高要求场景下，生成式分析既高效又可靠。
整体来看，我们并不是用 Agent 去替代人，而是让人机各自发挥特长：AI 提供自动化、流程化的能力，人提供判断、审核和方向性输入。通过前置标准化流程与事中协同机制，AskTable 能够在高安全场景下实现既智能又可控的分析体验。
5. 您曾强调‘数据准确率是准入要求’，但大模型本身存在幻觉风险。除了‘AI 只生成代码，系统执行计算’的隔离机制外，AskTable 是否引入了其他技术创新（如动态校验、多模态验证）来进一步提升 Agent 输出结果的可靠性？
崔京：当我们强调 AskTable 的“数据准确率是准入要求”时，我们关注的不只是模型幻觉，而是从“能否执行”到“是否符合理业务规则”的一整套可靠性工程。因此，我们把准确率问题拆成两个阶段解决：配置阶段的系统化校验与运行阶段的轻量策略。
在配置阶段，我们投入了最核心的创新。AskTable 使用自研的 SQL 编译器与语义模型组成“双重校验体系”：编译器负责语法与结构化规则，模型负责业务语义与意图校验。企业用户还能通过字典、术语、半结构化规则、示例问答等方式，把业务知识沉淀成可复用的测试集。所有配置都会自动进入持续集成式的验证流程，运行中的错误也会反馈回测试池，让系统的可靠性不断增强。
这意味着：准确率不是在运行时“补救”，而是在工程层面被提前构建出来。
至于运行阶段，我们保持克制。交叉验证确实是一个技术选项，我们也做过多模型互校的实验，但成本高、复杂度大，而且同一模型系列难以纠正彼此偏差，因此在实时交互场景中收益并不显著。不过，如果企业确有特殊需求，我们仍然可以提供。多数情况下，我们选择让 Agent 主动澄清不确定性，并在速度、成本与准确率之间让用户灵活切换策略。
最终，AskTable 的方法论非常明确：把准确性前置工程化，把业务规则结构化，把验证体系持续化，而把运行时校验保持为辅助机制。这让我们能够在大模型仍有不确定性的时代，提供可控、可审计、真正可信赖的数据分析体验。
立即报名参会
6. ‘Vibe Analyzing’概念强调‘连续、直观的分析体验’，这是否意味着 Agent 需要具备记忆能力以支持多轮对话上下文？AskTable 如何管理 Agent 的会话状态，避免因上下文丢失导致分析逻辑断裂？
崔京：“Vibe Analyzing” 的核心是一种连续、直观、不被打断的分析体验。但这并不等同于传统意义上的「大模型长记忆」。我们更关注的是：如何让分析链路保持连贯、上下文不丢失、逻辑不走样。
在 AskTable 中，我们将 Agent 的会话状态拆成三类来管理：
第一类是用户可见的上下文。
比如节点、图表、已执行的查询、数据片段等，这些都以“原子节点”的形式保存在 Canvas 上。每个节点既是界面元素，也是 Agent 可引用的计算上下文。
这种结构让用户的思路永远可见、可追溯，不依赖模型自身的短期记忆。
第二类是系统管理的过程性上下文。
例如当前任务的语义意图、字段推断、数据约束、执行历史等。
这些信息被封装为结构化状态，并在任务链路中显式传递，而不是隐式塞入大模型的 Prompt 里。这避免了大模型在长对话中出现“上下文漂移”。
第三类是业务规则层面的持久语义。
包括字段词典、术语、示例与业务规则，这些是跨会话长期有效的。
它们不会作为“记忆”混入模型，而是作为约束条件在每轮推理前被结构化引入，从根本上减少模型忘记规则或解释不一致的可能性。
基于这三层结构，AskTable 选择了一条更可控的路径：不是让模型自己去“记住”什么，而是让系统把可见逻辑、推理链路与业务规则结构化持久保存。
这样带来的好处是：
1. 多轮分析可以任意跳转，不会因模型忘记上下文而断链。
2. 复杂任务可以拆解成稳定的原子 Agent，不会因为上下文膨胀而失真。
3. 用户始终能看到 AI 的每一个推理节点，而不是面对白盒变黑的不可控记忆。
换句话说，AskTable 的设计是让 Agent 具备“可管理的上下文”，而不是“不可控的记忆”。这正是支撑 Vibe Analyzing 连续沉浸体验的关键。
7. 面对企业级多源异构数据（如财务系统、IoT 传感器数据），Agent 如何自动完成数据治理（如清洗、关联、口径对齐）？在数据质量参差不齐的场景下，如何确保 Agent 生成的分析结论不偏离业务真实？
崔京：对于企业级的多源异构数据，比如财务系统、IoT 传感器数据，大家往往会期待 Agent 能自动完成数据治理，例如清洗、关联、口径对齐。但我们在实践中看到，一个非常重要的前提是：数据治理本身仍然离不开人，不能完全交给 Agent。
现阶段、我们更愿意把 AskTable 的能力比喻为“打造一个现代化的厨房”。以前做数据分析，就像是在河边野炊——工具简陋、流程粗放，结果高度依赖个人能力；而现在，通过 AI 和自动化，我们提供的是一套像“高压锅、电烤箱、微波炉”这样的现代化设备，让分析师可以更高效、更有品质地完成菜品。
但无论厨房设备多先进，真正决定菜品是否符合业务口径、是否满足企业要求的，始终是“厨师”本人，而不是设备。
在多源、质量参差的数据场景下，Agent 可以极大提升处理效率：自动生成文本清洗逻辑、自动做字段关联、自动对齐口径，但最终的分析结论是否准确、是否符合企业内部的定义和业务逻辑，仍然需要由人来把关。
换句话说，Agent 在这里扮演的是“现代化厨房设备”的角色，而不是替代分析师的“自动厨师”。通过这种方式，我们既利用了 AI 的自动化优势，又确保了最终输出不会偏离业务真实。
8. 您提到‘AI 无法替代行业专家’，但在实际落地中，专家知识（如财务月报逻辑）往往隐含且碎片化。AskTable 是否通过 Agent 技术实现了专家经验的沉淀与复用（如构建动态知识库或可调用的分析模板）？
崔京：这是一个既重要又很困难的问题，我们目前也在和一些客户一起探索。之所以重要，是因为技术最终是为业务服务的。如果一个 Agent 只懂技术、不懂业务，它在企业中的价值是有限的；而真正理解业务、能够复用行业知识，才是 AI 在企业落地的关键。
但要把专家知识沉淀下来并自动复用，本质上非常难。我们的思路并不是内置一批标准模板来“硬套”业务场景，而是希望企业在实际使用过程中，让自己的专家逻辑自然沉淀下来。因为各家企业的业务差异太大，无法靠一套通用模板覆盖。例如财务月报分析，每位 CFO 的分析逻辑都不一样；即便把某个 CFO 的逻辑抽取出来，迁移到另一家公司时，只要数据结构稍有缺失，这个逻辑就无法直接应用。
在这种背景下，AskTable 的 AI 画卷（基于无限画布的设计）就非常关键。我们希望未来无论是分析师一步一步对数据的分析路径，还是 AI 模拟人类的思考过程、拆解过程，都能够在画布上被显性化、可视化地记录下来。
当这些原本“隐含”的知识有了可度量、可观察的载体之后，企业才能逐步把专家经验沉淀下来，并在后续不断迭代和改进。因为专家知识不是固定不变的，它本来就是需要持续演化的，而 AskTable AI 画卷的作用是让这种演化过程可见、可传承、可复用。
立即报名参会
9. 未来如果 GPT-5 类模型进一步降低幻觉但牺牲创造力，AskTable 的 Agent 设计是否会调整策略（如混合部署多模型，或引入强化学习优化生成逻辑）？您如何看待‘模型能力’与‘业务可控性’的长期博弈？
崔京：我会分两层来回答这个问题：一层是“未来模型生态会怎样”，另一层是“AskTable 会怎样用这些模型”。
第一，我们并不认为未来只有所谓的 “GPT-5 类一统天下”，而是必然走向模型多样化：
会有一类模型更擅长创意、叙事、类比，也会有一类模型更偏确定性、推理稳定、可控性更强。
AskTable 现在其实已经在做“混合模型编排”——根据任务拆分不同阶段，把子任务分配给更擅长这类工作的模型，让一整个长链路由多种模型协同完成。这个路线在今天已经落地，未来也会继续沿用，并随着模型生态变得更“百花齐放”而更精细。
第二，所谓“幻觉 vs 创造力”“模型能力 vs 业务可控性”，在我们看来并不是简单的对立关系，而是跟场景强相关的权衡问题：是实时问答，还是报表生成？是指标分析和归因，还是做预测和假设推演？
不同场景需要的“创造力/稳定性配比”完全不同，很难用一句话定义“哪类模型一定更好”。我们真正期待的，是未来有一整套丰富的模型池，我们只需要“用合适的模型干合适的事”。
在工程手段上，即便不能随意更换或微调底层模型，我们仍然有一整套 Prompt Engineering 和策略配置 的空间：通过约束式 Prompt、结构化输入输出、显式业务规则等方式，把同一个模型“调”成更稳定、更业务友好的形态，这对很多企业部署场景来说是现实可行的路线。
至于强化学习，我们的看法是，未来一定会做，但不会去和大厂竞赛“训练一个更大的通用模型”。
更现实的路径，是先在产品中沉淀足够多的用户行为数据和交互痛点——例如在新的“数据交互范式”下，用户在哪些操作上最容易卡住、误解、反复重试——然后基于这些明确的痛点，用强化学习去优化小模型或特定策略模块，显著提升交互体验和任务完成率，而不是在预训练层面重做一遍通用能力。
总结来看：未来模型会越来越强、越来越多样，但 AskTable 的核心策略不会变——我们不押注某一个“终极模型”，而是押注在一个能够灵活编排多模型、通过工程手段保持业务可控性的 Agent 框架上。模型能力越进化，这个框架的可用空间就越大。
10. Agent 技术在数据分析领域的终极形态可能是什么？是否会走向‘自主分析’（如自动发现数据异常、生成假设并验证）？在这一进程中，AskTable 的下一步技术布局将聚焦哪些方向（如实时决策、边缘计算场景）？
崔京：在相当长的一段时间内，它都不会是完全自主的，仍然需要人的参与。但在特定场景下，AI 确实会具备一定的自主化能力，比如自动发现异常——AI 不需要人提前定义什么是异常，也能够基于历史行为和模式自主发现问题。
其实要实现这些自主化能力并不难，真正的难点在于：当这些能力开始依赖于企业自身的“隐含专家知识”时，如何构建、度量这套知识体系，如何被持续迭代？如何让企业内部不同角色能够协同更新知识？以及如何确保 AI 随着知识的更新而不断演进，而不是在原地停滞？
我们把这种能力称为“可持续发展的 AI”。企业不是一次性把知识交给AskTable，然后AskTable永远使用同一套逻辑；而是企业的业务、规则、认知不断变化时，AI 也能同步更新，这样才能真正融入企业的日常运营。
未来 AskTable 的布局，会继续围绕这一点展开——构建一种能够持续进化、与企业共同成长的智能体系。
活动推荐
本次Agentic AI Summit 超级智能体系统架构峰会汇聚了顶尖互联网公司的 Agentic AI 建设先锋，内容直击企业AI落地的核心挑战与解决方案。无论您是关注Agent平台建设、还是Agent工具开发，都将在这里获得极具价值的启发与实践参考。
如果您想要来参会听演讲，和专家面对面交流，请电话或添加微信快速咨询，获取最新会议信息： 13311343487（宋宋）。🔥 8 折优惠购票火热进行中，点击「阅读原文」即可报名参会！
