从Coze谈起 | AIBI从Workflow到Agent的演进之路

当业务负责人提出这样的分析要求时，AIBI 不能预设“转化率一定下降”，也不该一上来就给出原因。它必须先取得本周与上周可比较的事实，再依据业务规则判断波动是否异常，才能决定任务是否需要进入归因分析。

“因为业务最先需要的不是一条更自由的路径，而是一个可信的答案。”

早期AIBI的能力侧重智能问数。针对“本周与上周的新客转化率是多少”这一问题，难点远不止生成一条 SQL。什么算新客？转化发生在哪个时间窗口？分母采用访问人数还是有效触达人数？这些都会影响最终的数据结果。不同负责人能够查看的数据范围也不同；即便口径明确，查询还可能因字段、条件或数据源变化而需要修正。

因此，AIBI最初用一条完整的问数Workflow 管理这些环节：完成口径与知识准备，定位指标和数据，生成并执行查询，必要时修正，再交付数据、图表与依据。对于案例中的第一次问数“本周与上周的新客转化率是多少”，这条固定路径用于统一两周的口径，并保留查询依据，便于业务负责人继续追问和复核。

回到开头的问题，系统应先完成“问数”，取得连续两周且具备可比性的数据。

• 如果数据没有明显异常，系统直接输出结果和数据依据。

• 如果发现异常，再根据实际证据，进一步从渠道、人群或触点等维度分析，并生成报告。

因此，后续的归因分析和报告生成，是否执行、分析哪些维度，都取决于前面的数据结果。

如果只是把归因和报告流程直接接在问数流程后面，那么即使没有异常，系统也会把整条流程跑完，造成不必要的处理。即使增加条件分支，系统也无法提前确定异常后一定要检查哪些维度，因为具体方向需要根据刚获得的数据和证据来判断。

另外，如果业务方没有明确的异常判断标准，系统只能描述数据发生了什么变化，并请求业务方补充判断标准，不能擅自设定阈值。

如果把这些判断全部提前写进 Workflow，Workflow 就会逐渐变成一棵庞大的条件树，既难以理解，也会不断增加维护成本。

固定 Workflow 保证“这一步怎样正确完成”，却不擅长应对需要持续依据新证据调整的任务路径。当 AIBI 从单次问数走向归因分析和人群洞察，原先只在流程内部使用的一些结果，需要暴露给 Agent，成为下一步决策的依据。

先让不同业务能力成为独立的Tool

我们最开始的设想很直接：把问数Tool、分析Tool、人群圈选与洞察 Tool分别独立出来，每个Tool内部继续使用已经成熟的完整 Workflow。Agent不再面对一条包办所有工作的总流程，而是先判断任务需要哪种业务能力，再调用对应Tool。

这一步让 Agent 获得了业务层选择权：简单问题只调用问数，发现异常后可以继续分析，需要理解目标人群时再进入人群圈选与洞察。各领域原有的口径、权限和执行规则仍留在 Workflow 中，成熟能力不必推倒重来。

❌ 没有解决什么？

但在这一阶段的拆分方式下，选择权只停留在 Tool之间，Tool内部仍是黑盒。新客转化率需要按渠道补查时，问数Tool已经召回的业务知识、指标和数据引用，对Agent仍然不可见，也无法直接交给分析Tool复用；SQL生成或执行一旦失败，也不能只进入修正环节，而是需要重跑整条问数Workflow。一次局部失败因此变成多轮模型与工具调用，响应时间被明显拉长。

按业务决策边界开放内部能力

第二次拆分开始进入问数Tool内部，但目标不是制造更多接口，而是逐项回应第一阶段遗留的问题：为知识复用建立明确边界，让数据引用可传递，让SQL失败能够从局部恢复。

以标准自然语言问数为例，先确认业务口径；联网搜索只补充外部背景，查询知识召回则补足事件、标签、用户属性与数据约束；随后按需召回指标并确认表结构。Agent 完成时间校验、需求拆解与可行性判断后，对每个子需求调用需求提炼、SQL 生成与执行能力。如果执行明确失败且原因可读，Agent 再调用SQL修正能力，并重新执行。本场景最多重试 3次，前面已经取得的知识、指标和表结构不必重新召回。

但打开黑盒，不等于把每个代码方法都变成Tool。若拆到鉴权、字段校验或格式转换，模型面对的只是更多技术步骤，真正的业务选择反而被淹没，还可能绕开强制规则。一项能力是否应该独立，关键看Agent是否需要单独选择这个动作，并根据它的结果决定下一步。

具体可以用下面四个问题判断：

把这四个判断放回新客转化率的案例来看，问数负责取得本周与上周的数据；确认存在异常后，分析Tool再负责定位影响因素。问数结果会决定是否进入分析，因此问数和分析是两项不同的业务能力，可以分别成为Tool。

再看问数内部：指标召回、SQL执行等环节会产出影响后续步骤的结果。如果Agent需要根据这些结果决定复用还是重取、修正还是停止，相关业务动作就需要通过Tool暴露清晰的输入和结果。这里的“完整业务结果”可以是一份报告，也可以是下游能够直接使用的指标定义、数据引用或查询结果。

权限检查、参数校验和安全控制则是每次执行都必须遵守的规则，应由Tool内部的确定性流程强制执行。拆分应围绕 Agent 需要判断和选择的业务动作展开，保留动作内部必要的执行约束。

经过这两轮拆分，AIBI逐步把任务的选择权交给 Agent：先将问数、分析等业务能力独立出来，让Agent能按需调用；再打开过重Tool的内部边界，让知识与数据定位结果可以复用，SQL执行失败也能局部修正。这样，当经营分析需要根据查询结果继续补查或进入归因时，Agent就能利用已有结果调整路径，减少重复准备和整条流程重跑。

但能力拆开之后，如何保证这些结果能在不同任务、会话和执行顺序下被可靠使用？这就需要进一步明确Tool之间如何传递依赖。

把隐藏依赖变成显式契约

所谓无状态Tool指的是：Tool不依赖自己记住的历史调用信息，而是根据本次明确传入的参数和运行时提供的可信上下文，完成一次业务动作。无状态Tool的关键是让每次调用所需的依赖都明确可见：业务参数和上游结果通过输入显式传入，任务进度及各步骤的结果由Agent或运行时记录和传递，Tool无需暗中读取前序调用留在会话中的状态。

例如，AIBI完成问数后，如果需要继续分析转化率波动，Agent就应将本次归因目标，以及上游已经确认的指标与数据表引用，显式传给分析 Tool。如果分析Tool默认“上一轮已经准备好这些数据”，换一个任务、会话或执行顺序，就可能失效。

要让这种组合可靠运行，接口还需要把三类信息说清楚：Agent提供哪些业务参数，运行时注入哪些可信上下文，以及Tool如何返回可判断的执行结果。

能力拆分之后，AIBI还需要解决一个实际问题：如何让各个Tool围绕同一个业务目标协同工作，并在结果发生变化或某一步失败时继续推进任务？

回到开头“判断本周新客转化率是否异常，如有异常再定位原因”的请求。AIBI由Agent统筹任务：先确认业务口径、定位指标与数据，再调用 SQL生成与执行能力，取得本周与上周可比较的数据。取得数据后，Agent根据业务规则与查询结果决定下一步：

✅ 没有异常

Agent依据前述规则与问数证据，交付两周数据、变化幅度和判断依据。任务停在可信事实上，不额外分析；标准不明确时，则请求负责人补充判断标准。

❌ 存在异常

问数结果成为Agent继续归因分析的依据。Agent按分析契约构造本次归因目标，并把上游data中确认的受治理指标与数据表引用原样传入；分析Tool据此按渠道、人群或关键触点展开分析，结合证据解释波动并形成报告。若某一步失败，Agent根据reason决定补足条件或调整路径，保留前面已经取得的可用结果，而不是让整条任务从头开始。

企业知识在这里也得到了复用：同一份指标定义或活动说明，可以帮助问数确认口径，也可以帮助分析解释波动。各Tool内部仍可保留确定的Workflow：查询经营数据时，继续执行权限校验与安全控制；分析波动原因时，继续按既定步骤组织证据、生成结果。Agent只需编排对任务方向有意义的业务动作，由Tool完成各自内部的执行步骤。

阅读原文