很多人用 Agent，方式仍然和用 ChatBot 差不多。拿数据任务来说，业务问一个问题，Agent 返回一份结论，对话到这里结束。答案可能比传统 BI 更丰富，但圈人、定策略、建实验这些后续工作，仍然由人接着完成。

前段时间，我在「Coding Agent 能做数据挖掘吗」里写过一次用 Coding Agent 做会员流失诊断的经历。

最初我们深入看了几个高价值用户，很快得到一个结论：这批人偏好知识内容，因为内容供给没有跟上而流失。Agent 扩大样本、拉长观察周期后，这个判断被推翻了。知识型用户只占很小一部分，相当一部分会员到期后仍在使用产品，只是没有继续付费；离开之前，很多人的消费还经历了一段衰减。

文章写到分析结论就结束了。实际项目里，我们把后面的工作继续交给自建的 Data Agent。它集成了取数、画像、行为、圈人和实验分析等能力，会根据新的发现调整分析路径和策略，最后形成可以上线验证的人群和方案。

以前这些工作要在分析师、运营、数据开发和产品之间来回流转，现在都在一个任务里完成。

分析之后，继续圈人和做实验

分析做完后，Agent 接着把结论变成可以执行的人群。它按生命周期拆出三类用户：仍在消费但没有续费、消费正在衰减、长期沉默。再调用画像、原始行为和圈人能力，把分析中的判断转换成结构化条件。

候选人群出来后，Agent 继续分层抽样，检查圈出来的人是否符合最初的判断。长期偏好用来判断用户可能需要什么内容，近期原始行为确认需求是否还在，结构化字段则控制会员状态、活跃时间和触达资格。

实际圈选结果再次改变了策略。最初设想的知识型人群很精准，但规模很小；按生命周期和消费状态识别出的人群规模大得多，也更值得优先干预。业务问题随之从「怎样召回已经流失的人」，变成了「怎样在流失过程中更早介入」。

接着，Agent 查找相似人群做过的历史实验。过去一些覆盖面很宽的触达没有产生预期收益，还影响了长期价值。这条证据排除了「多发广告或优惠」的简单做法，策略转向内容召回、续费修复和更严格的频控。

对仍在消费但没有续费的用户，在内容需求出现时提醒会员权益，文案结合近期稳定消费的题材和具体内容；对消费正在衰减的用户，优先做内容续接，减少直接的价格刺激；长期沉默用户的证据最弱，降低优先级并控制触达成本。

Agent 最后准备好几组可执行的人群条件，以及对应的内容策略、触发时机、频率上限、退出条件、核心指标和保护指标。它可以直接创建实验配置，用户只需要在 A/B 系统里做最后确认。

分析原因 → 识别人群 → 生成策略 → 创建实验 → 上线执行 → 读取结果

这条链路里有人工确认，但没有人工接力。业务方不用下载名单、复制圈选条件，也不用把分析结论重新解释给下一组人。

这条链路依然是离线的。Agent 负责分析、准备策略和创建实验，不参与每次线上请求的实时决策。用户确认后，具体策略由现有的推荐模型和业务系统执行。

串起来之后，变化在哪里

单独看每一步都不是新的。数据平台可以查数，画像平台可以看用户，圈人平台可以创建人群，实验平台可以做效果评估。只是过去这些系统各管一段，整项工作仍然由人在中间组织。

当这些能力被 Agent 串起来后，分析中的新发现可以直接改变后面的执行。知识型人群规模不足，Agent 会继续寻找更大的可干预人群，不用停下来等人重新提需求。历史实验显示宽泛触达有风险，它就调整策略和约束，不把错误结论带到线上。

最直接的价值是少走弯路。最初的小样本结论如果直接上线，资源会投向一个规模很小的人群，触达方式也可能重复过去的失败。

同一份分析也可以支持多组实验。Agent 把生命周期、内容需求和触发时机组合成不同方案，不必把所有用户塞进一个大人群，使用同一套策略。

策略上线后，原任务会按预先设定的观察周期读取结果，同时检查消费、付费和保护指标。有效的判断进入下一轮策略，失败的尝试留下适用边界。这份分析继续留在任务里，供后续策略读取。

把数据平台变成 Agent 的工作接口

传统的数据平台按产品划分能力。查数在分析平台，用户理解在画像平台，人群在圈选平台，效果验证在实验平台。任务状态和业务判断却留在人身上。换一个系统，就要重新解释一次目标和上下文。

要把这项工作交给 Agent，不用推倒重建这些平台，但要改变它们提供能力的方式。

原来的产品能力Agent 需要的工作接口
在分析平台输入查询、查看结果接收明确的查询任务，返回结构化数据和可处理的错误
在画像平台逐个查看用户按用户和时间范围读取画像、记忆与原始行为
在圈人平台手动配置条件把自然语言判断转换成条件，返回规模、样本并创建人群
在实验平台搜索和配置实验查询历史实验、创建实验配置，并在用户确认后执行
各平台分别登录和操作继承发起人的权限，记录整条任务的调用过程

光有接口还不够。Agent 还要知道应该查什么数据、指标采用什么口径、结果是否异常，以及过去的实验说明了什么。表结构、指标定义、加工逻辑、领域知识和纠错记录，需要进入它可以读取的六层 Data Context。否则它也可能沿着错误口径把整条链路跑完。

每个接口还要有稳定的输入输出。取数、画像、行为查询、分层抽样、圈人和实验分析被封装成工具，业务上怎么使用这些工具则整理成 Skill。数据团队开始建设可以被反复调用的能力，也就是从写 SQL 转向训练 Agent。

权限也要从单个平台里的账号控制，延伸到整条任务。只读查询可以自动完成，创建人群和实验这类会改变外部状态的动作必须留下记录，并在执行前让用户确认。

实验上线后，平台还要保留最初的假设、人群条件和策略版本，把结果送回原任务。经过验证的结论进入后续 Context，稳定的过程沉淀为 Skill，继续参与下一轮计划。

怎么判断 Agent 真的在干活

ChatBot 交付一份答案，评估时主要看回答是否正确。Agent 的答案只是中间结果，还要看任务被推进到了哪里。

先看任务完成率。一条业务问题最后停在分析报告，还是形成了真实人群、实验配置和可追踪的结果，是完全不同的完成度。

再看人工接力次数。用户确认权限或实验上线属于必要的控制点；如果还要人工下载数据、重写圈人条件、重新解释结论，这项工作仍然没有交给 Agent。

还要看从问题到实验的时间。分析准确，但几周后才进入业务，对业务的帮助仍然有限。一条有效洞察要能更快进入验证。

最后看线上增量。任务完成率和执行速度说明 Agent 能不能把工作做下去，线上实验回答它有没有带来业务价值。实验结果还要进入下一轮策略，否则下次仍然要从头开始。