1. 为什么先谈架构问数Agent不是又一个Chat Bot最近在公司内部搭建问数项目智能体时很多同事第一反应是这不就是一个套了Prompt的SQL生成器吗给模型一个Schema让它输出SQL再执行一下返回结果完事了。真这么做你会在上线第一周就被业务方拉黑。自然语言问数和普通对话最大的差异在于它最终要产生一个用户能直接相信的数据结论。用户问这个月华东区销售额同比变化多少他需要的不是一段看起来合理的SQL而是经过验证的、口径正确的、能解释为什么这个数涨了的完整回答。这对Agent的架构设计提出了完全不同的要求。LCoder这套方案我们最终定位为面向问数场景的可编排Agent底座。它不只是把大模型包一层接口而是要解决五个问题用户意图怎么理解、数据怎么安全访问、SQL怎么生成并保证正确、结果怎么解读、系统怎么运维和评测。这五个问题如果不在架构阶段想清楚后期任何一个都可能导致推倒重来。所以这个系列的第一篇我先不写代码先把架构讲透。适合的人群是准备做Text-to-SQL产品、企业内部问数机器人、或者想基于大模型搭一个能真实落地的Agent应用的技术同学。你不需要有很深的算法背景但需要会用SQL、理解基本的前后端交互并且见过至少一个Agent框架的使用方式。我见过太多从Demo到生产失败的案例病根基本都出在架构没有为数据可信和结果可控留出位置。这一篇就是我这个项目踩完坑之后的架构复盘把为什么这样拆每一层解决什么问题选型理由是什么一次说清楚。2. 问数项目的核心链路拆解从用户问题到可信结论的四道关2.1 四道关理解、翻译、执行、表达问数Agent看起来只有一句话进去、一个答案出来但内部链路远不是调用LLM然后执行SQL这么简单。我把它拆成四道关每一道都有独立的失败模式和应对策略。第一道是理解关。用户的原话往往是模糊的帮我看看最近销售情况怎么样这里面至少缺三个信息最近是多久近7天还是近30天、销售情况指的是销售额还是订单量、需不需要对比。如果Agent不做意图澄清直接生成SQL大概率产出错误结果。理解关要做的是意图分类、槽位抽取、多轮澄清。第二道是翻译关。也就是把自然语言翻译成一条可执行的SQL。这里的难点不在SQL语法而在业务口径。同样的销售额有的团队算的是含税实付金额有的算的是订单金额减去退款口径不对答案就错。翻译关需要把Schema、指标字典、同义词映射都喂给模型并且用Few-shot示例约束它采用正确口径。第三道是执行关。SQL生成了不代表能跑、能跑不代表该跑。这里要做只读校验、权限校验、超时控制、行数限制。我们的经验是执行前必须过一道安全预检否则线上数据库被一条失控的查询压垮只是时间问题。第四道是表达关。用户要的不是一张几十行的表而是一句话结论加一张合理的图表。表达关要把查询结果转成可读的洞察比如较上月增长12.3%主要受华东区拉动同时给出数据来源口径方便用户核对。2.2 为什么不能问完就出SQL每道关都有失败率很多人觉得四道关多此一举加大模型Prompt长度不就行了。实际不是这样每一道关都有独立的失败模式集中在一起处理会让错误就像黑洞——用户看到的是不知道哪里错了但结果就是不对。我们早期原型把四道关全部交给一个大Prompt效果在简单查询上不错一旦涉及多表Join、口径选择、时间范围推理错误率直线上升。更难受的是难以定位用户说结果错了你根本不知道是理解错了、SQL错了还是执行错了。拆成四道关之后每一关都有输入输出记录出错就能快速回放模型Prompt迭代也互不影响。这也是为什么架构阶段必须先拆链路链路不清晰后面就是一笔糊涂账。2.3 架构设计要回答的五个问题基于四道关架构设计可以收敛成五个具体问题问题如何被理解——意图识别模块、多轮对话管理、澄清机制、槽位填充。数据如何被安全访问——数据源连接、Schema元数据仓库、行列级权限、脱敏、审计。SQL如何生成并保证正确——Schema裁剪、指标字典、Few-shot、自检与重生成。结果如何被解读——结论生成、图表推荐、口径说明、异常提示。系统如何被运维——全链路日志、评测集、回归测试、告警和版本回滚。这五个问题和四道关一一对应架构阶段只要把每个问题对应的模块职责、接口关系定清楚后续开发就是填充细节而不是边写边设计。我们内部把这条链路总结为理解—翻译—执行—表达四个词贴在公司问数项目周报的第一页所有协作方对齐都用这一句话。3. 总体架构设计编排层、推理层、工具层与数据层如何分工3.1 四层架构概览问数项目整体分成四层入口与编排层、推理层、工具层、数据层。用一张表先看清每层的职责层级主要职责关键组件典型技术选型入口与编排层接收请求、维护对话状态、调度工具调用顺序Web聊天界面/API网关、Agent Orchestrator、记忆模块WebSocket/SSE、LangGraph或Spring AI Multi Agent推理层理解意图、生成SQL文本、生成结论大模型、Prompt模板、Few-shot示例库、思维链Qwen/GLM/DeepSeek等按需选择工具层把数据能力封装成Agent可调用的原子能力Schema检索工具、SQL生成工具、SQL执行工具、图表工具MCP协议、内部HTTP服务、JDBC连接池数据层数据的存储、元数据管理、指标口径管理业务库/数仓、元数据库、指标字典表MySQL、ClickHouse、Presto、OpenMetadata这里要注意推理层和工具层的区别很关键。推理层是想的地方工具层是做的地方。模型不直接连数据库而是通过工具层暴露的接口去拿Schema、去执行SQL。好处是每个工具都可以单独设权限、单独加审计、单独做降级。我们最初图省事让模型直连数据库配置后来因为权限没法按用户隔离而被迫重写。3.2 编排层Agent的大脑与手脚之间的调度中枢编排层是整个架构里最容易低估的部分。很多人以为编排层就是按顺序调用几个函数真正做起来才发现要处理分支、循环、重试、回退、并发。以LCoder的Agent编排器为例它维护了一张状态图收到用户消息后先做意图分类如果是问数意图进入Schema选择子图拿到相关表之后进入SQL生成子图生成后进入安全校验子图校验通过进入执行子图执行完成进入结果解读子图。任何一个子图返回信息不足就回到澄清节点让模型继续追问用户。这个流程在LangGraph里就是若干个Node和Edge在Spring AI Multi Agent里则是多个Agent协作如果全自研那就是一张状态机表加一个循环调度器。我更推荐用现成编排框架因为状态持久化、断点续跑、并发控制这些基础能力自研代价很高。LCoder默认接的是LangGraph风格编排但在Java生态里用Spring AI的Multi Agent模块也能实现同样的效果。3.3 推理层的边界模型不直接决定一切推理层要刻意保持轻。它只做两件事一是根据当前状态决定下一步调用哪个工具、传什么参数二是生成面向用户的自然语言回复包括SQL文本解释、结果结论。不要把业务规则硬塞进推理层。比如哪些字段是敏感字段不能查哪些表只允许财务角色访问这些规则应该放在工具层做强制校验而不是指望模型自觉遵守。我们的原则是模型负责柔性理解工具负责刚性校验。模型可以犯错但工具层要在执行前把错误拦截住。这个边界一旦模糊比如试图在Prompt里写一百条权限规则最后的结果一定是漏洞百出。还有一点经验推理层的上下文窗口要当成稀缺资源来管理。Schema不能一次性全塞进去数据字典也不能。要由工具层先做检索和裁剪再返回给推理层。很多项目做到一半发现上下文爆了就是没建这个元数据检索工具。3.4 工具层一切能力皆是可插拔工具工具层的设计目标是新增一种数据源、新增一种图表类型不需要改动推理层代码。每个工具都有标准的输入输出协议模型只需要知道这个工具是干嘛的、参数是什么、什么时候用不需要知道内部实现。我们当下的工具清单大致有五个Schema检索工具、指标口径查询工具、SQL生成辅助工具用来查同义字段和常用聚合写法、SQL执行工具带安全预检、图表数据转换工具。其中Schema检索工具调用最频繁几乎每个问数请求都会触发。工具层的标准化用了MCP协议这个我下一章节展开讲。这里只强调工具接口的输入输出必须严格定义成JSON Schema并且要写清楚工具的适用场景和不适用场景。比如SQL执行工具必须说明只能执行SELECT任何DML都会被拒绝这样模型才不会在工具调用时自由发挥。4. 关键技术选型与理由模型、框架、MCP协议和SQL执行引擎4.1 模型选型SQL能力优先不要只看通用榜单模型是问数Agent的核心引擎选型直接决定效果上限。我们的经验是不要盯着通用大模型排行榜要用自己的业务Schema和问题集做评测。我们当时对比了GLM、Qwen、DeepSeek和ChatGPT系的几个版本评测方式是准备50条典型问数问题每个问题标注期望的SQL和答案跑一遍看准确率。结果通用能力强的模型在SQL生成上不一定最好有些模型在做长文本对话时很优秀但在需要严格遵循JSON Schema输出工具参数时反而经常出错。选型时需要重点看四个能力维度SQL方言适配能力——是否熟悉你用的ClickHouse、Presto、MySQL方言特性比如ClickHouse的数组函数、Presto的Unnest语法。工具调用/Function Calling稳定性——能不能严格按JSON Schema输出参数不丢字段、不添字段。长上下文与指令遵循——能否在给了10-20张表结构后不混淆表名和字段名。中文业务术语理解——对同比环比累计日均这类词的理解是否准确。我们最终选择了一个在SQL生成和工具调用上平衡最好的模型同时把模型接口封装在推理层方便后续替换。封装时留了模型版本字段每次Prompt升级都带上版本号这样线上效果异常时能快速定位是模型变了还是Prompt变了。4.2 Agent编排框架LangGraph vs Spring AI Multi Agent vs 自研编排框架的选型要结合团队技术栈。我们因为同时有Python和Java两套团队实际各写了一版原型这里把结论分享一下。LangGraph的特点是状态图显式、节点和边清晰、天然适合复杂流程控制。它把每个Node定义成一个函数状态在节点间传递调试时可以逐步回放。缺点是Python生态和公司Java技术栈集成有成本而且状态图一旦复杂新人上手有门槛。Spring AI Multi Agent则是Java生态的自然选择如果你公司整体是Spring Boot体系用它做Agent编排可以和现有服务无缝集成。它有Agent、ChatClient、Tool Calling等抽象适合做企业级服务。缺点是多Agent协作的粒度控制不如LangGraph那么细复杂分支逻辑要自己多写代码。自研编排器则适合需求极其简单、或框架无法满足特定约束的场景。我不建议从零开始因为状态管理、断点恢复、并发控制这些都是不起眼但很费时间的坑。LCoder项目最终采用了一个折中方案核心编排逻辑用LangGraph编写并独立成服务对外提供HTTP接口Java业务层通过OpenAPI调用。这样既享受了LangGraph的流程控制能力又不绑定团队技术栈。如果你团队只有Java直接用Spring AI Multi Agent完全可行架构层不用变只换编排层实现。4.3 MCP协议让工具接入标准化MCPModel Context Protocol在问数项目里解决了一个很实际的问题工具接入方式不统一。数据库连接、HTTP服务、内部RPC、脚本命令每一个都要写一套适配代码模型调用时参数格式也五花八门。MCP把这些封装成标准化的Tool接口模型请求和工具响应的格式都走统一协议。在问数Agent里我们把Schema检索、SQL执行、指标查询、图表转换都包成MCP Tool。每个Tool都有清晰的name、description、input_schema和output_schema。比如SQL执行Tool的description里会明确写用于对只读数据源执行SELECT语句不允许执行DML执行前会自动加LIMIT和超时限制。标准化带来的一个最大好处是工具可以跨项目复用。我们在另一个智能报表项目里直接复用了Schema检索Tool和指标口径查询Tool零改动接入。如果你现在还在用每个工具写一个Prompt描述的老办法建议尽早迁移到MCP这是Agent工具层的大趋势。4.4 SQL执行引擎与数据源连接层SQL执行层是问数Agent里最不能出问题的部分。我们的选型原则是用成熟的数据源连接方案不自己写执行器。业务数据在ClickHouse和MySQL通过JDBC连接池连接外面包一层查询服务。查询服务要做几件事连接池管理、只读事务开启、超时控制、结果行数限制、敏感字段过滤、全量审计日志。我们给查询服务设计了一个核心参数表参数默认值说明query_timeout10s单个查询最大执行时间max_rows1000返回结果最大行数max_memory2GB查询最大内存ClickHouse侧设置enable_readonlytrue强制只读拦截非SELECT语句audit_logtrue记录用户、SQL、耗时、影响行数这里有个容易被忽略的点超时和行数限制要在数据库侧和查询服务侧双重设置。数据库侧设了应用侧也要兜底防止数据库配置变更导致失控查询拖垮集群。我们曾经因为只设置了应用侧超时数据库侧没设一条大查询把ClickHouse某个节点内存打满影响同集群其他业务非常尴尬。现在任何新数据源接入都要先过一遍这个参数表评审。5. 核心模块详细设计意图识别、Schema管理、SQL生成、结果解读5.1 意图识别与多轮对话管理先分清能问和不能问意图识别模块决定了Agent会不会答非所问。我们把它分成三层第一层判断用户是否在问数第二层判断是否属于当前数据域第三层做槽位抽取。第一层分类器用轻量模型加正则结合区分问数、闲聊、报表请求、非数据问题四类。只有第一类是走问数链路其他都有各自处理逻辑。这个分类非常重要否则用户说你好在吗Agent真的跑去查一遍数据库浪费算力还尴尬。第二层判断数据域。比如用户问库存周转率怎么样如果当前Agent只接了销售数据源就应该直接回答暂不支持库存数据而不是硬生成一段可能错误的SQL。我们为此维护了一个可问主题清单清单没有的关键词Agent会触发澄清而不是猜测。第三层槽位抽取是核心。槽位包括时间范围、维度地区、品类、渠道等、指标销售额、订单量、毛利率等、过滤条件。抽取用模型完成但槽位枚举值要从指标字典和维度字典里做约束。比如地区只能是华东、华北、华南等枚举值模型乱填一个南方大区就在槽位校验阶段被打回要求Agent主动澄清。5.2 Schema管理与指标字典元数据是好效果的根基问数Agent有一个常被新手忽略的真相模型不知道你的数据长什么样它只能根据你给的Schema和字典猜。Schema管理和指标字典的建设决定了SQL生成的准确率上限。Schema管理要做四件事表结构同步、字段注释清洗、同义词映射、指标口径登记。表结构同步可以定时任务从数据库元数据表拉取存到元数据库里。字段注释清洗要处理无注释注释是拼音缩写注释语义含糊三类脏数据清洗后模型才能理解。同义词映射解决同一个东西叫法不同的问题。比如用户说客户数库里字段叫user_cnt字典里要登记客户数、用户数、会员数/ user_cnt / customer_count的映射关系。指标口径则更重要我们在指标字典表里为每个核心指标记录了三项信息指标名称与业务定义比如销售额订单实付金额-退款金额计算公式与涉及字段使用示例SQL这个指标字典一方面给模型做Few-shot另一方面也用于校验生成SQL的字段引用是否合理。比如用户问毛利额但字典里根本没有这个指标Agent会提示用户没有毛利额指标是否指毛利润而不是硬生成一段可能错误的SQL。5.3 SQL生成与自校正不信任单次输出SQL生成模块是推理层的重头我们的做法是生成—校验—再生成三阶段。生成阶段不是一股脑把完整需求丢给模型而是先用Schema检索工具拿到相关表结构再拼装Prompt。Prompt里固定四块内容角色设定你是资深数据分析师、表结构定义只包含相关表、指标口径字典只包含相关指标、Few-shot示例2-3个类似问题的最佳SQL。这样每次调用的上下文都尽量精简模型准确率比全库Schema喂进去高很多。校验阶段做的是规则校验加模型自检。规则校验查三类问题SQL语法是否合法、是否只含SELECT、字段和表名是否存在于Schema中。模型自检则是把SQL再交给模型让它充当一个严格的数据工程师审稿看SQL是否符合同一个问题下的业务口径、时间范围是否按用户意图处理。自检发现的问题会返回给生成阶段带上错误说明让模型重写最多重写两次。实测下来加上自校正环节SQL正确率能提升大概15到20个百分点。这个概念非常大。但也要注意自校正不是万能的如果第一次生成的SQL方向就错了模型重写两次也还是错所以超过两次就不再循环直接转人工兜底。5.4 安全执行与权限控制工具层必须拦住模型犯的错执行模块每天要拦截不少模型觉得没问题、但实际有风险的SQL。这是个设计选择题你是信任模型的自我约束还是信任工具层的强制规则我的选择是后者。安全执行模块分三层。第一层是语句级校验只允许单条SELECT禁止分号拼接、禁止注释绕过、禁止关键字如SELECT INTO/INSERT/UPDATE/DELETE。第二层是权限校验根据当前用户角色先查他能不能访问这张表再查字段级脱敏比如手机号、身份证字段要打码。第三层是资源限制自动附加LIMIT、设置超时、开启只读事务。一个重要细节是权限判断要用用户身份而不是Agent身份。因为Agent背后可能有很多用户在用如果不做身份透传就会出现某人通过Agent绕过行级权限看到了不该看的数据。我们在HTTP头部统一传递user_id和角色列表SQL执行Tool每次都要拿这个信息去权限服务校验。审计日志也在这里做。每条SQL都要记录用户、时间、表名、SQL全文、执行耗时、返回行数、错误信息。一方面是安全合规另一方面是后续做评测集和问题回溯时这些日志就是黄金数据。我强烈建议从第一天就全量记录哪怕前期用不上后面做模型效果分析会感激自己。5.5 结果解读与可视化用户要的是结论不是表格最后一道关是结果表达。SQL执行完拿到的是二维表直接丢给用户等于把翻译工作留给了用户自己。结果解读模块要把表格转成人话。解读分成三个层级。第一层是数据摘要总计、均值、最大值、趋势方向这些由统计函数自动生成。第二层是归因提示根据数据特征提示华东区占本月销售额40%环比增长23%是整体增长的主要贡献者。这一层可以交给模型做但必须限制它只能基于查询结果和维度字段说话禁止编造结果里没有的信息。第三层是建议操作比如华东区增长显著建议进一步查看品类结构这个属于增值能力要谨慎使用因为它最容易跑偏。图表推荐用规则引擎实现比用模型更稳定。我们总结了一套规则一个时间维度加一个指标推荐折线图一个维度加多个指标推荐柱状图维度是地区/城市推荐地图两个维度交叉推荐热力图。规则放在工具层模型只提供数据不直接决定图表类型这样图表样式可控、不会产生奇怪输出。6. 数据契约与API设计让Agent的每个部件都可测试、可观测6.1 对话状态与消息结构统一事件格式问数Agent的编排层、推理层、工具层之间通过统一数据契约通信。这个契约设计得不好后面调试和扩展都难受。我们采用类OpenAI消息格式并扩展了工具调用专用字段。每条消息包含roleuser/assistant/tool、content、tool_calls模型请求调用工具时的参数、tool_call_id工具调用的唯一标识。所有日志消息和状态流转都基于这套结构。好处是每一轮的输入输出都能完整序列化到日志复盘出错时只需要看 JSON 回放不需要查数据库猜过程。另外我们设计了一个推理过程事件流也就是后端向前端推送的SSE事件。事件类型包括token模型输出增量、tool_start某个工具开始执行、tool_end工具执行完成、sql最终SQL、chart_data图表数据、error错误信息。前端根据事件类型做流式展示用户能看到Agent正在查Schema正在生成SQL正在执行查询的过程体验上非常接近真实的AI助手而不是一个黑盒转圈。6.2 工具调用协议与Mock能力工具层的输入输出JSON Schema是数据契约的核心。每个工具在注册时必须提供完整的OpenAPI描述和JSON Schema。我们还强制要求每个工具自带Mock响应这样在模型调试和前端联调时可以不依赖真实数据源大大提升开发效率。比如SQL执行Tool它的输入Schema包括sql必填、user_id必填、role_list必填、data_source可选输出Schema包括data数组、columns数组、rows_count数字、execution_time_ms数字、error可选。Mock响应就是一个固定的二维表联调环境里用Mock生产环境走真实执行前端开发可以并行推进不用等后端就绪。这里有一个很实用的建议所有工具调用都要做超时和重试的分离设计。超时时间要在工具层配置重试策略则在编排层配置两层不要混在一起。比如SQL执行Tool本身超时10秒编排层对它的重试次数设为0因为重复执行可能放大资源消耗而Schema检索Tool超时3秒编排层允许重试2次。这种区分让故障行为更可控排查问题时也更有条理。6.3 可观测性全链路追踪不是可选项问数链路长、跨度大跨了前端SSE、编排层、推理层模型调用、工具层多个服务没有追踪系统基本没法排障。我们接入OpenTelemetry用trace_id贯穿整个链路日志里每个关键节点都打点记录时间戳。除了技术层追踪业务层还记录了一份对话审计记录用户原始问题、最终SQL、执行状态、模型置信度、是否触发自校正、用户是否点踩。这些数据最值钱的用途是构建评测集。我们在上线后从日志里捞了一百多条用户真实问题和反馈人工标注后作为回归测试集每次改Prompt或者换模型都跑一遍效果变好还是变差一目了然。评测集这件事我建议越早做越好等系统上线再补你会发现缺了一大堆线上真实case。7. 架构层面的风险提前排雷幻觉、权限、性能与评测体系7.1 幻觉控制不让Agent一本正经地编数据问数Agent的幻觉和普通对话略有不同它主要幻觉在三个地方字段名幻觉、口径幻觉、结论幻觉。字段名幻觉是模型编造了一个不存在的字段比如用户问新客数Schema里没有模型硬写一个new_customer_count。解决办法是Schema检索工具做强制约束生成前先用字段清单限定候选集模型输出时用规则检查所有字段必须存在于候选集中。口径幻觉是用了错误的计算口径比如用户问销售额却按订单金额去算。解决办法主要靠指标字典和Few-shot同时在自校正阶段让模型解释一遍你的SQL用了什么口径解释不合逻辑就重生成。结论幻觉则发生在结果解读模块模型根据一个并不显著的波动编出了大幅增长的结论。我们治理方式是在结果解读的Prompt里写明只能基于输入数据说话如果要使用大幅显著等程度词必须先给出数值依据同时在输出后做一个简单的数值规则校验发现结论数值和数据冲突就直接拦截。7.2 数据权限按身份隔离不按Agent隔离前面提过权限要按用户身份处理这里再展开讲一个典型的坑如果你在工具层把所有请求都当成Agent请求那权限模型就只有能查/不能查两档无法支持华东区销售能看到华东数据、华南区销售能看到华南数据这种行级需求。我们的解决方案是三层权限模型表级权限、行级权限、字段级权限。表级权限控制能访问哪些表行级权限通过执行前改写SQL自动加WHERE条件实现字段级权限负责脱敏。行级权限的改写逻辑放在SQL执行Tool内部模型不感知模型生成的SQL不会自动带上行级条件但执行前会被统一注入。比如role_list里带华东销售执行工具自动拼上WHERE region 华东这样即使模型生成一个不带任何条件的SELECT全表实际执行也不会越权。权限配置本身建议做成服务化不要在Agent代码里硬编码。因为权限规则是业务方运营的他们需要能自助修改而不是每次改权限都找开发发版本。7.3 性能与并发问数Agent的漏斗式加速性能优化思路可以用漏斗来理解越靠近入口的层越要快越重、越昂贵的计算越要往后放并且要做缓存。意图分类和槽位抽取这一层用轻量模型或正则先过滤大部分简单问题在入口就能快速响应。Schema检索是第二道缓存重点我们把常用表的Schema结果缓存在Redis里设置5分钟过期避免每个请求都查询元数据库。SQL执行结果则按问题哈希用户角色时间范围做缓存完全相同的查询直接命中缓存不再重复执行数据库。模型调用是整个链路里最贵的部分要控制的重试次数和并发。我们的并发策略是每用户限制1个并发问数请求超出排队系统层面限制模型API的TPM每分钟token数不超过配额的一半留一半给其他Agent项目。否则问数Agent一个促销活动就能把模型额度耗尽其他业务同事会来找你聊人生。7.4 评测体系没有评测迭代就是盲人摸象Agent项目最大的风险不是开发不出来而是改了一个Prompt你不知道效果是好了还是坏了。所以评测体系必须在架构阶段占位置。我们的评测体系分三层。第一层是单元评测用固定的100条问题-期望SQL对每次SQL生成模块改动后跑一遍计算SQL精确匹配率和执行成功率。第二层是端到端评测用50条真实用户问题走完整链路人工判断最终答案是否正确、结论是否自然、权限是否生效。第三层是线上监控对线上请求做抽样评分记录用户反馈点赞/点踩每日汇总准确率趋势。三层配合下来每个版本上线前都能回答一个问题现在的效果与上个版本相比是提升还是回退这个能力让团队敢于持续迭代Prompt和模型而不是因为怕出问题而不敢动。在LCoder架构里评测集和编排流程是并列的一等公民不是后期补丁。8. 落地经验与系列预告先跑通最小闭环最后分享一点落地层面的心得。问数Agent架构看着复杂但不要试图一次性全部实现。我们的建议是分三步走。第一步先跑通单表固定指标的最小闭环。只接一张表、支持最常见的十个指标、不支持复杂Join、不支持模糊查询。这个闭环的价值是打通全链路验证大模型、工具层、前端SSE、日志追踪都正常。我们当时用一周时间就上线了内部MVP业务方体验后给了大量宝贵反馈。第二步再扩多表动态指标。这个阶段重点是Schema管理、指标字典、权限模型要跟上否则多表Join和动态口径会把模型准确率打崩。第三步才是加深度分析能力比如归因解读、异常检测、预测这些能力依赖积累一定规模的数据和评测集提前上容易翻车。问数项目本身的迭代路径很长架构只是第一课。下一篇我会讲Schema管理与指标字典的落地细节包括元数据表结构设计、同义词映射的数据模型、以及如何用这些数据让SQL生成准确率明显提升。这些问题我在踩坑时纠结了很久值得单独写一篇讲透。