一个 Agent，
干不完一件像样的事。

• 天花板 · 01 · CONTEXT DRIFT

  任务超过 50 步后，前面的指令被新内容稀释

  你给 agent 一个 system prompt + 任务目标，让它跑 80 步。 到第 50 步时，agent 实际上已经看不太到原始 system prompt 了——它在被自己最近的输出 + tool 调用结果淹没。 观察症状：开头执行得很好，后面突然开始走样、忘记规则、答非所问。 模型再强也救不了——这是 attention 机制 + 上下文长度的物理限制。

• 天花板 · 02 · TOOL OVERLOAD

  同一个 Agent 装了 20+ 个工具，调用判断越来越乱

  随着你给 agent 加越来越多的 tool（Gmail、Calendar、Notion、SQL、Web search、自定义 API...）， 每次决策时它需要在 N 个 tool 之间选一个——选错就走偏。 实测：tool 数量超过 15 个后，agent 的 tool selection 准确率开始线性下降；超过 30 个，几乎不可用。 装得越多越无能——这是 Function Calling 的固有问题，不是 prompt 调教能解的。

• 天花板 · 03 · ERROR COMPOUNDING

  单线程任务一旦中间出错，后面全部基于错信息往下推

  agent 在第 12 步把客户名字读错了，从第 13 步开始的所有动作（查记录、写回复、发邮件）全是错的， 但 agent 自己看不出来——它没有第二双眼睛检查它的中间结果。 到第 30 步你发现不对，回去查日志，发现问题源头是第 12 步——但这一切已经发生在生产环境。 这是单 agent 模式最常见的事故来源。

• 天花板 · 04 · ROLE COLLAPSE

  同时要它"做+检查+报告"，哪一样都做不好

  你写了一段巨长的 prompt：先研究市场、再起草文案、再批判性 review、最后输出 markdown 报告。 agent 在每个角色里都浅尝辄止——因为它没法在同一次推理里真正切换思维模式。 尤其是 "Drafter + Critic" 不分开，几乎一定会自圆其说：写文案的它和批评文案的它本就是同一个推理流。

判断"是不是真 multi-agent"，看一个标准：两个 agent 各自的 context 窗口是不是真的独立。 如果只是同一个 system prompt 里 "you are agent A...you are agent B"，那只是个角色扮演——不是 multi-agent。

真正的 multi-agent 有 4 种典型协作模式。它们解决的问题不同，复杂度不同。多数生产系统是这 4 种的组合。

• 模式 · 01 · MANAGER–WORKER

  一个 Manager 拆任务，N 个 Worker 各自执行

  最常见、最容易理解。Manager agent 收到一个大任务，把它拆成 N 个子任务， 分发给专门的 Worker agents，每个 worker 用独立 context 跑自己那一段， 完成后汇报给 manager，manager 汇总并出最终结果。

  USE写一份 50 页调研报告 · Manager–Worker 实现

  ·MANAGER拆成 8 个章节 → 分配给 8 个 Researcher

  ·WORKER ×8每个独立查资料、写自己那章 · 互不干扰

  ·MANAGER收齐 8 份 → 统一风格 → 写引言 + 结论

  WHEN TO USE任务能被静态拆分 · 子任务之间没有强依赖
• 模式 · 02 · PIPELINE

  Agent A → Agent B → Agent C，每步处理完丢给下一步

  流水线式。每个 agent 负责一个阶段的转化，前一个 agent 的输出 = 后一个 agent 的输入。 和 Manager–Worker 的区别：流水线是串行单线，没有中央调度者。

  USE内容生产 · Pipeline 实现

  01RESEARCHER挖 10 篇同行爆款 → 提炼共性

  02IDEATOR基于研究 → 出 7 个选题 + 大纲

  03WRITER写完整草稿

  04EDITOR校稿、改人设语料

  05PUBLISHER排版 + 多平台适配 + 排期

  WHEN TO USE任务是一条线性产业链 · 每段都有专门技能要求
• 模式 · 03 · SPECIALIST ROUNDTABLE

  多个专家 Agent 并行看同一个问题，最后一个 Synthesizer 汇总

  "三家会诊"模式。同一个输入同时送给多个专家 agent， 每个 agent 用自己的专业 lens 看，给出独立判断；最后一个 synthesizer 把多视角合并。 重点是并行——专家之间互不沟通，避免彼此污染。

  USE股票决策 · Roundtable 实现

  ·QUANT看技术面 (双均线、RSI、量价) · 独立打分

  ·FUNDAMENTAL看财报、行业、估值 · 独立打分

  ·SENTIMENT看新闻、社媒、机构动作 · 独立打分

  ·RISK看仓位、波动、关联性 · 独立打分

  ·SYNTHESIZER汇总 4 个独立结论 → 出决策建议

  WHEN TO USE需要多个独立视角 · 怕"单一思维定式"
• 模式 · 04 · ADVERSARIAL

  Drafter 写，Critic 挑刺，反复迭代到收敛

  对抗式。一个 agent 负责产出（Drafter），另一个 agent 天职就是找问题（Critic）。 两者来回多轮，直到 Critic 没意见或迭代次数到上限。 解决的核心问题：单 agent "自己审自己" 几乎一定自圆其说。

  USE代码 Review · Adversarial 实现

  01DRAFTER读 issue → 写实现 + 测试 → 提交 v1

  02CRITIC挑刺 (边界、安全、性能、可读性) → 列改进项

  03DRAFTER基于反馈改 → 提交 v2

  04CRITIC再 review → 直到通过或达 3 轮

  WHEN TO USE产出质量是死命题 · 错了代价大 (代码 / 合同 / 法律意见)

• LEVEL · 01 · SINGLE AGENT

  你的任务能在 10 步内完成、且不会反复发生？

  如果是：不要上 Skill，更不要上 Multi-agent。 你只需要一个 ChatGPT / Claude 窗口 + 一段 prompt。Skills 和 Multi-agent 都有维护成本——任务不重复就别立基础设施。

  触发信号：每周 0-1 次的临时任务 · 单一职能 · 无并行需求
  真实例子：写一封一次性邮件 / 调研一个临时问题 / 查一份资料
• LEVEL · 02 · SINGLE AGENT + SKILLS

  同一个 Agent 要做 5+ 种类型的活，或者某段工作流反复复用？

  如果是：上 Skills，但还不需要 Multi-agent。 Skills 让一个 Agent 像一个团队那样干活——同一个 context，可调用模块化能力。维护成本中等：要写 SOP，但只有一个 agent 在跑。

  触发信号：同一 agent 处理 5+ 类任务 · 某段工作流被多处复用 · 需要团队协作维护 prompt
  真实例子：个人助理（邮件 + 日历 + Notion + 备忘） / 一体化客服（多类工单 + 知识库 + 升级）
• LEVEL · 03 · MULTI-AGENT

  任一信号触发：context 超载 / 需要独立审核者 / 需要真并行？

  如果是：上 Multi-agent。但准备好为协议设计、调试链路、监控状态多花 5-10×的工作量。 Multi-agent 不是"更高级的版本"，是不得不分工时的选择。

  触发信号：单 agent 跑过 50 步会漂移 · 必须独立眼挑刺 · 4+ 子任务可并行 · context 装不下完整 schema
  SUB-CHOICE4 种模式怎么选

  ·MANAGER-WORKER任务能静态拆分 · 子任务互相独立

  ·PIPELINE任务是顺序转化 · 每步有专门技能

  ·ROUNDTABLE需要多个独立视角 · 怕思维定式

  ·ADVERSARIAL质量是死命题 · 错代价大 (代码 / 合同)

  REMEMBER多数生产系统是 2-3 种模式的嵌套组合

• 观察 · 01 · LANGGRAPH WRAPPER

  "Multi-agent Platform / OS"

  2024-2026 涌出大量"Multi-agent OS / 平台"创业项目。多数本质是 LangGraph + 一层 UI， agent 之间根本没有真正独立的 context。判断标准很简单：问他们"两个 agent 各自能看到什么 system prompt？"—— 答不出具体边界，就是个 wrapper。

• 观察 · 02 · MORE TOOLS > BETTER AGENT

  "我们的 Agent 装了 100+ Skills"

  "Skills 数量"被当成卖点，但 §02-02 的 Tool Overload 天花板对 skills 同样成立—— 装得越多，agent 选择哪个 skill 的判断越乱。 生产实测：超过 15-20 个 skills 后，召回准确率断崖式下跌。 装精的 10 个 > 装杂的 50 个。

• 观察 · 03 · ACADEMIC vs PRACTICAL

  "Multi-agent 是通向 AGI 的路径"

  这是学术界辩了 20 年的话题（agent-based modeling, swarm intelligence, multi-agent reinforcement learning…）， 跟你今天搭一个能跑通客服工单的系统没有关系。 这种宏大叙事经常被用来给一个简单的 LangGraph demo 装门面——听到就先记住：再宏大也得能跑工单。

• 观察 · 04 · PROPRIETARY FRAMING

  "Skill 是 Anthropic 的专有功能"

  错。Skill 不是某个厂商的功能，是一种设计模式。 它跟 OpenAI Custom GPT Actions、LangChain Tools、自己写的 modular prompt 文件、 甚至 Unix 工具 + 一段 README 文档，本质都是同一回事——把可复用的能力打包成可被发现 + 可被调用的单元。 谁封装得最干净是另一回事，但概念不归任何一家。

• 观察 · 05 · WRONG ORDER

  "复杂任务必须用 Multi-agent"

  通常说反了。复杂任务最该做的第一件事是SOP 化——把它拆成可重复的步骤、明确每步的输入输出。 做完 SOP 之后，多数任务的"复杂度"会下降到能用单 agent + skills 解决；只有真正剩下的、需要并行 / 独立审核的部分才上 multi-agent。 顺序搞反——直接堆 multi-agent——结果是用昂贵的协调成本掩盖你没想清楚的工作流。

• WEEK 1 – 2 · 找候选

  列出你工作流里 3 个最高频的子任务

  不是找"想用 AI 替代的活"——是找"每周做 5+ 次、每次步骤几乎一样"的事。 这些是 Skill 的天然候选。写下来：任务名 / 频率 / 输入 / 输出 / 当前耗时。 失败信号：列不出 3 个——说明你的工作流还没规律化，回 Ep 01。 怎么办：继续做一周纯人工，每做一件事记一笔。

• WEEK 3 – 4 · 写第一个 Skill

  挑最痛的那个候选 — 写成 SKILL.md 跑通

  按 §03 那 4 要素（DESCRIPTION / CONTRACT / PROMPT / TOOLS）写一个独立文件。 在 Claude Code 或自己的 agent 里挂上，连跑一周——每次需要这个任务时只调它，不手写 prompt。 失败信号：第 4 周末你还在频繁手动改 SKILL.md 里的 prompt。 怎么办：不是 Skill 不行——是你选的任务还不够 SOP。回去拆得更具体。

• WEEK 5 – 8 · 装满一个 Agent

  写 3-5 个 Skill，装到同一个 Agent

  把 Week 1-2 列的另外 2-4 个任务也做成 Skill。 现在你的 agent 应该能在一个 context 里处理 5 种不同类型的活—— 体验上，从"通用助理"升级成"有专业能力的同事"。 失败信号：agent 经常调错 Skill / 把两个 Skill 的逻辑混着用。 怎么办：说明你装太多了——压回 3 个最高频的，剩下的留到 Multi-agent 阶段。

• WEEK 9 – 12 · 第一次分工

  挑一个跑不通的复杂任务，设计 2-3 agent 协作

  找一个 §02 天花板真撞到的任务——单 agent 跑过 50 步崩、或需要独立 critic、或需要并行处理。 按 §04 4 种模式选一种，搭一个最小可用 multi-agent 系统。 不要做大、做完整——做能跑通最简单版本即可。 失败信号：到第 12 周还在调 prompt / 协议，跑不通 end-to-end。 怎么办：多数时候是你想搭的系统太复杂——拆到只剩两个 agent，看哪个真有必要独立。

12 周后你该能回答这个问题： "我现在每天工作的哪一段，是同一个 Agent 调一组 Skill 跑完的？哪一段是几个 Agent 协作跑完的？"

能具体指出这两段、有产出物、有日志——你就跨过了 Ep 01 → Ep 02 的边界。 回答不出来——说明你还是在用"一个 ChatGPT 窗口"在做事，没"搭系统"。

← EP 01 · What is AI Agent　·　EP 02（你在这里）　·　EP 03 (coming)