自动化不是终点：如何构建以 Agent 为核心的“意图驱动”投放中台？

上篇文章吸引到了部分投放的同学，他们对自动化+Agent的话题比较感兴趣，恰巧我最近也一直在探索Agent和投放系统的融合，今天我们一起探讨一下如何从投放中台过渡到自动化投放，再如何过渡到Agent投放。在开始文章之前我先叠个甲：我从21年开始做投放自动化,经历过数据系统、预估系统、自动化中台的完整周期。这篇文章不是纸上谈兵,是一些纯感悟。核心问题只有一个:投放自动化的尽头在哪里？我的答案是:Agent不是用来替代自动化,而是用来处理自动化做不了的事。

开头可以先放上视频内容：

自动化是堡垒，但不是万能药

在文章的开始我可以介绍下我对自动化系统的看法。公司和公司的不同、投放产品形态的不同都决定了自动化的侧重点在哪里。有能力建设投放工具和投放平台的公司一直把投放工具定位为效率套件，这本身没有什么问题。但是作为一个效率套件最核心的问题就是解决三方平台的复杂操作和做内部数据整合，市面的B端投放工具亦是这个思路。当投放的SKU变得复杂，变现侧的统计出现很多物理性阻碍的时候，投放工具平台就兼任的数据平台、预警平台的能力。所以投放混合变现APP和投放小程序以及投放一些直接的SKU的时候逻辑完全是三套，但是比较倒霉的是我面对的平台这三件事情都要做，大家解决问题有一些工具惯性，就会导致某些模块的残缺或者过重。

投放侧的自动化理想状态下讲的是从素材生产到广告创编再到效果追踪的全链路自动化，这里面每个Part面对的问题都相当复杂，过去我们尝试尽可能的去堆砌出一座完美的堡垒。但随着业务深入，我发现过度自动化的陷阱正变得越来越明显：

• 素材生产的“审美断层”： 自动化可以实现批量合成，但是所谓混剪的效果总是差强人意，不管是AIGC还是多模态内容理解，在当前阶段已经成为了成本黑洞

• 广告创编的“逻辑爆炸”： 当我们适配了多套投放逻辑、多个业务线，底层的代码逻辑已经膨胀到了难以维护、代码门槛高的程度。

• 效果追踪的“上下文缺失”：自动化只能做到“看到 A 触发 B”，但它无法处理“因为大盘竞争激烈导致的瞬时 ROI 波动”这种需要模糊判断的场景

所以，自动化系统的瓶颈不在于功能的多寡，而在于“逻辑的僵化”。 我们投入了大量的研发资源，却只是在用代码去死磕那些瞬息万变的业务 SOP。这种“重度研发、缓慢交付”的模式，在日新月异的投放战场上，已经显得有些力不从心。

非常经典的CASE就是做的工具总会有人从合理的角度提出难用的部分，我确实难以反驳运营提出的一些诉求，但是我知道开发成本又比较高。

从“硬编码”到“解耦执行”

我从开始做效果跟踪的时候就有想过引入通用的规则引擎来触发，这个是来自刚毕业的时候做订单发送的时候积累的一点经验，广告投放的效果跟踪存在大量的规则适配，我认为这部分如果只是单纯的做规则适配规则引擎再完美不过。起初，我寄希望于通过引入一套通用的规则引擎来解决这种无止境的适配。我想象中，只要把业务逻辑抽象成一套可配置的 If-Then 算子，就能把研发从运营无休止的需求中解绑。

但最终，这套规则引擎并没有落地。除了项目排期紧迫、不给研发“造大轮子”的时间这个现实因素外，更深层的考量在于我预判到了两个无法避开的深坑：

• 配置成本的“次生灾害”： 规则引擎看似灵活，但对于运营同学来说，学习一套复杂的配置语法（甚至是伪代码）的门槛，并不比直接提需求给研发低。最终结果往往是：研发不仅要开发引擎，还得负责帮运营写配置。这不过是换了一种形式的“接需求”，研发并没真正解脱。

• 非标场景的“逻辑塌缩”： 投放逻辑从来不是单纯的数学题。比如“素材由于平台政策微调导致的过审波动”或“特定节假日的流量瞬时倾斜”，这些带有强烈上下文背景的判断，硬核的规则引擎极难覆盖。强行去写，只会让规则库变得臃肿不堪，最后变成谁也看不懂的“黑盒”。

这一刻我意识到，我们不应该再试图用更复杂的“硬代码”去套死业务，而应该寻找一种“解耦执行”的新范式。

与其花三个月造一个可能上线即过时的规则引擎，不如直接把这部分“逻辑处理”的权力移交给更具通用推理能力的 Agent。我们要做的是 “能力的原子化”：研发不再负责写“如果 ROI 小于 0.5 且消耗大于 100 则关停”这种死逻辑，我们只负责提供一堆原子化的执行能力（Atomic Capabilities） ：比如“查询消耗”、“获取 ROI”、“执行关停”。

这种“解耦”带来的改变是颠覆性的：
研发的工作从“适配运营的每一个奇思妙想”，变成了“维护一套稳定、标准、高性能的底层工具库”。当运营想尝试一种全新的投放策略时，不再需要等研发排期修代码，而是通过 Agent 直接调用这些原子能力。

Infra 是基本功，没底座的 Agent 只是空中楼阁

这部分我认为是落地Agent最关键的一部分，实际上在当前的互联网业务里Infra的权重依旧很高。之前看OpenAI翁家翌PodCast的时候他就提到模型差距里面三个大因素是算力、数据和Infra，对于我们普通公司而言我觉得Infra的基本功是一切的大前提：

1. 分钟级的数据响应：Agent 的“视神经”

投放决策玩的就是时效性。如果数据链路延迟半小时，Agent 就会根据“过去的信息”指挥“现在的动作”。我们重点优化了变现侧与投放侧的数据合流，确保了核心 KPI 能够分钟级别回传。没有实时性，Agent 的灵活性就是伪命题。 这个事情其实缠绕了我相当长的时间，我和数据打交道很久，从21年自己构建分钟级别预测LTV的Clickhouse数据系统到25年使用动态RDS订阅解决千万存量账户的分钟级数据变更，这里面问题很多受到的限制也很多，好在各个平台趋于正规化，不然如果搞大数据量级别的投放系统，很多事情都变成了空谈。

2. 全链路的监控预警：Agent 的“安全阀”

AI 具备非确定性，而投放预算是真金白银。我们建立了一套超越 API 报错层面的监控体系，不仅监控“动作是否成功”，更监控“逻辑是否合理”。在 Agent 产生幻觉前，底层的熔断机制必须是最后一道防线。这部分预警目前看虽然还是很脆弱，但是从我的角度看这也是基本功，投放系统作为花钱的出口，业务SLA保障的不只是业务平台的稳定性，还有三方平台异常、炸量等异常状况的及时熔断和预警。

3. 业务报错的健全处理：Agent 的“闭环能力”

这是最容易被忽视的一点。传统的接口报错只是一串代码，但我们要给 Agent 提供的，是语义化的反馈。只有让 Agent 知道是“余额不足”还是“素材重复”，它才能根据报错自我修正策略，而不是陷入死循环。这部分只能靠实际的经验去趟平，只有见过多少报错才有多少报错的处理Case，在代码里叫容错异常处理，在Agent里其实算一个通用的Skills能力，让模型理解什么时候该重试，什么时候该放弃。

落地：为什么 MCP 是过渡期的“最强神经元”？

在确定了“解耦执行”的方向后，我们面临最现实的问题是：Agent 怎么调动我的 Infra？ 如果只是写一堆私有的 API Skill，那我们又回到了“为每个 Agent 定制逻辑”的老路。我们需要一种更标准、更工业化的协议。这时候，MCP (Model Context Protocol) 成了我们的破局点。我把它定位为 Agent 时代的“神经元”，因为它解决了三个最棘手的落地难题：

1. 资产的“即插即用”：拒绝烟囱式开发

在投放业务里，我们有巨量、腾讯、磁力等多个平台。以往做自动化，每个平台都要写一套适配逻辑。

• MCP 的解法： 我们将内部数仓和投放 API 封装成独立的 MCP Server。对 Agent 来说，它不需要理解底层的数据库表结构或 API 文档，它看到的只是 fetch_ad_roi 或 update_budget 这种标准化的“动作指令”。

• 业务收益： 研发沉淀下来的不再是死代码，而是标准化的能力资产。今天给投放 Agent 用，明天可以直接给财务 Agent 用。

2. 安全与权限的“物理隔绝”：让 Agent “在跑道内狂奔”

把核心权限交给 AI 是有风险的。直接写 Skills 往往意味着要把数据库账号密码或高权 Token 暴露在 Agent 环境里。

• MCP 的解法： MCP Server 运行在独立的宿主环境，它像一个“授权网关”。Agent 只能通过协议发起请求，它接触不到任何底层敏感信息。

• 业务收益： 我们可以精准地在 MCP 层控制：Agent 每小时最多能改多少次价？单次预算调整幅度是否超过 20%？这给了我们从“观察”到“托管”最需要的工程安全感。

3. 语义化的“自愈能力”：从报错到解决

这是 MCP 相比于传统 API 最硬核的地方。

• 实战场景： 当自动化系统报错“代码 4001”时，传统的系统就死机了。但我们的 MCP 接口会返回语义化信息：“当前计划处于审核中，无法调整预算”。

• Agent 反应： Agent 读到这个反馈后，会自我修正逻辑：“既然在审核，那我先去检查同组的其他计划”，或者“记录下该状态，10分钟后重试”。这种“理解错误并修正动作”的能力，是过渡到纯托管的关键。

闭环：给模型长出“眼”和“手”

如果说 MCP 解决了 80% 的标准化数据和 API 操作，那么剩下的 20% 则是最令投手头疼的“非标深水区”——比如去后台分析素材为什么被判违规、手动处理复杂的申诉、或者去竞品页面观察装修套路。这些地方 API 触达不到，是传统自动化无法逾越的鸿沟。

为了填补这最后的 20%，我们引入了 OpenClaw。如果说 MCP 是 Agent 这种“硅基大脑”直接对接系统的神经接口，那么 OpenClaw 就是给它装上了模拟人眼的“视觉”和模拟人手的“触觉”。

• 眼（视觉感知）： 自动化系统看到的是“计划已关停”的状态码，而 Agent 通过 OpenClaw 看到的是具体的诊断详情页截图。它能识别出是因为“文案存在夸大宣传”还是“图片背景过于杂乱”。这种对 UI 界面、对视觉素材的泛化理解能力，是传统代码无法模拟的。

• 手（柔性执行）： 在某些没有 API 开放的旧系统或复杂的审核后台，Agent 可以驱动 OpenClaw 模拟鼠标点击，完成“重新提交”、“申请复核”等动作。

我们的实战闭环逻辑是：

1. 感知： 自动化底座（Infra）触发异常告警，Agent 通过 数据 MCP 确认消耗与 ROI 异常。

2. 诊断： Agent 驱动 OpenClaw “亲自”去投放后台看一眼，通过视觉分析锁定拒审原因。

3. 决策： Agent 结合数据与截图信息，判断是该“换素材重发”还是“调低出价观望”。

4. 执行： 最终通过 操作 MCP 一键下发指令。

这种“眼手合一”的架构，让 Agent 真正具备了处理业务 Case 的闭环能力，而不再只是一个只能在控制台发消息的聊天机器人。

边界：哪里用自动化规则？哪里启动 Agent？

在落地过程中，我最先解决的是“权力分配”问题。Agent 不是来取代自动化的，它是来接管自动化处理不了的“模糊地带”。我们需要在系统架构中划清那道红线。

1. 定时调度与自动化规则：追求“极致的确定性”与“零成本执行”

对于那些 “非黑即白”、 “高频触发” 的逻辑，我们依然坚定地留在自动化规则里。

• 适用场景： 预算熔断（如计划消耗达限额立即关停）、秒级监控（如 ROI 跌破 0.1 强制切断）、定时报表推送。

• 成本帐： 这类逻辑的执行成本几乎为零（几行 SQL 或简单的 API 调用），且对响应时间要求是毫秒级的。如果这类活儿也叫 Agent 去“思考”一下，不仅浪费 Token，更会因为 LLM 的推理延迟（通常在秒级）导致超支风险。

• 定位： 它是系统的“硬防御”。

2. Agent 决策能力：追求“上下文理解”与“非标处理”

当规则进入 “灰色地带”，或者需要 “看数+看图+看趋势” 进行综合判断时，才是 Agent 出场的时刻。

• 适用场景： 素材衰退判断（ROI 波动是因为大盘环境还是素材由于高频曝光导致疲劳？）、拒审原因诊断、新策略试错建议。

• 成本帐： 调动一次 Agent 的成本（Token + 推理耗时）虽然远高于自动化规则，但它节省的是“昂贵的人工决策时间”。

• 定位： 它是系统的“软编排”。

---

算清楚这笔成本帐：为什么“贵”的 Agent 反而更省钱？

作为一个技术负责人，我必须面对老板最灵魂的考问：既然 Agent 调一次要花 Token 钱，为什么不继续写代码实现？

我给出的答案是：“研发成本”与“维护损耗”的账，必须算在内。

1. 研发成本的“杠杆效应”

• 传统自动化： 增加一个复杂的复合维度规则（比如：结合变现回传+素材标签+竞品热度），研发需要调研、写代码、测试、发布，周期以天计，人力成本过万。

• Agent 架构： 研发只需提供一个标准的 MCP 接口。运营通过 Prompt 描述策略，分钟级上线。虽然单次执行有 Token 成本，但研发的一次性投入（CapEx）转换成了按需分配的运营成本（OpEx），极大地提高了资金周转效率。

2. “动作”与“思考”的成本剥离

我们采取了 “小模型监控，大模型决策” 的混合架构：

• 低成本层： 用自研的自动化脚本（Infra 层）进行 24 小时全量扫描，只有当数据触发特定的“异动阈值”时，才唤醒 Agent。

• 高收益层： Agent 被唤醒后，带着上下文信息去“思考”这 1% 的非标 Case。

• 结论： 这样我们用 1% 的 Token 成本，解决了 90% 需要人工盯着屏幕的枯燥工作。

3. 避免“硬代码”导致的坏账

错误的规则适配（比如规则写死导致误关了正在起量的爆款计划）造成的直接损失，往往是 Token 费用的几万倍。Agent 具备的语义理解能力，本质上是为投放买了一份“逻辑保险”。

未来的护城河是“盘感”的数字化

在从自动化向 Agent 过渡的过程中，我最深刻的感悟是：代码不再是护城河，逻辑才是。

在过去，一个投放团队的壁垒可能是他们拥有一个多重、多复杂的自动化中台，里面堆砌了无数个研发熬夜写出来的规则。但在 2026 年，这种壁垒正在瓦解。随着 Agent 架构的普及，任何公司都能在短时间内通过标准的 MCP 接口组装出一套具备执行力的系统。

真正的护城河，正悄然转移到如何将顶尖投手的“盘感”进行数字化复刻。

• “盘感”不再是玄学： 以前老投手的经验是口传心授，现在我们可以将其转化为 Agent 的 System Prompt，转化成 MCP 工具的调用逻辑，转化成 OpenClaw 的巡检 SOP。

• 从“招人”到“育种”： 未来增长团队的核心资产，不再是招了多少个能熬夜看数的投手，而是沉淀了多少套高质量的 Skill 库。这些 Skill 库里封装了公司对流量的理解、对素材的审美、以及对风险的嗅觉。

• 研发角色的蜕变： 研发的重心将彻底从“写业务逻辑”转向“写能力接口”。我们不再是业务的跟随者，而是“数字生命”的架构师。我们提供最稳固的 Infra（底座）、最标准的 MCP（接口），然后看着这些 Agent 在投手的指挥下，在千变万化的市场中自我演化。

---

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