企业级问答系统的架构里，有一个取舍能同时影响调用成本、结果准确率与审计追溯：数值计算交给谁。流行的做法是把计算也交给模型——把数据塞进上下文，让它边读边算。我们在生产环境里选择了相反的方向：把数值计算留在数据源侧，模型只负责理解问题与组织结论。
为什么不让模型算数
大模型对数值的处理是「生成」而不是「计算」，浮点运算的可靠性没有保证。更关键的是审计：模型算出来的数，无法回答「这个数是哪张表哪一行的哪个字段求和来的」。监管与经营场景里，无源的数据比没有数据更危险。
编排层的职责边界
我们的做法是把系统拆成两层。模型侧负责理解意图：识别用户想问什么、缺哪些参数、应该调用哪个工具。数据侧负责计算：按调用计划在数据源侧执行 SQL 或服务接口，把带出处的结果返回。模型拿到的是已经算好的数字，它的工作是把数字放进正确的表述与结论结构里。任何一次回答里的每一个数字，都能回溯到一次真实的取数调用。
工具清单的维护
这套架构长期运转的关键，是那张「模型可以调用哪些工具」的清单。清单里的每个工具都有明确的入参定义、数据来源与权限要求，新增分析场景时先在清单里注册工具，再配置场景。清单本身要纳入版本管理——它既是功能边界，也是审计时「系统理论上能取到什么数据」的证明材料。
三笔账都算得过来
调用成本：上下文里不再需要塞进原始数据表，token 消耗显著下降。结果准确率：数值由程序计算，不存在模型幻觉算错的可能，模型只需要保证「调对了工具」。审计追溯：取数计划、执行记录与返回结果全程留痕，出问题可以定位到具体环节，而不是对着一段生成的文本猜。
边界之外
这个架构不排斥模型做它擅长的事——理解模糊提问、组织结构化结论、生成文档草稿。它的边界只在数值与结论的正确性上。企业级问答系统上线前的信心，来自这条边界被清晰地写进架构，而不是寄希望于模型能力迭代。
延伸：检索失败的兜底体验
门禁越严，「查不到」出现的概率越高，兜底体验就越重要。查不到时不要只回一句「无权限」，要区分三种情况给出引导：资料存在但超出可见范围，提示走权限申请；资料不存在，提示换一种问法或推荐相近的已命中内容；命中但来源校验未过，如实告知依据不足。让用户知道下一步该做什么，门禁才不会变成使用门槛。