Multi-Agent
Multi-Agent 是典型的高级追问题。很多候选人会把它讲成“多开几个模型同时跑”，但真正的重点是边界、协议和收益是否成立，也就是你能不能先证明为什么要拆，再说明拆完以后怎么收敛。
这一页建议始终带着“复杂度是否值得”这条线来读。先用短答版记住必要性判断，再用深答版补角色边界、任务契约、冲突仲裁和故障隔离，这样你回答 Multi-Agent 时就不会只讲架构图，而是能讲清楚为什么它不是默认更高级。
高频题
1. 什么时候真的需要多 Agent？
题目：为什么不能把所有能力都塞进一个 Agent？
面试官想听什么：你是否有“先证明必要性，再增加复杂度”的工程判断。
短答版：如果任务存在明显的职责分离、上下文隔离需求或并行子任务收益，多 Agent 才值得考虑。否则单 Agent 加工具通常更简单，是否上多 Agent 看的是收益能否覆盖协作成本。
深答版：
展开深答版
这题的本质是看你会不会克制地使用多 Agent。单 Agent 的优势是简单、状态集中、调试路径短，所以除非任务真的存在明确的职责分离、上下文隔离需求或可证明的并行收益，否则没必要主动加第二个 Agent。
一个很实用的判断标准是：这个角色是不是一个独立决策体。如果它只是一个确定性执行步骤、输入输出也很清楚，那通常更适合做成工具；只有当它自己也需要局部目标、局部上下文和独立推理时，拆成子 Agent 才有意义。
工程上，多 Agent 的收益来自分工和隔离，代价来自通信、同步和定位复杂度。常见误区是把多 Agent 当成更高级的架构风格。你可以记成：
先证明拆分必要，再增加 Agent 数量。追问方向：什么情况下“多 Agent”其实只是过度设计？
2. 多 Agent 最核心的设计点是什么？
题目：如果你要设计一个多 Agent 系统，第一件事会先定什么？
面试官想听什么：你是否知道多 Agent 的重点在接口和边界，而不是角色命名和数量。
短答版：我会先定边界，不是先定数量。每个 Agent 负责什么、拥有什么上下文、能调用哪些工具、和谁通信，这些接口如果不稳定，多 Agent 很快就会失控。
深答版：
展开深答版
这题的核心判断是，多 Agent 系统首先是一个边界设计问题，而不是角色命名问题。你需要先回答每个 Agent 负责什么、看见什么、能调用什么、交付什么，如果这些边界不稳，角色再多也只是把复杂度打散，而不是被管理起来。
真正重要的不是“有几个 Agent”，而是每个 Agent 能不能在不读取全系统细节的前提下完成自己的职责。一个健康的角色边界应该同时限定职责、输入输出、可见上下文和通信协议，否则多个 Agent 很快就会互相越界、互相抢活。
工程上，边界越清晰，系统越容易替换、测试和扩展；边界过细，又会引入大量协调成本。你可以记成：
多 Agent 先定边界，再谈数量。追问方向：为什么角色说明写得很漂亮，但系统还是可能一团乱？
3. 子 Agent 和工具的边界怎么划？
题目：一个能力什么时候应该做成工具，什么时候应该做成子 Agent？
面试官想听什么：你是否能根据能力性质做拆分，而不是凭感觉把复杂模块一律做成子 Agent。
短答版：如果能力是确定性执行单元、输入输出清晰，通常更适合作为工具；如果它本身也需要多步推理、局部上下文和独立决策，再考虑做成子 Agent。关键是看它是不是独立决策体。
深答版：
展开深答版
这题本质上是在分“能力单元”和“决策单元”。工具更像被调用的能力接口，重点是输入清晰、输出稳定；子 Agent 更像局部自治体，它接到目标后，会自己决定内部要怎么拆步骤、怎么取信息、何时返回结果。
所以判断标准不该是“这段逻辑复杂不复杂”，而应该是“它需不需要独立决策”。像查数据库、解析文件、调用第三方 API，这些通常更适合做工具；而像 Research、Code Review、复杂 Summarize 这类本身就有多步推理和局部上下文的能力，才更接近子 Agent。
工程上，工具更简单、更可控，子 Agent 更灵活但也更重，因为你还要治理它的上下文、权限和交付协议。你可以记成：
工具是能力接口，子 Agent 是局部决策体。追问方向：Code Review、Research、Summarize 这几类能力分别更像工具还是子 Agent？
4. 多 Agent 为什么容易失控？
题目：系统里 Agent 一多，最常见的问题是什么？
面试官想听什么：你是否真正见过多 Agent 的代价，而不是只会画并行执行图。
短答版：最常见的问题是消息膨胀、责任不清、重复工作和上下文漂移。每多一层协作，都会增加通信协议、状态同步和错误定位成本。
深答版：
展开深答版
这题的核心判断是，多 Agent 的主要难点不是数量，而是协调。只要系统里出现多个自治体，你就必须处理它们怎么通信、怎样同步状态、冲突时谁拍板、失败时谁负责，这些问题本质上都比单 Agent 更复杂。
多 Agent 容易失控，不是因为每个角色本身写不清，而是因为系统级联动会把原来隐性的风险放大。上下文漂移、状态不一致、消息膨胀、重复工作、互相等待，这些都不是单个 Agent 的局部问题，而是协作面的问题。
工程上，多 Agent 可以换来并行和隔离，但前提是协议稳定、边界清楚、失败可收敛。你可以记成：
多 Agent 难的不是单体聪明，而是整体收敛。追问方向：如果两个 Agent 给出冲突结论，系统怎么收敛？
5. 多 Agent 的收益怎么验证？
题目：你怎么证明多 Agent 不是架构炫技？
面试官想听什么：你能不能用结果和指标来证明架构选择，而不是靠“感觉更高级”。
短答版：要看它是否在任务完成率、延迟、成本、可维护性中至少一项带来可度量改善。没有指标支撑的多 Agent，很容易只是把复杂度转嫁出去。
深答版：
展开深答版
这题本质是在看你是否会做收益验证。多 Agent 不是目的，它只有在并行化、上下文隔离、职责清晰或质量提升上带来明显可量化收益时，才值得引入额外复杂度。
真正该看的不是某个 demo 看起来更炫，而是稳定任务集上的完成率、延迟、成本、人工介入率和调试成本有没有净收益。有时候多 Agent 确实把正确率拉高了，但如果同时把调用成本和治理成本推太高，整体可能并不划算。
工程上，没有指标支撑的多 Agent，往往只是把复杂度转嫁出去。你可以记成：
多 Agent 要看净收益，不看架构气势。追问方向：如果多 Agent 让正确率提高了，但成本翻倍，你怎么判断是否值得？
扩展题
6. 两个 Agent 结论冲突时，谁来仲裁？
题目：如果 Planner 和 Reviewer，或者两个 specialist 给出相反结论，系统该听谁的？
面试官想听什么：你是否知道多 Agent 不能靠“大家聊一聊”自然收敛，必须提前定义冲突仲裁机制。
短答版：我不会把仲裁留给临场发挥，而是先定义谁有最终决策权、什么证据能推翻上一步，以及冲突升级路径。没有仲裁规则，多 Agent 很容易变成互相否定。
深答版：
展开深答版
这题的核心是收敛机制。多 Agent 一旦出现不同结论，问题就不再是“谁更聪明”，而是系统用什么规则把冲突收束。没有仲裁规则，多个 Agent 只会互相否定、不断消耗 token，却不一定更接近正确答案。
仲裁可以按角色权责来定，比如 Planner 决定路径，Reviewer 只对质量门槛有否决权；也可以按证据等级来定，谁拿到的外部证据更强，谁优先。关键是规则要事先定义，而不是等冲突发生时靠临场发挥。
工程上，中心化仲裁更稳、更好调试，但会增加一个控制点；完全去中心化看起来灵活，实际上很容易陷入来回讨论和消息膨胀。生产系统更需要有限轮次、明确升级和最终拍板人。
追问方向：如果仲裁 Agent 本身也可能判断错，怎么避免它变成新的单点风险？
7. 多个 Agent 之间为什么不能共享一份大状态？
题目：既然都在做同一个任务，为什么不让所有 Agent 直接读写同一份上下文和状态？
面试官想听什么：你是否理解共享状态虽然省事，但会快速放大污染、耦合和责任不清的问题。
短答版：共享状态不是越多越好。多 Agent 更适合共享最小必要事实，而不是共享完整思维过程和所有中间结论，否则一个角色的噪声会立刻污染全系统。
深答版：
展开深答版
这题本质上是在谈状态边界。单 Agent 里“都放在一个上下文里”还勉强可控，到了多 Agent，如果所有角色都能读写同一份大状态，系统很快会出现信息覆盖、局部猜测被误当事实、以及责任归属说不清的问题。
更稳的做法是只共享最小必要事实，比如任务 ID、阶段结果、显式决策和可验证证据；把局部推理、草稿、临时判断留在私有上下文里。这样每个 Agent 有自己可控的思考空间，但不会把噪声直接污染全局。
工程上，共享少一点会增加一些传递成本，但能明显降低污染和耦合风险。共享状态不是越多越好，很多时候只是让错误传播得更快。
追问方向：你会把哪些信息定义成公共状态，哪些强制留在私有上下文？
8. Agent 和 Agent 之间的任务契约怎么定？
题目：主 Agent 把任务交给子 Agent 时，最少要约定哪些东西？
面试官想听什么：你是否知道 Agent 间协作的关键不是一句自然语言命令，而是稳定的任务契约。
短答版：至少要定目标、输入、输出格式、权限边界、完成标准和失败语义。没有契约，子 Agent 很容易越界发挥，主 Agent 也很难接结果。
深答版：
展开深答版
这题的核心判断是，Agent 间交付本质上是接口设计。一个可用的任务契约至少要回答几件事：要做什么、能看什么、能用什么工具、必须返回什么、什么算完成、失败时怎么表达。
契约太模糊，子 Agent 的自由度会很大，但结果波动也会很大；契约太细，又会把它降级成机械工具调用。真正好的契约应该约束结果和边界，而不是规定每一步内部思路，这样既保留局部自治，也保证系统可组合。
工程上，任务契约是多 Agent 协作能不能稳定复用的关键。只写一句“帮我研究一下”，最后回来的结果通常既难验证，也难安全接进主流程。
追问方向：任务契约应该更偏自然语言，还是更偏结构化 schema？
9. 你怎么证明并行化真的值得做？
题目：多 Agent 经常强调并行执行，你怎么证明这不是看起来很快的错觉？
面试官想听什么：你是否会先证明任务独立性和端到端收益，而不是见到多个步骤就机械并行。
短答版：我会先证明子任务之间真的独立，再看端到端延迟、成功率和额外协调成本有没有净收益。不是把多个调用同时发出去，就等于系统更优。
深答版：
展开深答版
这题的本质是并行化证明。首先要证明依赖关系上确实可以并行，也就是各子任务之间没有顺序约束，不需要共享中间决策；其次要证明在系统指标上也值得并行，比如总耗时下降明显，而额外协调成本没有把收益吃掉。
如果多个 Agent 最后仍需要大量交叉对齐、互相修正，或者都在等同一个关键状态，那所谓并行往往只是把串行依赖藏起来。看上去同时开始，并不等于关键路径真的变短。
工程上，并行适合独立检索、独立分析、再统一汇总的场景；不适合高度耦合、强确认链路或副作用重的任务。关键不是“开了几个 Agent”，而是端到端净收益是否成立。
追问方向：如果并行后平均更快，但长尾更差，你会怎么判断是否保留？
10. Reviewer Agent 的边界应该画到哪里？
题目：如果加一个 Reviewer Agent，它应该只负责审查，还是可以直接改计划、改代码、改结论？
面试官想听什么：你是否知道 Reviewer 的价值在于质量把关，而不是让它变成第二个主 Agent。
短答版：我更倾向让 Reviewer 负责发现问题、给出审查意见和通过/驳回信号，而不是无限制直接接管执行。边界不清，Reviewer 很快会和主执行链抢职责。
深答版：
展开深答版
这题核心是 reviewer boundary。Reviewer 的职责通常是做独立视角校验，检查是否遗漏风险、违反约束或不满足验收标准，而不是把整个主流程重新执行一遍。
如果允许 Reviewer 直接重写目标、随意改方案甚至自行调用高风险工具，它就不再是审查角色，而变成另一个执行者。这样系统里就会出现两个决策中心，责任链也会立刻模糊。
工程上，限制 Reviewer 只输出问题清单、证据和明确 verdict，更容易做审计和回归。放开修改权看似高效，但很容易引入“谁最终负责”的混乱，尤其在生产场景里。
追问方向：什么时候 Reviewer 应该只有建议权，什么时候可以有否决权？
11. 一个 Agent 失败了，怎么把故障限制在局部？
题目：如果某个子 Agent 跑偏、超时或返回脏结果，怎么避免整条链路一起崩？
面试官想听什么：你是否有 failure containment 思维，知道多 Agent 真正难的是局部失败不要扩散成系统失败。
短答版：关键是隔离上下文、限制写权限、给每个子任务单独超时和验收门槛。不要让一个失败结果自动污染共享状态或触发级联重试。
深答版：
展开深答版
这题本质是在谈故障隔离。多 Agent 系统不是不能失败，而是要让失败停在该停的地方，不要因为一个子 Agent 跑偏，就把全链路一起拖下水。
更稳的方式是让子 Agent 尽量只返回结构化结果和状态，而不是直接改全局事实；共享状态写入前还要经过验证或仲裁。这样即使某个角色产出错误，也不会立刻污染全系统。
工程上，超时、重试上限、结果校验和降级路径会增加编排复杂度，但能显著降低级联故障概率。把失败简单理解成“再试一次”，在多 Agent 系统里往往会放大问题。
追问方向：你会怎么区分“局部失败可降级”和“必须立即终止”的情况？
12. 什么情况下应该收缩回单 Agent？
题目：如果多 Agent 跑起来了，但效果一般，你怎么判断该不该合并回单 Agent？
面试官想听什么：你是否有回退能力，愿意在收益不成立时主动降低系统复杂度。
短答版：当角色边界不稳、并行收益不明显、冲突和治理成本持续高于收益时，我会考虑收回单 Agent。能证明多 Agent 必要，也要能证明什么时候它已经不值得了。
深答版：
展开深答版
这题的核心判断是，多 Agent 不是只能加不能减。只要你发现角色职责长期重叠、子 Agent 只是包装了一层 prompt、共享状态治理成本越来越高，或者最终大部分任务还是回到一个中心角色统一拍板，就说明这套拆分可能没有真正成立。
收缩回单 Agent 并不代表系统退步，而是承认当前任务复杂度不足以支撑多角色协作，把可控性、成本和调试效率重新放回优先级前面。复杂度是要用收益证明的，不是上了就不能撤。
工程上，单 Agent 会失去一部分隔离和并行机会，但会显著降低协调开销和排障难度。多 Agent 一旦上线就不愿意回退，是很常见也很昂贵的执念。
追问方向：你会看哪些信号来决定“继续优化多 Agent”还是“直接收缩架构”？