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

来源：InfoQ

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

原文来源：InfoQ Presentation: Multi-Agent Patterns from Spotify's AI Powered Advertising Platform

演讲者：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 出了问题？完善的链路追踪、中间状态日志与逐环节评估体系是落地的必要前提。

技术分析

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

# 简化的监督者模式示意（伪代码）
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 的工具权限应遵循最小权限原则

实践建议

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

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

总结

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

立即实践

体验现有多 Agent 编排沙盒，验证上述工作流的输入、结果与下一步操作。此 Demo 是相关实践工具，不代表原项目的完整实现。

Article summary