主题
高频面试题
子 Agent（Subagent）模式有什么优势和挑战？父 Agent 调用子 Agent 时需要考虑哪些边界问题？
这道题看似在问多 Agent，实际在问“父 Agent 如何委派而不失控”：任务边界、上下文边界、权限边界和验收边界都要说清。
面试官角度分析，想考什么
为什么要引入子 Agent？它和普通工具差在哪？
考定义：子 Agent 有独立上下文和执行循环，不是一次函数调用。父 Agent 委派时边界怎么定？
考契约：目标、范围、最小上下文、最小权限、输出 schema 和失败条件。返回后怎么验收，风险是什么？
考控制：证据验收、冲突处理；防止上下文泄漏、权限放大和循环调用。
可直接抄走的 30 秒参考答案
text
Subagent 模式适合复杂任务中边界清晰的子问题，比如调研、代码实现、评审、合规检查。它的优势是专业化、上下文隔离、工具隔离、并行执行和独立制衡；挑战是拆分错误、上下文丢失、成本延迟增加、循环调用、错误传播和权限放大。父 Agent 调用子 Agent 时不能只是发一句话，而要给明确任务契约：目标、范围、输入、工具权限、预算、输出 schema 和失败条件。子 Agent 返回后，父 Agent 还要验收证据、处理冲突并对最终结果负责。面试回答详解，知其所以然
Subagent 模式不是“开更多 Agent”。它本质上是一种委派机制：父 Agent 把某个边界清晰的子任务交给另一个 Agent 执行，子 Agent 在自己的工具和上下文里完成任务，再把结果、证据和不确定性返回。
1. Subagent 的优势
- 专业化：Research、Coder、Reviewer、Data Analyst、Compliance 可以有不同 instruction、工具和评估标准。
- 上下文隔离：子 Agent 只看到完成子任务所需信息，减少主上下文污染和 token 压力。
- 工具隔离：不同子 Agent 拿不同工具，避免一个全能 Agent 拥有过宽权限。
- 并行执行：多个相互独立的调研、代码扫描或文档处理任务可以同时跑。
- 独立制衡：Reviewer 或 Evaluator 子 Agent 可以不继承生成 Agent 的推理路径，降低盲点。
- 可替换性：某类子 Agent 可以单独换模型、换 prompt、调预算和做 eval。
面试中最好补一句：这些优势只在任务可拆、边界清晰时成立。任务高度耦合时，Subagent 会增加协调成本。
2. Subagent 和 Tool Call 的区别
普通工具调用像函数：
text
父 Agent -> call tool(args) -> result -> 父 Agent 继续Subagent 调用像委派：
text
父 Agent -> 子任务契约 -> 子 Agent 自己 plan/act/observe -> artifact/report -> 父 Agent 验收关键差异：
- 自主性：工具通常是确定性执行，子 Agent 会自己计划、调用工具、重试和判断停止。
- 上下文：工具只接收参数，子 Agent 可能接收任务背景、约束、可用资料和输出格式。
- 权限：工具权限是单动作权限，子 Agent 权限是一组能力和执行预算。
- 结果：工具返回原始结果，子 Agent 应返回经过整理的产物、证据和不确定性。
- 可观测性：子 Agent 内部有自己的 trace，父 Agent 需要能引用和检查。
如果只是查数据库、发 HTTP 请求、格式转换，不必包装成子 Agent。Subagent 适合需要多步推理和多工具循环的子任务。
3. 父 Agent 调用子 Agent 前要定义任务契约
父 Agent 不能只说“你去研究一下”。高质量委派要明确：
- 目标：子任务要回答什么问题，完成标准是什么。
- 范围：包含什么、不包含什么，哪些方向不要做。
- 输入：必要背景、用户约束、已有证据和相关文件。
- 工具权限：允许哪些工具，禁止哪些工具，是否允许写操作。
- 预算：最大轮数、最大时间、最大 token、最大外部请求数。
- 输出 schema：结论、证据、引用、风险、不确定性、下一步建议。
- 失败处理：何时返回 blocked，何时请求父 Agent 补充信息。
一个稳定的子 Agent 输出可以长这样：
json
{
"status": "completed",
"answer": "...",
"evidence": [{"source": "...", "claim": "..."}],
"confidence": "medium",
"open_questions": [],
"actions_taken": ["searched docs", "read file"],
"risks": ["source coverage is limited"]
}4. 上下文边界：传少，但传准
父 Agent 容易犯两个错误：要么把完整历史全塞给子 Agent，要么只传一句任务导致子 Agent 猜背景。
更好的做法是传“任务包”：
- 用户原始目标的相关摘录。
- 当前子任务需要的约束，例如语言、格式、禁止操作。
- 已知事实和证据来源。
- 相关文件、资源或上下文片段的引用。
- 不要传的内容：无关对话、其他子任务内部推理、敏感凭据、全量用户资料。
这能降低 token 成本，也能减少 prompt injection 和隐私泄漏面。
5. 权限边界：子 Agent 不能继承父 Agent 全部权限
父 Agent 拥有的工具不应该自动下放给子 Agent。授权应该按子任务重新计算：
- Research 子 Agent 可以联网搜索和读取资料，但不应该写数据库。
- Coder 子 Agent 可以编辑工作区和跑测试，但不应该访问用户邮件。
- Reviewer 子 Agent 可以读 diff 和测试结果，但不应该直接修改代码，除非明确授权。
- Compliance 子 Agent 可以读候选输出和规则库，但不应该看到不必要的原始 PII。
子 Agent 的输出也不应自动触发副作用。即使子 Agent 建议“发送邮件”，父 Agent 或 runtime 仍要走高风险确认。
6. 父 Agent 的验收责任不能外包
父 Agent 调用子 Agent 后，不能简单相信返回结果。至少要做：
- 结构校验：是否符合 schema，关键字段是否缺失。
- 证据检查：结论是否有来源、测试或工具结果支持。
- 冲突处理：多个子 Agent 结果不一致时要标注并裁决。
- 权限复查：子 Agent 是否越界调用工具或使用了不该看的数据。
- 质量验收：是否满足原始用户目标，而不只是完成了子任务。
- 失败恢复：不完整时重新委派、缩小范围、换 Agent 或请求用户澄清。
面试里可以说：父 Agent 是 orchestrator，不是转发器；它对最终答案负责。
7. 主要挑战和失败模式
- 任务拆分错误：子任务过宽、重叠或遗漏，导致重复劳动或漏答案。
- 上下文割裂：子 Agent 缺关键背景，产出看似正确但不适配最终目标。
- 成本和延迟膨胀：多个子 Agent 并行或递归调用，token 和外部请求快速上升。
- 循环调用：父子之间互相委派，或者子 Agent 内部无法停止。
- 错误传播：早期子 Agent 的错误被父 Agent 汇总成更确信的结论。
- 权限放大：子 Agent 继承过宽工具，产生越权写入或数据泄漏。
- trace 分散：没有统一 trace 时，很难复盘哪个 Agent 出错。
面试官追问3个问题
追问一：什么时候不该用 Subagent？
- 考察点：是否会控制复杂度。
- 回答方向：任务短、流程固定、上下文高度耦合、延迟敏感或没有验收机制时，不该强行拆。单 Agent 加好工具或 workflow 更稳。
追问二：父 Agent 应该给子 Agent 完整聊天历史吗？
- 考察点：上下文治理。
- 回答方向：一般不应该。应传任务相关摘要、约束、证据和资源引用。完整历史会增加成本、泄漏风险和上下文污染。
追问三：多个子 Agent 结果冲突怎么办？
- 考察点：聚合验证能力。
- 回答方向：要求每个子 Agent 返回证据和置信度；父 Agent 比较来源质量、时间、工具结果和测试；冲突无法解决时标注不确定性或请求进一步验证。
扩展知识
Subagent、Handoff 和 Orchestrator-Workers 的关系
- Subagent：强调父 Agent 委派子任务，子 Agent 完成后通常返回父 Agent。
- Handoff：强调控制权移交，新 Agent 可能直接接管后续用户交互。
- Orchestrator-Workers：强调主控拆分多个子任务，多个 worker 并行执行后聚合。
三者可以组合，但面试时要讲清控制权是否返回、用户是否感知、结果如何汇总。
子 Agent 输出必须带证据
没有证据的子 Agent 输出只是另一段模型文本。尤其是调研、代码审查、合规判断，输出应该带来源、文件、测试结果、风险和不确定性，方便父 Agent 验收。
子 Agent 也是安全边界
间接 prompt injection 不只会攻击主 Agent，也会攻击子 Agent。委派前要限制输入，执行中要限制工具，返回后要检查子 Agent 是否把外部恶意指令当成系统指令。