谷歌云面试官问：多Agent拆完反而更乱？

这课进入更高层的问题多个 Agent 拆出来之后怎么组织协作四种方式各有适用场景用错一个就是调试地狱。一、面试现场面试题“你的代码修复 Agent 跑到 80k tokens 就开始乱。拆 subagent 还是改 handoff判断标准是什么”谷歌云 AI 平台组三面。候选人做过一个代码修复系统——单 Agent 拥有文件读写、运行测试等工具处理简单 bug 没问题一旦涉及 8 个以上文件context 膨胀到 80k tokens模型开始忘记最初的 bug 描述重复修改已经改过的文件。面试官不问要不要拆L02 已经解决了问的是拆了之后四种组织方式怎么选。这不是某一次面试的原题而是从真实面经和岗位 JD 中提炼的高频判断题。二、大多数人怎么答的“让多个 Agent 互相调用就行。” 或者“上 A2A 协议用最新的标准。” 两种回答都暴露了同一个问题——没搞清楚四种组织方式各自解决什么问题。让 Agent 互相调用是最笼统的说法等于没说A2A 在绝大多数内部系统里根本用不着。典型误判“多个 Agent 协作就是让它们互相调用 / 就得上 A2A。”——没区分四种组织方式的适用边界。三、正确判断框架四种组织方式各有各的适用场景。选对了省事选错了调试成本翻倍。Subagentcontext 膨胀时的降压阀Main agent 把封闭子任务委托出去subagent 只看自己需要的信息做完返回摘要。适用main context 太大需要隔离。关键判断subagent 做完后 main 还需要用结果。违反后果如果 main 拿到摘要后又全量展开看——隔离白做反而多了一层。Handoff阶段性交接不回头前一个 agent 做完直接退出把控制权传给下一个。适用职责明确、前后无交叠的流水线planner → coder → reviewer。关键判断交接后不需要回到上一个 agent。违反后果交接没写清当前状态 未完成项接手 agent 从头猜。Orchestrator-Workers中心分发并行执行中心 agent 拆任务、分给 worker、汇总结果worker 之间不互相通信。适用任务可拆成并行独立子任务。关键判断子任务之间没有依赖。违反后果orchestrator 给 worker 的输入没裁剪worker 的 context 和 main 一样膨胀。A2A跨组织协作最后才考虑截至 2026 年 4 月A2A 仍是早期草案。适用且仅适用于跨组织、跨平台、长生命周期异步任务。同进程直接函数调用、同团队 REST API、同集群 handoff 都比 A2A 简单得多。违反后果单机系统硬包 A2A协议开销没收益部署和调试反而更难。四、面试官追问链追问 1“Context 已经 60k tokenssubagent 还是 handoff”看后续是否还需要用 subagent 产出的结果。如果 main 还要基于子任务结果做下一步决策——用 subagent它做完回来汇报。如果是纯阶段性交接planner 做完 coder 接手planner 不再参与——用 handoff省掉回传开销。追问 2“三个 Agent 都是 Python跑在同一个 K8s 集群你还会上 A2A 吗”不用。同语言、同集群、同团队控制——直接 handoff 或 orchestrator 更简单。A2A 的协议开销Agent Card、Task 状态机、JSON-RPC在这个场景下没有收益。只有协作跨组织或跨平台时A2A 的标准化才真正显出价值。加分题“Orchestrator-Workers 和’中心 agent 一堆 tool’的区别”方向worker 自身是 agent能做多轮决策和推理tool 是一次性函数调用输入输出确定。当子任务需要多步推理时用 worker当子任务是确定性操作时用 tool。五、落地案例实战拆解代码修复系统从单 Agent 到 Orchestrator-Workers 的演进同一个业务场景里四种组织方式的对比。**v1 单 Agent。**一个 coder agent 拥有 file_read / file_write / run_test 工具。简单 bug 没问题涉及多文件时 context 跑到 80k 就开始乱——重复修改已改过的文件、忘记最初的 bug 描述。**v2 引入 Subagent。**Main coder 把修一个文件丢给 file-subagentsubagent 只看 bug 描述 该文件 相关依赖返回 diff。Main 只保留 diffs 和 test resultscontext 大幅缩减。**v3 拆 Handoff。**任务变复杂后拆成 planner → coder → reviewer。Planner 做完退出不再回来coder 专注实现reviewer 专注检查。每个角色只看自己需要的上下文。**v4 Orchestrator-Workers。**一次要同时修 3 个独立文件时orchestrator 同时派 3 个 coder worker 并行各自只看自己的文件和 bug 描述汇总后给 reviewer。六、上线坑点坑 1Subagent 隔离失败Subagent 做完main 还要全量看一遍——隔离白做反而多了一层延迟。坑 2Handoff 交接不清交接没写清当前状态 未完成项 下一步接手 agent 从头猜效率比单 agent 还差。坑 3把单机系统硬包 A2A协议开销没收益部署和调试反而更难。内部系统直连更简单。七、本课总结与面试锦囊一句话结论多 Agent 不是拆了就赢。Subagent 降压、Handoff 交接、Orchestrator 并行、A2A 跨组织——四种方式各有适用场景用错一个就是调试地狱。面试锦囊先说四种组织方式解决不同问题——subagent 降 context 压、handoff 做阶段交接、orchestrator 做并行分发、A2A 做跨组织协作。再说选择标准看三个维度——需不需要结果回传、子任务能不能并行、是不是跨组织。最后补绝大多数内部系统不需要 A2A。同进程直连、同集群 handoff 永远比协议标准化更简单。判断 Checklist☐ Context 膨胀需降压 需要结果回传 → Subagent☐ 阶段性职责清晰 不需回传 → Handoff☐ 并行独立子任务 → Orchestrator-Workers☐ 跨组织跨平台 长生命周期异步 → A2A别再踩的坑• Subagent 做完 main 全量看——隔离白做• Handoff 交接不写状态——接手 agent 从头猜• 内部系统硬包 A2A——协议开销没收益学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】