多智能体内容生产

典型题：设计一个多智能体内容生产系统，比如自动调研、写稿、审校、生成最终报告。

面试官真正想看什么

内容生产可以拆成选题、事实核查、写作和审校，但每一步都要有交接字段和负责人。若两个 Agent 同时改标题，系统应合并 patch 或让主管裁决，而不是靠最后写入覆盖。

• 你是否知道多智能体的价值在分工，不在数量。
• 你能不能设计清楚的角色 ownership。
• 你会不会处理结论冲突、职责冲突和文件编辑冲突。
• 你能不能证明多 Agent 比单 Agent 更值得。

先问清楚

Q1：设计前先问什么？

参考答案

我会先问：

• 内容类型是什么：文章、报告、客服知识、营销文案、技术文档。
• 是否需要事实来源。
• 是否允许自动发布。
• 是否多人协作或多 Agent 同时编辑同一产物。
• 成功标准是什么：准确、完整、风格、成本、速度还是合规。

这些问题决定系统是一个简单流水线，还是一个需要版本管理、审批和发布控制的生产系统。

最小架构

角色与 ownership

Q2：角色应该怎么拆？

参考答案

我会先做最小流水线版本：

角色	输入	输出	不该做什么
主管智能体	用户目标、约束	计划、分派、最终收口	不直接编造证据
调研智能体	子问题、资料范围	证据、要点、未确认项	不写最终正文
写作智能体	要点、受众、语气	草稿	不新增无来源事实
审校智能体	草稿、标准、证据	问题清单、修改建议	不无限重写

关键是每个 Agent 只负责一段明确工作，不要所有 Agent 都又查资料、又写稿、又审稿。

Q3：为什么要有主管智能体？

参考答案

主管智能体负责收口。多 Agent 系统如果没有最终 owner，很容易出现：

• 每个 Agent 都觉得自己对。
• 审校和写作反复互改。
• 事实和表达混在一起。
• 最终产物没人负责。

主管不是为了“更智能”，而是为了让系统有任务分派、冲突裁决和最终交付的中心。

状态与交接

Q4：共享状态应该怎么设计？

参考答案

共享状态应该结构化，字段尽量少而清楚：

task_id
user_request
plan
evidence
draft
review_comments
final_answer
cost
status

每个 Agent 只写自己负责的字段。例如调研 Agent 写 evidence，写作 Agent 写 draft，审校 Agent 写 review_comments，主管 Agent 写 final_answer。

Q5：Agent 之间怎么交接？

参考答案

交接要短、准、可追踪。每次 handoff 至少包含：

• 当前阶段目标。
• 上游结论。
• 证据编号。
• 未确认项。
• 下游约束。
• 输出格式。

不要把上游完整聊天记录直接丢给下游。这样会让上下文变脏，也会增加成本。

冲突处理

Q6：调研和写作结论不一致怎么办？

参考答案

事实以证据为准。写作 Agent 不能新增无来源事实，也不能把未确认项写成确定结论。如果写作内容和调研证据冲突，应该：

• 回到 evidence 看来源。
• 要求写作修正。
• 必要时让调研补证据。
• 仍然冲突时由主管标注不确定性。

内容生产系统的底线是：表达可以优化，事实不能乱编。

Q7：审校和写作反复互改怎么办？

参考答案

我会设置最大修改轮数和收口规则，例如：

• 写作生成初稿。
• 审校只提问题和建议。
• 写作最多修改 1-2 轮。
• 主管最终决定是否接受审校意见。

不能让写作和审校无限循环。审校 Agent 的输出应该是“问题清单”，而不是无限重写全文。

Q8：多个 Agent 编辑同一个文件怎么处理？

回答脉络

这是这题最重要的工程追问之一。

参考答案

我会把文件写入当成受控资源：

1. 单写者原则：同一个文件同一时间只有一个写者。
2. 其他 Agent 输出 patch 或评论：不直接覆盖文件。
3. patch 带 base version：明确基于哪一版生成。
4. 应用前检查文件是否变化：变化了就重新生成或人工合并。
5. 主管或人工做最终合并：冲突不要让多个 Agent 同时抢写。

如果是内容文档，可以让调研 Agent 只写证据区，写作 Agent 只写正文草稿，审校 Agent 只写评论区。字段和文件 ownership 清楚，冲突会少很多。

Q9：两个来源冲突怎么办？

参考答案

不要强行合并。应该：

• 标出冲突点。
• 比较来源权威性。
• 比较更新时间。
• 判断是否是地区、版本或口径差异。
• 把无法确认的内容写进未确认项。

多智能体系统里，冲突处理不应该靠“谁声音大”，而要靠证据和规则。

发布、安全与成本

Q10：是否允许自动发布？

参考答案

默认不允许直接自动发布。尤其是对外文章、营销文案、法律/医疗/金融内容、公司公告，都应该有人类确认。可以自动生成草稿、自动审校、自动给风险提示，但发布动作要受控。

如果业务一定要自动发布，也要有：

• 发布前检查。
• 黑名单词和合规规则。
• 低置信度拦截。
• 审计日志。
• 回滚机制。

Q11：怎么控制多智能体内容生产的成本？

参考答案

我会从这些方面控成本：

• 限制 Agent 数量。
• 限制修改轮数。
• 复用调研证据。
• 交接只传结构化摘要。
• 不让每个 Agent 都拿完整上下文。
• 记录各 Agent 成本占比。

多 Agent 很容易成本翻倍，所以必须证明它带来的质量提升值得这笔成本。

评估

Q12：如何证明多 Agent 比单 Agent 更好？

参考答案

要先做单 Agent 基线，再比较多 Agent 方案：

• 任务完成率。
• 事实正确率。
• 引用覆盖率。
• 审校问题修复率。
• 人工修改量。
• 成本和延迟。
• trace 可读性。

如果多 Agent 没让质量、稳定性或可调试性明显提升，就不应该上。

Q13：内容生产系统的 eval 怎么设计？

参考答案

可以准备这些样本：

• 有明确事实来源的写作任务。
• 资料不足的任务。
• 来源冲突的任务。
• 风格要求强的任务。
• 高风险合规任务。
• 需要多轮修改的任务。

评估时不要只看“写得好不好”，还要看事实是否有来源、冲突是否标出、是否乱编、是否超成本。

30 秒收口

Q14：你会怎么总结这个系统？

参考答案

我会先做流水线版本：调研 -> 写作 -> 审校 -> 主管收口。
调研只产证据，写作只产草稿，审校只提问题，最终由主管或人工确认。
同一文件采用单写者原则，其他 Agent 只提交 patch 或评论。

本题常见扣分点

• 只讲“多个 Agent 一起写”。
• 没有最终 owner。
• 没有 evidence 和 draft 的边界。
• 多个 Agent 直接同时改同一个文件。
• 不控修改轮数。
• 不和单 Agent 基线比较。

深挖追问：把方案讲成可上线的系统

Q15：如果面试官让你给出容量、延迟和成本目标，你会怎么估？

参考答案

我不会脱离业务直接报一个并发数，而是先把工作负载拆开。假设系统服务内部报告：日均 1,000 个任务、工作高峰 5 倍；每个任务平均拆成 5 个调研子问题，产生 1 次初稿、1 次审校、最多 1 次修订。那么高峰期并不是“1,000 个 Agent 同时跑”，而是任务队列中会出现约 5 + 1 + 1 + 1 = 8 类模型调用和若干检索调用。

我会先约定可检验的 SLO：简单摘要 P95 在 15 秒内完成；有外部调研的报告 P95 在 90 秒内先返回进度、5 分钟内交付；系统成功率 99%，超过预算或证据不足的任务必须以明确状态结束，不能静默超时。实现上把任务拆为可恢复的异步步骤，用并发上限保护模型供应商；同一份报告中的调研可以并行，但写作和最终合并保持串行。

成本估算要按步骤记账：调研、写作、审校、修订分别记录输入、输出、缓存命中、检索和重试费用。主管在计划阶段分配总预算，例如 2 元；调研阶段花到 60% 预算仍没有足够证据时，应该缩小问题或要求补充资料，而不是继续派更多 Agent。这样能同时说明容量、体验和成本为什么互相制约。

替代方案何时使用

低频、非实时的离线报告可以使用批处理队列和更长的完成窗口，以换取更低单价；需要边写边看的交互式任务，则先流式返回计划、已验证证据和草稿片段，但“最终结论”仍必须等待审校完成。

常见扣分点

• 只说“用消息队列扩容”，没有任务量、阶段数量和 SLO。
• 把所有步骤并行，导致草稿基于尚未验证的证据。
• 只统计模型单价，不计检索、重试和失败任务。

Q16：主管智能体的状态机和核心接口应该长什么样？

参考答案

主管不应把状态藏在一段自然语言里。我会定义显式状态：PLANNED -> RESEARCHING -> WRITING -> REVIEWING -> REVISING -> APPROVAL_PENDING -> PUBLISHED，并增加 BLOCKED、FAILED、CANCELLED、BUDGET_EXHAUSTED 等终止或暂停状态。每次状态迁移都带 task_id、attempt_id、配置版本、输入摘要、输出引用和原因码，确保后续能回放。

对下游 Agent 的接口采用结构化契约。例如调研 Agent 返回 claims[]，每条包括 claim、source_id、quote、retrieved_at、confidence 和 scope；审校 Agent 返回 issues[]，每条包括 severity、location、evidence_ids、suggested_action，而不是直接返回一篇改写后的全文。主管通过 POST /tasks/{id}/events 追加事件，通过 POST /tasks/{id}/artifacts 写不可变产物，再由一个 materialized view 生成当前任务状态。

这套设计的意义是把“Agent 说做完了”变成可验证的状态转移。写作只有拿到足够证据、且证据版本未失效时才能开始；审校通过不等于自动发布，必须走审批策略。即使模型的自然语言输出不稳定，平台边界也稳定。

替代方案何时使用

原型可以先用一张任务表加 JSON 状态，不必一上来建设事件溯源；但一旦任务有重试、人工介入、多 Agent 并发或合规审计，事件日志和不可变产物版本就很值得。

常见扣分点

• 只有“进行中/成功/失败”，无法表达等待人工确认或预算耗尽。
• Agent 之间用自由文本交接，无法自动校验字段。
• 覆盖原始输出，导致无法复盘哪个版本引入了错误。

Q17：多个 Agent 的通信协议怎样避免信息污染和重复劳动？

参考答案

我会区分三种通信内容：事实证据、任务命令和讨论性建议。事实证据写入共享证据库并附来源；任务命令由主管发出并带输入版本、deadline、预算和幂等键；讨论性建议只作为评论，不能直接改变最终产物。Agent 接收消息时只看到自己职责需要的最小上下文，例如写作 Agent 读已批准的 claim 和写作约束，不读调研过程中的全部网页噪声和其他 Agent 的思维记录。

为了避免两个调研 Agent 查同一个问题，主管先把问题拆成互斥子任务并登记 research_scope，如“法规原文”“竞品公开定价”“用户提供材料”。执行前按 task_id + scope + corpus_version 查去重表；已有新鲜结果时复用，结果过期或来源不足才重新执行。消息消费方以 event_id 去重，工具操作以 idempotency key 去重，避免网络重试后重复抓取、重复写入或重复发布。

此外，所有来自网页、邮件、附件的内容都标记为 untrusted_data。它们可以作为证据，但不能改变系统指令、角色权限和发布规则。这是通信设计中的安全边界，不是单靠提示词说一句“忽略恶意内容”。

替代方案何时使用

非常小的两三步流水线可以用同步函数调用和显式参数传递；跨机器、长任务、需要暂停恢复或人工接管时，采用持久化消息队列和事件表更可靠。

常见扣分点

• 给每个 Agent 全量聊天历史，既贵又容易被错误结论锚定。
• 只靠“请不要重复调研”防重。
• 把外部内容当作指令，让邮件或网页能驱动工具调用。

Q18：同一份文档必须多人或多 Agent 协同编辑时，具体怎样处理冲突？

参考答案

我会先尽量从流程上消灭冲突，而不是把冲突交给模型“聪明地合并”。产物拆成章节或区块，每个区块有明确 owner 和 base_revision：调研 Agent 只能新增证据卡片，写作 Agent 负责正文区块，审校 Agent 只能提交评论或结构化 patch，发布 Agent 才有最终写权限。真正的共享文档采用单写者队列，所有写请求都先转换为 patch。

一个 patch 至少包含 document_id、base_revision、target_anchor、operation、content、rationale、evidence_ids 和 author_agent。服务端做 optimistic concurrency control：当前 revision 与 base_revision 相同才自动应用；若不同，先判断 patch 影响的锚点是否不重叠。非重叠 patch 可以三方合并；同一段落或同一事实字段发生修改则进入 CONFLICT_PENDING，由主管基于证据优先级裁决，或展示 diff 给人工确认。任何自动合并后都重新跑事实引用、格式和敏感内容检查。

我不会让两个 Agent 同时直接保存整份 Markdown 或直接调用文件写工具，因为后写者会静默覆盖先写者。即便使用 Git，也不能只说“Git 会解决”：Git 只能发现文本冲突，不能判断哪个数字或结论是真的；事实冲突仍要回到 evidence 和 owner 规则。

替代方案何时使用

协同编辑产品可以用 CRDT 解决字符级并发和离线合并，但 CRDT 解决的是文本收敛，不解决语义、事实和责任冲突。报告类产物更适合“区块 owner + patch + 审批”；确实需要多人实时编辑时，再在 CRDT 之上叠加语义审校和发布门禁。

常见扣分点

• 只说加锁，没有锁的粒度、超时、续租和异常释放策略。
• 只说 Git merge，不说明如何裁决事实冲突。
• 审校 Agent 直接重写正文，导致写作与审校无限抢同一区块。

Q19：当 Agent 对结论、优先级或执行策略发生冲突时，谁来裁决？

参考答案

我要先区分冲突类型。事实冲突按来源质量、发布时间、适用范围和直接引用裁决；风格冲突按用户指定的风格 guide 裁决；资源冲突按任务 SLA 和预算优先级裁决；安全冲突采用保守原则，只要某个独立检查发现高风险，就升级人工或阻断发布。

主管的裁决不是“再找一个 Agent 投票”。我会把规则写成可执行 policy，例如：一手来源优先于二手转述，带原文引用优先于无引用摘要，更新更近但范围不同的证据并列展示，高风险断言至少需要两个独立且可追溯来源。若证据仍不足，最终文稿保留不确定性，写成“现有材料无法确认”，而不是通过多数表决生成看似确定的答案。

每次裁决输出 decision_id、候选方案、被采用证据、拒绝理由、裁决规则和审批人。这样下次同类冲突能复用 policy，也能统计哪些规则经常导致人工介入，从而改进任务拆分或数据源。

替代方案何时使用

低风险创意选题可以采用加权投票或由编辑偏好决定；法规、财务、医疗等事实性强的内容应采用证据门槛和人工升级，不能用投票替代验证。

常见扣分点

• “让主管 Agent 判断”但没有判断依据。
• 把模型置信度当作事实可信度。
• 没有记录裁决过程，线上争议无法复盘。

Q20：一个步骤超时、模型失败或人工迟迟不审批，怎么恢复？

参考答案

每个步骤都要有 deadline、重试策略和可恢复检查点。短暂的 429、网络超时可以指数退避重试，但要限制次数，并且重试使用同一个幂等键；模型返回结构化结果不合格时，先做一次格式修复或换同等级备用模型，不能无限让模型“再想一次”。工具有副作用时必须先查询结果或使用操作幂等键，确认没有成功才可重试。

恢复时从最近一个已落盘的成功 artifact 继续。例如调研已经完成、写作模型超时，就保留证据并重新排写作，不重复调研；审校失败可以回退到“待审校”并标出未经审校，不能把草稿伪装为最终稿。人工审批超过 SLA 后通知任务创建者并进入 APPROVAL_EXPIRED，默认不自动发布；用户取消任务后取消尚未开始的子任务，对已经在跑的任务设置 cancellation token，并把可能产生外部副作用的工具切断。

替代方案何时使用

对强一致的发布动作，可以采用事务性 outbox 和人工恢复队列；对纯只读调研，至少一次投递配合幂等写入通常足够，没必要为每个查询构建复杂事务。

常见扣分点

• 失败就“重试三次”，不区分可重试错误、业务错误和已执行副作用。
• 重启后从头开始，浪费成本并造成结果漂移。
• 审批超时后自动发布。

Q21：质量评估怎样覆盖“内容好不好”和“协作好不好”？

参考答案

我会把评估分成结果、过程和经济性三层。结果层看事实正确率、引用可追溯率、覆盖用户需求的完整率、风格符合率、风险遗漏率和人工最终修改量；过程层看计划拆分是否合理、重复调研率、冲突发现率、冲突裁决准确率、无效循环次数、人工介入率；经济性看单任务成本、每条被采纳结论成本、P50/P95 完成时间和缓存/证据复用率。

离线建立一组带标准证据的任务集，刻意包含资料不足、来源冲突、相互矛盾的编辑意见和同文件 patch 冲突。在线则抽样人工标注，结合发布后纠错率、用户采纳率和撤回率。上线前必须和单 Agent 基线做 A/B 或 shadow 对比：如果多 Agent 只增加成本，却没有降低事实错误、人工修改或高风险漏检，就应该收缩到单 Agent 加规则，而不是坚持“多 Agent 更先进”。

替代方案何时使用

早期没有标准答案时，可以先用成对人工偏好和专家抽检；任务规模稳定后，再逐步沉淀 golden set 和自动指标，避免一开始迷信 LLM-as-a-judge。

常见扣分点

• 只用“文笔好不好”作为指标。
• 只让另一个模型当裁判，没有人工校准。
• 不和单 Agent 对照，无法证明系统复杂度的价值。

Q22：怎样灰度上线，并防止错误内容大规模传播？

参考答案

上线顺序应从影子运行开始：先拿历史任务只生成结果，不影响用户，用于比较质量、成本和冲突率；再向内部编辑开放“只生成草稿”，所有发布都需人工确认；随后按租户、内容类型或低风险场景做小流量灰度。每次灰度固定 Agent 配置、模型版本、提示词版本和规则版本，避免同时改太多变量。

我会为发布设置硬门禁：证据覆盖不足、存在未解决高严重度审校问题、越过预算、触发安全策略、配置版本未通过评估时，一律不可自动发布。监控指标包括事实纠错率、人工拒绝率、发布后撤回率、P95 延迟、单位成稿成本和冲突待裁决积压量；任何一项超过阈值，立即停止扩大流量并回滚到上一个已验证的配置版本。回滚应回滚路由、提示词、Agent 图和发布策略，而不是试图删除已经发出的内容；对已发布内容则触发撤回、通知和人工复核流程。

替代方案何时使用

内部低风险知识整理可以加快到“草稿默认生成”；面向外部、法律或品牌敏感内容始终保留人工发布门，即使系统指标很好也不取消。

常见扣分点

• 一次性全量发布，只依赖事后投诉。
• 灰度只看接口成功率，不看事实与合规质量。
• 没有配置版本，发现问题后不知道该回滚什么。