为数据分析管道增加编排层

多年来仪表板一直是与数据交互的主要界面。它们呈现指标、可视化趋势并通过图表和过滤器支持决策。但它们也要求用户解释结果、提出后续问题并手动调查根本原因。如果这个调查层可以由系统驱动呢这就是编排变得关键的地方。Agentic AI 系统通常以 tool calling 或大语言模型来描述。然而在实践中决定性的转变不是工具本身——而是增加了一个编排层它可以协调这些工具、决定下一步做什么并迭代优化响应。1、仪表板呈现数据Agent 协调数据上的工作流而且越来越多地最接近数据的人——那些已经编写查询、定义指标并理解领域的人——正在构建这个协调层。不是因为工具需要深厚的 AI 专业知识而是因为难点从来不是模型。永远是知道要对数据问什么问题以及按什么顺序问。在我们继续之前以下是核心论点的五个要点Tool calling 是访问。编排是控制。能调用函数的 LLM 不是 Agent。能决定调用哪些函数、按什么顺序调用、以及如何处理结果的 LLM——那才是 Agent。核心架构是一个循环——决定、执行、观察——可以用不到 40 行 Python 实现并适用于任何 chat-completion LLM。你不需要新组件。大多数数据团队已经有了 SQL 查询、管道和预计算的 ML 输出。编排协调你已有的东西。在受限的企业环境中领域特定工具优于通用插件。有清晰契约的精选工具胜过广泛工具包。在原型中需要约 15 分钟仪表板导航的多步骤调查在不到 30 秒的对话交互中完成。2、Tool Calling vs 编排许多现代系统支持 tool calling——LLM 调用预定义函数如 SQL 查询或 API 端点的能力。这很有用但它本质上是单步执行选择一个函数、运行它、返回输出。没有迭代、没有结果评估、没有自适应跟进。编排不同。它管理工具如何跨多个步骤使用。如果说 tool calling 是单一反射编排就是推理循环——有时称为ReAct推理和行动模式解释用户的目标-决定下一步行动工具 参数执行工具-观察结果-用新证据更新上下文重复直到目标满足——或达到轮次限制这将执行从静态管道转变为有状态的决策过程。系统不再一步回答问题——它动态构建工作流其中每一步都由前一步的结果提供信息。在代码中核心循环很紧凑def run_agent(goal, tools, call_llm, execute_tool, max_rounds6): messages [ {role: system, content: build_prompt_from(tools)}, {role: user, content: fGoal: {goal}}, ] for round in range(1, max_rounds 1): response call_llm(messages) # DECIDE parsed extract_json(response) if parsed.get(action) final_answer: return parsed[answer] # DONE action parsed[action] params parsed.get(params, {}) result execute_tool(action, params) # EXECUTE messages.append({role: assistant, content: response}) messages.append({role: user, # OBSERVE content: fResult of {action}:\n{result}\n\n fContinue reasoning or return final_answer.}) return synthesize_from_partial_results(messages)这与模型无关。它适用于 OpenAI、Anthropic、Databricks Model Serving 或任何支持 chat completions 的 LLM。智能不在循环结构中——而在 LLM 在每一步决定做什么以及工具及其输出如何设计。3、从分析管道到 Agentic 系统Agentic 系统中使用的组件并不新鲜。大多数数据团队已经有了针对仓库表的 SQL 查询转换和聚合数据的管道预计算的 ML 输出预测、评分、分类分析转换和 KPI 逻辑这些不是需要获取的前提条件。它们是大多数分析组织中已经存在的资产。构建这些管道的团队——理解连接、边界情况、WHERE 子句中嵌入的业务逻辑——已经拥有了谜题中最难的部分。直到最近他们还没有的是让这些资产在运行时组合的协调机制。改变的是这些组件如何被协调。没有编排 用户 → 查询 → 结果有编排 用户 → 编排层 → 工具₁ → 评估 → 工具₂ → 评估 → … → 综合答案4、实践中的架构在为企业合规分析构建的原型系统中编排层位于用户界面和现有分析工具之间。系统有四层每层有清晰的职责入口层——通过聊天 UI、REST API 或仪表板进行用户交互。编排层——多步推理循环目标解析、工具选择、轮次管理和结果综合。工具层——约 20 个领域特定函数提供对数据和计算的结构化访问包括 SQL 支持的查询和 LLM 辅助的摘要。数据与 ML 层——持久化和推理基础SQL 仓库表、预计算的 ML 风险评分和 Delta 表。5、工具作为单一注册表一个关键的架构选择所有工具定义在一个单一注册表中它同时驱动 LLM 的 system prompt 和执行分发器。TOOL_REGISTRY [ {name: get_weekly_kpis, description: Compliance KPIs for a specific week., params: [{name: week_ending, type: date}]}, {name: get_risk_scores, description: ML-predicted risk levels for entities., params: [{name: level, type: High | Medium | Low | All}]}, {name: get_entity_history, description: Recent activity history for a named entity., params: [{name: name, type: string}]}, {name: get_approval_flags, description: Approvers with anomalous delay rates., params: []}, # … ]system prompt 在启动时从这个注册表生成。当 LLM 推理要调用哪个工具时它看到的描述与分发器能执行的内容完全匹配。在一个地方添加工具prompt 和分发逻辑保持同步。文档和实现之间没有漂移。6、ML 作为数据而非端点第二个设计选择是将 ML 输出视为数据资产而非实时推理端点。风险评分由批量训练作业产生在我们的案例中是对历史合规模式的随机森林并写入表中。编排层像查询任何其他数据源一样查询该表。这保持了 Agent 延迟较低将 ML 生命周期与 Agent 生命周期分离并提高了可观察性——你可以查询 Agent 使用的相同评分来验证其推理。6、实践中的编排循环抽象的架构很简单。以下是当经理提问时编排实际做的事情 *为什么上周合规率下降了* **第 1 轮 - 建立基线。** LLM 选择 get_weekly_kpis(week_ending2026-03-07)。→ total_records: 847 | on_time: 731 (86.3%) | late: 93 | missing: 23 上一周: 94.1% - 下降 7.8 个百分点系统现在知道合规率下降了但数字不是解释。它继续。 **第 2 轮 - 识别下降集中在哪里。** LLM 选择 get_risk_scores(levelHigh)。→ 23 个实体标记为高风险 区域分布东北地区占 23 个中的 14 个61% 平均连续迟到周数: 3.2数据显示了地理集中性。东北地区占比过高。 **第 3 轮 - 调查结构性原因。** LLM 选择 get_approval_flags() 来检查问题是在提交端、审批端还是两者。→ 4 位审批人迟到率 50%过去 4 周 其中 2 位在东北地区 平均审批延迟同比增加约 40%现在 Agent 有了因果链东北地区的审批延迟与合规率下降相关。 **第 4 轮 - 综合并回答。** LLM 返回 final_answer *合规率从上周的 94.1% 下降到 86.3%-7.8 个百分点。 下降集中在东北地区该地区占 23 个高风险实体中的 14 个。 两位东北审批人的迟到率超过 50%平均审批延迟比前一周增加约 40%。 建议本周优先跟进东北经理的审批流程。*这个答案需要四次操作每次都建立在前一次之上。没有单一工具调用能产生它。调查路径——基线 → 风险分布 → 审批分析 → 综合——从数据中涌现而非来自预定义的工作流。执行相同调查的人类分析师会打开仪表板、按周过滤、扫描 KPI 瓷砖、切换到风险视图、按区域过滤、打开审批人报告、交叉引用两个视图并起草摘要。那至少是 15 分钟的手动导航。编排的 Agent 在不到 30 秒内完成了它。编排循环可视化展示 4 轮调查流程——每步都有决定/执行/观察数据从一轮流向下一轮。## 7、编排不太有效的地方编排最适合具有清晰分析路径的调查性问题——可以分解为数据检索和比较的问题。当问题需要主观判断或数据无法捕获的组织政治、仓库尚未反映的实时数据、或超出相关性的因果推理时它变得不太有效。承认这些边界很重要。编排扩展了分析系统能自主做的事情。它不能替代人类对模糊或高风险决策的判断。8、塑造系统的设计决策每轮一个工具。模型被指示每个 LLM 响应调用一个工具。这使循环可预测、可调试且易于记录。代价是延迟——4 工具调查需要 4 次 LLM 往返。在实践中大多数查询在 2-3 轮内解决我们的 p95 响应时间保持在 8 秒以下。有界的轮次。无界循环是可靠性风险。如果 LLM 混淆了有界的循环我们用 6 轮确保系统仍然返回有用的东西。当达到上限时系统从收集到的任何内容综合摘要而不是返回错误。服务器端日期解析。早期且持续的问题LLM 幻觉日期。上周可能产生两周前的星期五。我们通过在服务器端确定性地解析所有时间引用来解决这个问题。LLM 仍然选择调用哪个工具并解释用户意图——我们只覆盖具体日期。这种混合模式LLM 负责推理确定性代码负责事实被证明是必不可少的。格式化输出优于原始 JSON。早期工具实现返回原始 JSON。我们切换到带有上下文注释的格式化文本表例如“per server calendar”、“(14 of 23)”LLM 综合质量显著提高。当工具输出类似于人类分析师在工作笔记中写的、而不是 API 会返回的东西时LLM 推理得更好。9、观察结果在几周内迭代了编排设计、工具库和前端。原型的观察多步骤调查时间从约 15 分钟下降到约 30 秒。需要导航仪表板、过滤视图和交叉引用报告的查询变成了单一的对话交互。10 个标准合规问题中有 8 个无需人工干预即可回答。KPI 摘要、风险识别、审批人分析和经理简报自主解决。两个失败涉及模糊的时间引用——后来通过服务器端日期解析解决了。每查询平均轮次2.1。标准查询最大值4。简单问题KPI 查找在 1-2 轮内解决。调查性问题“为什么 X 下降了”需要 3-4 轮。20 个领域工具覆盖了完整的分析面。我们从 8 个开始增加到 20 个。最后的添加是细化拆分同一指标的周度与范围变体而非新功能。工具数量不是瓶颈——工具设计才是。每个工具的质量更多取决于对数据和业务上下文的理解而非任何 LLM 特定的知识。10、入门指南如果你想在自己的分析数据上试验编排这是一个实用的起点。识别 3-5 个高频查询。从你的团队已经在回答的问题开始——分析师每周一运行的那些、每个冲刺刷新的仪表板。每个都变成一个工具带清晰描述、类型化参数和 SQL 支持实现的命名函数。实现循环。使用本文中的决定-执行-观察模式。它适用于任何 chat-completion LLM。循环与模型无关智能来自工具和 LLM 对它们的推理。尽早添加护栏。三个会节省调试时间的护栏服务器端确定性日期解析、轮次上限6 是好的默认值到达时进行部分综合、以及工具白名单以便只有注册工具可以执行。迭代工具输出格式。工具返回给 LLM 的文本比你预期的更重要。带行数、日期范围和简要注释的干净表格比原始 JSON 产生更好的综合。11、值得考虑的框架和工具LLM——OpenAI、Anthropic、Databricks Model Serving 或本地模型。任何 chat-completion API 都可以。数据——Databricks SQL、SQLAlchemy 或直接针对仓库的 REST API。编排——ReAct 循环约 40 行。LangChain 和 LlamaIndex 提供 Agent 抽象但对于领域特定工具自定义循环提供更多控制和更少的调试层。前端——Flask 或 Streamlit 用于原型React 用于生产。MCP模型上下文协议——将工具包装为 MCP 服务器使它们可被多个 AI 客户端Cursor、Claude Desktop 等访问而无需耦合到单一提供商。12、结束语Agentic AI 系统通常与高级模型或新框架相关联。在实践中核心架构转变更简单且更根本。编排引入了一个控制层决定使用哪些工具、按什么顺序、基于哪些中间结果。它将分析系统从静态管道转变为动态的、目标驱动的工作流。从仪表板到 Agent 的转变不是替换现有组件。而是引入一个能协调它们的层——一个像分析师一样对数据推理的循环但更快且不需要用户知道去哪里看。组件是熟悉的。架构是一个循环。重要的工作在于工具设计、护栏以及保持系统扎根于它能实际接触的数据的纪律。随着 Agentic 系统成熟竞争优势将不属于拥有最强大模型的人。它将属于对自己的数据、领域以及编码了多年机构知识的分析工作流有最深理解的人。编排层只是让这种理解变得可组合。从循环开始。其余随之而来。原文链接为数据分析管道增加编排层 - 汇智网