搭完 MatchInfluence Multi-Agent 系统后，我回答了第一篇的问题

2026 年 5 月，我花了 3 周时间搭完了 MatchInfluence v0.4——一个 4-agent 的 Multi-Agent 系统，做 influencer marketing 全流程自动化。技术栈是 Python 3.11 + LangGraph 0.2 + Claude Sonnet 4 + PostgreSQL 16。

业务同学拿着 Claude Code demo 来找我的那天（系列第 1 篇），我在文章最后写了一句：变化真的来了。

那时候我不确定方向。搭完 MatchInfluence 之后，清楚了一些。

起点：为什么需要 Multi-Agent

15 个 skill 摆在面前的时候（详见系列第 4 篇），问题从怎么写变成了怎么协同。一个需求进来，该调哪个 skill。三个 skill 串在一起，顺序怎么定。中间出错了谁负责。

手动调度撑不了多久。我需要一个系统，能自己决定怎么用这些 skill。

MatchInfluence 的目标很具体：做 influencer marketing 的全流程自动化。从策略到达人筛选到触达到效果追踪，每个环节需要的专业能力不同。

第一次尝试：单 Agent 的失败

一开始试过用一个 agent 干所有事。把整个流程塞进一个 system prompt，告诉 AI 一步一步来。

# v0.1: 单 agent 架构（失败）
agent = Agent(
    system_prompt=STRATEGY + SOURCING + TRACKING + RULES,
    model="claude-sonnet-4",
    max_tokens=8192
)

结果和预期的一样。第一步还在轨道上，第二步开始偏，第三步已经忘了第一步的目标。

一个 agent 的上下文窗口撑不住这么长的链路。每一步的中间产物会堆积，早期的决策会被后面的信息挤掉。第 3 篇提到的 Lost in the Middle，在这里以另一种方式出现了。Strategy Agent 定好的 KPI（比如"30 天内触达 500 万目标用户"）传到 Sourcing Agent 时，关键数字已经模糊了。

拆成多个 agent 是顺理成章的选择。但怎么拆，拆完怎么协作，才是真正花时间的地方。

Multi-Agent 系统设计

v0.4 架构：4 个 Agent 的边界设计

经过 3 次迭代（v0.1 单 agent → v0.2 双 agent → v0.3 三 agent → v0.4 四 agent），最终的架构是：

Agent	职责	输入	输出
Strategy	campaign 策略、KPI、预算	业务需求 brief	`CampaignBrief` 结构化对象
Sourcing	达人发现、筛选、联系	`CampaignBrief`	`CreatorList[]`
Tracking	效果追踪、报告	`CreatorList[]` + 实时数据	`PerformanceReport`
Orchestrator	调度、异常处理、人工升级	全部事件流	任务状态机

决策 1：边界（boundary）

每个 agent 有自己的范围。如果一件事不属于任何 agent 的边界，它不猜。它报错。

class StrategyAgent:
    SCOPE = {"campaign_goal", "kpi", "budget", "target_audience"}
 
    def handle(self, input):
        if not input.keys() <= self.SCOPE:
            raise OutOfScopeError(f"unknown fields: {input.keys() - self.SCOPE}")
        ...

这个原则做起来最难，因为人习惯模糊，但 agent 不行。

决策 2：通信（communication）

Agent 之间用结构化数据通信，不用自由文本。

# CampaignBrief schema (Pydantic v2)
class CampaignBrief(BaseModel):
    campaign_id: str
    goal: Literal["awareness", "conversion", "retention"]
    kpi: dict[str, float]          # {"reach": 5_000_000, "cpm": 50.0}
    budget_usd: float
    target_audience: AudienceSpec
    start_date: date
    end_date: date

Strategy Agent 输出一份 CampaignBrief，有固定的字段结构。Sourcing Agent 读这份 brief，在自己的范围内执行。如果 Sourcing Agent 需要理解 Strategy Agent 的一段自由文本，每读一次都是一个概率分布，偏差会累积。

结构化数据让偏差没有机会累积。

决策 3：决策权（decision rights）

Strategy Agent 设定框架。Sourcing Agent 在框架内自主决策。

框架之外的事，升级到人。这个逻辑跟管理团队一样。自主权是边界内的自由。

# Sourcing agent 自主决策的边界
AUTONOMOUS = {"filter_by_audience", "rank_by_engagement", "draft_outreach"}
REQUIRES_HUMAN = {"send_contract", "approve_budget", "finalize_list"}

决策 4：失败处理（failure handling）

Agent 超时不响应怎么办，输出质量不达标怎么办，每一步都可追溯。

# 每个 agent 调用都记录 trace
trace.log(
    agent="Sourcing",
    input_hash=hash(brief),
    output=creator_list,
    latency_ms=3200,
    token_usage={"input": 1200, "output": 800},
    status="success" | "timeout" | "quality_fail",
)

这些问题设计阶段漏掉一个，线上就是一次事故。

上线后的关键数据

v0.4 在 2026 年 5 月 20 日上线，跑了 3 周后我回顾了一下数据：

总执行任务：47 个 campaign
平均端到端时延：从输入 brief 到生成 PerformanceReport，平均 4 分 12 秒
Agent 调用次数：单次 campaign 平均 23 次（包含重试）
失败率：3.2%（主要是 Sourcing Agent 在小众市场召回不足，触发人工升级）
成本：单次 campaign 平均消耗约 18k tokens，按 Claude Sonnet 4 定价约 $0.27

数据不算亮眼，但够用。更重要的是，每一笔失败都能从 trace 里复盘，这在单 agent 时代是做不到的。

产品经理的新位置

搭完 MatchInfluence 之后，我重新想了一遍第 1 篇的问题。

业务同学可以用 AI 做 demo 了。研发可以用 vibe coding 搭原型了。产品经理还剩什么。

我现在做的事是：设计决策系统。搞清楚一件事的决策权怎么分配、信息怎么流动、异常怎么处理、质量怎么判断。这些问题的答案，在过去是团队协作中自然形成的。但 AI 没有自然形成这个过程。你不设计好，它就是乱的。

写 PRD 的能力底层没有变：结构化思维、边界定义、预期管理。只是翻译对象从人换成了 AI。

第 2 篇我写过，LLM 的原理是在概率分布里选词。接受这个前提之后，产品经理的工作就变成了设计一个系统，让 AI 在概率波动中也能稳定输出。前者靠 prompt，后者靠架构。

回到起点

如果现在业务同学再拿着一个 AI demo 来找我，我不会觉得不安。

我会问他：你要做的这件事，一个 prompt 能搞定，还是需要一个系统。

这两个问题的答案不一样。分辨它们的能力，可能就是产品经理在新阶段的核心价值。

从 ChatGPT 到 Multi-Agent，工具换了，方法换了。理解问题、设计边界、管理预期这些事没变。翻译对象从人换成了 AI。

系列完结。下一篇会拆解 ai123.com 的 vibe coding 全过程——从想法到上线，2 周，零后端经验。