MarketingClaw 技术架构：多 Agent 协作是怎么跑起来的

MarketingClaw 技术架构：多 Agent 协作是怎么跑起来的

摘要：MarketingClaw 是一支由多个 AI Agent 组成的营销团队------COO Agent 统筹、内容 Agent 创作、数据 Agent 追踪。本文从技术架构角度，拆解多 Agent 协作的核心机制：任务编排、Agent 间通信、数据流转、异常处理，帮助开发者理解多 Agent 系统的设计思路。

---

一、先看结论：多 Agent 不是"多个 ChatGPT 同时开"

很多人对多 Agent 的理解停留在"同时开几个 AI 聊天窗口"。实际上，多 Agent 系统要解决的核心问题是：

• 任务怎么拆：一个大目标如何分解为可并行执行的子任务
• Agent 怎么协作：谁先做、谁后做、结果怎么传递
• 状态怎么管理：任务卡住、失败、超时怎么办
• 数据怎么流转：Agent A 的输出怎么变成 Agent B 的输入

MarketingClaw 的架构设计，围绕这些问题给出了一个可落地的方案。

二、系统架构总览

先看整体：

┌─────────────────────────────────────────────────────────┐
│                    用户交互层                              │
│          Web UI · CLI · 消息接口（Telegram/微信等）          │
└────────────────────────┬────────────────────────────────┘
                         │
┌────────────────────────▼────────────────────────────────┐
│                    调度层（Orchestrator）                   │
│   任务接收 · DAG 编排 · 优先级队列 · 依赖管理 · 超时控制       │
└────────────────────────┬────────────────────────────────┘
                         │
┌────────────────────────▼────────────────────────────────┐
│                    Agent 执行层                            │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐   │
│  │COO Agent │ │内容 Agent │ │投放 Agent │ │数据 Agent │   │
│  │  规划调度  │ │ 文案创作  │ │ 渠道分发  │ │ 效果追踪  │   │
│  └──────────┘ └──────────┘ └──────────┘ └──────────┘   │
└────────────────────────┬────────────────────────────────┘
                         │
┌────────────────────────▼────────────────────────────────┐
│                    基础设施层                              │
│  消息总线(Kafka/Redis Streams) · 状态存储 · 安全沙箱       │
│  外部API适配器 · 日志追踪 · 配置中心                        │
└─────────────────────────────────────────────────────────┘

核心设计原则：每个 Agent 是独立进程，通过消息总线通信，不共享内存。

这样做的好处是：

1. Agent 可以独立部署、独立扩展
2. 一个 Agent 崩溃不会拖垮整个系统
3. 可以对不同 Agent 使用不同的 LLM 模型（成本优化）

三、任务编排：DAG 引擎

3.1 什么是 DAG 编排？

DAG（有向无环图）是多 Agent 系统的核心调度模型。每个任务是一个节点，任务之间的依赖关系是边：

选题策划 ──→ 文案创作 ──→ 格式适配 ──→ 渠道发布 ──→ 数据追踪
                              │
                              └──→ 渠道发布（并行）

MarketingClaw 的 DAG 引擎负责：

• 解析依赖：自动识别哪些任务可以并行，哪些必须串行
• 拓扑排序：确定执行顺序
• 并发调度：无依赖的任务同时执行
• 状态追踪：每个节点的 pending / running / success / failed 状态

3.2 任务定义格式

{
  "task_id": "campaign_001",
  "goal": "新产品推广",
  "steps": [
    {
      "id": "topic_planning",
      "agent": "coo",
      "action": "plan_topics",
      "params": { "product": "MarketingClaw", "platforms": ["csdn", "xiaohongshu"] },
      "depends_on": []
    },
    {
      "id": "content_creation",
      "agent": "content",
      "action": "create_content",
      "params": { "topic": "${topic_planning.output}" },
      "depends_on": ["topic_planning"]
    },
    {
      "id": "publish",
      "agent": "publisher",
      "action": "publish_all",
      "params": { "content": "${content_creation.output}" },
      "depends_on": ["content_creation"]
    },
    {
      "id": "track",
      "agent": "data",
      "action": "track_performance",
      "params": { "campaign_id": "campaign_001" },
      "depends_on": ["publish"]
    }
  ]
}

注意 depends_on 和 ${xxx.output} 的引用机制------这是 DAG 引擎实现数据自动流转的关键。

四、Agent 间通信：消息协议

4.1 为什么用消息总线？

Agent 间通信是多 Agent 系统最容易出问题的地方。直接 RPC 调用看似简单，但会带来强耦合和级联故障。

MarketingClaw 采用消息总线作为核心通信机制：

Agent A ──发布消息──▶ [消息总线] ──订阅消费──▶ Agent B

优点：

• 解耦：Agent 不需要知道彼此的存在，只关心消息格式
• 可靠：消息持久化，Agent 重启后可以重新消费
• 可追溯：所有通信记录可审计

4.2 消息协议定义

所有 Agent 间的消息遵循统一格式：

interface AgentMessage {
  message_id: string;          // 唯一标识
  type: 'task' | 'result' | 'error' | 'heartbeat' | 'control';
  source_agent: string;        // 发送方
  target_agent: string;        // 接收方（或 'broadcast'）
  payload: {
    task_id: string;           // 关联的任务
    data: any;                 // 实际数据
    schema_version: string;    // 协议版本
  };
  metadata: {
    timestamp: number;
    priority: 'low' | 'normal' | 'high' | 'critical';
    retry_count: number;
    ttl: number;               // 消息生存时间(ms)
  };
}

4.3 消息类型说明

类型	用途	示例
task	分配任务给 Agent	COO → 内容Agent：创建文章
result	Agent 完成任务后返回结果	内容Agent → COO：文章已生成
error	任务执行失败	内容Agent → COO：API 调用超时
heartbeat	Agent 健康状态上报	各Agent → 调度层：我活着
control	系统级控制指令	调度层 → 所有Agent：暂停执行

4.4 实际通信示例

一次完整的文章创作流程中，消息交互如下：

时间线:
00:00  COO → 内容Agent [task]     "创建CSDN文章: 多Agent架构"
00:02  内容Agent → 调度层 [heartbeat]  "正在处理..."
00:15  内容Agent → COO [result]    "文章已生成, 3200字, 含5个代码块"
00:15  COO → 内容Agent [task]      "适配小红书格式(800字+图文)"
00:17  内容Agent → COO [result]    "小红书版本已生成"
00:17  COO → 投放Agent [task]      "发布到CSDN, 明天10:00"
00:17  COO → 投放Agent [task]      "发布到小红书, 明天12:00"

五、数据流转：从创作到分析

5.1 数据生命周期

一条内容从创建到效果评估，数据在系统中的流转路径：

创作阶段          发布阶段          追踪阶段
────────        ────────        ────────
原始文案          平台ID           阅读量
    ↓              ↓               ↓
格式适配          发布时间         互动数据
    ↓              ↓               ↓
SEO优化          账号信息         搜索排名
    ↓              ↓               ↓
元数据生成        回执确认         效果报告

5.2 元数据驱动

每个内容在创建时都会生成一个元数据对象，贯穿整个生命周期：

{
  "content_id": "20260701-csdn-001",
  "title": "MarketingClaw 技术架构",
  "platform": "CSDN",
  "status": "published",
  "created_at": "2026-07-01T08:00:00+08:00",
  "published_at": "2026-07-01T10:00:00+08:00",
  "url": "https://blog.csdn.net/xxx/article/details/xxx",
  "metrics": {
    "views": 1250,
    "likes": 89,
    "comments": 12,
    "bookmarks": 45
  },
  "performance_score": 78,
  "keywords_rank": {
    "多Agent协作": 15,
    "AI营销架构": 8
  }
}

这个元数据对象会被数据 Agent 持续更新，形成完整的内容生命周期记录。

六、异常处理：系统怎么"容错"

多 Agent 系统最常见的问题是：一个 Agent 挂了，整条链路怎么办？

6.1 异常分类

异常类型	示例	处理策略
瞬时故障	API 限流、网络抖动	自动重试（指数退避）
持久故障	账号被封、API Key 失效	标记任务失败，通知人工
超时	Agent 执行超过阈值	强制终止，回滚状态
逻辑错误	内容不符合平台规范	退回重做，附带修正建议

6.2 重试机制

class RetryPolicy:
    max_retries = 3
    backoff_base = 2  # 指数退避基数
    
    def should_retry(self, error, attempt):
        if attempt >= self.max_retries:
            return False
        if error.type == 'rate_limit':
            return True  # 限流可以重试
        if error.type == 'auth_expired':
            return False  # 认证过期不能重试
        return error.type == 'transient'
    
    def get_delay(self, attempt):
        return self.backoff_base ** attempt  # 1s, 2s, 4s

6.3 降级策略

当某个 Agent 不可用时，系统自动降级：

• 内容 Agent 不可用 → COO Agent 自己生成简单内容，降低质量要求
• 投放 Agent 不可用 → 保存草稿，等恢复后自动发布
• 数据 Agent 不可用 → 标记数据缺失，下次采集时补全

七、安全与隔离

7.1 Agent 沙箱

每个 Agent 运行在独立的安全沙箱中：

• 网络隔离：Agent 只能访问必要的外部 API
• 资源限制：CPU、内存、API 调用次数有上限
• 数据隔离：Agent 之间不共享敏感数据（如 API Key）

7.2 数据安全

用户数据 → 本地加密存储 → Agent 调用时解密 → 结果加密回写

所有用户数据（账号信息、内容数据、分析结果）在本地加密存储，Agent 只在需要时解密使用，不上传到外部服务。

八、性能优化：让系统跑得更快

8.1 并行执行

DAG 引擎的最大优势是支持并行。例如：

• 3 个平台的内容创作可以同时进行
• 多个平台的发布可以错峰并行
• 数据采集可以批量异步执行

8.2 缓存策略

class ContentCache:
    # 相似查询缓存，避免重复调用 LLM
    def get_cached_content(self, topic, platform, style):
        cache_key = f"{topic}:{platform}:{style}"
        cached = self.store.get(cache_key, ttl=3600)
        if cached:
            return cached
        # 未命中，调用 LLM 生成
        content = self.llm.generate(topic, platform, style)
        self.store.set(cache_key, content)
        return content

8.3 模型路由

不同任务使用不同模型，平衡质量和成本：

任务类型	推荐模型	原因
选题策划	Claude/GPT-4	需要深度理解
文案创作	Claude/GPT-4	需要创意和质量
格式适配	轻量模型	规则明确，不需要太强推理
数据分析	专用模型/代码执行	结构化输出

九、总结

多 Agent 协作不是简单的"多个 AI 同时工作"，而是一套完整的系统工程：

维度	关键设计
任务编排	DAG 引擎，自动拆解和调度
Agent 通信	消息总线，解耦+可靠
数据流转	元数据驱动，全生命周期管理
异常处理	分级重试+降级+通知
安全隔离	沙箱+加密+资源限制
性能优化	并行+缓存+模型路由

这套架构的核心思想是：让每个 Agent 专注做一件事，通过标准化协议协作，最终形成一支能自主运转的营销团队。

如果你想体验这套架构的实际效果，而不需要自己从零搭建------

MarketingClaw 玄策 已经将这些能力封装为开箱即用的产品：COO Agent 统筹、内容 Agent 创作、数据 Agent 追踪，全平台 7×24 小时主动运营。

👉 立即了解 MarketingClaw

---

本文为「AI 营销」专栏系列文章，关注获取更多 AI Agent 营销技术深度内容。