[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"consumer-news-detail-944":3,"consumer-news-interaction-944":38,"consumer-news-related-944":41},{"detail":4,"item":34},{"card":5,"schemaVersion":21,"fields":22,"content":28},{"id":6,"kind":7,"targetType":8,"targetId":9,"subtype":7,"typeLabel":10,"title":11,"subtitle":12,"summary":13,"coverUrl":14,"badgeText":14,"href":15,"sourceName":12,"meta":16,"metrics":18,"tags":19,"resolved":20},"NEWS_ARTICLE:944","news","NEWS_ARTICLE",944,"资讯","Text-to-SQL 已过时？DolphinX 正在重新定义 AI 问数","博客园","在推动工业场景 AI Agent 能力落地过程中，DolphinDB 选择智能问数作为具体切入点，基于 DolphinX 做了一个智能问数 Agent，尝试探索一套面向企业数据的智能问数链路应该如何构建。","","\u002Fnews\u002F944",[17],"2026",{},[],true,"consumer-content-detail-v1",{"sourceName":12,"authorName":23,"summary":13,"description":13,"publishTime":24,"updateTime":25,"sourceUrl":26,"language":27},"DolphinDB","2026-09-10T10:03","2026-09-11T15:21:59","https:\u002F\u002Fwww.cnblogs.com\u002FDolphinDB\u002Fp\u002F22916454","中文",{"format":29,"policy":30,"normalized":20,"html":31,"text":32,"wordCount":33,"hasBody":20},"HTML","NEWS_CONTENT_V1","\u003Cblockquote>\n \u003Cp>“请分析 2026 年 6 月 14 日至 6 月 16 日各设备的平均油温、最高油温和最低油位，并关联同期告警和故障数量。请按最高油温从高到低排列，优先关注油温较高且同时存在告警或故障的设备。”\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>看起来，这只是一次数据查询。但执行起来，远不只是生成一段 SQL。\u003C\u002Fp>\n\u003Cp>系统首先要知道该查哪几张表，哪些字段分别代表“油温”“油位”“告警”和“故障”，时间字段是哪一个；还要找到正确的关联关系，完成统计、排序和结果组织。\u003C\u002Fp>\n\u003Cblockquote>\n \u003Cp>如果用户接着说一句：“再按油位也排一下。”\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>AI 还必须知道，这不是一个新问题，而是在修改刚才那次查询。\u003C\u002Fp>\n\u003Cp>自然语言问数难的地方，从来不是把一句话翻译成 SQL，而是让 AI \u003Cstrong>理解数据结构、维护查询上下文，并在尽可能短的链路中快速生成正确的 SQL，最终确保查询能够在真实数据库中安全执行。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>在推动工业场景 AI Agent 能力落地过程中，我们选择\u003Cstrong>智能问数\u003C\u002Fstrong>作为一个具体切入点，并基于 DolphinX 做了一个智能问数 Agent，尝试探索一套面向企业数据的智能问数链路应该如何构建。\u003C\u002Fp>\n\u003Ch2>不只是 Text-to-SQL\u003C\u002Fh2>\n\u003Cp>如果只是把自然语言翻译成 SQL，问题其实并不复杂。真正困难的是，用户的问题往往不是一次性的：他会继续追问、修改条件，甚至回到更早的一次查询重新调整。\u003C\u002Fp>\n\u003Cp>因此，我们探索的并不只是“自然语言 → SQL”，而是一条完整的智能问数链路：问题理解、上下文构建、元数据检索、真实 Schema 探查、SQL 生成、安全检查、查询执行和执行结果检查。\u003C\u002Fp>\n\u003Cp>目前，我们的智能问数 Agent 主要覆盖三类典型的场景：\u003C\u002Fp>\n\u003Cul>\n \u003Cli>查数据：数量、明细、筛选、排名、Top N、分组、趋势、占比等常见分析需求。\u003C\u002Fli>\n \u003Cli>追问题：基于当前查询继续增加条件或分析维度。例如\"同一时间范围\"\"区域也加一下\"\"只看华东\"等自然语言追问，可以继承之前查询中仍然有效的条件和数据范围。\u003C\u002Fli>\n \u003Cli>改问题：定位历史查询，并对其中的条件进行修改。例如，用户可以回到更早的一次查询：\"把前面那条检修计划查询改成只看上半年。\"\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>这意味着，AI 在这里不只是一个 SQL 生成器，而是在尝试维护一个持续演进的\u003Cstrong>查询上下文\u003C\u002Fstrong>——它需要记住用户问过什么，也需要判断当前这句话究竟是在延续、修改，还是重新开始。\u003C\u002Fp>\n\u003Ch2>不再把元数据一次性丢给模型\u003C\u002Fh2>\n\u003Cp>企业数据环境里，一个常见做法是把数据库元数据全部交给大模型，然后让模型自己选表、选字段。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>我们没有这么做\u003C\u002Fstrong>。我们认为：模型可以判断用户想查什么、应该使用哪些字段、如何组织查询，但不能凭空创造数据库对象。\u003C\u002Fp>\n\u003Cp>因此，我们选择让模型负责判断，让数据库负责提供事实。这样做的目的，是让 AI 的判断始终建立在真实的数据结构之上，而不是依赖模型自身的猜测。\u003C\u002Fp>\n\u003Cp>在实际应用中，Agent 会首先根据用户问题召回少量候选表，再从 DolphinDB 探查真实字段、字段注释、类型以及必要的字段值样例。随着查询上下文逐步明确，系统可以动态扩展字段和表；如果当前候选范围仍无法满足需求时，再进一步扩大元数据搜索范围。\u003C\u002Fp>\n\u003Cp>这种按需检索、逐步收敛的方式，不只是为了提高 SQL 的准确性，也是在控制 AI 处理的信息范围，减少无效的上下文和推理，让模型更快定位到真正需要的数据。\u003C\u002Fp>\n\u003Ch2>给 AI 划定安全边界\u003C\u002Fh2>\n\u003Cp>当 AI 开始直接面对企业数据，\u003Cstrong>哪些操作可以执行，哪些操作必须被禁止？\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>我们希望 AI 不仅要在明确的边界内访问数据，整个查询过程也应该是可见、可验证、可干预的，而不是让用户只能等待一个最终答案。\u003C\u002Fp>\n\u003Cp>在我们的实践方案中，问数并不是直接从自然语言生成 SQL，而是被拆解为\u003Cstrong>问题理解、上下文构建、元数据检索、真实 Schema 探查、SQL 生成、安全检查、查询执行和结果检查\u003C\u002Fstrong>等多个阶段。\u003C\u002Fp>\n\u003Cp>首先是\u003Cstrong>让 AI 的数据访问可控\u003C\u002Fstrong>。所有查询请求在执行前都会经过服务端 Hard Stop（强制拦截）检查，拦截写操作、DDL、非法函数，以及超出最终 Schema 的表和字段引用。通过检查后，统一进入只读执行链路。即使 SQL 执行失败，Agent 根据错误信息进行局部修复后，修复后的 SQL 也必须重新经过安全检查才能再次执行，目前最多自动修复 5 次。\u003C\u002Fp>\n\u003Cp>其次是\u003Cstrong>让 AI 的查询过程可见\u003C\u002Fstrong>。每个阶段的关键结果都会呈现给用户：AI 如何理解问题、构建了什么查询上下文、检索了哪些元数据、实际探查到了哪些字段和类型，以及最终生成了什么 SQL。用户不需要仅仅根据一个最终数字来判断答案是否可信，而是可以沿着整个查询过程检查 AI 的判断。\u003C\u002Fp>\n\u003Cp>更重要的是，\u003Cstrong>这个过程不是只能“看”，还可以随时“改”\u003C\u002Fstrong>。如果用户发现 AI 在某个阶段理解错了，例如选错了数据表、字段含义理解有误，或者统计口径不符合预期，可以直接打断并纠正。AI 会基于修正后的上下文继续后续查询，而不是让错误一路传递到最终结果。\u003C\u002Fp>\n\u003Cp>简单地说，我们想解决的并不只是“AI 能不能查到数据”，而是让 AI 在一个\u003Cstrong>安全、透明且可控的执行链路\u003C\u002Fstrong>中完成查询。用户既可以把分析任务交给 AI，也始终保留对数据访问和查询过程的控制权。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>注\u003C\u002Fstrong>：目前实现的智能问数 Agent 主要面向个人开发者，旨在重点验证 AI 与企业结构化数据交互的核心链路。未来如果进一步进入企业生产环境，还需要接入企业权限体系，整体链路还需要增加身份与权限校验，确保 AI 的每一次数据访问都建立在用户已有的数据权限之上。\u003C\u002Fp>\n\u003Ch2>下一步，我们还会做什么\u003C\u002Fh2>\n\u003Cp>这次实践并不试图一次性解决所有问题。\u003C\u002Fp>\n\u003Cp>目前的实现主要关注的是结构化数据的查询和分析，暂不处理写入、更新、删除等数据库操作，也不把自己定位成完整的数据治理平台。后续，我们还会继续探索：\u003C\u002Fp>\n\u003Cul>\n \u003Cli>图表与报告生成：让查询结果进一步转化为可读的图表和分析报告。\u003C\u002Fli>\n \u003Cli>跨会话长期记忆：让 Agent 能够理解更长期的业务分析上下文。\u003C\u002Fli>\n \u003Cli>账号与权限体系：接入企业身份认证和数据权限控制。\u003C\u002Fli>\n \u003Cli>向量化元数据检索：提升复杂数据环境下的表、字段和业务语义召回能力。\u003C\u002Fli>\n \u003Cli>多轮分析任务：从单次查询进一步扩展到连续的数据分析任务。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>这些能力的共同目标，并不是让 AI 生成更多 SQL，而是让它能够理解更多业务上下文，完成更复杂的数据分析任务。\u003C\u002Fp>\n\u003Ch2>从问数开始，但不止于问数\u003C\u002Fh2>\n\u003Cp>但比这些能力本身更值得关注的，是一个更大的问题：\u003Cstrong>AI 能不能从“回答问题”走向“帮助分析问题”？\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>例如，在实际场景里，用户关心的可能是\"这个指标为什么突然上涨\"，而不是\"给我查一下上涨了多少\"。前一个问题已经不只是查询。AI 需要进一步关联数据、理解指标变化、识别异常，并寻找可能的原因。\u003C\u002Fp>\n\u003Cp>从回答问题到解释问题、发现问题，变化的不只是 AI 能完成的任务数量，更是 \u003Cstrong>AI 参与数据分析的方式\u003C\u002Fstrong>。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>智能问数只是一个具体的起点\u003C\u002Fstrong>。从数据查询到数据分析，再到问题发现与决策支持，AI 正在逐步从一个“回答问题”的工具，走向真正参与分析的智能助手。\u003C\u002Fp>","“请分析 2026 年 6 月 14 日至 6 月 16 日各设备的平均油温、最高油温和最低油位，并关联同期告警和故障数量。请按最高油温从高到低排列，优先关注油温较高且同时存在告警或故障的设备。” 看起来，这只是一次数据查询。但执行起来，远不只是生成一段 SQL。 系统首先要知道该查哪几张表，哪些字段分别代表“油温”“油位”“告警”和“故障”，时间字段是哪一个；还要找到正确的关联关系，完成统计、排序和结果组织。 如果用户接着说一句：“再按油位也排一下。” AI 还必须知道，这不是一个新问题，而是在修改刚才那次查询。 自然语言问数难的地方，从来不是把一句话翻译成 SQL，而是让 AI 理解数据结构、维护查询上下文，并在尽可能短的链路中快速生成正确的 SQL，最终确保查询能够在真实数据库中安全执行。 在推动工业场景 AI Agent 能力落地过程中，我们选择智能问数作为一个具体切入点，并基于 DolphinX 做了一个智能问数 Agent，尝试探索一套面向企业数据的智能问数链路应该如何构建。 不只是 Text-to-SQL 如果只是把自然语言翻译成 SQL，问题其实并不复杂。真正困难的是，用户的问题往往不是一次性的：他会继续追问、修改条件，甚至回到更早的一次查询重新调整。 因此，我们探索的并不只是“自然语言 → SQL”，而是一条完整的智能问数链路：问题理解、上下文构建、元数据检索、真实 Schema 探查、SQL 生成、安全检查、查询执行和执行结果检查。 目前，我们的智能问数 Agent 主要覆盖三类典型的场景： 查数据：数量、明细、筛选、排名、Top N、分组、趋势、占比等常见分析需求。 追问题：基于当前查询继续增加条件或分析维度。例如\"同一时间范围\"\"区域也加一下\"\"只看华东\"等自然语言追问，可以继承之前查询中仍然有效的条件和数据范围。 改问题：定位历史查询，并对其中的条件进行修改。例如，用户可以回到更早的一次查询：\"把前面那条检修计划查询改成只看上半年。\" 这意味着，AI 在这里不只是一个 SQL 生成器，而是在尝试维护一个持续演进的查询上下文——它需要记住用户问过什么，也需要判断当前这句话究竟是在延续、修改，还是重新开始。 不再把元数据一次性丢给模型 企业数据环境里，一个常见做法是把数据库元数据全部交给大模型，然后让模型自己选表、选字段。 我们没有这么做。我们认为：模型可以判断用户想查什么、应该使用哪些字段、如何组织查询，但不能凭空创造数据库对象。 因此，我们选择让模型负责判断，让数据库负责提供事实。这样做的目的，是让 AI 的判断始终建立在真实的数据结构之上，而不是依赖模型自身的猜测。 在实际应用中，Agent 会首先根据用户问题召回少量候选表，再从 DolphinDB 探查真实字段、字段注释、类型以及必要的字段值样例。随着查询上下文逐步明确，系统可以动态扩展字段和表；如果当前候选范围仍无法满足需求时，再进一步扩大元数据搜索范围。 这种按需检索、逐步收敛的方式，不只是为了提高 SQL 的准确性，也是在控制 AI 处理的信息范围，减少无效的上下文和推理，让模型更快定位到真正需要的数据。 给 AI 划定安全边界 当 AI 开始直接面对企业数据，哪些操作可以执行，哪些操作必须被禁止？ 我们希望 AI 不仅要在明确的边界内访问数据，整个查询过程也应该是可见、可验证、可干预的，而不是让用户只能等待一个最终答案。 在我们的实践方案中，问数并不是直接从自然语言生成 SQL，而是被拆解为问题理解、上下文构建、元数据检索、真实 Schema 探查、SQL 生成、安全检查、查询执行和结果检查等多个阶段。 首先是让 AI 的数据访问可控。所有查询请求在执行前都会经过服务端 Hard Stop（强制拦截）检查，拦截写操作、DDL、非法函数，以及超出最终 Schema 的表和字段引用。通过检查后，统一进入只读执行链路。即使 SQL 执行失败，Agent 根据错误信息进行局部修复后，修复后的 SQL 也必须重新经过安全检查才能再次执行，目前最多自动修复 5 次。 其次是让 AI 的查询过程可见。每个阶段的关键结果都会呈现给用户：AI 如何理解问题、构建了什么查询上下文、检索了哪些元数据、实际探查到了哪些字段和类型，以及最终生成了什么 SQL。用户不需要仅仅根据一个最终数字来判断答案是否可信，而是可以沿着整个查询过程检查 AI 的判断。 更重要的是，这个过程不是只能“看”，还可以随时“改”。如果用户发现 AI 在某个阶段理解错了，例如选错了数据表、字段含义理解有误，或者统计口径不符合预期，可以直接打断并纠正。AI 会基于修正后的上下文继续后续查询，而不是让错误一路传递到最终结果。 简单地说，我们想解决的并不只是“AI 能不能查到数据”，而是让 AI 在一个安全、透明且可控的执行链路中完成查询。用户既可以把分析任务交给 AI，也始终保留对数据访问和查询过程的控制权。 注：目前实现的智能问数 Agent 主要面向个人开发者，旨在重点验证 AI 与企业结构化数据交互的核心链路。未来如果进一步进入企业生产环境，还需要接入企业权限体系，整体链路还需要增加身份与权限校验，确保 AI 的每一次数据访问都建立在用户已有的数据权限之上。 下一步，我们还会做什么 这次实践并不试图一次性解决所有问题。 目前的实现主要关注的是结构化数据的查询和分析，暂不处理写入、更新、删除等数据库操作，也不把自己定位成完整的数据治理平台。后续，我们还会继续探索： 图表与报告生成：让查询结果进一步转化为可读的图表和分析报告。 跨会话长期记忆：让 Agent 能够理解更长期的业务分析上下文。 账号与权限体系：接入企业身份认证和数据权限控制。 向量化元数据检索：提升复杂数据环境下的表、字段和业务语义召回能力。 多轮分析任务：从单次查询进一步扩展到连续的数据分析任务。 这些能力的共同目标，并不是让 AI 生成更多 SQL，而是让它能够理解更多业务上下文，完成更复杂的数据分析任务。 从问数开始，但不止于问数 但比这些能力本身更值得关注的，是一个更大的问题：AI 能不能从“回答问题”走向“帮助分析问题”？ 例如，在实际场景里，用户关心的可能是\"这个指标为什么突然上涨\"，而不是\"给我查一下上涨了多少\"。前一个问题已经不只是查询。AI 需要进一步关联数据、理解指标变化、识别异常，并寻找可能的原因。 从回答问题到解释问题、发现问题，变化的不只是 AI 能完成的任务数量，更是 AI 参与数据分析的方式。 智能问数只是一个具体的起点。从数据查询到数据分析，再到问题发现与决策支持，AI 正在逐步从一个“回答问题”的工具，走向真正参与分析的智能助手。",2643,{"id":6,"kind":7,"title":11,"summary":13,"image":14,"href":15,"meta":17,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":37},"#2563eb","16 \u002F 10",[7,8],{"targetType":8,"targetId":9,"likedByMe":39,"likeCount":40,"commentCount":40,"contentLikeCount":40,"contentCommentCount":40,"sourceLikeCount":40,"sourceCommentCount":40},false,0,[42,51,57,63,72,79,85,92],{"id":43,"kind":7,"title":44,"summary":45,"image":46,"href":47,"meta":48,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":49},"NEWS_ARTICLE:927","HelloCrab - 短视频开源爬虫，仅供学习参考","HelloCrab 基于 Avalonia、Playwright、AI与 FFmpeg 的跨平台桌面采集器，支持9大平台，以及 Android、iOS、Browser 远程控制端。 Made By ChatGPT & Vincent with ❤ 平台 是否接入 哔哩哔哩 ✅ 抖音 ✅ 快手","https:\u002F\u002Fwww.cnblogs.com\u002Fhupo376787\u002Fp\u002FScreenshot\u002FWindows.jpg","\u002Fnews\u002F927","2026 · 软件开发",[50],"软件开发",{"id":52,"kind":7,"title":53,"summary":54,"image":14,"href":55,"meta":48,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":56},"NEWS_ARTICLE:929",".NET 异常处理的\"暗门\"：代码里写满 catch，你依然能抓住它——从一个 AI Agent 运行时的源码说起","一个健壮的系统，必然到处都是有意的 catch；异常被消化不等于问题不存在。 观测与韧性，是一个硬币的两面——降级逻辑保证系统不崩，FirstChance 保证你能看见它为什么降级。","\u002Fnews\u002F929",[50],{"id":58,"kind":7,"title":59,"summary":60,"image":14,"href":61,"meta":17,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":62},"NEWS_ARTICLE:928","架构师化繁为简，执行者化简为繁","新手改三天，你改三行——反而是你显得更不重要。因为化繁为简做得越纯熟，产出看起来越小。这篇聊聊两种能力的辩证关系，以及为什么'看不见'的那部分工作，恰恰是最难的部分。","\u002Fnews\u002F928",[7,8],{"id":64,"kind":7,"title":65,"summary":66,"image":67,"href":68,"meta":69,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":70},"NEWS_ARTICLE:930","基于 vLLM+Nginx 构建负载均衡推理集群","企业内部私有环境部署大模型推理集群时，很容易遇到流量调度混乱、节点负载失衡、会话上下文丢失、接口缺少鉴权防护等一系列问题，单 vLLM 推理节点难以支撑并发请求。本文基于 Ubuntu 22.04 系统环境，搭建 Nginx + vLLM-Semantic-Router + vLLM-Router","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F1379525\u002F202609\u002F1379525-20260910165534385-2022408098.png","\u002Fnews\u002F930","2026 · 人工智能",[71],"人工智能",{"id":73,"kind":7,"title":74,"summary":75,"image":76,"href":77,"meta":69,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":78},"NEWS_ARTICLE:932","2026年AI编程工具大全，33个主流工具一次看懂","事情是这样的，前两天看到一张图，是某个社区官网的「支持的工具」清单，我数了数，整整31个AI编程工具。 两年前这份清单撑死5个，现在直接31个，而且我居然每一个都认识。。。 干脆整理成一篇，顺手把最近字节的TraeWork和豆包工作也补了进来，凑成33个。 今天给大家推荐一遍，每个工具说说它是干什么","https:\u002F\u002Fimage.kjdaohang.com\u002Fimg\u002F20260909210838518.png","\u002Fnews\u002F932",[71],{"id":80,"kind":7,"title":81,"summary":82,"image":14,"href":83,"meta":17,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":84},"NEWS_ARTICLE:931","SH 中文化样例数据使用手册","在数据库演示与 PoC 场景中，Oracle 自带的 SH 示例模式虽然经典，但英文维度数据往往让国内演示效果打折扣。笔者整理了一套方案：保留 SH 标准英文对象名，同时装载中文化维度数据，并按参数生成可复现的销售历史数据，方便个人测试与概念验证。 01 | 环境准备 使用前请确认满足以下条件： O","\u002Fnews\u002F931",[7,8],{"id":86,"kind":7,"title":87,"summary":88,"image":89,"href":90,"meta":48,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":91},"NEWS_ARTICLE:933","写给 C++ 工程师的 OpenClaw.NET 上手指南：用你熟悉的 C++ 思维，跑起一个生产级 AI Agent","它像一个「基于 boost.asio + REST 端点的常驻服务」——对外是 HTTP \u002F WebSocket \u002F 各 IM 的 webhook，对内跑着一个能调工具、读写记忆、跨渠道对话的 AI Agent——只不过协程不用你手写 promise_type，内存不用你管 new\u002Fdelete。","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F510\u002F202609\u002F510-20260905070811424-1837144874.jpg","\u002Fnews\u002F933",[50],{"id":93,"kind":7,"title":94,"summary":95,"image":96,"href":97,"meta":69,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":98},"NEWS_ARTICLE:935","[Agent Memory \u002F 强化学习] MemPO源码学习笔记 ---（1）--- 总体","[Agent Memory \u002F 强化学习] MemPO源码学习笔记 （1） 总体 目录[Agent Memory \u002F 强化学习] MemPO源码学习笔记 （1） 总体0x00 概要0x01 基础 & 背景1.1 用RL训练记忆系统的要点1.2 主要难点1.3 主要思路1.4 RL训练方案1.","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F1850883\u002F202609\u002F1850883-20260906190854637-986949885.jpg","\u002Fnews\u002F935",[71]]