SubAgent 设计
Q：什么时候该用 subagent？为什么工具调用多就倾向用 subagent？
来源：蚂蚁集团一面 【小红书 Agent 岗一面追问：多 Agent 相比单 Agent 的优势及上下文压力】
新手答：“工具调用多就用 subagent，少就不用。”
高手答：
用不用 subagent 的核心判断不是“工具调用多不多”，而是上下文隔离的收益是否大于通信的成本。
什么时候该用 subagent：
- 子任务会产生大量中间结果，但主任务只需要最终结论：比如“搜索 10 个文件找到某个函数定义”——subagent 内部产生大量搜索结果和文件内容，主 agent 只需要一个文件路径和行号。如果不用 subagent，这些中间结果会污染主 agent 的上下文窗口
- 子任务的上下文和主任务高度不相关：主任务在做代码重构规划，中间需要查一下某个 API 的用法文档——两者的上下文完全不同，混在一起会干扰主任务的推理
- 需要并行处理多个独立子任务：比如同时在三个模块里查找某个接口的调用方，三个搜索互不依赖，用 subagent 可以并行执行
为什么工具调用多就倾向用 subagent：
工具调用多意味着中间状态膨胀快。每次工具调用的输入和返回都会占用上下文窗口：
主 agent 直接调 10 次工具：
上下文增量 = 10 × (工具调用描述 + 工具返回结果) ≈ 数千 token
→ 主任务的原始上下文被稀释，推理质量下降
用 subagent 封装：
上下文增量 = 1 × subagent 返回的结论摘要 ≈ 几百 token
→ 主任务上下文保持干净本质上，subagent 是一种上下文管理策略——用进程隔离的思路解决上下文污染问题。和操作系统里“子进程做脏活、父进程只看结果”是同一个思路。
差距在哪：新手把 subagent 当成”工具调用多时的自动选择”。高手理解 subagent 的核心价值是上下文隔离，判断标准是”中间结果对主任务有没有价值”。面试官考的是你对上下文管理的工程化理解。
追问：主 Agent 和子 Agent 共用同一个上下文吗？
来源：bilibili AI研发实习一面
答案是：不共用，这正是 subagent 存在的意义。
主 Agent 和子 Agent 各自维护独立的上下文窗口，通过结构化消息而非共享上下文来通信：
主 Agent 上下文：
[系统指令] [用户任务] [规划结果] [子Agent1的结论] [子Agent2的结论]
子 Agent 上下文：
[系统指令] [主Agent分配的子任务] [工具调用1] [工具返回1] [工具调用2] [工具返回2] ...主 Agent 看不到子 Agent 的工具调用细节，子 Agent 也看不到主 Agent 的全局规划和其他子 Agent 的结果。两者之间的通信是：
| 方向 | 传递内容 | 形式 |
|---|---|---|
| 主→子 | 子任务描述 + 必要上下文 | 结构化的任务指令 |
| 子→主 | 执行结论 + 关键数据 | 结构化的结果摘要 |
为什么不共用上下文：
- 上下文污染：子 Agent 执行 10 次工具调用产生的中间结果，会把主 Agent 的任务目标和关键约束”淹没”，导致主 Agent 推理质量下降
- 窗口浪费：主 Agent 不需要知道子 Agent 的每一步操作细节，只需要最终结论。共用上下文意味着大量无用信息占据宝贵的窗口空间
- 职责混乱：共用上下文后，子 Agent 可能被主 Agent 的其他指令干扰，偏离自己的子任务目标
类比：主 Agent 是项目经理，子 Agent 是具体执行者。经理不需要看到执行者的每一封邮件和每一次会议记录——只需要一份结论报告。这就是上下文隔离的核心思想。
Q：任务简单但工具调用多，用 subagent 是否浪费 token？怎么解决？
来源：蚂蚁集团一面
新手答：“简单任务就不用 subagent 了，直接调工具。”
高手答：
这个问题的核心矛盾是：subagent 有启动成本（system prompt + 上下文初始化），但简单任务的推理本身不需要那么多 token。
先量化一下成本：
| 方案 | token 消耗构成 | 适合场景 |
|---|---|---|
| 主 agent 直接调工具 | 工具调用 × N（累积在主上下文中） | 工具调用少（❤️ 次），结果对主任务有用 |
| 启动完整 subagent | system prompt + 任务描述 + N 次工具调用 + 总结 | 工具调用多，需要独立推理 |
| 轻量级工具链 | 预定义的工具编排序列，无需模型推理 | 流程固定，不需要模型判断 |
解决方案是分层处理：
- 简单 + 工具少（如“读取某文件的第 10 行”）→ 主 agent 直接调，不值得启动 subagent
- 简单 + 工具多但流程固定（如“在 5 个目录里分别执行 ls”）→ 用轻量工具链，把多次工具调用编排成一个复合操作，不经过模型推理，零 token 消耗
- 简单 + 工具多但需要判断（如“搜索某个函数定义，可能在多个文件里”）→ 用 subagent，但精简 system prompt，只给必要的任务描述，不加载完整的能力描述
关键洞察：“浪费 token”的根源不是 subagent 本身，而是没有根据任务复杂度调整 subagent 的“规格”。就像不需要为查一个文件启动一台虚拟机——轻量容器就够了。
差距在哪：新手把 subagent 当成全有或全无的选择。高手给出了三级分层方案——直接调用、轻量工具链、精简 subagent，根据任务特征选最经济的方案。面试官考的是你对 Agent 系统成本控制的精细化思维。
Q：图片信息怎么在 subagent 之间流转？
来源：蚂蚁集团一面
新手答：“把图片传给下一个 subagent 就行。”
高手答：
图片在 subagent 间流转的核心挑战是多模态数据的序列化成本远高于文本。一张图片编码成 token 可能占几百到上千 token，如果在 subagent 之间原样传递，成本和延迟都会爆炸。
三种流转策略：
1. 传引用，不传内容（首选）
subagent A 处理图片 → 输出：{image_ref: "cache://img_001", description: "架构图，包含三层..."}
subagent B 接收引用 → 需要时才通过 image_ref 加载原图把图片存在共享缓存（内存/磁盘/对象存储），subagent 之间只传引用 ID 和文本描述。大多数下游 subagent 只需要文本描述就够了，只有真正需要“看图”的 subagent 才加载原图。
2. 传结构化摘要（最省 token）
如果上游 subagent 已经理解了图片内容，直接传结构化的理解结果：
{
"image_type": "流程图",
"entities": ["用户请求", "API 网关", "服务集群"],
"relationships": ["用户请求 → API 网关 → 服务集群"],
"key_info": "三层架构，网关做鉴权和限流"
}下游 subagent 拿到结构化数据就能工作，完全不需要再看图片。
3. 多分辨率传递（平衡质量和成本）
对同一张图片生成多个版本：缩略图（低 token）、中等分辨率、原图。根据下游任务需要选择合适的分辨率：
- 只需要判断“这是什么类型的图” → 缩略图
- 需要读取图中文字 → 中等分辨率
- 需要精细分析细节 → 原图
核心原则：图片数据在 subagent 间流转时，能用文本描述替代就用文本，能用引用替代就用引用，只有确实需要视觉理解时才传递图片本体。这和微服务间传大对象的思路一样——传 ID 不传 blob。
差距在哪：新手想到的是直接传图片——这是最暴力也最浪费的方式。高手给出了引用传递、结构化摘要、多分辨率三种策略，核心思想是“尽可能用低成本的信息载体替代高成本的原始数据”。面试官考的是你对多模态系统中数据流转的工程化设计能力。