考察点
这道题出自字节跳动 Agent 开发实习一面（2026 年牛客面经），问的是 coding agent 最核心的两块架构能力：面对复杂任务怎么规划，以及多个 agent 怎么协作。面试官想分辨你是"调了个 ReAct 循环"还是"真设计过任务分解系统"。好的答案要体现：plan 不是一次性生成的一坨文字，而是一个可持久化、可修订的状态对象；多 agent 编排要讲清楚上下文隔离、任务分发、结果汇合、冲突处理这些具体工程问题。追问通常往"plan 执行到一半发现不对怎么办""子 agent 之间怎么通信、文件冲突怎么处理"上走。
参考答案
Plan 是怎么生成的
面对复杂任务，我的 agent 不是上来就写代码，而是先走一个探索-规划-确认的前置阶段。探索阶段只用只读工具：列目录结构、读关键文件、grep 相关符号，目的是搞清楚"这件事涉及哪些代码、现状是什么"。探索产出被喂给规划阶段，模型生成一份结构化计划：分成哪几步、每步动哪些文件、每步完成后的验证方式（跑哪个测试、检查什么输出）。计划默认要用户确认才执行，高置信度的低风险任务可以配置成自动通过。
这里有一个关键工程决策：plan 是一个持久化的状态对象，不是聊天记录里的一段话。我把它存成 markdown 文件（也在上下文里保留），每个步骤有 pending / in_progress / done / failed 状态。它有三个作用：第一，作为上下文压缩时的锚点——不管历史被压掉多少，plan 始终保留，agent 不会"忘记自己在干嘛"；第二，给用户一个可干预的抓手，随时能看到进度、能喊停；第三，步骤完成时强制 agent 勾选并验证，把"我以为做完了"变成"验证过了才算完"。
Replan：计划必然会失效
真实任务里计划赶不上变化是常态：改到一半发现某个依赖不能动、测试暴露了新问题。所以 plan 必须支持修订。我的做法是每步执行完做一次轻量检查：结果是否符合预期、后续步骤是否还有意义。触发 replan 的信号包括步骤失败、工具返回与假设矛盾、用户中途插入新需求。replan 不是推倒重来，而是保留已完成步骤的结论，只重新规划剩余部分。这里要防一个坑：模型有"无限 replan"的倾向，遇到点挫折就改方案，我加了约束——同一任务 replan 超过 N 次必须向用户说明原因并请求指示，避免 agent 在原地打转。
多 Agent 编排的实现
我用的是 orchestrator-worker 结构。一个 lead agent 负责理解整体任务、拆分成相互独立的子任务、分发给 worker 子 agent、最后汇总结果。每个 worker 有独立的上下文窗口——这是多 agent 架构最核心价值：lead 的上下文里只有任务定义和 worker 返回的结论，worker 探索过程产生的海量中间内容（读文件、跑命令的输出）不会污染 lead，等于把上下文容量横向扩展了。
具体实现上有几个关键点。任务分发用结构化 JSON：子任务描述、涉及范围（哪些目录/文件）、约束、期望产出格式。worker 之间默认不直接通信，都通过 lead 中转——直接互发消息很容易产生循环依赖和状态不一致，star 拓扑简单可控。文件冲突的处理是按范围隔离：拆任务时就保证 worker 的工作目录或文件集合不重叠；做不到不重叠的（比如都要改同一个公共文件），要么串行执行，要么用 git worktree 给每个 worker 开独立工作区，最后由 lead 合并。结果汇合时 lead 不盲目信任 worker 的"我完成了"，而是要求返回可验证的产物（diff、测试输出），自己做最终校验。
多 agent 不是银弹，我的使用原则是：子任务可以并行、各自需要大量独立上下文时才拆（比如同时调研三个模块）；强耦合、需要频繁共享中间状态的任务，单 agent 顺序做反而更好，拆开纯粹增加协调成本。
可能的追问
plan 太长/太细，执行中维护成本高怎么办？ 分层：lead 只维护粗粒度里程碑（3-7 步），worker 内部再细化自己的步骤；计划粒度以"可验证"为单位，一个步骤必须有一个明确的验证动作。
怎么决定一个任务要不要拆给多 agent？ 看两点：子任务间的上下文是否相互独立，以及拆开后协调成本是否低于并行收益。我会让 lead 先产出拆分方案并说明理由，用户可否决。
worker 失败了怎么处理？ 先让原 worker 根据失败信息重试（它有上下文优势）；连续失败则 lead 接管该子任务自己分析，必要时降级为"向用户报告该子任务受阻，继续其他部分"，不要让一个 worker 的失败拖死整个任务。