AI Agent 自动投广告？我花一个月验证，踩了 4 个结构性深坑

m0_60351600

215人浏览 · 2026-07-02 18:34:37

m0_60351600 · 2026-07-02 18:34:37 发布

摘要： 我把 Claude Code 直连 Meta Marketing API，试图让它自主管理广告投放。分析能力很强，但执行层在 4 个结构性节点上彻底断裂——且不是 prompt engineering 能修的问题。本文是完整技术复盘。

背景

最近 Codex、Claude Code 这类编程 Agent 的能力跃升很快。社区里开始有人尝试用它们串接 Meta / Google Ads API，做「自主投放」。

我也试了一个月。结论是：

分析层无敌。执行层全挂。

这不是模型能力问题，而是 4 个来自平台侧和业务逻辑的结构性约束。GPT-5 来了也修不了。
在这里插入图片描述

下面是完整技术复盘。

实验架构

┌────────────────────────────────┐
│         Claude Code            │
│  (Anthropic API / CLI)         │
├────────────────────────────────┤
│    Python wrapper layer        │
│  - Meta Marketing API client   │
│  - Insights 数据拉取           │
│  - Campaign / Ad Set CRUD      │
└──────────────┬─────────────────┘
               │ HTTP/REST
               ▼
┌────────────────────────────────┐
│     Meta Marketing API v21     │
│   (Graph API + Insights API)   │
└────────────────────────────────┘

目标很简单：Agent 读取投放数据 → 判断要不要调整 → 自主执行调整（调预算、暂停、开启）。

结果：读和判断都没问题。一到执行，四个坑一个比一个深。

约束一：平台行为检测——你不是被限流了，你是被标记了

在这里插入图片描述

公开限制

Meta 对写入类端点（campaign/ad set/ad 的 create 和 update）强制执行 100 QPS 上限，按 app_id × ad_account_id 组合计算。

# 典型的 rate limit 响应
{
  "error": {
    "message": "(#17) User request limit reached",
    "type": "OAuthException",
    "code": 17,
    "error_subcode": 2446079
  }
}

隐性限制（更致命）

公开 QPS 之下还有一套行为评分系统在静默运行：

每个 API caller 累积声誉分
异常模式会无声降分：凌晨 3 点批量编辑、快速 create/delete 循环、人类不可能产生的编辑频率
降分后果：24h 冷却 → 永久审核 → 直接停号

关键问题是：Agent 的调用模式天然看起来不像人。 它不休息、不犹豫、批量操作频率是人的 10-50 倍。

实测结果

第三天开始收到 error_subcode: 2446079，频率递增。第七天直接进了 App Review 状态。4 万美元活跃花费的账户差点没保住。

Meta 官方 MCP 能救吗？

2025 年 6 月 Meta 发布了官方 MCP server。它解决了合规通道问题（不再是非授权 scraping），但：

依然受 QPS 和行为评分约束
MCP 是协议层，不负责告诉你"什么时候该做什么"
你仍然需要 MCP 之上的 rate-limit compliance + behavioral pattern shaping

结论： 问题不是"能不能调 API"。是你调了三个月之后，账户还在不在。

约束二：不可逆操作——没有 undo 的 API

在这里插入图片描述

场景还原

Agent 识别到一条 campaign 的 CPA 是 target 的 3 倍。逻辑判断：暂停。

# Agent 执行的操作
requests.post(
    f"https://graph.facebook.com/v21.0/{campaign_id}",
    params={"status": "PAUSED", "access_token": token}
)
# 返回 200 OK。搞定了？

搞定了个鬼。

为什么这是灾难

学习期重置：这条 campaign 是唯一还在给 Pixel 喂 purchase events 的。暂停 → ad set 退出学习 → $2000 学习投资归零
预算不可逆：daily_budget 从 50 拉到 50000，Meta 的 delivery system 立刻围绕新上限优化。改回来了，但投放分配不会恢复原样
没有原子事务：不存在 BEGIN TRANSACTION ... ROLLBACK 的概念

Agent 的问题在哪

对 Agent 来说，每个 API 调用都是等价的——发请求，收 200 OK。它没有原生能力区分：

这个操作是否可逆？
这个操作的二阶效应是什么？
当前上下文下这个操作的风险系数是多少？

# 对 Agent 来说，以下两个操作"看起来一样"：
# 低风险：修改广告文案
update_ad(ad_id, creative={"body": "新文案"})

# 高风险：暂停学习期内的唯一活跃 campaign
update_campaign(campaign_id, status="PAUSED")

结论： 你需要一个 irreversibility-aware 的决策层——冷却期、阶梯式扩量、学习期保护规则、human-in-the-loop gate。通用 Agent 没有这些。

约束三：API 返回的是数据，不是上下文

Meta Insights API 返回值

{
  "actions": [{"action_type": "purchase", "value": "12"}],
  "action_values": [{"action_type": "purchase", "value": "1847.30"}],
  "purchase_roas": [{"action_type": "purchase", "value": "2.31"}]
}

数据结构很干净。但 Agent 拿到这些数据之后，关键问题全不在 payload 里：

决策所需信息	API 是否返回	获取方式
归因窗口（7d click vs 1d）	❌	需从 `attribution_setting` 端点另查
当前是否在学习阶段	❌	需拼凑 `delivery_info` + 花费曲线推断
品类 CPA 基线	❌	无 API，需人工维护
历史花费曲线和 CV 累积	❌	需自建 time-series 存储
这条 ad set 的业务定位	❌	纯业务知识

实测

给 Claude Code 喂了 Insights 返回值，问它 “CPA=$45，这条广告组该暂停吗？”

它的回答：

“CPA=$45 相对于大多数电商品类偏高，建议暂停或降低预算。”

但实际情况：这条是高客单价品类（AOV=$300），CPA=$45 对应 ROAS≈6.7，是账户里表现最好的广告组。

问题不在模型能力。 如果你把学习期、历史花费、转化量、品类基线全部喂给它，它当然能做正确分析。但 API 本身不返回这些上下文。Agent 需要从 5-7 个不同的端点拼凑，交叉引用自建的业务状态存储，再套用品类经验规则。

这不是 prompt 能修的。这是基础设施缺失。

约束四：Agent 没有持续业务状态

在这里插入图片描述

场景

周一: 新建 ad set, targeting US F25-44, interest:skincare, budget=$50/day, CPA target=$28
周二: CPA=$47 → Agent 判断 "超支" → 执行 PAUSE
周三: 重启 → CPA=$24 → 学习期白花 $200

根因

周二的 Agent 不知道这条 ad set 才跑了 18 小时，处于 7 天学习期的第一天。它看到一个数字，对着数字做了动作。

“但 Agent 不是有 Memory 吗？”

Claude Code 有 Project Memory。Codex 有 checkpoint。GPT 有 conversation history。

但那些是笔记，不是结构化业务状态机。

一条广告组的状态演化是这样的：

learning_phase (day 1-7)
  → stable_delivery (day 8+)
    → scaling (budget $50 → $200 → $500)
      → saturation (frequency > 3.5, CTR declining)
        → refresh_needed

这个连续演化需要被结构化追踪——不是从聊天记录里"回忆"出来的。

Agent 的 Memory 可以记住"你跟我说过这条广告组很重要"，但它没有能力维护一个实时更新的业务状态对象：

# 专用系统维护的状态对象（示意）
ad_set_state = {
    "id": "23851234567890",
    "phase": "learning",
    "phase_start": "2025-06-30T08:00:00Z",
    "budget_trajectory": [50, 50, 50],  # 每日
    "cv_accumulation": [0, 3, 8],
    "estimated_learning_exit": "2025-07-06",
    "saturation_score": 0.12,
    "last_human_override": None
}

通用 Agent 没有这层。它每次被调用，都要从零重建上下文。

总结：这不是模型问题，是基础设施问题

四个约束的本质：

约束	本质	模型能修吗
权限/行为检测	平台侧的安全机制	❌ 会收紧不会放松
不可逆操作	业务逻辑决定的	❌ 需要专用决策层
上下文缺失	API 设计+业务知识	⚠️ 部分缓解
无持续状态	架构层面的	⚠️ 部分缓解

GPT-5 或 Claude 4 来了能修吗？

约束 3 和 4 会随着上下文窗口增大和 tool-use 增强而部分缓解。

约束 1 和 2 不会。它们是平台施加的、业务逻辑要求的。随着更多 Agent 试图自主操作广告账户，这些限制只会收紧。

那什么架构才是对的？

如果你要搭一个能真正跑广告的 Agent 系统，需要的不是更强的 LLM，而是：

┌─────────────────────────────────────────────┐
│                LLM Layer                     │
│  (分析、推理、生成策略建议)                    │
├─────────────────────────────────────────────┤
│          Infrastructure Layer                │
│  ┌─────────────┬──────────────────────────┐ │
│  │ Permission  │ - Rate-limit compliance  │ │
│  │ Manager     │ - Behavioral shaping     │ │
│  │             │ - Token rotation         │ │
│  ├─────────────┼──────────────────────────┤ │
│  │ Guardrail   │ - Irreversibility scoring│ │
│  │ Engine      │ - Cooling-off periods    │ │
│  │             │ - Human-in-the-loop gate │ │
│  ├─────────────┼──────────────────────────┤ │
│  │ Context     │ - Multi-endpoint assembly│ │
│  │ Assembler   │ - Business rule overlay  │ │
│  │             │ - Category benchmarks    │ │
│  ├─────────────┼──────────────────────────┤ │
│  │ State       │ - Phase tracking         │ │
│  │ Machine     │ - Budget trajectory      │ │
│  │             │ - Saturation curves      │ │
│  └─────────────┴──────────────────────────┘ │
├─────────────────────────────────────────────┤
│          Platform API Layer                  │
│  (Meta / Google / TikTok)                    │
└─────────────────────────────────────────────┘

LLM 是大脑。基础设施是让大脑不会烧掉你广告账户的东西。