P.S. 目前国内还是很缺AI人才的，希望更多人能真正加入到AI行业，共同促进行业进步，增强我国的AI竞争力。想要系统学习AI知识的朋友可以看看我精心打磨的教程 http://blog.csdn.net/jiangjunshow，教程通俗易懂，高中生都能看懂，还有各种段子风趣幽默，从深度学习基础原理到各领域实战应用都有讲解，我22年的AI积累全在里面了。注意，教程仅限真正想入门AI的朋友，否则看看零散的博文就够了。

前言

说实话，我写了22年代码，见过太多"全栈工程师"——就是那种前端后端运维测试客服销售全一个人干的。最后啥结果呢？头发没了，脾气大了，代码里全是TODO。AI Agent也一样，你非要一个Agent既当爹又当妈，它迟早给你表演一个"人工智障"。

今天咱们聊聊Multi-Agent——怎么让多个AI分工协作，而不是让一个AI累到冒烟。放心，不整那些八股文，咱们用说人话的方式，把这事儿唠明白。

一、一个Agent扛所有？你是想让它猝死吗

我见过最离谱的Prompt，足足写了三千字。开头是"你是一个全能助手"，中间列了二十八条技能，结尾来一句"请保持专业"。大哥，你这是在写招聘JD还是写Prompt啊？

结果就是，这个Agent做数学题的时候想着怎么写代码，写代码的时候惦记着查资料，查资料的时候又琢磨着要不要给用户讲个笑话。精神分裂都没它分得这么彻底。

更惨的是串行执行。五个任务排队等，前面一个卡住，后面四个全在那儿刷抖音。你说急不急？

所以Multi-Agent的核心就俩字：分工。
专业的人做专业的事，专业的Agent做专业的活。检索的Agent就老实检索，计算的Agent就专心算数，写代码的Agent别瞎操心别的。各干各的，互不打扰，偶尔开个会同步一下进度。

二、Host-Worker：项目经理与打工仔的故事

这个模式我特别熟，因为我当过Worker，也当过Host——当然，更多的时候我是那个被Host呼来喝去还得陪笑的Worker。

Host-Worker的逻辑特别像互联网公司：

Host 就是项目经理，手里有一份"员工花名册"——每个Specialist（专家Agent）会什么、能干啥，它门儿清。用户提需求过来，Host扫一眼，心里盘算："这事儿得找研究员查资料，再找工程师写代码。"然后啪一声，派活！

注意啊，Host不是普通聊天模型，它是ToolCallingChatModel。这名字听着唬人，其实就是能输出结构化指令的模型。它不说"你去干吧"这种废话，而是精确到：“调用研究员Agent，参数是’查询Redis集群优化方案’。”

然后几个Specialist并发执行。研究员去查资料，工程师去写代码，两个人同时干活，谁也不等谁。最后Summarizer 出场，把几份报告攒成一份完整的，交给用户。

关键点来了：
• Host选了一个Specialist → 直接返回结果，Summarizer放假
• Host选了多个Specialist → 并发执行，Summarizer加班汇总
• 每次派活都会触发HandOff事件，你可以监听，就像偷看项目经理在给谁派活

我用eino框架写了个示例，Host配置长这样：

hostCfg := &host.Config{
    Host: host.Host{
        ToolCallingModel: myLLM,
        SystemPrompt: "你是项目经理，根据任务类型分配给合适的专家。",
    },
    Specialists: []host.Specialist{
        {
            AgentMeta: host.AgentMeta{
                Name: "researcher", 
                IntendedUse: "负责资料检索和调研"
            },
            ChatModel: researchLLM,
            SystemPrompt: "你是研究员，擅长搜索和分析信息。",
            Invokable: researchAgent.Invoke,
        },
        {
            AgentMeta: host.AgentMeta{
                Name: "coder", 
                IntendedUse: "负责编写和调试代码"
            },
            ChatModel: codingLLM,
            SystemPrompt: "你是工程师，只负责写代码，不做其他事。",
            Invokable: coderAgent.Invoke,
        },
    },
}

你看这配置，清清楚楚，明明白白。研究员就叫researcher，工程师就叫coder，各司其职。不像某些公司，招个"全栈工程师"，结果让人家修打印机。

三、Plan-Execute-Replan：计划赶不上变化

Host-Worker适合那种"任务类型明确"的场景。但生活中更多情况是：你也不知道要几步，走一步看一步，中间还可能翻车。

比如你说"帮我规划个北京三日游"。一开始想的是查景点、查天气、订酒店。结果查完天气发现台风来了，得改室内行程。订酒店发现满房了，得换区域。这就是典型的步骤不确定。

Plan-Execute-Replan就是专门治这种"计划赶不上变化"的病的。它有三个角色：

Planner（规划师）：先拆步骤，“查景点→查天气→规划路线→订酒店”
Executor（执行者）：干第一步，比如调searchTool查景点
Replanner（复盘师）：看结果，决定继续、调整还是收工

这三个角色形成一个循环：Planner → (Executor → Replanner) × N，直到Replanner说"行了，完事了"。

我特别喜欢Replanner的设计，因为它只有两个选择，不纠结：

1. 任务没完 → 输出新计划，继续循环
2. 目标达成 → 输出最终答案，退出循环

没有"我再想想"、"要不问问领导"这种选项。decisiveness，懂吗？

它们之间靠Session键值对传状态。Planner写Plan，Executor读Plan.FirstStep()执行，然后把结果写进ExecutedStep。Replanner读所有历史ExecutedSteps，判断下一步。没有消息总线，没有微信群@所有人，就是简单的键值对读写。

Planner有个很骚的操作：用ToolChoiceForced强制LLM输出结构化计划。不许说废话，不许抒情，不许"我觉得吧"，直接给我输出JSON步骤列表。就像有些产品经理，需求文档必须按模板写，少一个字都不行。

var PlanToolInfo = schema.ToolInfo{
    Name: "plan",
    Desc: "制定按序执行的步骤列表",
    ParamsOneOf: NewParamsOneOfByParams(map[string]*schema.ParameterInfo{
        "steps": {
            Type: schema.Array,
            ElemInfo: &schema.ParameterInfo{Type: schema.String},
            Desc: "按顺序排列的执行步骤",
            Required: true,
        },
    }),
}

Replanner也类似，只有两个工具可选：plan（继续规划）和respond（完成任务）。简单粗暴，我喜欢。

四、Supervisor：官方都不推荐的冤种模式

Supervisor这模式，我劝你有多远躲多远。eino官方代码里直接标了⚠️ Not Recommended，相当于餐厅菜单上写"厨师不推荐"。

它的逻辑是这样的：Supervisor把整段对话上下文塞给Sub-Agent，Sub-Agent干完活再把全部上下文还回来。下次派活，又塞一遍全部上下文。

你品品，这像什么？像不像你那个每次开会都要把PPT从公司历史讲起的领导？context越来越长，token越来越贵，效果还越来越差。实验数据证明，全上下文传递并没有带来更好的效果，纯粹是烧钱玩。

所以官方推荐用AgentTool替代。把Sub-Agent包装成一个工具，Parent Agent按需调用，不共享全上下文。就像你叫外卖，只需要说"我要一份宫保鸡丁"，不用把你们家族谱讲给厨师听。

agentTool := adk.NewAgentTool(ctx, subAgent)

parentCfg := &adk.ChatModelAgentConfig{
    Model: llm,
    ToolsConfig: adk.ToolsConfig{
        ToolsNodeConfig: compose.ToolsNodeConfig{
            Tools: []tool.BaseTool{agentTool, otherTool},
        },
    },
}

简洁，优雅，省钱。记住，能省token的地方一定要省，毕竟你的API账单不会跟你讲笑话。

五、Agent之间怎么通信？靠喊吗

有人问我，这些Agent之间怎么交流？靠微信群？靠飞书？靠站在走廊里喊？

都不是。它们靠schema.Message列表通信。Host-Worker模式里，Host通过ToolCall路由，框架自动根据ToolCall.Function.Name把结果送到对应的Specialist手里。你不需要手写路由逻辑，除非你想给自己找不痛快。

ToolCall长这样：

type ToolCall struct {
    ID string
    Function struct {
        Name string      // Specialist的名字
        Arguments string // JSON格式的任务描述
    }
}

Name就是你要找的Agent，Arguments就是你要它干的活。简单直接，没有"在吗"、“忙吗”、"有个小事"这种职场黑话。

六、任务分配的三种策略，别选错

最后给大家总结一下三种任务分配策略，选错了就像穿拖鞋去面试——不是不行，是有点离谱。

1. LLM路由（Host-Worker）
Host LLM自己决定派给谁。适合任务类型多样、边界模糊的场景。比如用户说"帮我搞个项目"，Host得判断是写代码、做设计还是写文档。

2. 结构化规划（Plan-Execute-Replan）
先拆步骤，再执行，错了就重规划。适合步骤未知、需要迭代调整的复杂任务。比如旅行规划、故障排查。

3. AgentTool调用（推荐替代Supervisor）
把Sub-Agent包装成工具，按需调用。适合子任务边界清晰、不需要共享上下文的场景。简单、轻量、省钱。

七、总结：别为了复杂而复杂

写了22年代码，我最大的感悟就是：能简单就别复杂。

Multi-Agent不是越复杂越好。能用一个Agent加几个工具解决的，别上Multi-Agent。上了Multi-Agent，优先选Host-Worker或者Plan-Execute-Replan。Supervisor？除非你想跟钱包过不去。

选型速查表：
• 问题可能需要多个专家 → Host-Worker
• 任务复杂、步骤未知、可能失败重试 → Plan-Execute-Replan
• 子任务边界清晰、轻量 → AgentTool
• 多层嵌套、复杂协调 → DeepAgent（下次再聊）

记住，AI Agent跟人一样，分工明确才能干好活。你非要一个人干十个人的活，最后只能得到十个人加起来那么贵的账单，和一个人那么差的产出。

好了，今天就聊到这儿。我是那个写了22年代码、头发还剩几根的老程序员。咱们下回见。

P.S. 目前国内还是很缺AI人才的，希望更多人能真正加入到AI行业，共同促进行业进步，增强我国的AI竞争力。想要系统学习AI知识的朋友可以看看我精心打磨的教程 http://blog.csdn.net/jiangjunshow，教程通俗易懂，高中生都能看懂，还有各种段子风趣幽默，从深度学习基础原理到各领域实战应用都有讲解，我22年的AI积累全在里面了。注意，教程仅限真正想入门AI的朋友，否则看看零散的博文就够了。