单多 Agent 决策与模式

Q：怎么判断一个 Agent 该做成单 Agent，还是多 Agent？

来源：腾讯大模型应用开发二面 【阿里国际一面追问：Claude Code 是 multi 还是 single agent】

新手答：“复杂任务用多 Agent，简单任务用单 Agent。”

高手答：

关键不是任务听起来复不复杂，而是三个判断维度：

1. 能力边界是否清晰：如果任务里包含明显不同的专业能力（代码修改、合规审查、数据分析），拆开更清晰
2. 上下文是否容易污染：不同子任务的中间状态混在一起会互相干扰时，隔离有价值
3. 是否存在天然并行：多个子任务可以同时进行时，多 Agent 能降低总延迟

如果整个任务虽然长，但上下文高度统一，一个 Agent 加状态机通常就够了。

多 Agent 的好处是职责分离、上下文隔离、局部优化方便，但成本也更高——需要处理通信、调度和一致性。所以不是越多 Agent 越高级，很多场景单 Agent 反而更稳。只有在“拆开明显比揉在一起更好管”的时候，多 Agent 才值得做。

差距在哪：新手用“复杂 vs 简单”做判断——这个维度太模糊。高手给出了三个具体判断标准（能力边界、上下文污染风险、天然并行性），且指出多 Agent 的隐性成本。面试官考的是你选架构时有没有明确的判断框架，而不是凭感觉。

---

Q：在多 Agent 协作系统中，记忆应该如何共享？是全局共享还是每个 Agent 独立？

来源：后端 AI 八股 / Memory 系统 【小红书AI应用开发同题：多Agent上下文管理与共享】

新手答：“全部共享，大家都能看到。”

高手答：

既不是全局共享，也不是完全独立——是分层共享：

记忆层	共享范围	示例
全局共享记忆	所有 Agent 可读	用户画像、系统规则、全局上下文
团队共享记忆	同一任务的 Agent 组可读写	当前任务的中间结果、协作状态
私有记忆	单个 Agent 独占	Agent 自己的推理过程、工具调用中间态

关键设计原则：

1. 读写权限分离：全局记忆大部分 Agent 只读，只有特定角色能写
2. 传结论不传过程：Agent 之间共享的是结构化结论（“查到用户订单号是 XXX”），不是原始推理链
3. 版本化防冲突：共享记忆带版本号，并发写入时用乐观锁，防止互相覆盖
4. 按需订阅：Agent 不轮询共享记忆，而是订阅自己关心的字段变更，事件驱动

全局共享的风险是上下文污染——A Agent 的中间推理被 B Agent 当成事实。完全独立的问题是信息孤岛——Agent 之间重复劳动。分层共享是平衡点。

记忆隔离与上下文污染防治：

在多 Agent 系统中，不同 Agent 使用不同工具，工具返回的原始数据如果不经处理就写入共享记忆，会造成跨工具上下文污染——A Agent 的搜索结果被 B Agent 当成事实依据。

防治措施：

污染类型	具体表现	防治方案
工具结果泄漏	Agent A 的搜索结果被 Agent B 误用	工具返回值只写入调用者的私有记忆，共享记忆只存结论
推理过程泄漏	Agent A 的 chain-of-thought 被 Agent B 当成事实	严格区分“推理过程”和“确认结论”，只共享后者
状态竞态	并发 Agent 同时更新共享状态，互相覆盖	乐观锁 + 版本号，冲突时由编排层仲裁
角色混淆	共享上下文中包含多个 Agent 的指令，模型混淆角色	每条共享信息标注来源 Agent ID 和角色

核心原则：共享记忆中只存“what”（结论和事实），不存“how”（推理过程和工具原始返回）。每个 Agent 的 thinking 和 tool outputs 严格限制在私有空间内。

差距在哪：新手要么全共享（污染风险）要么全独立（效率低）。高手用三层共享模型平衡了协作效率和隔离安全，且给出了权限、传递、版本、订阅四个关键设计点。面试官考的是你对多组件共享状态的架构设计能力。

---

Q：单 Agent 还是多 Agent 的？子 Agent 的任务是什么？

来源：抖音基础架构 Agent 一面

新手答：“用一个 Agent 就行。”

高手答：

以 AI 代码测试系统为例，用多 Agent 架构，分四个角色：

┌─────────────┐     ┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│  代码分析器   │ ──→ │  测试生成器   │ ──→ │  测试验证器   │ ──→ │  覆盖率检查器 │
│  Analyzer    │     │  Generator   │     │  Validator   │     │  Coverage    │
└─────────────┘     └─────────────┘     └─────────────┘     └─────────────┘

1. 代码分析器：解析待测代码的 AST，提取函数签名、依赖关系、分支结构、复杂度指标，输出结构化的分析报告
2. 测试生成器：基于分析报告和提示词模板，生成测试代码。它只负责“写”，不负责“验”
3. 测试验证器：执行生成的测试，检查语法是否正确、能否通过编译、断言是否合理。失败的用例连同错误信息反馈给生成器重试
4. 覆盖率检查器：跑覆盖率工具，分析哪些分支没覆盖到，把未覆盖的分支信息反馈给生成器做补充生成

拆成多 Agent 的原因：每个环节的失败模式不同，分开才能精准重试。生成失败和验证失败的处理逻辑完全不一样，混在一起会导致无效重试。

差距在哪：新手默认用单 Agent 解决所有问题。高手的多 Agent 架构有明确的拆分理由——不同环节的失败模式不同，分开才能精准处理。面试官考的是你为什么拆、怎么拆、拆完各个子 Agent 之间怎么协调。

---

Q：多 Agent 设计里，按“职能拆分”和按“阶段拆分”各有什么优缺点？

来源：Agent 开发面试 30 题

新手答：“按职能拆更清晰。”

高手答：

两种拆分方式解决的是不同的问题，不存在“哪个更好”：

按职能拆分（Functional Split）：

用户请求 → 路由器 → 搜索 Agent / 计算 Agent / 写作 Agent / 数据库 Agent

每个 Agent 有独立的能力域，路由器根据用户意图分发。

优点	缺点
职责清晰，每个 Agent 的 Prompt 和工具集精简	复杂任务需要多个 Agent 协作，通信成本高
单个 Agent 可独立优化和测试	路由器成为单点瓶颈，路由错了全盘皆输
新增能力只需加一个 Agent，不影响其他	跨 Agent 的状态共享是难题

按阶段拆分（Stage Split）：

用户请求 → 理解 Agent → 规划 Agent → 执行 Agent → 总结 Agent

每个 Agent 负责任务流水线的一个阶段，依次传递。

优点	缺点
流程清晰，每步输出是下步输入	增加一个阶段需要改整条链路
天然适合有明确先后依赖的任务	前一阶段出错，后续全部受影响（错误级联）
状态传递简单（线性传递）	不适合需要灵活分支的场景

实际工程中的选择标准：

• 任务类型多样、各子任务独立性强 → 职能拆分（如客服系统：查询/投诉/咨询各一个 Agent）
• 任务流程固定、阶段依赖强 → 阶段拆分（如代码审查：理解 → 分析 → 修复建议 → 总结）
• 两者可以嵌套：宏观按阶段拆，某个阶段内部按职能拆

差距在哪：新手只知道职能拆分。高手对比了两种拆分方式的优缺点和适用场景，且指出两者可以嵌套组合。面试官考的是你在多 Agent 架构设计时有没有系统性的拆分思路。