AI Agent 架构实战：从零拆解多Agent协作营销系统的设计与实现

AI Agent 架构实战：从零拆解多Agent协作营销系统的设计与实现

36氪最近发文称"AI SaaS 潮水来袭，Agent 时代软件价值重估"。作为开发者，与其看行业分析，不如直接拆解一个真实的多 Agent 营销系统------本文从架构设计到代码实现，讲清楚多 Agent 协作到底是怎么落地的。

一、为什么营销场景需要多Agent协作

单个 LLM 调用能做什么？写一篇文章、回一条消息、生成一个标题。但一个完整的营销流程远不止于此：

1. 选题研究：分析热点、匹配产品卖点、确定切入角度
2. 内容创作：撰写稿件、SEO 优化、平台规则适配
3. 多平台分发：格式转换、登录态管理、定时发布
4. 数据回收：采集阅读/评论/收藏数据、异常检测
5. 复盘优化：分析数据趋势、调整内容策略

每个环节需要不同的能力、不同的工具、不同的执行策略。用一个 Agent 做所有事，就像让一个人同时当策划、文案、运营和数据分析师------理论上可行，实际上每个角色都做不好。

多 Agent 协作的核心价值：让每个 Agent 专注自己的领域，通过结构化通信实现任务流转，最终形成 1+1>2 的协作效果。

二、系统架构总览

以一个实际运行中的 AI 营销系统（GrowthClaw）为例，它的多 Agent 架构分为四层：

┌─────────────────────────────────────────────────┐
│                   用户层                          │
│  产品信息输入 → 目标设定 → 审核确认 → 数据查看     │
└────────────────────┬────────────────────────────┘
                     │
┌────────────────────▼────────────────────────────┐
│               调度层（COO Agent）                  │
│  任务拆解 → 优先级排序 → Agent 分派 → 进度追踪     │
└──┬──────────┬──────────┬──────────┬─────────────┘
   │          │          │          │
┌──▼──┐  ┌───▼───┐  ┌───▼───┐  ┌───▼───┐
│内容  │  │ 投放   │  │ 数据   │  │ 策略   │
│Agent │  │ Agent  │  │ Agent  │  │ Agent  │
│      │  │        │  │        │  │        │
│选题  │  │多平台  │  │指标    │  │营销    │
│创作  │  │分发    │  │采集    │  │计划    │
│SEO   │  │定时    │  │异常    │  │复盘    │
│审核  │  │登录    │  │报告    │  │优化    │
└──────┘  └────────┘  └────────┘  └────────┘

2.1 各 Agent 职责边界

Agent	核心职责	工具依赖	输入	输出
COO Agent	任务编排、进度管理、审核把关	Flow 引擎、待办系统	用户目标/营销计划	任务单、审核结果
内容 Agent	选题→创作→SEO→自检→提交	LLM、热点采集、内容注册表	任务单	审核稿件
投放 Agent	登录→发布→结果确认→回写	浏览器自动化、CDP	审核稿件	发布结果
数据 Agent	指标采集→异常检测→报告	CDP、指标库	已发布文章列表	运营数据
策略 Agent	计划制定→热点跟踪→复盘分析	热点采集、指标库	历史数据+产品信息	策略建议

2.2 关键设计原则

职责单一：每个 Agent 只做一类事，做好一件事。内容 Agent 不碰发布，投放 Agent 不写文章。

状态机驱动：任务生命周期由状态机（task.json）承载，不靠目录搬迁或文件重命名。状态流转有明确的前置条件和后置动作。

信箱接力：Agent 之间通过待办系统（todos.db）异步通信，不直接阻塞等待。登录失效？落待办、等用户扫码、自动续跑。

三、任务编排：COO Agent 的核心能力

COO Agent 是整个系统的"大脑"，核心职责是把用户的模糊目标拆解成可执行的任务链。

3.1 任务拆解流程

以"本周在 CSDN 发 3 篇技术文章"为例，COO 的工作流：

# 伪代码：COO 任务拆解
def plan_weekly_content(user_goal, product_info, hotspots):
    tasks = []
    for i in range(user_goal.article_count):
        # 1. 匹配热点与产品卖点
        angle = match_hotspot_to_product(hotspots, product_info)
        
        # 2. 生成任务单
        task = {
            "task_id": f"{date}-csdn-{i+1:03d}",
            "platform": "csdn",
            "status": "assigned",
            "research": {
                "angle": angle.description,
                "target_keywords": angle.keywords,
                "hotinfo_ref": angle.hotspot_id
            },
            "strategy": {
                "content_type": angle.content_type,
                "seo_strategy": angle.seo_plan
            }
        }
        tasks.append(task)
    
    # 3. 分派给内容 Agent
    for task in tasks:
        dispatch_to_content_agent(task)

3.2 Flow 引擎：步骤级编排

COO 不直接写代码控制流程，而是通过声明式的 Flow YAML 定义步骤链：

# content-production-flow.yaml（简化版）
name: content-production-flow
steps:
  - id: preflight
    description: "平台匹配校验"
    
  - id: research
    description: "选题研究"
    condition: "$preflight.platform_match == true"
    
  - id: strategy
    description: "内容策略"
    
  - id: draft
    description: "内容创作"
    condition: "$strategy.strategy_done == true"
    
  - id: seo
    description: "SEO优化"
    
  - id: rule_check
    description: "平台规则审核"
    
  - id: quality
    description: "质量自检"
    condition: "$rule_check.passed == true"
    
  - id: submit_review
    description: "提交审核"

每个步骤有明确的前置条件 （condition）和输出产物（outputs）。条件不满足？流程自动停在那里，不会跳步。这是多 Agent 系统可靠运行的基础。

四、Agent 间通信：信箱接力模式

多 Agent 协作最大的工程挑战不是"怎么调用"，而是"怎么处理失败"。

4.1 传统 RPC 的问题

如果 Agent A 同步调用 Agent B：

Agent A → 调用 B → 等待 30s → B 失败 → A 也失败 → 整条链路重跑

在营销场景中，"B 失败"的原因往往是用户需要扫码登录------这不是代码能自动修复的，需要人工介入。同步等待会导致整个流程卡死。

4.2 信箱接力方案

GrowthClaw 采用信箱接力模式：

Agent A → 写待办到 todos.db → 正常结束（不阻塞）
                                ↓
用户扫码登录 → 待办状态变更 → mailbox_relay 检测到 → 自动 resume Agent A 的后续步骤

核心代码逻辑：

# 信箱接力：Agent A 发现登录失效
def on_login_expired(flow_id, task_id):
    # 1. 落待办（不阻塞）
    todo_upsert(
        type="login_pending",
        platform="csdn",
        task_id=task_id,
        action_hint=flow_id  # 关联 Flow ID，用于自动续跑
    )
    
    # 2. 通知用户
    notify_main_agent("请扫码登录 CSDN")
    
    # 3. 退出但保持 Flow blocked（不标记失败）
    sys.exit(1)

# mailbox_relay：后台轮询待办
def relay_loop():
    for todo in get_resolved_todos():
        if todo.action_hint:  # 有关联 Flow
            resume_flow(todo.action_hint)  # 从断点续跑

关键设计 ：action_hint 字段关联了待办和 Flow，用户解决待办后系统自动续跑，不需要人工重新触发。

五、发布流程：浏览器自动化实战

投放 Agent 负责将审核通过的稿件发布到各平台。以 CSDN 为例，发布流程涉及浏览器自动化：

5.1 CDP（Chrome DevTools Protocol）操作链

# 发布流程核心步骤
def publish_to_csdn(task, content):
    # 1. 检查登录态（三态契约）
    login_status = check_login()  # LOGGED_IN / NOT_LOGGED_IN / UNKNOWN
    if login_status != "LOGGED_IN":
        return on_login_expired(flow_id, task.task_id)
    
    # 2. 打开编辑器
    cdp_open("https://editor.csdn.net/md/")
    
    # 3. 隐藏 AI 助手弹窗（遮挡编辑区）
    cdp_evaluate("document.querySelector('iframe.ai-assistant')?.style.display='none'")
    
    # 4. 注入标题（nativeInputValueSetter 绕过框架）
    cdp_evaluate(f"""
        var input = document.querySelector('input[placeholder*="标题"]');
        var nativeSetter = Object.getOwnPropertyDescriptor(
            HTMLInputElement.prototype, 'value').set;
        nativeSetter.call(input, {json.dumps(title)});
        input.dispatchEvent(new Event('input', {{bubbles: true}}));
    """)
    
    # 5. 注入正文（contentEditable，禁止 browser type）
    cdp_evaluate(f"""
        var editor = document.querySelector('[contenteditable=true]');
        editor.innerHTML = {json.dumps(marked_content)};
        editor.dispatchEvent(new Event('input', {{bubbles: true}}));
    """)
    
    # 6. 点击发布（需 --submit-confirmed 人工确认）
    if submit_confirmed:
        click_visible_button("发布文章")
        article_id = wait_for_success_page()

5.2 安全机制

发布流程有多层安全门禁：

1. pre_publish_validate：检查 draft 存在、status 合法、发布许可门匹配
2. submit-confirmed 开关：没有这个标志，publish.py 不会真正点发布按钮
3. verify_publish：发布后 HTTP 验证文章可访问 + 标题匹配
4. archive_publish：幂等回写 content.db，COALESCE 保留已有值

六、数据闭环：采集→分析→优化

数据 Agent 负责采集已发布文章的运营数据，形成闭环：

6.1 数据采集架构

content.db（已发布文章白名单）
        ↓
cdp_collect.mjs（CDP 网络拦截 + DOM 降级）
        ↓
store_metrics.py（幂等入库，INSERT OR REPLACE）
        ↓
data/csdn.db（article_metrics + account_metrics）
        ↓
COO Agent（异常检测 + 复盘报告）

6.2 幂等性设计

数据采集的核心挑战是幂等性------同一天多次运行不能产生重复数据：

-- 唯一索引保证幂等
CREATE UNIQUE INDEX idx_article_daily 
  ON article_metrics(article_id, metric_date, account_id);

-- INSERT OR REPLACE：同日同文章重采覆盖而非追加
INSERT OR REPLACE INTO article_metrics 
  (platform, article_id, metric_date, clicks, likes, ...)
VALUES (?, ?, ?, ?, ?, ...);

七、落地经验与踩坑记录

7.1 浏览器自动化的坑

• CSDN 编辑器 ：标题输入必须用 nativeInputValueSetter + dispatchEvent，直接设 value 不触发框架更新
• AI 弹窗遮挡：编辑器打开时自动弹出 AI 助手 iframe，必须先隐藏才能操作
• 标签输入丢事件：Enter 后 DOM 重建丢事件（实测 4 丢 2），需要两段式「设值→sleep→补发 Enter→验证」
• 冷启动时序：新开浏览器 tab 后 SPA 需要额外加载时间，直接操作会找不到 DOM 元素

7.2 多 Agent 协作的坑

• 并发冲突：同一平台同时发布两篇文章会导致浏览器状态混乱，需要串行调度
• 状态不一致：task.json 和 content.db 必须保持同步，单点写入（content_registry.py）是关键
• 待办过期：login_scan 待办如果用户一直不处理，需要有超时和重试机制

八、FAQ

Q1：多 Agent 和单 Agent + 多工具调用有什么区别？

单 Agent + 多工具的问题是上下文膨胀------一个 Agent 要记住所有工具的用法、所有平台的规则、所有流程的状态。当工具超过 10 个、流程超过 5 步时，LLM 的指令遵循能力会显著下降。多 Agent 通过职责拆分，每个 Agent 只需要理解自己领域的 3-5 个工具，可靠性大幅提升。

Q2：Agent 之间怎么传递数据？

两种方式：共享文件系统（task.json + content.db）和待办系统（todos.db）。不走 RPC，不走消息队列------文件系统是最简单、最可靠的共享状态方案，崩溃恢复天然支持。

Q3：这套架构适合什么规模的团队？

最适合一人公司或小团队（1-3 人）。大团队有专职运营，不需要 AI 替代；一人公司需要 AI 承担全部营销工作，多 Agent 架构正好填补这个需求。

Q4：怎么保证生成内容的质量？

三层质量门禁：规则审核（违禁词/字数/格式）→ 质量自检（产品一致性/品牌调性/CTA）→ 人工审核（主理人把关）。AI 自动过前两层，人工只审最后一层，效率和质量兼顾。

Q5：开源吗？有完整代码吗？

本文描述的架构来自 GrowthClaw 项目的实际实现。核心组件（Flow 引擎、待办系统、内容注册表、指标采集）均已工程化，但本文侧重架构设计而非逐行代码讲解。感兴趣的开发者可以关注后续的工程实践系列。

九、总结

多 Agent 营销系统的核心架构可以归纳为三个关键词：

1. 职责拆分：COO 编排、内容创作、投放执行、数据采集、策略优化，各司其职
2. 状态驱动：task.json 状态机 + Flow YAML 步骤链，不靠目录搬迁，不靠口头约定
3. 信箱接力：Agent 通过待办系统异步通信，中断可恢复，用户介入不影响自动化

这套架构已经在实际生产环境中运行，覆盖 CSDN、头条、微博、知乎、搜狐等 11 个平台的内容创作和分发。对于想做 AI 营销自动化的开发者来说，多 Agent 不是概念，而是工程落地的正确路径。

---

本文架构描述基于 GrowthClaw 项目的实际实现。数据和案例来自真实生产环境运行记录。