交完三百万学费，我才明白Agent是投放自动化的终极答案

自动化规则解决的是”怎么执行”，Agent解决的是”该不该执行”。这一层判断力的缺失，就是三百万学费的根因。

Hi，朋友们好，又到了更新日。这篇文章我准备了挺久，因为要把一些不太光彩的事情摊开来讲（额滴2023年终奖啊😭😭😭😭）。但我想了想，踩坑的经验本身就是最有价值的内容——你在任何地方都能看到”我们做了什么牛逼的系统”，但很少有人告诉你”我们的系统是怎么把钱亏掉的”。

今天就讲这个。

本篇是”意图驱动的增长中台”系列的第六篇，前面几篇从经营终局、系统协议化、模型选型、素材引擎几个角度把框架搭完了。这篇回到投放执行层（上周和其他同学聊了聊，他倒是挺多想法，但是执行做盯盘发昏的不行，我觉得还是得想清楚目标和线路，怎么做很关键，里面的数据指标和预期怎么定，落地节奏是什么怎么规划得先想好了，不然应该建设不了这么长链复杂的系统），今天我就从从真实踩坑案例出发，讲清楚一个问题（我的个人看法嗷）：Agent在投放自动化里的边界到底在哪，跟现有的规则系统是替代关系还是共建关系，以及产品层面到底怎么落地。 前面的文章篇幅有限只能说我的大体思路但是没法描述落地链路，现在的探索阶段欢迎朋友们一起脑暴，我们逐步完善整个系统。

废话不多说，先上那个我职业生涯第二贵的故事（还有高手？是的还有高手，在我的职业生涯300w亏损也就还好😢）。

一、先讲那个三百万的故事

Case 1：一条错误配置，三百万打水漂

2023年，我们的自动化投放系统出了一次严重事故。

起因很简单：运营在配置投放策略的时候，把”买转化”配成了”买曝光”。这个操作本身就是一个人为失误，但如果系统有最基本的语义校验——“你设定的ROI目标是1.2，但你选的出价方式是买曝光，这两者逻辑上矛盾”——这个错误就会在提交的那一秒被拦住。

但我们的系统没有这层校验。它是配置驱动的，运营配什么它就执行什么，不问为什么。

更要命的是，系统有一个”自动追加预算”的功能。这个功能的设计初衷是好的——当计划跑量势头好的时候，自动加钱让它继续跑。但叠加上”买曝光”这个错误配置，效果就变成了：系统在疯狂烧钱买无效曝光，越烧越多，还自动给它加预算让它烧得更快。

整个过程没有任何熔断机制介入。没有任何节点去判断”这个消耗速度和转化数量的比例是不是严重异常”。

再叠加一个背景条件：三方数据平台没有T0（实时）的数据看板，数据回传有延迟。等团队发现消耗异常的时候，三百多万已经出去了。

三百万，几个小时，没了。

这不是某个人的责任。这是系统的结构性缺陷——它有执行力，但没有判断力。它会忠实地执行任何指令，包括错误的指令。

Case 2：控损规则杀死起量计划

为了防止再出Case 1这种事故，我们加了大量的控损规则（其实没做，这是来新公司先做的功能，笑嘻了）。逻辑很直觉：ROI低于阈值就关停，消耗超过上限就暂停，各种if-then写得密密麻麻。

结果新问题来了：投放起量有一个窗口期，前几个小时ROI数据经常是失真的——数据回传有延迟，转化归因需要时间。一条计划可能正在起量的关键节点上，ROI因为数据延迟暂时看起来很低，控损规则一刀切把它关了。

我们确实有复开机制——规则关停之后如果数据回正会自动复开。但投放的起量窗口转瞬即逝，被关停几个小时再复开，平台已经不给你流量了。等于这条计划被规则杀死了。

本质矛盾是：控损规则和起量逻辑在打架。 控损说”数据不好就关”，起量说”前期数据不准要忍”。两条规则各自都对，但放在一起就互相拆台。if-then规则处理不了这种需要”结合上下文做综合判断”的场景。

Case 3：每个人都有自己的”最优策略”

我们团队有多个投手，每个人对”测新”和”跟投”都有自己的一套逻辑。有人觉得应该快速放量看数据，有人觉得应该小额慢跑稳着来。有人喜欢看ROI 12h做判断，有人坚持要等ROI 24h甚至LT值。

（这图笑死我了 Minimax Image-01 99块每天可以干100张，但是我跑了二十张就这一张还行的）

每个人都有道理，谁也说服不了谁。

结果是什么？系统疲于适配每个投手的个人偏好。这个投手要加一个”我的模板”，那个投手要改一下”我的放量逻辑”，产品经理和研发被拖进无休止的需求迭代里，模块越来越多，功能越来越碎，但整体投放效果并没有变好。

研发资源在被个人偏好消耗，而不是在逼近平台算法的最优解。 每个投手的”最优策略”都是他个人经验的投射，但没有一个是真正针对平台推荐算法的全局最优。系统在适配人，而不是在逼近真相。

Case 4：基建很强，方向不明

到2026年，我们的自动化基建能力已经很强了——批量建计划、自动调价、自动关停、自动复开、素材自动裂变、预算自动分配，该有的都有。

但有效率一直在走低。

系统什么都能干，但不知道该干什么。它有一堆工具，但没有一个”经营意图”在驱动这些工具。就像你给一个人配了全套厨具，但没告诉他今晚做什么菜——他只会把每个锅都烧热，然后等人来告诉他下一步。

自动化解决的是”怎么做”的问题，但”做什么”和”为什么做”这两层，它完全是空白的。 这就是为什么基建越强、功能越多，反而越迷茫——工具多了但方向没有，等于给迷路的人发了一辆更快的车。

二、四个Case的统一诊断：规则死在哪，Agent活在哪

把四个Case放在一起看，会发现一个共同的结构性问题：if-then规则只能处理确定性场景，但投放中最贵的决策全在模糊地带。

逐个拆一下，Agent在每个Case里能做什么，以及它的边界在哪。

Case 1 → Agent能力：语义级校验 + 异常模式识别

规则系统看到的是”运营提交了一个配置，格式合法，执行”。它不理解配置的语义。

Agent能做的是在配置提交的那一刻做一层语义校验：你的ROI目标是1.2，但出价方式选的是买曝光——这两者逻辑上矛盾。Agent会拦住这条配置，要求运营确认”你确定要这么做吗？”

即便配置通过了，Agent还能在执行过程中做异常模式识别：消耗速度飙升但转化量没跟上，这个模式跟”买错了出价方式”的历史Case高度吻合——触发预警，要求人工确认。

Agent的边界：它能识别”这个配置跟目标矛盾”，但它判断不了运营的”本意”到底是什么。也许运营就是想做一波品牌曝光呢？所以Agent的正确做法不是直接拦截，而是”拦住+确认”。确认通过，放行；确认超时，熔断。这个机制比无脑执行和无脑拦截都要合理。

Case 2 → Agent能力：上下文感知的软判断

规则看到的是”ROI < 阈值”→ 关停。它不管ROI低是因为数据延迟还是真的效果差。

Agent能做的是结合上下文做软判断：这条计划刚起量2小时，历史上同类计划的ROI在前3小时都偏低，而且当前的点击率和完播率趋势是向上的——这大概率是数据延迟导致的ROI失真，不应该关停。

或者反过来：这条计划已经跑了8小时了，ROI还是低于阈值，点击率也在下滑——这是真的不行，应该关停。

同样的ROI数字，不同的上下文，对应的决策完全不同。这是if-then规则做不到的，因为规则没有”上下文”的概念。

Agent的边界：当Agent自己也拿不准的时候——比如数据模式既不像典型的”延迟失真”也不像典型的”效果差”——它不应该强行做判断，而是把决策权交给人。“我不确定这条计划该不该关，当前数据模式是XX，请你看一下。“这比规则的一刀切强一百倍。

Case 3 → Agent能力：对齐平台算法，而非适配个人偏好

系统之前在做的事情是适配每个投手的偏好，结果是系统越来越碎，效果没有收敛。

Agent能做的是跳过个人偏好，直接对齐平台算法的最优逻辑。不是”张三觉得应该看ROI 12h”或者”李四觉得要看LT”，而是”根据这个品类在这个平台上的历史数据，哪个指标组合跟最终跑量效果的相关性最高”。

Agent输出的不是某个投手的经验复刻，而是基于数据的”平台最优策略”。测新用什么逻辑、跟投看什么指标、放量的节奏怎么控——这些不再因人而异，而是有一个统一的、持续优化的策略基准。

Agent的边界：Agent的策略建议不能一上来就覆盖所有人的判断。需要一个验证期——Agent的建议和投手的实际操作并行跑一段时间，看谁的结果更好。数据证明Agent更优的场景逐步交给Agent，数据证明投手更优的场景保留人工。不是一刀切替代，是用数据说话的渐进式迁移。

Case 4 → Agent能力：给自动化系统装上经营意图

自动化系统有工具没方向，Agent能做的是给每一个自动化动作注入”为什么”。

不是”ROI低于1.2就关停”这种无脑规则，而是”当前的经营目标是在ROI不低于1.1的前提下最大化消耗，因此ROI在1.1-1.2之间的计划应该保留观察而不是直接关停”。

同一条规则，在不同的经营意图下，执行方式完全不同。“保ROI”和”冲消耗”是两个不同的意图，对应的关停阈值、调价幅度、预算分配策略全都不同。Agent把经营意图翻译成具体的执行参数，自动化系统按参数执行。

Agent的边界：经营意图本身需要人来定义。“这个月的目标是守ROI还是冲规模”——这是老板或者投放负责人的判断，Agent不创造意图，Agent执行意图。但它能把一句模糊的意图（“ROI守住1.1，尽量多花钱”）拆解成一整套可执行的自动化参数，这是它的核心价值。

三、Agent和自动化系统的关系：分层共建

讲完四个Case，结论已经很清楚了：Agent不是来替代自动化规则的，它是来补上规则系统缺失的那一层——判断力。

两者的关系是分层共建：

规则层：处理确定性场景

有些事情不需要判断，规则做得比Agent好：

• 参数格式校验（出价不能是负数、预算不能超过账户余额）

• 硬性约束（单日预算上限、频次控制、黑名单过滤）

• 确定性触发（余额不足告警、审核不通过通知）

这些场景特征是：条件明确、不需要上下文、错了就是错了没有灰色地带。 用规则处理又快又准，没必要过Agent。

Agent层：处理模糊决策场景

Agent处理的是规则处理不了的部分：

• 语义级校验（配置跟目标是否矛盾）

• 上下文判断（ROI低是延迟还是真差）

• 策略优化（当前意图下应该怎么调价）

• 异常识别（这个消耗模式正不正常）

这些场景特征是：需要结合上下文、需要综合多个维度、同样的数据在不同背景下结论不同。 这是Agent的主场。

两层之间怎么交互

结合之前文章里讲过的逻辑网关架构，整个链路是这样的：

Agent生成决策 → 规则层做硬约束校验 → 通过则执行，不通过则打回Agent重推

Agent不绕过规则层。它生成的任何决策——调价、关停、追加预算——都要过逻辑网关里的规则校验链。Agent是”参谋”，规则是”宪法”。参谋的建议可以被宪法否决，但宪法不能替代参谋的判断力。

这就是我之前在《全闭源精锐选型》里讲的Opus+Codex二元对冲的落地版本：Opus（Agent）出策略，Codex（规则+数学校验）做审计。两层叠在一起，既有判断力又有约束力。

四、产品设计：盯盘Agent到底长什么样

架构讲完了，产品层面怎么落地？

Agent的形式：不是聊天框，是投放助手

很多人一听”Agent”就想到ChatGPT那种对话界面。在投放场景里不是这样的。

我们设计的Agent以投放助手的形式嵌入现有的投放后台系统。优化师可以在后台页面上把自己负责的计划托管给助手——选中计划，点击”托管给助手”，设定经营意图（保ROI/冲消耗/测新探索），助手开始接管盯盘。

托管之后，优化师不需要盯着投放后台了。助手会通过钉钉跟优化师做交互——这是关键的产品决策：交互界面不在投放后台，在钉钉里。

为什么选钉钉？因为优化师的工作场景本来就在钉钉里。他们不会一直开着投放后台的页面，但钉钉是一直开着的。把Agent的交互放在钉钉里，等于把盯盘能力嵌入了他们已有的工作流，不增加新的操作负担。

系统链路

完整的链路是这样的：

几个关键设计：

MCP服务是Agent调用投放系统能力的唯一入口。Agent不直接操作数据库，不直接调媒体API，所有操作都通过MCP暴露的原子能力执行。这样权限可控、行为可追溯。

逻辑网关是之前文章讲过的那套校验链——权限校验、风控熔断、状态对齐。Agent的每一个操作指令都要过这道关卡。

Agent消息MCP是一个专门处理Agent到人之间通信的协议层。Agent的输出（决策、建议、告警）通过这个MCP转化为钉钉消息格式（其实钉钉助理机器人也是Agent，这一步反而可以压缩，但是做了可以套个B端对话框说自己是投放Agent，对话花钱闹麻了），推送给对应的优化师。

钉钉助理是整个链路的最后一公里。它不是一个简单的通知机器人，而是一个支持双向交互的助理——优化师可以在钉钉里回复指令，这些指令会反向回传到Agent基础服务。

盯盘场景的具体交互流程

用Case 2（控损误杀起量计划）作为示例，走一遍完整的交互流程：

Step 1：异常识别
Agent监控到计划A的ROI跌破阈值。传统规则会直接关停，但Agent启动上下文分析：这条计划刚起量3小时，点击率在上升，完播率稳定，历史上同类计划前4小时ROI普遍偏低。Agent判断这大概率是数据延迟导致的ROI失真。

Step 2：决策生成
Agent生成决策：“保持计划A运行，暂不关停，设定2小时观察窗口。如果2小时后ROI仍未回升到X以上，再执行关停。”

Step 3：校验
决策进入逻辑网关。规则层检查：当前出价是否在允许范围内？保持运行的风险敞口是否在单计划预算上限内？校验通过。

Step 4：通知优化师
钉钉助理给优化师推送消息：

📊 计划A 盯盘提醒
当前ROI：0.85（低于阈值1.0）
助手判断：大概率数据延迟导致，建议保持运行
依据：起量3h内，CTR↑12%，完播率稳定，同类计划前4h ROI普遍偏低
处理方案：保持运行，2h后复检
⚠️ 风险敞口：预估最大额外消耗 ¥XXX

👉 确认保持  |  👉 立即关停  |  👉 我来盯

Step 5：优化师响应

• 点”确认保持”：Agent按方案执行，2小时后自动复检

• 点”立即关停”：Agent执行关停，记录优化师的判断供后续学习

• 点”我来盯”：Agent退出托管，控制权回到优化师手里

Step 6：闭环
2小时后Agent自动复检。如果ROI回升到阈值以上，推送”计划A已恢复正常”；如果没有回升，执行关停并推送”计划A已关停，最终ROI为X”。

通知分级：什么情况Agent自己干，什么情况要问人

这个分级直接决定了产品体验和风险控制的平衡：

L1（静默执行）：日常微调，影响范围小。比如出价微调±3%以内、非核心计划的常规优化。Agent自己干，干完在日报里汇总通知，不单独打扰。

L2（通知+自动执行）：有一定影响但在可控范围内。比如关停一条ROI持续偏低的非核心计划。Agent执行后通知优化师”我关了XX计划，原因是XX”，优化师如果不同意可以手动恢复。

L3（通知+等待确认）：影响较大或Agent不确定。比如Case 2这种”该不该关起量计划”的模糊判断。Agent给方案但不执行，等优化师在钉钉里确认。超时未确认走保守策略（比如降低出价但不关停）。

L4（告警+强制人工）：异常场景或重大决策。比如发现消耗模式类似Case 1的”配置错误”模式，或者单日预算变动超过30%。Agent触发告警，同时启动熔断，必须人工介入才能恢复。

五、Agent凭什么能分析清楚数据和策略？

前面讲了Agent能做”上下文判断”、能做”语义校验”、能做”策略优化”。但具体怎么做？它凭什么比一堆if-then规则更能分析清楚投放数据？

这个问题不讲清楚，Agent就还是一个概念。

Agent的数据分析不是”看数字”，是”读上下文”

if-then规则看到的数据是扁平的：ROI=0.85，低于阈值1.0，执行关停。结束。

Agent看到的数据是立体的。同一个ROI=0.85，Agent会去关联：

时间维度：这条计划跑了多久？3小时还是8小时？同品类计划的ROI曲线在前4小时通常是什么形态？当前ROI在历史同期计划中处于什么分位？

趋势维度：ROI是在往下掉还是在往上走？虽然当前值低于阈值，但过去1小时的趋势是每小时+0.05，照这个趋势2小时后能不能回到阈值以上？

关联维度：ROI低的同时，CTR和CVR是什么状态？如果CTR在涨但ROI在跌，大概率是数据回传延迟——转化已经发生了，只是还没归因回来。如果CTR也在跌，那就是素材真的不行了。

环境维度：今天是不是大促节点？大盘的eCPM水位是不是在波动？竞争对手是不是在集中投放？这些外部因素会影响ROI的短期表现，跟素材本身的质量无关。

这就是”上下文”。 规则看到的是一个数字，Agent看到的是这个数字背后的一张关系网。它能区分”这个数字代表真实的差”和”这个数字代表暂时的异常”，这是if-then规则做不到的根本原因。

具体怎么实现：数据MCP是基础

Agent不是凭空分析数据的，它需要一个结构化的数据接入层。这就是我们正在搭建的数据MCP的作用。

数据MCP把投放系统里散落在各处的数据源——媒体API回传的消耗数据、三方归因平台的转化数据、内部BI系统的ROI计算结果、素材库的素材表现数据——统一封装成Agent可调用的标准化工具包。

Agent在做决策的时候，不是一次性拿到所有数据然后算，而是按需调用：

Agent思考：计划A的ROI低于阈值，我需要判断是数据延迟还是真差。
→ 调用数据MCP：获取计划A过去3小时的ROI分钟级趋势
→ 调用数据MCP：获取计划A的CTR/CVR小时级趋势
→ 调用数据MCP：获取同品类计划在起量前4小时的ROI分布
→ 调用数据MCP：获取今日大盘eCPM水位
→ 综合以上信息，输出判断

这个过程跟一个有经验的投手盯盘时的思考路径是一样的——他也不是只看一个ROI数字就做决策，他会去翻各种数据面板、看趋势、看同类对比、看大盘环境。Agent做的事情本质上一样，只是它能同时盯几百条计划，而人盯不过来。

策略分析：不是拍脑袋，是基于历史验证的概率判断

Agent的策略建议也不是凭空生成的。它背后有一个策略知识库——记录了历史上所有的投放决策及其结果。

举个具体例子。Case 2那个场景：起量3小时，ROI低于阈值。Agent怎么判断”该不该关”？

它会去策略知识库里检索：历史上跟当前Case最相似的计划有多少条？它们在3小时节点被关停的结果是什么？被保留运行的结果是什么？

如果历史数据显示：起量前4小时ROI偏低但CTR上升的计划，被保留运行后有72%最终ROI回升到阈值以上，被关停的计划100%无法再次起量——那Agent的建议就是”保持运行，概率对你有利”。

这不是拍脑袋，是基于历史验证的概率判断。每一次Agent的建议都附带置信度和依据，优化师可以看到”Agent为什么这么建议”，而不是一个黑箱吐出来的结论。

策略知识库怎么建：不是数据仓库，是”决策病历本”

策略知识库听起来像是一个很重的东西，但它的核心设计思路其实很简单：记录每一次决策的上下文、动作和结果，形成一个可检索的”决策病历本”。

为什么叫”病历本”？因为医生看病不是靠背教科书，是靠看大量的病例积累出模式识别能力。投放策略也一样——Agent需要的不是一堆抽象的规则，而是大量真实的”这个情况下做了什么、结果怎么样”的案例。

一条策略记录长什么样：

{
  "case_id":"strat-20260315-0042",
"context":{
    "category":"小说推文",
    "platform":"巨量引擎",
    "running_hours":3,
    "roi_at_decision":0.85,
    "roi_threshold":1.0,
    "ctr_trend":"rising",
    "cvr_trend":"stable",
    "ecpm_environment":"normal",
    "material_decay_score":0.2,
    "intent":"冲消耗，ROI底线1.0"
},
"decision":{
    "action":"hold_and_observe",
    "made_by":"optimizer_zhangsan",
    "agent_suggestion":"hold_and_observe",
    "agent_confidence":0.82,
    "aligned":true
},
"outcome":{
    "roi_after_6h":1.15,
    "roi_after_24h":1.22,
    "total_spend":45000,
    "result_tag":"successful_recovery"
}
}

几个关键设计点：

Context要足够丰富。 不是只记”ROI=0.85然后关了”，而是记录决策发生时的完整上下文——品类、平台、运行时长、各项指标趋势、大盘环境、素材状态、当时的经营意图。上下文越丰富，后续的相似Case检索越精准。

决策和结果要关联。 每条记录不仅记”做了什么”，还记”做了之后怎么样”。保留运行的计划最终ROI回升了还是继续恶化？关停的计划如果不关停会怎样（通过同期对照组估算）？这些outcome数据是Agent学习的核心素材。

同时记录人的决策和Agent的建议。 在L2阶段Agent只给建议不操作，但我们同时记录Agent建议了什么和优化师实际做了什么。两者一致的Case确认Agent判断正确，两者不一致的Case对比最终结果看谁更优。这是Agent持续进化的数据来源。

知识库的检索不是关键词匹配，是相似度检索。 当Agent需要做决策时，它不是去搜”ROI=0.85的Case”，而是把当前的完整上下文向量化，在知识库里找上下文最相似的历史Case群。这跟我们在素材引擎里用向量检索找相似素材的逻辑一样——不是精确匹配，是模式匹配。

知识库需要持续维护。 随着平台算法更新、竞争环境变化，历史Case的参考价值会衰减。2024年的策略经验到2026年可能已经过时了。所以知识库要有时间衰减权重——越近的Case权重越高，越远的Case权重越低。同时定期清理那些”环境已经完全变了”的过期记录。

这套知识库的冷启动怎么解决？ 最初Agent没有历史Case可参考。冷启动阶段，知识库的初始数据来自两个来源：一是从现有投放系统的历史日志里回溯整理（虽然格式不完整，但能提供基础的context-decision-outcome关联）；二是把团队里最有经验的投手的决策逻辑做结构化采访，人工录入一批”专家Case”作为种子数据。

知识库不需要一开始就很大。几百条高质量的、上下文完整的决策记录，就够Agent在核心场景下做出有参考价值的建议了。随着系统运行，每天自然产生的新Case会持续充实知识库，Agent的判断会越来越准。

测新和跟投：Agent怎么解决”每个人逻辑不一样”的问题

回到Case 3。每个投手都有自己的测新和跟投逻辑，系统疲于适配。

Agent的解法不是”适配每个人”，而是建立一套统一的评估框架，然后用数据说话。

测新场景下，Agent会这样分析：

素材维度：这条素材的基因特征（钩子类型、节奏、视觉风格）跟历史爆款的相似度是多少？（来自素材引擎的归因结论）

人群维度：目标人群在当前平台上的竞争烈度如何？eCPM水位处于什么区间？

投放维度：当前的出价策略在这个品类里属于什么水位？偏激进还是偏保守？

历史维度：相似条件下（同品类、同人群、同出价水位），历史计划的起量成功率是多少？平均多久能跑出数据？

基于这些维度综合评估后，Agent会给出一个测新建议：“建议以X出价投放Y时长，观察Z指标。如果Z指标达到阈值A则加量，否则关停。”

这个建议不因人而异——它是基于数据和历史验证的”平台最优逻辑”。张三觉得应该看12h ROI、李四觉得应该看LT，Agent会告诉你：“在这个品类、这个平台上，用CTR+CVR做4小时判断跟最终LT的相关性最高，比12h ROI更准。”

不是谁的经验更对，是数据说了算。

当然，Agent的策略建议也不是从第一天就完美的。初期它的建议可能不如最好的投手，但随着数据积累——每一次测新结果都会反馈回策略知识库——它的判断会持续优化。而且它的优势在于：它不会忘记，不会情绪化，不会因为连续亏了三天就变保守。 它永远基于全量历史数据做概率判断。

六、落地路径：从现有系统怎么迁移过来

这套东西不可能一步到位。结合之前文章讲过的L1-L4演进路径，在盯盘这个具体场景里，迁移路径是这样的：

L1：自动化规则体系（已完成）

就是我们跑了几年的if-then规则体系。ROI低于阈值关停，消耗超限暂停，预算不足告警。有用，但有前面讲的四个结构性问题。

这一层不动，继续跑。Agent不是来替代它的，是来叠加在它上面的。

L2：Agent只建议，不操作（当前状态）

这是我们现在正在推进的阶段。数据MCP已经搭建完成，投放系统里的核心数据源（消耗、转化、ROI、素材表现）已经封装成Agent可调用的标准化工具包。Agent可以接入实时数据流，开始做”影子决策”——它会针对每一个需要人工判断的场景输出自己的建议。

但它不执行任何操作。优化师看到建议后自己决定做不做。

这个阶段的核心目的不是提效，是建立信任+收集数据。我们要看的是：Agent的建议和优化师的实际操作之间的一致率有多高？Agent建议”保持运行”而优化师选择”关停”的那些Case，最终谁的判断更正确？

这些数据是后续放权的依据。没有数据支撑的放权就是赌博。

接下来要做的是接入钉钉助理，让Agent的建议通过钉钉推送给优化师，而不是只在后台日志里。这一步完成之后L2才算真正跑起来。

L3：通过钉钉助理操作

当Agent在某些场景下的建议准确率达到足够高的水平时，开始放权：优化师可以直接在钉钉里点”确认执行”让Agent去操作，而不是自己回到投放后台手动操作。

这个阶段Agent有了执行权，但每一个操作都需要人点头。钉钉助理不只是通知渠道，变成了操作界面——优化师在钉钉里就能完成确认、拒绝、调整参数。

权限是逐步放开的：先放日常微调的确认权，再放关停/复开的确认权，最后放预算调整的确认权。每放一步都要看数据。

L4：Agent自动触发

终局状态。日常盯盘完全由Agent闭环完成，钉钉助理只发汇总日报和异常告警。优化师从”盯盘操作者”变成”策略定义者”——他们的工作是定义经营意图和调整Agent的边界参数，不是手动改出价。

L3和L4目前还没到。 我们现在的状态是：L1的规则体系稳定运行中，L2的数据MCP已经搭建完成、Agent基础服务在跑通核心的数据分析和策略建议能力，钉钉助理的接入还在设计阶段。

诚实地说，从L2完全跑通到L4，我估计需要半年到一年的时间。这不是一个买工具就能解决的事情，是一个需要系统搭建+数据积累+信任建立的过程。

七、结尾：三百万买的不是教训，是方向

回到开头那个问题：为什么Agent是投放自动化的终极答案？

不是因为Agent更聪明，是因为投放中最贵的决策——该不该关这条计划、该不该加这笔预算、这个ROI低是数据延迟还是真的烂——这些全在模糊地带。if-then规则处理不了模糊地带，它只会说”低于阈值就关”，不会说”等等，让我看看上下文”。

三百万的学费交在哪？交在”系统有执行力但没有判断力”这一层。Agent补的就是这一层。

但Agent不是银弹。它不替代规则（确定性场景规则更好），不替代人（经营意图需要人来定义），不替代基建（MCP、逻辑网关、多Agent协作这些工程基座必须先搭好）。它是在规则和人之间插入的一层”判断力”——让系统在需要的时候能停下来想一想，而不是无脑执行。

自动化规则解决的是”怎么执行”，Agent解决的是”该不该执行”。 这一层判断力的缺失，就是那三百万学费的根因。

我们正在补这一层。从设计到落地还有很长的路，但方向是清楚的。

下一篇会从工程视角拆这套系统的技术实现——MCP服务怎么设计、逻辑网关怎么跟Agent层对接、钉钉助理的消息协议怎么定义。感兴趣的可以等下周更新（这篇我可能顶不住了，我下周全是面试和BugFix的工作…可能来不及踩坑验证了）。

本文是”意图驱动的增长中台”系列第六篇。前序文章：《意图驱动的增长中台》《从操作面板到逻辑网关》《全闭源精锐选型》《投放素材的精致垃圾陷阱》《AIGC驱动的投放素材引擎设计》。对这个方向感兴趣的可以后台交流。

本文首发于微信公众号 kelovp.ai，原始发布时间为 2026年4月4日。查看公众号原文。