Appearance
Q117 · AI Agent 中 Agents、Teams、Workflows 的区别是什么？
用户问售后：“订单 A-17 的退款还没到账，能不能加急？请给我一个准确答复。”应用需要查订单状态、核对加急规则、写回复；如果加急会改变退款处理优先级，还要有人或有权限的系统确认。可以让一个 Agent 处理所有信息，也可以让多个专门的 Agent 分工，或者把必经的核验、分支和审批写成一条流程。这三种安排解决的是谁来决定下一步、谁负责哪部分、哪些步骤不能跳过。
在 Agno 的当前文档中，Agent、Team、Workflow 是明确的产品抽象：Agent 组装模型上下文、处理模型响应并执行工具；Team 组织多个 Agent 协作；Workflow 用定义好的控制流编排 Agent、Team 和函数。这里的英语复数 Agents、Teams、Workflows 可以理解为对三类组件的称呼。放到更广的行业语境，名称没有跨框架统一 API；例如 Anthropic 的工程文章主要区分“预设代码路径的 workflow”和“模型动态主导步骤的 agent”，并没有要求所有多 Agent 系统都叫 Team。以下先讲通用控制关系，再用 Agno 官方定义说明一种具体实现。Agno Agents · Agno Teams · Agno Workflows · Anthropic：Building effective agents
术语先对上业务对象
| 术语 | 这里是什么意思 | A-17 退款例子 |
|---|---|---|
| Agent | 能根据任务使用模型与可用工具、产生结果的执行单元；具体自主程度取决于应用配置 | 一个售后 Agent 决定先查订单还是先看规则 |
| 模型 | 根据输入生成下一条回复或工具调用建议的组件 | 根据已查到的订单信息起草解释 |
| 工具 | 应用提供的外部能力，调用后返回真实资料或产生受控动作 | 只读查订单、查政策；加急提交属于有副作用动作 |
| Team | 多个 Agent 的协作单元；在 Agno 中可有协调、路由、广播、任务列表等模式 | 订单专员和政策专员分别取证，协调者整合 |
| 成员 / 协调者 | Team 内负责子任务的 Agent，以及分派与汇总工作的组件 | 订单专员查状态；政策专员核规则；协调者汇总 |
| Workflow | 开发者明确规定步骤、条件、循环和执行者的控制流程 | 先验身份、查状态、核规则，再决定是否走人工确认 |
| 步骤 / 分支 | 流程中的单个动作；分支按条件选下一步 | “订单不存在”转人工；“符合加急条件”送审批 |
| 控制权 | 决定下一步执行什么、何时停止的权力 | 由 Agent 选择工具，或由 Workflow 的条件规定先后 |
| 人工确认 | 高影响动作前由有权限的人审阅或批准 | 真正提交加急申请前确认订单和规则 |
下文 A-17、订单状态和加急规则都是教学假设：假设 A-17 属于当前已认证用户，退款系统显示“处理中”，政策说“加急申请须由售后主管确认”，并未保证批准。文章比较的是架构选择，不代表真实平台的退款政策。
只用一个 Agent：让一个执行单元处理任务
假设售后 Agent 拿到用户问题，并被允许使用两个只读工具：订单查询返回 A-17 的实时状态，政策查询返回加急条件。它可以决定先查订单，再看规则，也可能先读规则再查订单。得到“处理中”和“须主管确认”后，它回答：“退款仍在处理中；可以提交加急申请供主管确认，目前不能承诺加急成功。”这就是一个 Agent 完成任务的正常路径。若应用还开放了“提交加急”工具，工具本身须校验用户身份、订单状态和审批权限；不能只凭模型一句“我觉得符合”就执行。
Agno 文档把 Agent 描述为建立模型上下文、处理响应、执行请求的工具并返回运行结果；工具是可选的，也可按需加记忆、知识和人工介入。调用 Agent 不意味着它必然能自动读所有系统或无限制规划；能做什么由工具、权限、提示和外部控制器共同决定。Agno：What are Agents?
单 Agent 的好处是结构简单：少了一层成员分派和跨角色结果合并，通常更容易观察、成本也更低。问题是当它同时要理解物流、财务、政策和合规时，工具菜单和上下文可能变大，错误定位困难。任务复杂才需要拆；如果只是查“退款现在什么状态”，一个受控 Agent，甚至直接按规则调用订单查询接口，就已经够用。
用 Team：多名专员协作，仍要有协调规则
同一个 A-17 问题若涉及不同知识域，可以让订单 Agent 只读订单与支付状态，让政策 Agent 只读加急条款，由 Team 协调者拆任务并汇总：订单成员说“当前处理中、尚未确认到账”，政策成员说“加急申请需主管确认”；协调者把两份结果合成给用户的答复。这样做的价值不是“Agent 数量更多”，而是每个成员有清晰职责、受限工具和可分别检查的产出。
以 Agno 为例，官方 Team 文档说明默认的 coordinate 模式由协调者按成员职责分派并汇总，也提供 route（路由给某一成员）、broadcast（把任务发给多名成员）、tasks（执行任务列表）等模式。因此 Team 也不等于永远自由讨论或永远并行；具体如何分派，要看配置的模式和任务。Agno 同时提醒，协调者与成员分别调用模型，会增加时延、token 使用和协调状态；任务只涉及单一专长时，单 Agent 更合适。Agno：What are Teams?
Team 的正常结果应保留成员证据。例如订单成员的结论来自哪个订单查询、查询时间是什么；政策成员用的是哪个条款版本。协调者不能把“订单处理中”和“允许提出申请”合成“系统已批准加急”。若两个成员意见冲突，先检查事实源和适用范围，必要时转人工；让第三个模型简单投票，并不能替代业务系统的状态与主管权限。
用 Workflow：把必须走的步骤写成控制流
若公司规定每一笔加急申请都必须先验证订单归属，再查当前状态，核对政策，最后由主管确认，那么这些必经条件应由 Workflow 或应用代码控制。一个可检查的流程可以这样走：
- 验证请求：系统确认来访者对 A-17 有查看与申请权限；不通过就停止，不向 Agent 泄露订单内容。
- 查实时状态：订单查询返回“处理中”；若订单不存在或接口超时，进入错误/人工路径，而不是继续假设状态。
- 核对规则：读取适用于 A-17 的政策版本。若规则允许提出申请，生成一份供主管查看的草稿；若不适用，给出有条款依据的解释。
- 人工门槛：真正提交或调整处理优先级前让有权限的主管确认。未确认、拒绝或超时都不能写成“已加急”。
- 对外回复：根据已完成的工具结果和审批结果，分别说明“申请已提交”“未获批准”或“仍待确认”，不把草稿当业务结果。
这条 Workflow 可以让一个 Agent 写解释，也可以让 Team 在“核对规则”这一步分别检查订单和政策；Workflow 是控制这些执行单元何时运行、输入输出和分支的外层安排。它并不排斥 Agent。Agno 官方文档明确说 Workflow 可以将 Agent、Team、函数和嵌套 Workflow 作为步骤，并可顺序、并行、条件分支和循环执行；所以 Workflow 也不是只能从左到右机械跑三步。Agno：What are Workflows? · Agno：Workflow patterns
Workflow 的优势是关键顺序、重试、停止和审批条件清楚，适合要审计的重复任务。代价是开发者要提前设计足够的分支；用户问题或业务规则变化时，流程需更新。即使步骤固定，某一步里的 Agent 生成文字仍可能变化，不能把“流程可重复”误解成“所有输出完全相同”。Agno 文档也明确区分可重复的控制流与可能变化的 Agent、Team 输出。Agno：What are Workflows?
放在同一张比较表里
| 比较维度 | 单个 Agent | Team | Workflow |
|---|---|---|---|
| 主要解决的问题 | 一个执行单元怎样理解任务并调用能力 | 多个专门执行单元怎样分工与汇总 | 哪些步骤、条件、审批必须发生，以及顺序如何 |
| 下一步由谁主导 | 任务内常由模型依据结果选择；外层仍可限制 | 取决于协调或路由模式，成员可各自选择工具 | 开发者定义的流程与条件主导；步骤内部可由 Agent 自主选择 |
| 执行者数量 | 一个 Agent | 多个 Agent 或嵌套 Team | 可含函数、一个 Agent、多个 Agent、Team，甚至子流程 |
| 可预测性 | 路径随模型判断变化，需工具与轮数上限 | 分派和成员输出也可能变化，协调更复杂 | 必经门槛与分支较易审计，步骤输出仍可能变化 |
| 典型成本 | 通常最省协调成本 | 多名成员与协调者带来额外调用 | 取决于步骤数量及执行者；可增加控制开销 |
| A-17 中最合适的事 | 查询当前退款状态并作简单解释 | 订单、政策确实需要不同专长时并行取证 | 加急申请必须验身份、核状态、审规则、主管确认 |
表格里的“常由模型选择”不是 Agent 的绝对定义。有些产品把带模型的可调用单元都叫 Agent，即使它只能执行一段固定提示；有些实现让 Team 由程序而非模型路由。判断系统时，比类名更有用的是看任务拆分是谁决定、每个工具谁能用、关键门槛能否被跳过、失败后怎样停止。Anthropic 的工程文章提出一个有用的通用区分：workflow 由预定义代码路径编排，agent 让模型动态引导过程与工具使用；这与 Agno 的类名相近，但不要求所有框架的 Team 或 Workflow 拥有相同 API。Anthropic：Building effective agents
同一个失败，三种安排各怎么收住
假设订单查询突然超时。单 Agent 若反复调用同一个工具，可能陷入循环；要给查询次数和总时长上限，最后说明“暂时无法核实实时状态”。Team 中订单成员超时，政策成员即使查到“可申请加急”的条款，协调者仍缺订单事实，不能替订单成员补写“已符合条件”。Workflow 的状态检查步骤应走明确的错误分支，停止审批与提交，并记录哪个步骤失败。这种失败不是“模型再想一会儿”就能可靠解决的。
再看规则冲突：政策成员查到旧版条款“普通退款可加急”，新版正式规则写“须主管确认”。Team 应携带来源与版本让协调者核对，而不是按成员数量投票。Workflow 应指定读取当前批准版本，旧版结果进入复核。单 Agent 同样要有可信政策源，不能被一个旧网页中的“忽略审批”文本带偏。最终是否提交加急由受权的业务接口与审批决定，三个名词都不自动提供权限保障。
选择时先看任务的真实复杂度。若“查状态并解释”占绝大多数，优先用直接工具调用或单 Agent；如果确实有彼此独立的专业资料、不同工具权限，而且分工能提升正确性，再用 Team；如果有必经顺序、审核、失败分支，就用 Workflow。复杂场景经常组合成“Workflow 控门槛，某个步骤调用 Team，Team 的成员各是 Agent”。设计后用同一组正常、超时、冲突、无权限案例比较答案正确性、工具轨迹、完成时间和成本，再决定是否值得保留多层结构。Anthropic 官方也建议从能解决问题的简单方案开始，增加复杂度时衡量性能收益与时延、费用。Anthropic：Building effective agents
面试中可以这样说
我先区分通用概念和框架类名。以 Agno 为例，Agent 是一个使用模型和可选工具完成任务的执行单元；Team 让多个 Agent 按配置的协调、路由等方式协作；Workflow 把 Agent、Team 或函数放进明确的步骤、条件与循环里。比如处理 A-17 退款咨询，单 Agent 可以查状态和规则后解释；如果订单与政策需要不同专员，就用 Team 分工并核对来源；如果申请加急必须验身份、核状态、过主管审批，就让 Workflow 控制这些门槛，并在步骤里调用 Agent 或 Team。它们可以组合。选型看谁决定下一步、是否真有分工收益、是否有不可跳过的业务条件，以及超时、冲突和无权限时能否正确停下。多 Agent 和更多步骤通常增加成本，不会自动提高正确率。
若追问“Team 一定比单 Agent 聪明吗”，可以回答：不一定。它增加了专门工具和分工，也增加成员调用、协调和冲突处理；应通过同一批任务评测收益。若追问“Workflow 是固定链，不能分支吗”，可以回答：Agno 官方 Workflow 支持条件、路由、并行和循环；所谓“预设”是控制规则由开发者设计，具体走哪条分支可依据运行结果。若追问“Team 和 Workflow 如何结合”，可说让 Workflow 负责身份验证和审批门槛，Team 作为其中一个取证步骤。
资料来源
- Agno：What are Agents?：当前 Agent 抽象、工具与运行结果说明。
- Agno：What are Teams?：Team 的成员、协调模式、适用性与协调成本。
- Agno：What are Workflows?：Workflow 对 Agent、Team、函数的编排及控制流边界。
- Agno：Workflow patterns：条件、并行、路由、循环等官方模式。
- Anthropic：Building effective agents：从通用架构角度区分预设工作流与模型动态主导的 Agent，并讨论复杂度取舍。