必须从角色、生命周期、通信方式和责任边界四维度区分Agent类型：Subagent由主Agent担责、快照传参、瞬时存在；Handoff移交责任、上下文移交、存活至对话结束；Agent Teams共担责任、共享状态、常驻且可直连通信。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
要区分 Agent Space 中不同类型的 Agent，必须回到它们在系统中承担的角色、生命周期、通信方式和责任边界这四个不可绕开的维度。直接套用“单 Agent”“多 Agent”这种宽泛说法，会掩盖实际部署中权限失控、状态丢失、协作断裂等真实问题。
看谁对最终结果负责
Subagent 由主 Agent 全权担责，它只是临时分出去的一个推理分支，任务结束即销毁上下文，不保留记忆也不参与后续决策。你让它查天气，它返回结果后就没了，连自己刚才用了哪个 API 都不记得。
Handoff 模式下，责任是移交的。前一个 Agent 把对话控制权完整交出，后续所有输出、工具调用、错误重试都由接手方负责。比如客服 Agent 把订单问题 handoff 给售后 Agent，那售后 Agent 就得自己判断要不要查物流、要不要补偿、要不要升级人工——主 Agent 不再插手。
【关键区别】Agent Teams 的责任是共担且持续的。Team Lead 不代答、不兜底，只协调；Teammates 各自维持独立上下文，能主动发消息、共享内存、互相打断。一个 teammate 卡住时，另一个可以直接调用它的调试接口或覆盖其变量，而不是等超时失败后由外部重试。
看信息怎么在 Agent 之间流动
方法一：Subagent 用“快照式传参”。主 Agent 把当前全部上下文、用户原始输入、任务拆解指令打包成 prompt 片段，丢给子代理。子代理执行完，只回传结构化结果（如 JSON），不带任何中间思考链或错误日志。这就像把一张纸条塞进信封，对方看完写个结论再还回来。
方法二：Handoff 走“上下文移交协议”。移交时不仅传目标指令，还要同步当前 session ID、用户身份凭证、已调用工具列表、最近三条 message history。接收方拿到的是可延续的对话流，不是孤立任务包。
方法三：Agent Teams 依赖共享状态层。它们共用一个 Redis 实例或内存数据库，每个 teammate 可以读写 /status/checkout_timeout、/memory/order_12345、/lock/invoice_generation 等路径。信息不是“传”，而是“露”——谁需要谁去取，改了别人立刻可见。
看它们能不能长期存在并自主交互
第一步：确认存活时间。Subagent 生命周期 ≤ 单次 LLM 调用耗时，通常几百毫秒；Handoff 接收方至少存活到本轮对话结束（可能数分钟）；Agent Teams 的 teammate 实例默认常驻，重启需手动触发或因资源超限被驱逐。
第二步：测试能否跨 agent 发起调用。在 Subagent 场景里，子代理无法主动调用另一个子代理，只能回传结果给主节点；Handoff 接收方可以调用工具，但不能调用其他 Handoff 实例；只有 Agent Teams 支持 teammateA → teammateB 直接发送 RPC 请求，且 B 可以拒绝、限流、要求重认证。
第三步：检查是否支持异步事件响应。Agent Teams 能订阅 /event/user_cancelled 或 /event/payment_confirmed 这类主题，收到后自动触发动作；Subagent 和 Handoff 均无事件监听能力，纯靠轮询或阻塞等待。
