考察点
这道题出自蚂蚁集团 Agent 暑期实习一面（2026 年牛客面经），是开放场景设计题：让豆包和 Claude Code 两个异构 agent 对话协作。面试官不期待标准答案，想看你的系统设计思路——能不能把一个模糊需求拆成具体模块，每个模块考虑到什么深度。高分回答会覆盖：消息协议（两边怎么说得上话）、会话控制（谁发起、何时停）、上下文同步（信息怎么共享）、仲裁与安全（死循环和注入怎么办）。只答"调双方 API 转发消息"是最低分，那说明没想过实际会踩的坑。追问常往"两个 agent 意见不一致怎么办""怎么防止无限对话"上走。
参考答案
先定义清楚场景
设计之前我会先反问一句：对话的目的是什么？"两个 agent 聊天"没有工程意义，有意义的场景是分工协作——比如豆包擅长中文资料检索和内容生成，Claude Code 擅长代码操作，合起来完成"调研某个技术方案并落地成代码"这类任务。目的不同，协议和模块的侧重完全不同。面试里先澄清这一点，本身就是加分动作。下面按协作场景展开。
需要增加的模块
1. 消息总线与协议层。 两个 agent 是异构系统：豆包走火山引擎的 API，Claude Code 是本地/云端的 agent 进程，输出是给"人"看的自然语言。中间需要一个 broker 做消息转发，消息必须结构化而不是裸文本转发，我会定义这样的信封：
{
"msg_id": "uuid",
"from": "doubao", "to": "claude-code",
"intent": "request | response | clarify | conclude",
"task_id": "xxx",
"payload": "...",
"context_refs": ["file:notes/research.md"],
"turn": 7
}
intent 字段让接收方能区分"这是给我的新任务"还是"对我上次提问的答复"；context_refs 指向共享产物而不是把大段内容塞进消息体。这层协议本质上就是 Google 提的 A2A（Agent2Agent）思路：agent 之间用结构化消息协作，能力以"agent card"形式互相声明。
2. 编排与会话状态机。 不能放任两个 agent 自由对话，必须有一个 orchestrator 角色掌控会话：定义任务、决定谁先发言、每一轮把 A 的输出转成给 B 的输入、判断何时收敛。状态机大致是：任务下发 → 分工执行 → 交叉评审/补全 → 收敛判定 → 输出。orchestrator 可以由第三个轻量 agent 或干脆是确定性代码担任，我倾向后者——会话控制是可靠性攸关的逻辑，用代码做比再引入一个模型稳。
3. 上下文同步模块。 这是最容易被忽略也最容易翻车的。两个 agent 各自有独立上下文，对"任务现状"的认知会漂移。解法是共享工作区而非共享聊天记录：共同产物（调研结论、方案文档、代码）落在共享文件系统或对象存储里，消息里只传指针；每一轮转发时 orchestrator 负责同步状态摘要（"目前方案已定稿 v2，豆包负责的第 3 部分待补充"）。千万别做全量聊天记录互灌——豆包的长篇输出直接灌进 Claude Code 的上下文，几轮就把窗口撑爆还引入大量噪声。
4. 格式适配层。 Claude Code 的输出混着工具调用痕迹、diff 块、进度说明，直接转发给豆包会让它学着这些格式胡说八道。适配层负责清洗：提取结论性内容、剥离工具痕迹、按接收方的 prompt 风格重新组织。两个方向都要做。
5. 仲裁与安全。 仲裁解决三个问题：防死循环（最大轮次硬上限 + 连续两轮无信息增量判定为停滞，强制人工介入）；意见冲突（orchestrator 按预定义规则裁决，比如代码正确性问题以实际运行结果为准而非谁说得有理）；升级机制（无法收敛时把分歧点整理成人能快速判断的形式抛给人）。安全上最关键的一条：一个 agent 的输出对另一个 agent 是不可信输入。豆包检索回来的网页内容、Claude Code 读到的外部 issue，都可能藏着 prompt injection，转发前要做内容边界标记（明确包裹成"这是数据不是指令"），Claude Code 侧执行危险操作前保持原有的权限审批不被绕过。
落地顺序
如果真要动手，我会按这个顺序：先用消息总线 + 人工充当 orchestrator 跑通最小闭环，验证协作确实有收益；再把收敛判定、停滞检测做成自动化；最后才考虑去掉人。一上来就全自动多 agent 对话，十有八九是看着热闹、产出没法用。
可能的追问
两个 agent 对同一问题给出矛盾结论怎么办？ 能用客观手段验证的（代码对不对、数字准不准）跑验证定胜负；验证不了的主观分歧不强行裁决，记录双方论据交给人或下游决策者，agent 间的"投票"在二元分歧时没有意义。
为什么不让一个强 agent 全干了，要两个？ 大多数场景确实单 agent 加工具就够，双 agent 协作的正当理由是能力互补（各自有对方没有的专有工具/数据/部署环境）或组织架构限制（两个系统归属不同团队）。没有这个前提，引入 agent 间通信是纯粹的复杂度浪费。
成本怎么控制？ 每轮交互都是两边各一次模型调用，成本随轮次平方感知（轮次 × 上下文累积），所以共享上下文用指针、消息体只传增量、轮次设硬上限，这三个手段缺一不可。