Day 45 / 共 68 天 · 阶段 8 多智能体

多智能体协作模式:交接 vs 子代理当工具

昨天(Day 44)我们把编排框架选型讲透,为"单个 Agent"画了句号。今天正式跨进多智能体:当一个 Agent 忙不过来,就得组队。第一课先讲两种最核心的协作方式——handoff(交接接力棒)agent-as-tool(把子代理当工具用),并说清为什么后者往往更可控。明天(Day 46)讲 Agent 之间"用什么协议对话"。

📍 你在阶段 8(多智能体 D45-48)的位置
D45 协作模式 D46 协作协议 D47 主管-专家 D48 多智能体实战
💡 用一个类比兜住今天(今天全程沿用「一家公司里的团队协作」的世界观) 多智能体 = 一家公司里几个同事协作办一件事单 Agent = 一个人身兼数职,累且容易出错;handoff 交接 = 把整件事连人带活"转交"给同事,自己退场(像接力赛把棒子递出去,之后就不管了);agent-as-tool = 我还是主办人,只是"把某个专家当外援叫来问一句",答完他回去,方向盘始终在我手里(像老板把活外包给顾问,拿到报告后继续自己拍板)。今天你从"独狼"变成"会用人的项目负责人"。
L01

单个 Agent 为什么不够用

🤔 痛点前面我们一直在打磨"一个"Agent。可当任务变大——又要查资料、又要写代码、又要审校、还要翻译——把这些全塞给一个 Agent,它的提示词越堆越长、工具越挂越多,结果什么都会一点,什么都做不精,还经常跑偏。
💡 本质和公司一样:一个人身兼采购、研发、财务、法务,迟早崩。分工能让每个 Agent 专注一件事、提示词短而精、工具少而准,整体更稳更好调。多智能体的出发点就是"把大任务拆给各有专长的小 Agent"
👶 为什么"塞一个大 Agent"会变差?模型的注意力有限(还记得 Day 18 的"lost in the middle"吗)。工具越多,模型越容易挑错工具;指令越杂,越容易顾此失彼。拆小 = 每个 Agent 的上下文更干净,就像把一间堆满杂物的屋子分成几个专用房间,找东西反而更快。
📝 举个例子:一个 vs 一队 做"市场调研报告":单 Agent 版常常查到一半忘了要写、写着写着又去查,来回打转。分工版——研究员只管查、写手只管写、审校只管挑错,各司其职,产出明显更整齐。
L02

handoff 交接:把接力棒递出去

🤔 痛点客服场景:接线员发现这是个"技术故障"问题,自己搞不定,得转给技术专线。转过去之后,后面整段对话就该由技术同事接管了。
💡 本质handoff(交接)= 把控制权整个转交给另一个 Agent,自己退出。接棒的 Agent 拿到上下文后独立往下跑,原来的 Agent 不再参与。像接力赛:棒子递出去,你就下场了。
handoff:控制权整个交出去(接力棒) 接线员 Agent 发现是技术问题 技术 Agent 接管后独立处理 🏃 递出接力棒(转交控制权) 交完就下场
图注:交接后主导权在新 Agent 手上,原 Agent 退出——适合"按类型分流到不同专线"。
适合场景:客服路由(按问题类型转不同专家线)、分诊台(先判断再转科室)。特点:一次转交、职责清晰。隐患:交出去后主流程"失去方向盘",如果新 Agent 又乱转,容易转成一团乱麻(下一讲重点)。
L03

agent-as-tool:把子代理当一个工具来调

🤔 痛点我这个主 Agent 想全程掌控大局,只是偶尔需要某个专家帮忙算一段/查一下,用完还想接着按我的计划走——不想把整个流程交出去。
💡 本质agent-as-tool(子代理当工具)= 把另一个 Agent包装成一个"工具"挂在主 Agent 身上。主 Agent 像调普通函数一样"叫"它一下、拿到返回结果,然后继续自己主导。方向盘始终在主 Agent 手里。这其实就是把 Day 29 学的 function calling 扩展一下:被调的"工具"内部是另一个完整的 Agent。
# 核心思想:把"子 Agent"包成一个普通函数(工具),主 Agent 需要时调用
def research_specialist(query: str) -> str:
    """研究专家:给我一个问题,还我一段调研结论(内部自己是个小 Agent)"""
    return sub_agent_run(role="研究员", task=query)   # 内部跑一个子 Agent

# 主 Agent 的工具表里,多了一个"叫专家"的工具
tools = {
    "search_web": search_web,            # 普通工具
    "ask_researcher": research_specialist,  # ← 子代理当工具!
}

# 主 Agent 决策时可能这样用:
# "这个问题我拿不准 → 调 ask_researcher 问一下 → 拿到结论 → 我继续写报告"
# 关键:调完专家,主导权立刻回到主 Agent 手里,不会跑丢
📝 举个例子:老板与外包顾问 你是项目负责人(主 Agent),负责一份方案。中途需要一份法律意见,就把"法务顾问"(子 Agent)当外援叫来:"帮我看看这条款有没有风险。"顾问给完意见就回去,你拿着意见继续按自己的节奏写方案。你从没把整个项目交给他——这就是 agent-as-tool。
L04

为什么 agent-as-tool 往往更可控

🤔 痛点两种模式都能"让多个 Agent 干活",为什么工程实践里大家越来越偏爱 agent-as-tool?
💡 本质因为它始终有一个"总指挥"不放手。handoff 是"击鼓传花",花传出去就不知道飘到哪;agent-as-tool 是"总指挥叫外援",每次外援干完都回到总指挥这里汇报,流程可预测、好追踪、易兜底
对比维度handoff 交接agent-as-tool 子代理当工具
控制权整个交出去,来回漂始终在主 Agent(更稳)
流程可预测性较弱(可能层层转丢)强(叫一次回一次)
出错兜底难定位是哪一棒出问题某个"工具"失败就单独兜底
适合清晰的一次性分流路由需要主线掌控的复杂协作
agent-as-tool:总指挥叫外援,用完就回来 主 Agent 总指挥(不放手) 研究员(工具) 计算器(工具) 审校(工具)
图注:实线=主 Agent 叫外援,绿虚线=外援把结果交回。控制权像橡皮筋,永远弹回中心。

👶 小白:那 handoff 是不是就没用、该淘汰了?

👨‍🏫 老师:不是!它俩是不同工具,不是优劣。handoff 在"清晰的一次性分流"上非常干净——比如客服总台按问题类型转到对应专线,转过去就该由专线独立负责,硬要总台全程盯反而多余。经验法则:需要一个总线始终掌控大局,就用 agent-as-tool;只是把请求路由到某条独立处理线,就用 handoff。很多真实系统两者混用。

L05

常见协作拓扑:团队怎么排阵

🤔 痛点知道了两种"叫人"方式,那多个 Agent 摆在一起,整体结构一般长什么样?
💡 本质常见就三种"阵型",都能用公司类比秒懂:
拓扑公司类比说明
流水线(Pipeline)装配线:一道工序接一道研究员→写手→审校,顺序传递,最简单
星形 / 主管制(Supervisor)项目经理带一队专家中心 Agent 分派+汇总(明天 Day 47 详讲)
群聊 / 对话(Group Chat)开会边聊边定多个 Agent 互相对话协商(AutoGen 那味)
三种常见阵型 流水线 星形/主管 群聊
图注:红=起点/中心,橙=执行者,紫=平等对话者。今天先混脸熟,Day 47/48 会把星形和流水线跑通。
L06

反模式与坑:别把简单事搞复杂

🤔 痛点学会了多智能体,是不是所有项目都该拆成一堆 Agent?听起来越"多智能体"越高级?
💡 本质恰恰相反——多智能体是有成本的:Agent 越多,调用次数越多(更贵更慢)、出错点越多、越难调试。能一个 Agent 干好的,就别硬拆。公司三个人能办的事,非要拉三十人开会,只会更慢更乱。
常见反模式:① 无脑拆——把本可一个 Agent 完成的活拆成五个,成本翻倍收益为零;② handoff 套娃——A 转 B、B 转 C、C 又转回 A,转丢方向;③ 没有兜底——某个子 Agent 挂了整条线崩(Day 54 会专门讲失败闸门);④ 上下文不传——交接时没把必要信息带过去,接棒的 Agent 一脸懵。
📝 举个例子:什么时候值得上多智能体 值得:任务天然分几类专长、需要"生产者+审查者"互相制衡、某步骤要独立的工具集。不值得:一问一答、单一领域、逻辑线性——这些一个 Agent 更省心。判断口诀:先想"一个 Agent 行不行",不行再拆。
L07

今日小结 + 动手 10 分钟

🧠 今天你应该能回答

  • 为什么"一个大 Agent 塞满工具"会变差?分工好在哪?
  • handoff(交接)和 agent-as-tool(子代理当工具)各是什么?
  • 为什么 agent-as-tool 往往更可控?它俩分别适合什么场景?
  • 三种常见协作拓扑(流水线/星形/群聊)分别像公司里的什么?
  • 什么时候不该上多智能体?

✋ 动手 10 分钟:用普通函数体会 agent-as-tool

不接真模型,用假的"子 Agent"(普通函数)体会"主 Agent 叫外援、用完继续主导"的手感:

# 两个"子 Agent",先假装成会返回结果的函数
def researcher(topic):
    return f"关于「{topic}」的三个要点:省钱、可控、易调试"

def critic(text):
    # 审校子 Agent:挑一个毛病回来
    return "审校意见:结论可以,但缺少具体例子"

# 主 Agent:全程自己主导,只在需要时"叫外援"
def main_agent(topic):
    print("主Agent:我来负责这份报告")
    facts = researcher(topic)         # ① 叫研究员(agent-as-tool)
    print("拿到素材:", facts)         #    → 控制权回到我手里
    draft = f"报告初稿:{facts}"       # ② 我自己写初稿
    review = critic(draft)            # ③ 叫审校(agent-as-tool)
    print("拿到审校:", review)        #    → 控制权又回到我
    return draft + "|(已据审校补充例子)"  # ④ 我根据意见定稿

print(main_agent("多智能体协作"))
# 体会:外援来一次走一次,方向盘一直在 main_agent 手上——这就是"可控"
明日预告 · Day 46:今天讲了 Agent 之间"怎么配合",明天讲它们"用什么语言/规矩对话"——三大协作协议 MCP / A2A / ACP:MCP 管"Agent 接工具"、A2A 管"Agent 之间通话"、ACP 又是什么。用"插座标准 + 普通话"的类比帮你一次分清。
← Day 44 · 框架选型对比 Day 46 · 协作协议 A2A/ACP/MCP →