Agent 时代，人到底负责什么

生产级 Agent 的分水岭，不在于能不能生成，而在于结果能否被验证、能力能否被度量，以及能否在生产运行中持续学习。

8 月 1 日，ChinaJoy 期间，ThinkingAI 在上海举办 Agentic Growth 全球泛娱乐行业峰会。ThinkingAI 联合创始人兼 CTO 周津围绕 Agent 如何进入真实业务流程进行了分享，并在现场播放了一段两分钟的完整链路实录：一个人带着 Agent，从发现问题，一直跑到结果被验证。

以下内容根据现场演讲整理。

Agent 每天都在跑，

为什么增长闭环还没有跑通？

过去一年，Agent 已经从演示走进日常工作。很多团队每天都在用它生成内容、做分析、执行任务。但让 Agent 跑起来，不等于跑通增长闭环。

真正需要跑通的，是一条完整链路：问题被发现之后，动作能不能接着发生；动作发生之后，结果能不能被验证；验证完成之后，经验能不能进入下一轮。

能生成，只说明 Agent 开始工作了。结果能不能被验证，Agent 在这条链路上的能力能不能被度量，运行中产生的经验能不能留下来，才决定它有没有真正进入生产。

我想从一个很普通的问题讲起。

一个玩家连续多次进入商城，一件道具也没买。他没有离开，还在反复进店。难的不是看见“购买为零”，而是回答接下来的三个问题：为什么没买？现在该做什么？做完有没有用？

这三个问题必须连在一起。为什么没买，决定做什么；做了什么，决定怎么验证。只回答第一个，得到的是分析报告；只做第二个，是在盲发礼包；只看最后的结果，连“有效”是相对谁而言都说不清。

过去，这条链路要经过运营、数据、产品和开发。问题每交接一次，目标、口径和上线条件都要重新解释。运营说“把逛了没买的人圈出来”，数据还要继续确认：最近几天算“逛”？买过一次礼包的算不算“没买”？一来一回，时间过去了，用户状态也变了。

问题不在于谁不努力，而是工作流把理解拆散了。每个人只掌握一段，没人真正拥有从问题到验证的完整链路。

Agent 的价值不只是让某个环节更快，而是把链路重新接起来。链路交给 Agent 连续执行后，首先要划清一条边界：什么可以交给它，哪些判断必须留在人手里？

人和 Agent，

要进入同一个循环

现在谈人和 Agent 的关系，常见的答案有两个极端。一种是人牢牢主导，Agent 只是执行工具；另一种是把事情从头到尾交出去，人最后看一眼结果。

我认为两种都不成立。第一种没有释放 Agent 的能力，第二种把风险全部留给了人。

我们在实践里的分工很明确：Agent 负责把事情做完，人负责决定结果算不算数。

具体到刚才的增长链路，人只做三次判断：圈谁，用什么口径定义候选玩家；发什么，实验组和对照组采用什么策略；看效果，按什么指标和观察窗口判断。

数据校验、口径统一、人群生成、分流配置、动作执行、持续观察和结果回传，则交给 Agent 连续完成。

这样的分工没有削弱人的作用。人的工作变少了，难度却更高：要知道自己想要什么，说清判断标准，把模糊的目标拆到可以执行，最后为结果负责。

而且，人并不只在开头下指令、最后看结果。一轮执行完成后，Agent 会把指标、口径、版本和来源一起带回来，先停在人的判断门前。只有人确认结果可信、动作值得继续，它才会成为下一轮的输入。

目标要不要调整、结果算不算好、策略方向对不对，这些判断不能交给自动化。人是循环的一部分，不是站在流程外面签字的人。

这也解释了为什么口径如此重要。Agent 可以连续执行很多动作，但它不知道企业心里那个“差不多”究竟是什么意思。对 Agent 来说，口径就是行动边界。边界不清楚，它自行补全一次，后面的偏差就会被连续执行不断放大。

分工清楚之后，还有更难的一问：Agent 把结果交回来，人凭什么判断它是对的？

可信的结果，

必须能展开、能追溯、能复算

还是“逛而不买”这群玩家。最近七天还是三十天？看所有道具还是只看礼包？是否排除测试账号？人群名称没有变，口径一换，圈出来的却是两批人，后续动作自然也不一样。

所以口径必须在行动前定好。发错人不只是浪费预算，还会打扰本来不该被打扰的玩家。

这需要一个可治理的知识底座，统一两件事：怎么算，以及谁和谁有关。

怎么算，是把公式、筛选规则和权限统一下来。比如“触达后 24 小时购买率”，分子、分母各是什么，时间从哪里开始计算，都必须有同一个答案。谁和谁有关，是把玩家、商城访问、礼包购买和触达任务之间的关系讲清楚，否则 Agent 知道要找“被触达过的玩家”，却不知道该沿着哪条关系去找。

知识也不是写进去就算完成。候选内容先从埋点方案、看板和分群等已有资产中提炼，再经过人工审核和版本发布，最后才交给 Agent 使用。审核和版本，决定了这些知识能不能被信任。

有了这层基础，Agent 给出的每个结果都不再是一个孤立的数字。比如一次实验出现 36.5%，向下可以看到它来自 57 除以 156：分子是实验组中完成购买的 57 人，分母是成功触达的 156 人。继续往下，还能看到采用了哪个口径版本、数据来自哪些事件和任务记录，确保相同条件下能够重新计算。

因此，业务不必先“相信”Agent，只需要顺着证据往下检查。

不过，一个能查清来源的数字，还不能证明礼包有效。要回答“做完有没有用”，还需要对照实验。

现场演示设置了两组实验。两组采用同样的人群口径和观察窗口，唯一变量是礼包策略：个性化礼包组的转化率为 36.5%，通用礼包组为 20.5%，相差 16 个百分点。实验条件在结果出现前确定，结果出现后仍按同一口径复算。

这组数字要说明的不是某种礼包策略一定有效，而是一条增长链路必须能够回答：结果为什么发生，策略究竟带来了多少变化。

在这轮实验中，人提出假设，Agent 配置分流；人确认发布，Agent 运行观察；最后仍由人判定结果。人和 Agent 交替出现，假设、发布和判定始终留在人手里。

AB 实验和假设验证在 Agent 时代会更重要。企业需要一条经得起检查的因果链，而不只是看起来正确的答案。结果能够被复核，这一轮才算跑完；结果能够被复算，下一轮才有可靠的起点。

一轮跑通之后，

真正的能力要留下来

一条业务链路跑通之后，还要回答：今天的方法，半年后能不能继续用？

企业使用 Agent 的入口一直在变。有人从 IDE 调用，有人从 Cursor、Claude Code 或其他工作台进入，过半年可能又换一批。但底层的数据、方法和治理不应该跟着重做。

我们的做法是入口开放、底座保持一致。上层工具可以更换，大模型和 Agent 框架也可以替换；真正需要留下来的，是企业自己的数据、方法和知识资产。接入需要经过开放接口和命令行，并不是任何 Agent 都能直接连接。

资产能够留下来，方法也要能留下来。

企业不缺 Agent 的想法，缺的是第一件值得投入、也值得验证的业务场景。我们把长期服务客户时遇到的问题整理成《企业 AI Agent 实战场景案例手册》。它不是功能清单，而是帮助企业判断什么场景值得先做、哪里容易形成闭环、应该如何验收。

找到场景以后，还要把方法变成 Agent 能执行的东西。文档只是在讲方法，只有写清输入、步骤、权限、输出和验收条件，它才成为一个 Skill。

以“目标人群识别”为例，输入是业务口径和行为数据，输出是可复用的人群包，验收条件是名单可解释。每个人为什么被选中，都要说得清。写到这个程度，Agent 才跑得动，人也验收得了。

再往下一层，是 FDE（Forward Deployed Engineer）。过去十年，ThinkingAI 在服务客户的过程中积累了大量业务问题和对应的产品能力。到了 Agent 时代，我们把反复出现的高频场景沉淀为数据模型、Skill 和底层能力，再交付到客户真实的业务流程里，用业务指标验证效果。

判断 FDE 做得好不好，我们只看两件事：客户的业务指标有没有变化，产品里多了什么。

第一次遇到的问题可能是交付成本，第二次开始，就应该成为产品里已有的能力。被验证的结果进入客户下一轮策略，共性问题则沉淀到底层产品。这样，一次项目不会在交付结束时归零，而会成为下一次执行的起点。

回到开头，人和 Agent 到底是什么关系？

人要知道自己想要什么，也要说得清判断依据；Agent 负责连续执行，并把可复核的结果交回给人。每一轮都能被验证，经验才会变成方法，方法才会变成企业自己的能力。

没有验证，就没有下一轮。

《企业 AI Agent 实战场景案例手册》电子版现已开放领取，其中整理了 ThinkingAI 在服务客户过程中沉淀的典型业务场景、可落地的判断标准和验收方式。快来点击阅读原文领取吧～