考察点
这道题出自字节跳动 Agent 开发实习一面（2026 年牛客面经），是上一题"多 agent 编排"的自然延伸，考察你设计子 agent 时的思考维度。面试官不满足于"我有个 explore agent 和 code agent"这种名词罗列，想听的是：子 agent 之间到底在哪些维度上不同——只是 prompt 不同，还是上下文、模型、权限都不同？第二问"能不能共享工具"是真正的考点，它把问题从功能设计推向并发安全和权限设计，答案必须是分层的：定义可以共享，状态和副作用必须隔离。追问会往"子 agent 上下文怎么隔离""写工具并发冲突怎么办"上走。
参考答案
子 agent 之间的区别，远不止 prompt
我系统里的子 agent 在四个维度上做区分。
职责与提示词是最表层的一层：explore agent 负责只读地调研代码库、回答"这个逻辑在哪、怎么工作"；plan agent 把调研结果变成结构化实施计划；code agent 按计划动手改；review agent 用挑剔的视角走查 diff。每个的 system prompt 都围绕单一职责写，职责越窄，prompt 越好写，行为越稳定。
上下文隔离是子 agent 架构的核心价值。每个子 agent 有独立的上下文窗口，主 agent 给它的是任务描述，它返回的是提炼后的结论。explore agent 可能读了二十个文件、翻了上万行代码，但这些中间内容全部留在它自己的上下文里，主 agent 只收到几百字的结论。没有这层隔离，多 agent 就失去意义——只是把一个臃肿的上下文拆成几个臃肿的上下文。
模型选择是成本维度：探索、格式整理这类难度低的任务用小一档的模型，复杂推理留给旗舰模型。一个任务跑下来，小模型承担七八成的 token 量，成本差距非常明显。
权限是安全维度：explore agent 只发只读工具，物理上不可能改坏东西；code agent 能写文件但限在工作区；能碰 bash 的子 agent 最少，且有命令白名单。权限跟着职责走，最小授权。
能不能所有子 agent 共享工具
这个问题要拆成"共享定义"和"共享状态"两层回答，混着答就掉坑里了。
工具定义可以也应该共享。 我的所有子 agent 用的是同一套工具库——同一套 schema、同一份描述、同一个实现。原因很简单：工具实现是代码资产，每个子 agent 各写一份会出现行为漂移（两个"读文件"工具对二进制文件处理不一致），维护也是噩梦。从模型角度看，一致的工具语义也让各 agent 的输出更可预期。
工具的状态和副作用不能共享，要按类别处理。 只读工具（读文件、grep、列目录）天然可并行共享，多个 explore agent 同时跑没有冲突。有副作用的工具必须隔离或串行化：两个 code agent 同时改同一个文件就是写冲突，我的做法是拆任务时保证工作范围不重叠，躲不开的用 git worktree 开独立工作区各改各的、最后由主 agent 合并。有状态的工具更要小心——比如一个维持着 shell 会话或数据库连接的工具实例，被多个 agent 并发使用会出现命令交错、状态串味，必须每个 agent 一个实例。
权限不允许共享。 即使工具库统一，发给每个子 agent 的子集必须按职责裁剪。全部共享等于全员最高权限，review agent 一个误判就能改生产配置，这违背最小授权原则。
所以完整答案是：同一工具库、不同工具子集；只读共享、写入隔离、有状态实例各持一份。这套原则和多线程程序设计的共享不可变数据、隔离可变状态是同一个思想，只是主角从线程换成了 agent。
可能的追问
子 agent 之间需要直接通信吗？ 我的默认是不允许，都经主 agent 中转。直接通信容易产生循环依赖和"电话游戏"式的信息失真；确实有高频协作需求时，用共享的结构化文档（如计划文件）做异步交换，而不是互发消息。
怎么判断该拆一个新的子 agent，还是给现有 agent 加个 skill？ 看上下文隔离需求：需要独立上下文、并行执行、不同权限的拆子 agent；只是"主 agent 偶尔要走的某个流程"写成 skill 更轻。子 agent 是隔离单位，skill 是知识单位。
子 agent 返回的结论主 agent 要验证吗？ 要。子 agent 会犯错也会幻觉，主 agent 对关键结论（"测试都通过了"）要求附上可验证证据（测试输出摘要、diff 统计），高风险的最终产物由主 agent 亲自复核。