# Presentation: Multi-Agent Patterns from Spotify’s AI Powered Advertising Platform

> 来源：[InfoQ](https://www.infoq.com/presentations/spotify-multi-agent-ai-architecture/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global)

# Spotify 广告平台的多智能体模式实践：一场值得关注的 InfoQ 分享

> 原文来源：[InfoQ Presentation: Multi-Agent Patterns from Spotify's AI Powered Advertising Platform](https://www.infoq.com/presentations/spotify-multi-agent-ai-architecture/)
> 演讲者：Pratik Rasam（Spotify）

## 背景与概述

近两年来，"多智能体系统"（Multi-Agent System）从学术概念迅速演变为工程界的热门实践。随着大语言模型（LLM）能力边界不断扩展，单一"万能 Agent"的局限性日益明显——上下文窗口膨胀、任务复杂度过载、错误难以隔离。业界开始倾向于将复杂任务拆解为多个职责单一、可协作的智能体，通过编排（Orchestration）模式完成端到端流程。

广告营销领域是这一趋势的绝佳试验场：一次广告投放涉及受众分析、创意生成、预算规划、竞价策略、效果归因等多个专业环节，天然适合由不同 Agent 分工协作。Spotify 作为拥有海量用户行为数据的流媒体平台，其广告业务 Spotify Ads Manager 正是多智能体架构落地的典型场景。本次 InfoQ 分享中，Spotify 的 Pratik Rasam 介绍了该平台背后的多智能体设计思路。

需要说明的是，本文基于 InfoQ 的分享摘要撰写，演讲中关于架构细节、具体技术指标与业务成果的描述**待核实**，以下分析更多结合公开的多智能体通用模式展开。

## 核心内容

### 1. 从单 Agent 到多 Agent 的演进动因

单一 Agent 在面对"端到端广告投放助手"这类复杂任务时，往往陷入提示词臃肿、决策链路黑盒化的问题。Spotify 的实践（据分享主题推断，具体动机**待核实**）反映了行业共识：**专业化分工优于全能化堆砌**——让每个 Agent 聚焦一个领域，各自携带精简的工具集与上下文。

### 2. 典型的多智能体协作模式

业界成熟的多智能体模式主要包括以下几类，Spotify 的具体选型**待核实**：

- **监督者模式（Supervisor）**：一个主控 Agent 负责任务拆解、分派与结果汇总
- **流水线模式（Pipeline）**：Agent 依次接力，前一环节的输出作为后一环节的输入
- **黑板/消息总线模式**：各 Agent 围绕共享状态协作，降低耦合

### 3. 人机协同（Human-in-the-loop）

广告场景涉及真金白银的预算决策，完全自治的 Agent 难以获得业务信任。合理的设计是在关键决策点（如预算审批、创意上线前）引入人工确认环节，这也是企业级 Agent 系统的普遍要求。

### 4. 评估与可观测性

多智能体系统最大的工程挑战之一是"错误归因"——最终输出出错时，是哪个 Agent 出了问题？完善的链路追踪、中间状态日志与逐环节评估体系是落地的必要前提。

## 技术分析

以一个简化的广告投放场景为例，多智能体架构可以这样组织：

```python
# 简化的监督者模式示意（伪代码）
class SupervisorAgent:
    def __init__(self):
        self.agents = {
            "audience": AudienceAgent(),   # 受众分析
            "creative": CreativeAgent(),   # 创意生成
            "budget":   BudgetAgent(),     # 预算规划
        }

    def run(self, campaign_goal: str) -> CampaignPlan:
        # 1. 拆解任务
        subtasks = self.plan(campaign_goal)
        results = {}
        for task in subtasks:
            # 2. 分派给对应 Agent，关键节点人工确认
            if task.requires_approval:
                self.human_review(task)
            results[task.name] = self.agents[task.owner].execute(task)
        # 3. 汇总并做一致性校验
        return self.synthesize(results)
```

技术上需要重点关注的维度包括：

- **状态管理**：Agent 间传递的应是结构化数据（JSON Schema 约束），而非自由文本，以保证可追溯性
- **容错设计**：单个 Agent 失败时的重试、降级与回退策略
- **成本控制**：多轮 LLM 调用带来的延迟与 Token 开销，通常需要缓存与并行执行优化
- **安全边界**：每个 Agent 的工具权限应遵循最小权限原则

## 实践建议

对于希望落地多智能体系统的团队，建议按以下路径推进：

1. **先评估是否真的需要多 Agent**。如果任务能被一个 Agent 加良好的工具调用解决，不要为拆而拆——编排复杂度是真实的工程成本。
2. **从两个 Agent 的最小协作开始**，跑通"拆解-执行-校验"闭环后再逐步扩展，避免一次性设计庞大的 Agent 拓扑。
3. **为每个 Agent 定义清晰的输入输出契约**，并使用结构化输出（如 Pydantic / JSON Schema）强约束。
4. **尽早建设评估体系**：为每个环节准备独立的测试集，用自动化评测代替人工抽查。
5. **在涉及资金、合规的节点保留人工闸门**，这是企业场景与 Demo 的本质区别。

## 总结

Spotify 在 InfoQ 的这次分享代表了多智能体技术从"概念验证"走向"生产级落地"的重要节点。广告平台这类业务链条长、专业分工明确的场景，恰好是多智能体架构的用武之地。虽然本次分享的具体架构细节与成效数据**待核实**，但其传递的核心信号值得开发者重视：**Agent 工程竞争的下半场，不在模型能力，而在编排、评估与工程治理**。对于正在探索 LLM 应用落地的团队而言，理解并实践这些多智能体模式，将是构建可靠 AI 系统的必修课。

## 立即实践

体验现有 [多 Agent 编排沙盒](/demos/agent-orchestrator-sandbox/index.html)，验证上述工作流的输入、结果与下一步操作。此 Demo 是相关实践工具，不代表原项目的完整实现。