智能体编排框架横评(4):多智能体框架
本文总结CrewAI、AutoGen、Microsoft Agent Framework 入门:先各自跑通一个最小例子,再讲角色团队、群聊和编排构建器怎么表达多 Agent,最后说明报销为什么一个 Agent 加工具就够。
智能体编排框架横评 第 4 站 · 上一站:厂商 Agent SDK · 下一站:轻量与类型化框架 · 全程:总览
这一站讲什么
前几站的框架默认只有一个 Agent 跑一个循环。多智能体框架让几个 Agent 分工合作:有的按岗位分工,有的像群聊一样轮流发言,有的由一个主管分派任务。
这一站讲三个框架:
| 框架 | 出品方 | 多 Agent 怎么表达 |
|---|---|---|
| CrewAI | CrewAI 公司 | 角色团队:每个 Agent 有岗位,任务按流程分派 |
| AutoGen | 微软研究院 | Agent 之间互发消息,团队类型决定谁发言 |
| Microsoft Agent Framework(MAF) | 微软 | 工作流图,加上一组现成的编排构建器 |
AutoGen 已经停止维护,MAF 是微软给出的接替者。这里还讲 AutoGen,是因为很多教程和老项目用的是它,读懂它有助于迁移。
主管、群聊、交接这些拓扑的概念在 Agent 架构图解:从工作流到事件驱动工单 讲过,这里只看 API。报销场景沿用 主线:一个报销请求走完整个 Agent 系统。先说结论:报销拆成制度专员、发票专员、审核主管三个 Agent 没有收益,一个 Agent 加三个工具就够,理由在后面"报销要不要拆成三个 Agent"一节。
代码按各家 2026-11 的官方文档写,是示意代码,没有运行过。
CrewAI
CrewAI 是什么
CrewAI 把 Agent 当团队成员。每个 Agent 有角色(role)、目标(goal)和背景(backstory),这三段文字拼成它的系统提示。你把任务分给成员,团队按顺序或者由经理分派来完成。
后来 CrewAI 又加了 Flow,一个事件驱动的流程层,用来写确定的步骤、分支和人工审核。官方现在建议从 Flow 开始写,需要几个角色自由协作的部分再放一个 Crew 进去。
安装
pip install crewai
export OPENAI_API_KEY="sk-..."
也可以用 crewai create crew 项目名 生成一个带配置文件的项目骨架。
第一个团队
hello_crew.py 文件代码:
from crewai import Agent, Task, Crew
writer = Agent(
role="报销顾问",
goal="用一句话回答员工的报销问题",
backstory="熟悉公司差旅制度",
)
task = Task(
description="员工问:报销一般需要哪些材料?",
expected_output="一句话回答",
agent=writer,
)
crew = Crew(agents=[writer], tasks=[task])
result = crew.kickoff()
print(result.raw)
输出结果类似:
一般需要发票、行程或用途说明,以及审批人签字。
运行时控制台还会打印 Agent 的思考过程和任务状态,用 verbose=False 可以关掉。
基本概念
Agent。 除了 role、goal、backstory,还可以设置 tools(工具)、llm(模型)、max_iter(最多循环几次,默认 20)、allow_delegation(能不能把活交给同事,默认不能)。Agent 也可以不进团队单独运行:agent.kickoff("...")。
Task。 一项任务,写清 description(做什么)和 expected_output(要什么样的结果),指定由哪个 agent 做。context=[其他任务] 可以把上游任务的输出交给它。
review = Task(description="根据制度和发票信息下结论", expected_output="能报或不能报,附理由",
agent=supervisor, context=[policy_task, invoice_task])
guardrail 可以给结果加校验,不通过就让 Agent 重做,默认最多重试 3 次。
Crew 和 Process。 Crew 把 Agent 和 Task 组在一起,process 决定执行方式,只有两种:
| Process | 怎么执行 |
|---|---|
Process.sequential |
按任务列表顺序执行,上一个的输出给下一个 |
Process.hierarchical |
由一个经理 Agent 规划、分派、验收,要提供 manager_llm 或 manager_agent |
Flow。 用装饰器把方法串成流程:
from crewai.flow.flow import Flow, start, listen, router
class DemoFlow(Flow):
@start()
def first(self):
return "INV-102"
@router(first)
def check(self):
return "over" if self.state.get("amount", 118.5) > 80 else "ok"
@listen("over")
def need_approval(self):
print("超标,需要审批")
@start() 是入口,@listen(x) 在 x 完成后执行,@router(x) 返回一个标签决定走哪个分支。状态放在 self.state,可以是字典,也可以用 Pydantic 模型定义类型。
持久化和人工审核。 @persist 把 Flow 的状态存进 SQLite(默认)。@human_feedback 让某一步在继续之前等人审核。
报销例子:Flow 加一个 Agent
按官方先写 Flow 的建议:Agent 只拿两个只读工具做判断,员工确认之后,Flow 用普通代码调 create_ticket。建单这个副作用不交给模型。
from crewai import Agent
from crewai.tools import tool
from crewai.flow.flow import Flow, start, listen
from crewai.flow.human_feedback import human_feedback, HumanFeedbackResult
@tool("search_policy")
def search_policy(query: str) -> str:
"""查报销制度条款"""
return "4.2:市内打车单次标准 80 元"
@tool("get_invoice")
def get_invoice(invoice_id: str) -> str:
"""查发票金额与适用标准"""
return '{"id": "INV-102", "amount": 118.5, "standard": 80}'
assistant = Agent(role="报销助手", goal="判断能否报销并引用条款",
backstory="熟悉差旅制度", tools=[search_policy, get_invoice])
class ExpenseFlow(Flow):
@start()
@human_feedback(message="按以上结论提交报销单吗?", emit=["confirm", "cancel"],
llm="gpt-4o-mini", default_outcome="cancel")
def assess(self):
return assistant.kickoff("上周打车超标还能报吗,发票 INV-102").raw
@listen("confirm")
def submit(self, result: HumanFeedbackResult):
return create_ticket(invoice_id="INV-102", note=result.output) # 普通函数
ExpenseFlow().kickoff()
运行过程:
assess让 Agent 查制度和发票,给出结论;@human_feedback把结论展示给员工,等员工回复;- 员工的回复由
llm归到confirm或cancel,归不进去就用default_outcome; - 归到
confirm时执行submit,建单。
默认在控制台等输入。在网页里用时,自定义一个 HumanFeedbackProvider,在里面抛出 HumanFeedbackPending,Flow 会自动保存状态;员工回复后用 ExpenseFlow.from_pending(flow_id).resume(feedback) 接着跑。
常见问题
Task 的 human_input=True 能不能当建单确认用? 不能。它只在 Agent 给出最终答案前让人看一眼,不拦截某一次工具调用。工具级的拦截用 @on(InterceptionPoint.PRE_TOOL_CALL, tools=[...]) 钩子。
层级流程每次分派结果不一样。 谁做什么由经理模型决定,同一输入两次运行可能分给不同的人。需要确定顺序的部分放进 Flow。
Agent 之间来回委派停不下来。 官方排错页把这叫 "Delegation Loops"。只给协调者开 allow_delegation,其他成员关掉。
员工的确认回复被归错了标签。 emit 需要模型把自由文本分类,员工回"好的,但金额改成 80"会被归到哪里由模型决定。建单这类操作,default_outcome 要设成取消。
同一工具重复调用后任务直接失败。 同一工具以相同参数调用、得到相同结果 5 次,任务会以 ToolExecutionFailedError 停止,这个上限是固定的。
自动检查点没写进去也没报错。 自动写入失败只记日志。依赖恢复的流程改用手动 state.checkpoint(),失败时会抛异常。
AutoGen
AutoGen 是什么
AutoGen 把多 Agent 协作当成 Agent 之间互发消息。几个 Agent 组成一个团队,团队类型决定下一句由谁说:轮流、由模型挑选,或者由当前发言者交接给别人。
现在常用的是 0.4 版的 AgentChat 接口(0.4 到 0.7 是同一套)。它和更早的 0.2 不兼容,看教程时注意区分:0.2 的写法是 import autogen 和 ConversableAgent。
安装
pip install autogen-agentchat "autogen-ext[openai]"
第一个团队
hello_autogen.py 文件代码:
import asyncio
from autogen_agentchat.agents import AssistantAgent
from autogen_agentchat.teams import RoundRobinGroupChat
from autogen_agentchat.conditions import MaxMessageTermination
from autogen_ext.models.openai import OpenAIChatCompletionClient
model = OpenAIChatCompletionClient(model="gpt-4o")
writer = AssistantAgent("writer", model_client=model, system_message="写一句报销提醒")
reviewer = AssistantAgent("reviewer", model_client=model, system_message="把提醒改得更简短")
team = RoundRobinGroupChat([writer, reviewer], termination_condition=MaxMessageTermination(3))
result = asyncio.run(team.run(task="提醒员工报销要附发票"))
for m in result.messages:
print(m.source, ":", m.content)
输出结果类似:
user : 提醒员工报销要附发票
writer : 温馨提示:提交报销时请务必附上对应发票,以免影响审核进度。
reviewer : 报销请附发票。
两个 Agent 轮流发言,消息总数到 3 条时停止。
基本概念
AssistantAgent。 带模型、工具和系统提示的 Agent,handoffs=[...] 列出它可以把对话交给谁。
团队类型。
| 团队 | 谁发言 |
|---|---|
RoundRobinGroupChat |
按顺序轮流 |
SelectorGroupChat |
每轮让模型根据历史和成员描述挑下一位 |
Swarm |
当前发言者用 HandoffMessage 交接给下一位,所有人共享同一份消息 |
MagenticOneGroupChat |
一个编排者制定计划、分派、跟踪进度 |
GraphFlow |
按你画的有向图执行 |
终止条件。 团队什么时候停,比如 TextMentionTermination("TERMINATE")(有人说出这个词)、HandoffTermination(target="user")(交接给用户时)。可以用 | 组合。
状态。 团队和 Agent 都有 save_state()、load_state(),返回可序列化的字典,存在哪里自己管。
报销例子:交接给员工确认
from autogen_agentchat.agents import AssistantAgent
from autogen_agentchat.conditions import HandoffTermination, TextMentionTermination
from autogen_agentchat.messages import HandoffMessage
from autogen_agentchat.teams import Swarm
from autogen_ext.models.openai import OpenAIChatCompletionClient
agent = AssistantAgent(
"expense",
model_client=OpenAIChatCompletionClient(model="gpt-4o"),
tools=[search_policy, get_invoice, create_ticket],
handoffs=["user"],
system_message="先查制度和发票。能报时把结论交给 user 确认,确认后才调用 "
"create_ticket,完成后回复 TERMINATE。",
)
team = Swarm([agent], termination_condition=HandoffTermination(target="user")
| TextMentionTermination("TERMINATE"))
await team.run(task="上周打车超标还能报吗,能就帮我提单")
# 团队停在交给 user 的那一步:把结论给员工看,拿到回复后续跑
await team.run(task=HandoffMessage(source="user", target="expense", content="确认提单"))
state = await team.save_state() # 存库,下次 load_state 接着跑
注意这里"确认后才建单"只写在 system_message 里,是提示词约束。create_ticket 在工具列表中,模型可以跳过交接直接调用。稳妥做法是把 create_ticket 从工具里拿掉,员工确认之后由代码调用。
常见问题
新项目还能用 AutoGen 吗? 不建议。microsoft/autogen 在 2026-10 声明归档,不再提供修复,迁移方向是 MAF。
AG2 和 AutoGen 是什么关系? AG2 是原作者团队 2024 年从 AutoGen 0.2 分出去的社区分叉,和微软无关。它的 v1 把接口换成了 import ag2 和 Network,经典的 import autogen 写法搬到了维护模式的 AG2 Classic。
UserProxyAgent 让整个团队卡住。 它会阻塞运行,官方建议只用于很短的交互。更好的做法是用终止条件停下,拿到人的回复后再 run 一次,就像上面的例子。
SelectorGroupChat 调用次数比预想多。 每轮都要先调一次模型挑人,被挑中的人再调一次模型发言。
Microsoft Agent Framework
MAF 是什么
MAF 是微软把 AutoGen 和 Semantic Kernel 合并后的框架,2026-04 发布 1.0,有 Python 和 .NET 两个版本。它分两层:
Agent:模型加工具的循环,和前几站的 Agent 一样;Workflow:由执行器(executor)组成的图,数据沿边流动,在边界写检查点。
常见的多 Agent 拓扑(顺序、并发、交接、群聊)都做成了建在 Workflow 上的构建器,几行代码就能搭起来。官方概览里有一句建议:"If you can write a function to handle the task, do that instead of using an AI agent."(能写成函数的,就别用 Agent。)
安装
pip install agent-framework
export OPENAI_API_KEY="sk-..."
第一个 Agent
hello_maf.py 文件代码:
import asyncio
from agent_framework import Agent
from agent_framework.openai import OpenAIChatClient
agent = Agent(client=OpenAIChatClient(), name="assistant",
instructions="你是公司的报销助手,回答要简短。")
async def main():
result = await agent.run("报销一般需要哪些材料?")
print(result.text)
asyncio.run(main())
输出结果类似:
一般需要发票、行程或用途说明,以及审批人签字。
基本概念
会话。 多轮对话用 session = agent.create_session(),每次 agent.run(..., session=session)。会话可以序列化保存。
工具和审批。 用 @tool 定义工具;@tool(approval_mode="always_require") 让每次调用先停下等批准。
Workflow。 执行器用 @handler 处理消息,用 ctx.send_message 发给下游:
from agent_framework import Executor, WorkflowBuilder, WorkflowContext, handler
class Upper(Executor):
@handler
async def run(self, text: str, ctx: WorkflowContext[str]) -> None:
await ctx.send_message(text.upper())
class Show(Executor):
@handler
async def run(self, text: str, ctx: WorkflowContext) -> None:
await ctx.yield_output(text)
upper, show = Upper(id="upper"), Show(id="show")
workflow = WorkflowBuilder(start_executor=upper).add_edge(upper, show).build()
检查点。 给 Workflow 配 checkpoint_storage(内存、文件或 Cosmos),运行时在每一步的边界保存,workflow.run(checkpoint_id=...) 恢复。工作流内部要人工输入时,用 ctx.request_info(...) 加 @response_handler。
编排构建器。 在 agent_framework.orchestrations 里:
| 构建器 | 拓扑 |
|---|---|
SequentialBuilder |
几个 Agent 依次处理 |
ConcurrentBuilder |
几个 Agent 同时处理,汇总结果 |
HandoffBuilder |
Agent 之间交接 |
GroupChatBuilder |
群聊,由编排 Agent 或选择函数决定谁发言 |
| Magentic | 编排者制定计划、分派、跟踪 |
报销例子:工具级审批
from agent_framework import Agent, Message, tool
from agent_framework.openai import OpenAIChatClient
@tool
def search_policy(query: str) -> str:
"""查报销制度。"""
return "4.2:市内打车单次标准 80 元"
@tool
def get_invoice(invoice_id: str) -> str:
"""查发票。"""
return '{"id": "INV-102", "amount": 118.5, "standard": 80}'
@tool(approval_mode="always_require")
def create_ticket(invoice_id: str, reason: str) -> str:
"""提交报销单,会真正建单。"""
return "R-55821"
agent = Agent(client=OpenAIChatClient(), name="expense",
instructions="先查制度和发票再下结论,能报就调用 create_ticket。",
tools=[search_policy, get_invoice, create_ticket])
session = agent.create_session()
result = await agent.run("上周打车超标还能报吗,能就帮我提单", session=session)
while result.user_input_requests:
req = result.user_input_requests[0]
ok = ask_employee(req.function_call.name, req.function_call.arguments) # 展示真实参数
result = await agent.run(
Message(role="user", contents=[req.to_function_approval_response(ok)]),
session=session)
print(result.text)
和 AutoGen 那版的区别是确认挂在工具上,不靠提示词:模型想建单,框架先停下来交出调用参数,员工确认了才执行。
如果一定要写成三角色版本,就是 SequentialBuilder(participants=[policy_agent, invoice_agent, supervisor]).build(),create_ticket 只给主管,审批照旧。
常见问题
交接后,接手的 Agent 看不到上一个 Agent 的工具结果。 handoff 不共享会话,转发前会过滤掉函数调用、函数结果和审批内容,只留文字。要传数据,让上一个 Agent 输出结构化摘要,或者改成把 Agent 当工具调用。
Sequential 编排的 token 用量很大。 默认把上一个 Agent 的完整对话传下去。GroupChat 也是所有人看全量历史。
Sequential 不能退回上一个 Agent。 两个 Agent 之间不能插自由反馈,也不能回退,需要的话换 handoff 或自定义 Workflow。
handoff 自主模式一直在跑。 自主模式是实验特性,.NET 版默认最多自主续跑 50 轮。要设终止条件。
Magentic 适合什么场景? 官方说它在原始 Magentic-One 设计之外的表现没有测试过,用之前自己验证。
拓扑在三家 API 里的写法
| 拓扑 | CrewAI | AutoGen | MAF |
|---|---|---|---|
| 顺序流水线 | Process.sequential |
RoundRobinGroupChat 或 GraphFlow 链 |
SequentialBuilder |
| 主管或层级 | Process.hierarchical 加经理 |
SelectorGroupChat、MagenticOneGroupChat |
GroupChatBuilder(orchestrator_agent=...)、Magentic、Agent 当工具 |
| 群聊 | 没有独立类型,靠 allow_delegation |
SelectorGroupChat、RoundRobinGroupChat |
GroupChatBuilder(selection_func=...) |
| 交接 | 没有对应 API,可用 Flow 的 @router 自己写 |
Swarm 加 HandoffMessage |
HandoffBuilder |
| 并发 | 多个 @start() 会并行执行 |
GraphFlow 扇出 |
ConcurrentBuilder |
| 图 | Flow 的 @start、@listen、@router |
GraphFlow |
WorkflowBuilder |
只有 MAF 把这些拓扑都建在同一个底座上,检查点和审批对所有拓扑一致。CrewAI 的多 Agent 有两种含义:Crew 内部的角色协作靠模型自由发挥,Flow 把多个 Crew 串起来是确定的流程。
报销要不要拆成三个 Agent
三角色版本跑一遍大致是这样:制度专员调 search_policy,写一段"超标部分需部门负责人审批"的摘要;发票专员调 get_invoice,写一段"INV-102 金额 118.5 元,标准 80 元,超 38.5 元";审核主管读这两段文字,下结论,请员工确认,再建单。
问题有三个:
- 专员这层几乎没有价值。 两个专员的工作各是一次工具调用。
- 主管拿到的是转述。 CrewAI 里是上游任务的输出文字,MAF 的 handoff 里工具结果被过滤。条款原文、发票字段可能在转述里漏掉或被改写。
- 模型调用变多。 单 Agent 大约两轮工具调用、一轮结论,确认后再一轮建单,共 3 到 4 次。三角色顺序流程每个专员至少一轮工具、一轮结论,主管再判断,共 6 到 9 次;层级流程还要加上经理规划、分派、验收的轮次。(都是按流程数出来的示意次数。)
下面这张图把两种做法的调用过程画在一起,点开可以看每一次调用:
- 单 Agent:一个模型自己调两个工具,直接读原始返回
- 三角色:两个专员各写一段摘要,主管读摘要下结论
- 结论一样,三角色的模型调用大约多一倍(示意)
单 Agent的细节:
- 模型决定先查制度,拿到的是条款原文
- 再查发票,金额和标准是工具返回的原始字段
- 同一个模型读着原文下结论,中间没有转述
- 员工确认后再调一次模型发起建单,共 3 到 4 次(示意)
三角色 crew的细节:
- 制度专员调 search_policy,再花一次调用写摘要
- 发票专员调 get_invoice,同样写一段摘要
- 主管读两段摘要下结论,每次调用都带着自己的角色提示
- 条款原文和发票字段不在主管的上下文里,可能漏掉或被改写
- 员工确认后建单,模型调用共 6 到 9 次(示意)
两家官方文档也是这么判断的。CrewAI 的用例评估把步骤少、精度要求高的场景归到"直接调用模型的 Flow,或者带结构化输出的简单 Crew"。MAF 概览说能写成函数的就别用 Agent。
拆分值得做的情形大致有三种:
- 子任务彼此独立、能并行,而且每个都要多轮探索,比如同时比对十家供应商;
- 单个 Agent 的工具集或上下文装不下,需要像 计划、子代理与上下文预算 的子代理那样隔离上下文;
- 权限必须物理隔离,比如只有某个进程能拿到建单凭证。
报销三条都不满足。"只有主管能建单"这类要求,用工具级审批或者把建单放进确定的流程步骤就能做到。
多 Agent 的常见问题:
| 问题 | 在框架里的表现 |
|---|---|
| 角色提示重复 | 每个 Agent 都带一份 role、goal、backstory 拼成的系统提示,经理再带一份;角色写得含糊时会互相反复提问 |
| Agent 之间丢上下文 | MAF handoff 过滤工具调用和结果;CrewAI 下游只拿到任务的输出文字 |
| 成本放大 | Sequential 默认传完整对话;GroupChat 全员看全量历史;SelectorGroupChat 每轮先用模型选人;委派可能循环 |
| 调试困难 | 委派失败的表现是经理自己把活干了,日志里没有显式报错 |
更一般的讨论(多 Agent 的 token 倍数、反对意见、五类失败)见 Agent 架构图解:从工作流到事件驱动工单。
版本说明
本文按 2026-11 初的文档写,查阅时 CrewAI 1.15,MAF Python 1.24。对照旧资料时注意:
- AutoGen 0.4(2025-01)是重写,和 0.2 不兼容;microsoft/autogen 最后一版是 0.7.5,2026-10 声明归档。
- MAF 2025-10 公开预览,2026-04 发布 1.0,官方定位是 Semantic Kernel 和 AutoGen 的接替者。
- CrewAI 的
@human_feedback从 1.8.0 开始有;Flow 续跑的旧写法inputs={"id": ...}已标弃用,改用kickoff(restore_from_state_id=...)。
和手写循环的对照
多 Agent 团队:持久队友、信箱与原子认领 用几百行代码手写了常驻队友:WORK、IDLE 两种状态的线程,.mailboxes/<name>.jsonl 文件邮箱,在锁内原子认领任务,关机和计划审批走带 request_id 的协议。计划、子代理与上下文预算 的子代理给每个子任务一份全新的 messages,只把最后一段文字交回,并且拿掉 task 工具防止套娃。拿这两站对照三个框架:
| 机制 | 手写 harness | CrewAI | AutoGen | MAF |
|---|---|---|---|---|
| 上下文隔离 | 子代理用全新 messages,只回最后文字 | 每个 Agent 各自对话,Task 输出作为下游 context | Swarm、群聊共享消息 | handoff 只转发文字;也可以把 Agent 当工具 |
| 常驻队友 | 线程常驻,空闲时轮询 | 每次 kickoff 跑完结束 | 团队可多次 run,状态 save/load | Workflow 实例加检查点 |
| 通信 | 文件邮箱 | 委派工具同步调用 | 消息投递或共享历史 | 边上的类型化消息 |
| 任务认领 | 锁内原子 claim | 经理分派或预先指定 agent= |
模型或轮转选人 | 构建器规则或选择函数 |
| 停止 | 去掉 task 工具,轮数上限 |
allow_delegation=False,max_iter |
终止条件 | 终止条件,轮次上限 |
| 审批 | 循环外的权限检查 | PRE_TOOL_CALL 钩子或 @human_feedback |
交接给 user | approval_mode 或 request_info |
框架替你做了拓扑的样板(谁说下一句、消息怎么转发、什么时候停)、检查点(CrewAI、MAF)和追踪接入。没替你做的有三件:
- 决定每个 Agent 看到什么。三家默认值各不相同,要自己读文档设置,这就是 计划、子代理与上下文预算 讲的预算问题。
- 副作用幂等。从检查点恢复后哪些步骤会重放,要自己守住,见 可靠执行:状态、幂等与恢复。
- 按 token 计的成本上限。三家只有轮次或迭代上限。
固定流水线可以复现,团队讨论不能复现,成本也难预测,这是 多 Agent 团队:持久队友、信箱与原子认领 里讨论过的取舍。在框架里,它对应 Flow 或 Workflow 与 Crew 或 GroupChat 的分工。固定编排与目标闸门:Workflow 运行时和 Goal Loop 的固定编排,就是 Flow 和 Workflow 的手写版本。
自测
CrewAI 里 Agent、Task、Crew 分别是什么?
参考:Agent 是成员,由 role、goal、backstory 和工具组成;Task 是一项任务,写清要做什么、要什么结果、由谁做;Crew 把成员和任务组在一起,按 Process 指定的顺序或层级方式执行。
AutoGen 的 RoundRobinGroupChat 和 SelectorGroupChat 有什么区别?
参考:前者按成员顺序轮流发言;后者每轮先让模型根据对话历史和成员描述挑下一位发言者,所以每轮多一次模型调用。
CrewAI 的 Task 级 human_input=True 能不能用来实现建单前的员工确认?
参考:不能。它只在 Agent 给出最终答案之前让人审阅,不拦截某一次工具调用。如果 create_ticket 在 Agent 的工具里,模型可能在给出最终答案之前就已经调过它了。正确做法是把建单放进 Flow 里 @human_feedback 之后的普通步骤,或者用 PRE_TOOL_CALL 钩子拦住 create_ticket。
在 MAF 的 HandoffBuilder 里,发票 Agent 调 get_invoice 拿到 118.5 和 80,然后交给主管。主管能看到 get_invoice 的原始返回吗?
参考:看不到。转发时函数调用、函数结果都被过滤,主管看到的是发票 Agent 用文字写出的金额,如果它没写标准额,主管就拿不到。解决办法:让发票 Agent 输出结构化摘要,或者改成把 Agent 当工具调用,或者用 Workflow 显式传数据。
有个新项目想用 AutoGen 的 SelectorGroupChat,你会怎么建议?
参考:microsoft/autogen 已声明归档,不再提供修复,不建议用于生产。MAF 里对应的是 GroupChatBuilder,传 orchestrator_agent 或 selection_func。
什么情况下值得把一个 Agent 拆成多个?
参考:子任务独立、可以并行,而且每个都要多轮探索;单个上下文装不下工具集或中间结果,需要隔离;权限必须按进程或凭证物理隔离。职责听起来不同本身不算理由,一次工具调用就能完成的职责做成工具就够了。
参考资料
以下链接均查阅于 2026-11。
- CrewAI 文档:Agents
- CrewAI 文档:Tasks
- CrewAI 文档:Processes
- CrewAI 文档:Flows
- CrewAI 文档:Collaboration
- CrewAI 文档:Human Feedback in Flows
- CrewAI 文档:Tool Call Hooks
- CrewAI 文档:Checkpointing
- CrewAI 文档:Production Architecture
- CrewAI 文档:Evaluating Use Cases
- microsoft/autogen 仓库 README
- AutoGen reimagined: Launching AutoGen 0.4
- AutoGen 文档:Selector Group Chat
- AutoGen 文档:Swarm
- AutoGen 文档:Human-in-the-Loop
- AG2 仓库 README
- Microsoft Agent Framework Version 1.0
- MAF 文档:概览
- MAF 文档:Tool Approval
- MAF 文档:Checkpoints
- MAF 文档:编排总览
- MAF 文档:Handoff
- MAF 文档:Observability
- MAF 文档:从 AutoGen 迁移
- Why Do Multi-Agent LLM Systems Fail?(arXiv 2503.13657)
连接
- 智能体编排框架横评:同一个报销 Agent 换六种写法:系列总览,本站是第 4 站。
- 智能体编排框架横评(3):厂商 Agent SDK:上一站,厂商 SDK 的交接和 Agent 当工具,可以和这里的 HandoffBuilder、Swarm 对照。
- 智能体编排框架横评(5):轻量与类型化框架:下一站,回到单 Agent 加类型化工具的轻量路线。
- 智能体编排框架横评(2):LangGraph:同样是图加检查点,MAF 的 Workflow 可以和它逐项对比。
- Agent 架构图解:从工作流到事件驱动工单:多 Agent 拓扑和五类失败的概念讲解,本站只讲对应的 API。
- 主线:一个报销请求走完整个 Agent 系统:报销场景的出处,本站用它判断该不该拆成多个 Agent。
- 人在回路:三家的确认机制分别挂在工具、流程步骤和提示词上,可靠程度不同。
- 多 Agent 团队:持久队友、信箱与原子认领:手写常驻队友、邮箱和原子认领,用来看清框架省掉了什么。
- 计划、子代理与上下文预算:子代理的上下文隔离,对应框架里每个 Agent 能看到什么的默认值。
- 固定编排与目标闸门:Workflow 运行时和 Goal Loop:固定编排的手写版,对应 Flow 与 Workflow。
- 可靠执行:状态、幂等与恢复:检查点恢复后的重放与副作用幂等。
- 可观测性:追踪一条任务的代价:多 Agent 排错依赖追踪。