Q：智能体可信通信怎么实现？

来源：字节AI开发二面

新手答：“用 HTTPS 加密通信就行了。”

高手答：

Agent 间可信通信不只是传输层加密，还涉及身份认证和内容完整性：

1. 身份认证：每个 Agent 需要有独立身份标识（类似 mTLS 的证书体系），通信前互相验证“你真的是你声称的那个 Agent”
2. 消息签名：Agent 发出的每条消息附带数字签名，接收方可验证消息未被篡改、确实来自声称的发送者
3. 能力声明与授权：Agent A 调用 Agent B 前，B 需要验证 A 是否有权限请求该能力（类似 OAuth scope）
4. 防 Prompt 注入：Agent A 传给 Agent B 的内容可能被恶意构造（间接注入），B 需要对输入做净化和边界隔离
5. 审计链路：所有 Agent 间通信需要留痕（who→whom, when, what），支持事后追溯责任
6. 信任传递控制：Agent A 信任 Agent B，B 信任 C，不代表 A 自动信任 C——需要显式信任链管理

差距在哪：面试官考察你对“Agent 是独立决策实体”的安全意识——不像微服务在同一可信域内，Agent 可能来自不同组织/不同供应商，必须零信任设计。

---

Q：子 Agent 之间的上下文怎么传递？传什么、不传什么？

来源：阿里 Agent 面经

新手答：“把上一个 Agent 的输出传给下一个就行。”

高手答：

“把输出传给下一个”在简单链路下能工作，但当子 Agent 数量增多或存在并行时，传递不当会导致两个问题：① 传太多——上下文膨胀、推理质量下降；② 传太少——下游 Agent 缺少必要信息，输出偏离。

核心原则：传结论和约束，不传过程和原始数据

传递内容的分类设计：

类别	传	不传	原因
任务结论	✅ 搜索到的关键结果	❌ 搜索的中间过程	下游只需要结果，不需要知道怎么找到的
约束条件	✅ 用户的硬性要求	❌ 已验证满足的约束	下游需要遵守约束，但不需要知道上游如何验证
状态信息	✅ 当前进度和待做事项	❌ 已完成任务的详细日志	下游只需要知道“到哪了”和“接下来做什么”
错误信息	✅ 失败结论（“方案 A 不可行”）	❌ 失败的详细堆栈	防止下游重复尝试已知不可行的路径

工程实现——标准化传递格式：

子 Agent 间传递的消息结构：
{
  "from_agent": "search_agent",
  "to_agent": "analysis_agent",
  "task_id": "task_001",
  "payload": {
    "conclusion": "找到 3 个符合条件的方案",
    "data": [结构化的候选列表],
    "constraints_carried": ["预算 < 5000", "需要支持 iOS"],
    "warnings": ["方案 B 的评价数据较少，置信度低"]
  },
  "context_budget": 800  // 告诉下游这条消息预期占多少 token
}

特殊场景的传递策略：

场景	策略
并行子 Agent 汇总结果	每个 Agent 返回独立结论，由聚合层统一整合，不互相传递
子 Agent 需要回溯上游	传引用（task_id + step_id），需要时通过编排层按需加载
子 Agent 链路很长（>3 跳）	每跳做一次摘要压缩，防止传递的上下文线性膨胀

差距在哪：新手把“输出传给下一个”当成全部——这在两个 Agent 的简单链路下没问题，但在多 Agent 系统中会导致信息膨胀或缺失。高手用明确的传/不传分类、标准化消息格式和特殊场景策略，把上下文传递变成了一个可控的工程方案。面试官考的是你对多 Agent 系统中“信息流动”的精细化设计能力。

---

Q：多 Agent 协作常见模式有哪些？各自适合什么任务类型？

来源：阿里 Agent 面经

新手答：“就是一个 Agent 做完交给下一个。”

高手答：

多 Agent 协作模式远不止“串行传递”。不同的任务特征需要不同的协作拓扑，选错模式会导致效率低下或质量失控。

五种核心协作模式：

各模式详细对比：

模式	适合任务	优势	劣势	典型场景
顺序链	流程固定、步骤有先后依赖	简单可控、易追踪	一步出错全链断；延迟线性增长	ETL 数据处理、代码审查
辩论式	需要多角度论证的决策问题	减少单一视角偏差	token 消耗高；需要好的仲裁机制	方案评估、风险分析
投票式	不确定性高、需要提升鲁棒性	降低单点幻觉风险	成本 ×N；投票策略影响结果	分类判断、事实验证
层级委托	复杂任务需要动态拆解	灵活、支持递归分解	Supervisor 是瓶颈；嵌套深度需限制	项目管理、多步推理
反馈循环	质量要求高、可迭代优化的生成任务	输出质量有保障	循环次数不可控；需设退出条件	代码生成+审查、文案优化

选型决策树：

任务特征分析：
  ├── 步骤间有强依赖？ → 顺序链
  ├── 需要多角度验证？ → 辩论式 或 投票式
  │     ├── 论证型（方案好不好）→ 辩论式
  │     └── 判断型（是 A 还是 B）→ 投票式
  ├── 任务复杂度未知、需动态拆解？ → 层级委托
  └── 生成质量要求极高？ → 反馈循环

生产中的组合使用：

实际系统很少只用一种模式。典型组合：

• 主流程用顺序链（保证确定性）+ 生成环节用反馈循环（保证质量）
• 外层用层级委托（动态拆任务）+ 每个子任务用投票式（提高鲁棒性）

差距在哪：新手只知道顺序传递。高手能画出五种协作模式的拓扑图，说清各自的适用场景和权衡，且指出生产中通常是混合使用。面试官考的是你对多 Agent 协作的“模式库”——面对不同任务特征能快速选出最合适的协作拓扑。

---

Q：主 Agent 与子 Agent 的通信和进度同步怎么做？是推还是拉？

来源：广州某小厂 Agent 后端开发二面

新手答：“子 Agent 做完了就告诉主 Agent。”

高手答：

“做完了通知”只是最简单的情况。实际系统中主 Agent 需要在子 Agent 执行过程中持续感知进度——否则无法做超时干预、动态调整、或向用户反馈进展。

推 vs 拉的对比：

维度	推模式（子 Agent 主动上报）	拉模式（主 Agent 主动查询）
实时性	高——状态变化即时通知	依赖轮询频率，有延迟
资源消耗	低——只在状态变化时通信	高——空轮询浪费资源
实现复杂度	需要事件机制/回调	简单轮询即可
适合场景	子任务执行时间长、进度有多阶段	子任务短平快、不关心中间状态

生产环境的最佳实践：推为主、拉为辅

具体设计：

1. 子 Agent 主动推送的时机：

事件	推送内容	主 Agent 的处理
任务开始	\{status: "started", estimated_time: 5s\}	记录开始时间，启动超时计时器
阶段完成	\{status: "progress", step: "2/5", intermediate_result: "..."\}	更新进度，按需向用户反馈
需要输入	\{status: "blocked", reason: "缺少参数 X"\}	决定是追问用户还是从其他来源获取
任务完成	<code v-pre>{status: "completed", result: {...}}</code>	取消超时计时器，整合结果
任务失败	\{status: "failed", error: "...", retry_suggestion: "..."\}	决定重试/降级/上报

2. 主 Agent 主动拉取的场景：

- 超时兜底：分发任务后启动计时器，超过预期时间未收到推送 → 主动查询
- 用户催促：用户问"到哪了" → 主 Agent 主动向子 Agent 拉取当前进度
- 动态调整：外部条件变化（如用户修改了需求） → 主 Agent 拉取当前状态后决定是否中断

3. 通信实现方式：

实现方式	适用场景	技术栈
回调函数	同进程内的子 Agent	直接函数调用，零网络开销
事件总线	同服务内多 Agent	Redis Pub/Sub、内存事件队列
Webhook/SSE	跨服务的异步 Agent	HTTP 回调或 Server-Sent Events
共享状态轮询	最简单的实现	子 Agent 写状态到 DB，主 Agent 定期读

4. 进度同步的工程细节：

• 幂等性：网络抖动可能导致推送重复，主 Agent 需要按 task_id + event_id 去重
• 顺序保证：推送可能乱序到达，每条消息带递增序号，主 Agent 按序处理
• 断线重连：子 Agent 挂了重启后，主动向主 Agent 重新汇报当前状态

差距在哪：新手只想到“做完通知”——这是最终态，不是过程态。高手设计了“推为主、拉为辅”的混合方案，覆盖了任务全生命周期的状态同步，且考虑了超时兜底、用户催促、动态调整等实际场景。面试官考的是你对异步系统中“状态可见性”的工程化理解——主 Agent 不能是盲人，必须随时知道子 Agent 在干什么。

---

Q：多个 Agent 并发操作数据库或文件，这种并发怎么处理？

来源：蚂蚁Agent开发一面

新手答：“加锁，谁先拿到锁谁先执行。”

高手答：

Multi-Agent 的并发和传统多线程并发有本质区别：Agent 的操作是语义级的（“修改第 3 段”、“更新用户配置”），不是简单的读写操作。需要分场景处理：

场景 1：操作同一个文件（如代码文件）

• 隔离执行 + 合并：每个 Agent 在独立副本（Git Worktree / 临时分支）上操作
• 执行完毕后做 diff merge——冲突时由 orchestrator Agent 裁决
• Claude Code 的 Worktree 隔离就是这个模式

场景 2：操作同一个数据库记录

• 乐观锁 + 语义冲突检测：每次写入携带 version 号
• 写入时检查 version 是否变化——变化说明被其他 Agent 改过
• 冲突时不是简单重试，而是重新读取最新状态 → 重新决策 → 再写入

场景 3：操作有依赖关系的资源

• 编排层声明依赖：在 DAG 中标注哪些 Agent 操作有数据依赖
• 有依赖的串行执行，无依赖的并行
• 运行时通过 semaphore 控制同一资源的并发度

通用原则：

• 优先隔离（避免冲突）> 检测冲突（乐观锁）> 防止冲突（悲观锁）
• Agent 的操作粒度比线程大得多，锁的粒度也应该更粗（资源级而非行级）
• 冲突解决需要“语义理解”——两个 Agent 同时改同一段代码，不是简单的“后来者覆盖”

差距在哪：新手直接想到传统并发控制（mutex/lock）。高手理解 Agent 并发的特殊性——操作是语义级的、冲突解决需要理解意图、最佳策略往往是隔离执行后合并而不是争抢同一个资源。