AI Agent · 单位 U40（工具调用 + 工作流进阶：人机协同审批、多 agent 通信协议与工具限流配额）

本段主题：工具调用与工作流的进阶——人机协同（HITL）审批（审批队列吞吐、门控成本-收益、审批点设计、冗余审批风险）、多 agent 通信协议（协议设计、一致性冲突、多数投票正确率）、工具成本与限流配额（max-min 公平分配、限流治理）、以及多 agent + HITL 平台设计。 合规声明：不含具体交易信号、投资建议、内幕信息；不鼓励绕过风控/合规（HITL 审批正是合规控制的一环）。

题目编号：TRACK-03-U40-Q01

• 题型：笔试 ｜ 考点：人机协同审批 / 审批队列吞吐 / 所需审批人数
• 题干：一个 Agent 工作流设有 HITL 审批环节，每天需人工审批的请求为 200 条。每位审批人每小时可处理 10 条，每人每天有效工作 6 小时。(1) 求所需的最少审批人数；(2) 若请求量增长到 500 条/天，需要几人？(3) 分别给出两种情形下审批人的工作饱和度（利用率）。
• 假设与边界：审批请求均匀分布在工作时段内（不出现瞬时峰值的额外余量）；每人处理速率固定 10 条/小时；人数取整数且向上取整（不足则积压）；利用率 = 实际工作量 / 可用工时。
• 解析：
• 每人每天处理量 = 10 × 6 = 60 条。
• (1) 200/60 = 3.33 ⇒ 向上取整 4 人。利用率 = 200/(4×60) = 200/240 ≈ 83.3%。
• (2) 500/60 = 8.33 ⇒ 向上取整 9 人。利用率 = 500/(9×60) = 500/540 ≈ 92.6%。
• (3) 情形一 83.3%、情形二 92.6%。
• 参考答案：(1) 4 人（利用率 83.3%）；(2) 9 人（利用率 92.6%）；(3) 见上。
• 验算/自检：另一种解法（按工时反算）——(1) 所需工时 = 200/10 = 20 小时/天；每人 6 小时 ⇒ 20/6 = 3.33 ⇒ 4 人 ✅。(2) 500/10 = 50 小时/天；50/6 = 8.33 ⇒ 9 人 ✅。边界复算：当请求量恰为 240 条/天时，4 人恰好满负荷（利用率 100%）；241 条即需 5 人。说明"向上取整"在临界处会显著改变人数，实务中应留利用率上限（如 ≤85%）以免积压。
• 常见错误：用 floor 取整（3 人会积压）；忽略"有效工作 6 小时"（用 8 小时）；把利用率算成"人数比"而非工作量比。
• 评分要点：两问人数正确（4、9）；利用率可复算；说明"取整与利用率上限"的影响。
• 追问/变形/还能这样考：若审批请求有明显峰值（如集中在某时段），如何用排队论估算所需人数？当引入"高优先级请求插队"时吞吐如何变化？如何通过"分级审批（低风险自动放行）"降低人工量？

题目编号：TRACK-03-U40-Q02

• 题型：笔试 ｜ 考点：人机协同审批 / 门控成本-收益 / 触发审批的损失阈值
• 题干：Agent 执行"高影响操作"时的两个策略：不审批直接执行，或先过人工审批。人工审批成本折算 c = $0.5/次。操作本身有 10% 概率出错，出错造成的损失为 L = $3。人工审批能拦下错误操作的概率（检出率）d = 0.8（拦下则不执行、无损失，但仍计审批成本）。(1) 求"不审批"的期望总成本；(2) 求"审批"的期望总成本；(3) 求使"审批划算"的损失阈值 L*（即 L 多大时审批优于不审批）。
• 假设与边界：操作正确率 90%（出错率 10%）固定；审批检出错误的概率 d=0.8 独立于损失；审批未检出的错误照常执行并产生损失；审批成本与损失可加；单位统一为美元；不考虑审批引入的延迟。
• 解析：
• (1) 不审批期望成本 = 0.1 × 3 = $0.3。
• (2) 审批期望成本 = c + 0.1×(1−d)×L = 0.5 + 0.1×0.2×3 = 0.5 + 0.06 = $0.56。
• (3) 审批优于不审批的条件：c + 0.1×(1−d)×L < 0.1×L ⇒ 0.5 + 0.02L < 0.1L ⇒ 0.5 < 0.08L ⇒ L > 6.25。
• 参考答案：(1) $0.3；(2) $0.56；(3) L > $6.25 时审批划算（L* = $6.25）。
• 验算/自检：另一种解法（临界代入）——L = 6.25：不审批 = 0.1×6.25 = $0.625；审批 = 0.5 + 0.02×6.25 = 0.5 + 0.125 = $0.625，两者相等 ✅。边界复算：L = 10（高风险）⇒ 不审批 $1.0、审批 0.5+0.2 = $0.7 ⇒ 审批更优；L = 1（低风险）⇒ 不审批 $0.1、审批 0.5+0.02 = $0.52 ⇒ 不审批更优。说明"按损失大小分级触发审批"是合理设计。
• 常见错误：忘记审批本身有成本 c（把审批当"免费保险"）；把检出率用反（漏检率应为 1−0.8=0.2）；把"拦下即无损失"漏掉；忽略阈值比较而直接说"审批总是更安全"（安全≠更优成本）。
• 评分要点：两策略期望成本正确；阈值 L* = 6.25 可复算；给出"按损失分级触发"的设计结论。
• 追问/变形/还能这样考：若审批检出率随操作复杂度下降，阈值如何变？当"漏检"的下游损失有溢出（如触发连锁）时，是否应提高 d 或强制审批？如何把"审批成本"用审批人时薪与占用时长更精细地折算（衔接 Q01）？

题目编号：TRACK-03-U40-Q03

• 题型：笔试 ｜ 考点：工具限流配额 / max-min 公平分配 / 等比缩减对比
• 题干：某工具 API 的总 QPS 配额为 100，3 个团队的需求分别为 T1 = 80、T2 = 40、T3 = 30 QPS（总需求 150，超配额）。(1) 按"最大最小公平"（progressive filling）分配，求各团队配额；(2) 按"按需求等比缩减"分配，求各团队配额；(3) 比较两种方案对需求最小团队 T3 的影响，并说明各自适用场景。
• 假设与边界：配额可无限细分（连续）；总配额 100 必须用尽或不超；max-min 公平：先满足需求最小者、剩余在未满足者间平均分；等比缩减：各团队按同一系数 α 缩放到总和 = 100；不考虑分配随时间变化。
• 解析：
• (1) max-min：初始平均 = 100/3 ≈ 33.33。T3 需求 30 ≤ 33.33 ⇒ T3 满额 30，剩余 100 − 30 = 70 在 T1、T2 间平均 = 35 各。T2 需求 40 > 35 ⇒ 维持 35；T1 需求 80 > 35 ⇒ 维持 35。结果：T1 = 35、T2 = 35、T3 = 30（合计 100）。
• (2) 等比缩减：系数 α = 100/150 = 2/3。T1 = 80×2/3 ≈ 53.33；T2 = 40×2/3 ≈ 26.67；T3 = 30×2/3 = 20（合计 100）。
• (3) 对 T3：max-min 给 30（其需求被完全满足），等比缩放只给 20（被砍 1/3）。max-min 保护"小需求者"（满足其全部需求后再分剩余），适合"保障基本配额、尾部小团队不被饿死"；等比削减按需求比例公平缩水，适合"大团队应有更大份额、按贡献/需求比例分配"的场景。
• 参考答案：(1) T1 = 35、T2 = 35、T3 = 30；(2) T1 ≈ 53.33、T2 ≈ 26.67、T3 = 20；(3) max-min 保护 T3（给足 30），等比削减砍至 20；max-min 适合保基本配额，等比适合按需求比例分配。
• 验算/自检：另一种解法（一致性核对）——(1) 合计 35+35+30 = 100 ✅；且任何 T1/T2 再增、T3 不减则超 100，故为 max-min 解。(2) 合计 53.33+26.67+20 = 100 ✅，且三者缩放系数一致（都乘 2/3）。边界复算：若总配额升到 150，max-min 与等比结果都等于原需求（无约束）；若配额降到 30，max-min = 10/10/10（三者均低于需求 30/40/80 中最小者）——此时退化为平均分配。
• 常见错误：max-min 直接把 100 三等分（忽略 T3 需求仅 30）；等比缩减漏乘系数或系数算错；把两者混用导致总配额不为 100；认为 max-min 一定让大团队吃亏（其实在满足小需求后大团队仍可能得更多份额）。
• 评分要点：max-min 的 progressive filling 过程正确；等比缩减系数 2/3 正确；比较与适用场景清晰。
• 追问/变形/还能这样考：当需求随时间波动时如何做动态公平分配？如何用"加权 max-min"体现不同团队优先级？当配额必须"按 token 消耗而非请求数"分配时，公式如何调整？

题目编号：TRACK-03-U40-Q04

• 题型：面试 ｜ 考点：人机协同审批 / 审批点设计 / 触发条件与交互形态
• 题干：请为一个投研辅助 Agent 设计 HITL（人机协同）审批机制：哪些操作需要审批、如何触发、审批界面应提供什么信息、如何避免审批成为瓶颈、以及如何审计审批过程。（本类为思路题，无唯一答案，考察思路；HITL 亦为合规控制手段。）
• 假设与边界：面向工程与合规；操作含"只读查询""数据写入""触发昂贵计算/对外动作"等；不涉具体监管细节；强调"人在关键节点、而非事事审批"。
• 解析：需审批的操作——按"影响面 × 可逆性"分级：不可逆/高影响（对外发布、触发大额资源消耗、写入共享状态、越过数据权限边界）必须审批；低影响/可逆（只读检索、本地草稿）自动执行。触发方式——风险阈值触发（如预估成本 > X、置信度 < Y、涉及受限数据）、规则触发（命中敏感操作清单）、异常触发（校验/一致性检查告警时升级）。审批界面——给出"将要做什么（动作 + 参数）""为什么（依据/来源）""可能影响（成本/范围/风险）""可选项（批准/拒绝/修改/降级）"，并附证据链（衔接 U21 溯源）。避免瓶颈——分级（低风险免审）、批量审批同类请求、设置超时默认策略（超时拒/超时降级为安全动作）、异步审批（不阻塞其他流程）、审批人扩容（衔接 Q01）。审计——记录"谁在何时批准/拒绝了什么、依据、当时上下文"，可复现可追责。
• 参考答案：要点：① 按"影响面×可逆性"分级决定是否审批；② 触发：风险阈值/规则/异常升级；③ 界面给"动作+依据+影响+选项+证据链"；④ 防瓶颈：分级免审、批处理、超时默认安全、异步、扩容；⑤ 审批全程可审计可追责。
• 验算/自检：自检——构造三类操作（只读查询/写共享库/触发昂贵计算）验证分别走"免审/审批/审批 + 成本确认"；构造"超时未审"场景，验证按预设默认策略（如安全默认=拒绝或降级）收敛而非无限等待。边界：当审批人不在线且流程可等待时，应持久化为 pending 而非丢弃；当同一请求反复被拒时，应触发流程级熔断而非无限重试审批。
• 常见错误：所有操作都审批（沦为瓶颈）；无超时默认策略（流程卡死）；审批界面信息不足导致"盲批"；审批不留痕（无法追责/复现）；把审批当形式（无人真正看证据）。
• 评分要点：分级审批原则；触发条件多类型；界面信息完整（含证据链）；防瓶颈措施；审计留痕。
• 追问/变形/还能这样考：如何用"分级 + 置信度校准"把审批量降到最小又不漏高风险（衔接 Q02 的阈值）？当审批涉及多角色（业务/风控）时如何设计会签与责任划分？如何度量"审批机制的净收益"（拦住的风险 vs 增加的延迟成本）？

题目编号：TRACK-03-U40-Q05

• 题型：面试 ｜ 考点：多 agent 通信协议 / 消息格式与语义 / 协议设计
• 题干：一个投研辅助系统由多个 Agent 协作（如"检索 Agent""计算 Agent""校验 Agent""汇总 Agent"）。请设计它们之间的通信协议：消息格式、语义（请求/响应/事件/流式）、寻址与路由、版本与兼容、失败与超时处理。（本类为思路题，无唯一答案，考察思路。）
• 假设与边界：面向工程；Agent 可能异构（不同模型/语言）；不涉具体产品；强调可扩展、可观测、可追溯；不鼓励绕过风控。
• 解析：消息格式——统一信封（envelope）：{消息 id、会话/任务 id、发送者、接收者、类型、时间戳、版本、载荷（结构化 schema，衔接 U37 契约）、可选追踪 id}。语义——四类：请求（带期望响应）/响应（关联请求 id）/事件（广播状态变更，无需应答）/流式（分块增量，需序号与结束标记）；明确幂等与去重（衔接 U39）。寻址与路由——按角色/能力寻址（能力注册表）而非硬编码地址；支持点对点、广播、请求-应答、发布-订阅；路由层负责负载均衡与重试。版本与兼容——信封带协议版本，载荷用 schema 版本（加性优先、破坏性升主版本，衔接 U37）；未知字段宽容、必填严格。失败与超时——每条请求带 deadline；超时/失败返回结构化错误（错误码 + 可重试标记）；对不可达 Agent 走降级或改派；避免"请求-响应"无限等待。可观测——追踪 id 贯穿，便于跨 Agent 追踪（衔接 U22）。
• 参考答案：要点：① 统一信封 + 结构化载荷 + 追踪 id；② 四类语义（请求/响应/事件/流式）并定义幂等与去重；③ 按能力寻址 + 多路由模式；④ 版本与兼容（加性优先/破坏性并行）；⑤ deadline + 结构化错误 + 降级改派；⑥ 全链路可观测。
• 验算/自检：自检——构造"请求超时"用例，验证返回结构化错误且不永久挂起；构造"事件广播重复到达"用例，验证订阅方去重；构造"新增协议字段"用例，验证旧 Agent 忽略未知字段不报错。边界：当接收方不可达时，路由应重试或改派而非丢弃请求；当流式消息乱序到达时，靠序号重排并在结束标记处确认完整。
• 常见错误：无统一信封导致解析各异；请求无 deadline（挂起）；事件与请求语义混淆（事件被当应答等待）；版本无序导致升级即崩；无追踪 id 导致跨 Agent 排障困难。
• 评分要点：信封 + 结构化载荷 + 追踪 id；四类语义与幂等；按能力寻址与路由；版本兼容；deadline 与错误处理。
• 追问/变形/还能这样考：如何用"能力注册与发现"解耦 Agent 部署？当需要在 Agent 间传递"引用/大对象"时，传值还是传引用（衔接沙箱的受控通道）？如何对协议流量做限流与配额（衔接 Q07）？

题目编号：TRACK-03-U40-Q06

• 题型：面试 ｜ 考点：多 agent 通信协议 / 一致性与冲突解决 / 共识与冲突处理
• 题干：多个 Agent 可能对同一问题给出冲突的结论或对共享状态做出并发修改。请设计"一致性保障与冲突解决"方案：如何组织多 Agent 的协作（是否引入协调者）、如何处理结论冲突与并发写、如何在分布式下达成一致，以及如何避免"死锁/活锁/脑裂"。（本类为思路题，无唯一答案，考察思路。）
• 假设与边界：面向工程；Agent 无共享内存、通过网络通信；可能出现消息乱序/丢失/重复；不涉具体共识算法细节；强调可终止、可审计。
• 解析：协作组织——可引入① 协调者/编排者（orchestrator）由中心 Agent 分派与汇聚（简单、易控，但有单点）；或② 对等协商（peer-to-peer）各 Agent 通过协议达成一致（弹性好、复杂）。结论冲突处理——多 Agent 输出冲突时：① 投票/多数决（衔接 Q09）；② 加权（按各 Agent 可信度/历史准确率，衔接 U37-Q07）；③ 引入仲裁者（专门 Agent 或人工）；④ 保留分歧并输出候选集合交下游。并发写处理——对共享状态用乐观并发（版本号/ETag，冲突则重试或合并）或悲观锁（租约），并保证幂等（衔接 U39）；避免"最后写入获胜"掩盖冲突。一致性与容错——对需要强一致的决策用单一权威源/协调者；对可最终一致的用事件传播 + 对账修复；避免"死锁"（统一加锁顺序/超时释放）、"活锁"（重试加随机退避）、"脑裂"（用租约/多数派防双主）。
• 参考答案：要点：① 协调者式 vs 对等式，明确取舍；② 冲突处理：投票/加权/仲裁/保留分歧；③ 并发写：乐观版本控制或租约 + 幂等；④ 强一致走权威源、最终一致走事件 + 对账；⑤ 防死锁（锁序/超时）、活锁（随机退避）、脑裂（租约/多数派）。
• 验算/自检：自检——构造"两 Agent 并发写同一字段"用例：验证乐观版本控制下冲突被检测并重试/合并，而非静默覆盖；构造"两个协调者同时存在"用例：验证租约/多数派能阻止双主。边界：当仲裁者本身不可用时，应降级为"保留分歧 + 人工介入"而非强行选一个；当冲突长期无法消解时，应触发流程级熔断。
• 常见错误：用"最后写入获胜"处理冲突（掩盖问题）；并发写无版本控制（丢更新）；无租约/多数派导致脑裂；重试无退避导致活锁；把对等式协作直接用于强一致需求。
• 评分要点：协作组织取舍；冲突处理四策；并发写版本控制/幂等；强/最终一致的适用范围；防死锁/活锁/脑裂。
• 追问/变形/还能这样考：如何在多 Agent 下实现"可解释的共识"（记录每个 Agent 的投票与理由）？当 Agent 数量大时，如何降低两两通信的复杂度（分层/总线）？如何把冲突解决与人工仲裁、审计结合（衔接 HITL）？

题目编号：TRACK-03-U40-Q07

• 题型：面试 ｜ 考点：工具成本与限流 / 限流与配额治理 / 令牌桶-熔断-降级
• 题干：Agent 调用大量外部工具，需要控制成本并遵守下游限流。请设计"工具成本与限流治理"方案：如何建模成本、如何做限流与配额、过载/超预算时如何降级、如何告警与追溯。（本类为思路题，无唯一答案，考察思路。）
• 假设与边界：面向工程；工具可能是付费 API（按调用/token 计费）、有 QPS/RPM 限制；不涉具体云厂商定价；强调"既不超支也不雪崩"；不鼓励绕过限流。
• 解析：成本建模——每次调用记录"工具、调用量、单价、缓存命中、归属任务"（衔接 U25 成本审计的口径），按任务/团队/工具聚合出单位成本；设"成本预算"（每日/每任务）。限流与配额——令牌桶（容量控制突发、速率控制稳态）控制对外 QPS/RPM；按团队/工具做配额分配（衔接 Q03 的公平分配）；对昂贵工具设独立预算池。降级——过载/超预算时的策略：① 降级到更便宜的工具/缓存/历史值（须标注，衔接 U36-Q05）；② 采样（只处理高优先级请求）；③ 队列化/延后（非实时任务）；④ 熔断下游持续失败的调用以保护整体。告警与追溯——对"接近配额/预算""异常成本尖峰""限流命中率升高"告警；用 trace 追溯成本到任务级（衔接 U22）。权衡——配额越严越不易超支但可能饿死合法需求；缓存/降级省成本但引入陈旧值风险；熔断保护系统但降低可用性。
• 参考答案：要点：① 成本建模到"任务/团队/工具"并设预算；② 令牌桶限流 + 按团队/工具配额（公平分配）；③ 过载/超预算降级（降级工具/采样/延后/熔断）；④ 告警（配额/预算/尖峰）与 trace 追溯；⑤ 明确"严格配额 vs 可用性"等权衡。
• 验算/自检：自检——构造"某团队瞬时突发"用例：验证令牌桶吸收突发、超过容量则排队/拒绝而非打爆下游；构造"接近日预算"用例：验证自动降级并在预算耗尽时拒绝昂贵调用、保留廉价调用。边界：当下游限流被触发且客户端重试时，应改为退避 + 降采样而非持续加压（避免重试风暴）；当缓存/降级值过旧时应标记并要求刷新。
• 常见错误：只限流不控成本（或反之）；无按团队配额导致个别团队吃掉全部额度；过载时无脑重试（放大下游压力）；降级后不标注时点；成本无 trace 无法追溯。
• 评分要点：成本建模与预算；令牌桶 + 配额；过载/超预算降级四策；告警与追溯；权衡。
• 追问/变形/还能这样考：如何用"自适应并发（AIMD）"在未知下游容量下逼近其限流线？当成本以 token 计（非调用数）时，令牌桶参数如何换算？如何把"成本超支"与"人工审批"挂钩（超预算的高影响调用走 HITL）？

题目编号：TRACK-03-U40-Q08

• 题型：逻辑概率 ｜ 考点：人机协同审批 / 冗余审批的风险与误拒 / 会签与放行规则
• 题干：某敏感操作由 2 名审批人独立复核。对"有风险"的操作，单个审批人误放行的概率 e = 0.15（独立）；对"无风险"的操作，单个审批人误拒的概率 f = 0.10（独立）。(1) 采用会签规则"两人都放行才执行"，求有风险操作被误放行的概率；(2) 同一会签规则（等价说法："任一人拒绝即拒绝"）下，求无风险操作被误拒的概率；(3) 若改为或签规则"任一人放行即执行"，求有风险操作被误放行的概率。
• 假设与边界：两名审批人判断相互独立；"误放行"= 有风险却通过了该审批人；"误拒"= 无风险却被该审批人拒绝；题中规则下：会签=全部放行才执行；或签=任一放行即执行；不涉审批顺序与信息共享。
• 解析：
• (1) "都放行才执行" ⇒ 有风险被误放行需两人都误放行：e² = 0.15² = 0.0225。
• (2) "任一人拒绝即拒绝" ⇒ 无风险被误拒 = 至少一人误拒：1 − (1−f)² = 1 − 0.9² = 1 − 0.81 = 0.19。
• (3) "任一人放行即执行" ⇒ 有风险被误放行 = 至少一人误放行：1 − (1−e)² = 1 − 0.85² = 1 − 0.7225 = 0.2775。
• 参考答案：(1) 0.0225；(2) 0.19；(3) 0.2775。
• 验算/自检：另一种解法（补事件）——(1) 至少一人拦下的概率 = 1 − e² = 1 − 0.0225 = 0.9775 ⇒ 误放行 0.0225 ✅。(3) 两人都拦下的概率 = (1−e)² = 0.7225 ⇒ 被误放行 = 1 − 0.7225 = 0.2775 ✅。边界复算：e=0.15 时，会签把误放行从单人 0.15 降到 0.0225（降 85%），但 (2) 的误拒从单人 0.10 升到 0.19（升 90%）——说明会签"降低误放行但抬高误拒"，是典型权衡；若 e 很小（如 0.01），会签误放行仅 1e-4。
• 常见错误：把"都放行"算成 1−(1−e)²（那是"任一放行"）；混淆会签（AND）与或签（OR）；把误放行与误拒的规则用反；忽略独立性假设。
• 评分要点：三问数值正确；区分会签/或签；指出"误放行↓则误拒↑"的权衡关系。
• 追问/变形/还能这样考：若两审批人判断相关（共谋或共享同一信息），公式如何失效、需要什么？3 人"多数放行"的误放行概率如何算？如何按操作风险等级动态选择会签/或签（高风险会签、低风险或签）？

题目编号：TRACK-03-U40-Q09

• 题型：逻辑概率 ｜ 考点：多 agent 通信协议 / 多数投票正确率 / Condorcet 与阈值反解
• 题干：由多个 Agent 独立判断同一问题，各自正确率均为 p，多数投票决定最终结论。(1) 3 个 Agent、p = 0.7 时，多数（≥2 票）正确率是多少？(2) 5 个 Agent、p = 0.7 时多数（≥3 票）正确率是多少？(3) 保持 3 个 Agent，要使多数正确率 ≥ 0.95，单个 Agent 正确率 p 至少需多少？(4) 引用 Condorcet 陪审团定理，说明 p 与 0.5 的关系对"增加 Agent 数"的影响。
• 假设与边界：各 Agent 判断相互独立，各自正确概率同为 p；多数票（严格过半数）决定；Agent 数取奇数以避免平票；(3) 用 3 人多数公式反解；(4) 引用 Condorcet 陪审团定理：p>0.5 时增加 Agent 数使多数正确率升向 1，p<0.5 时趋于 0，p=0.5 时恒为 0.5。
• 解析：
• (1) 3 人多数正确率 = P(≥2 正确) = C(3,2)p²(1−p) + p³ = 3×0.49×0.3 + 0.343 = 0.441 + 0.343 = 0.784。
• (2) 5 人多数正确率 = P(≥3 正确) = C(5,3)p³(1−p)² + C(5,4)p⁴(1−p) + p⁵。 各项：C(5,3)×0.343×0.09 = 10×0.03087 = 0.3087；C(5,4)×0.2401×0.3 = 5×0.07203 = 0.36015；p⁵ = 0.16807。 合计 = 0.3087 + 0.36015 + 0.16807 = 0.83692。
• (3) 3 人多数公式：M(p) = 3p² − 2p³。令 M(p) = 0.95 ⇒ 3p² − 2p³ = 0.95。试探：p = 0.865 ⇒ 3×0.748225 − 2×0.647215 = 2.244675 − 1.294430 = 0.950245 ≈ 0.95 ⇒ p ≈ 0.865。
• (4) Condorcet：p>0.5 时，Agent 越多多数越可靠（升向 1）；p<0.5 时，Agent 越多多数越不可靠（趋于 0）——即"个体优于随机才值得靠投票聚合"。
• 参考答案：(1) 0.784；(2) ≈ 0.8369；(3) p ≈ 0.865；(4) p>0.5 时加 Agent 提升、p<0.5 时加 Agent 反而恶化。
• 验算/自检：另一种解法（补事件）——(1) P(≥2) = 1 − P(0) − P(1) = 1 − 0.3³ − 3×0.7×0.3² = 1 − 0.027 − 0.189 = 0.784 ✅。(2) 1 − P(0,1,2) = 1 − [0.3⁵ + 5×0.7×0.3⁴ + 10×0.49×0.3³] = 1 − [0.00243 + 0.02835 + 0.1323] = 1 − 0.16308 = 0.83692 ✅。边界复算：(3) p = 0.86 ⇒ 3×0.7396 − 2×0.636056 = 2.2188 − 1.272112 = 0.946688 < 0.95；p = 0.87 ⇒ 3×0.7569 − 2×0.658503 = 2.2707 − 1.317006 = 0.953694 > 0.95 ⇒ 临界在 0.86–0.87 之间，与 0.865 一致。
• 常见错误：把多数正确率算成"平均 p"或"简单相加"；忽略组合数；p<0.5 时误以为"多投票总能提升"；把"≥2/3"与"恰好 2/3"混淆。
• 评分要点：两问数值正确；3 人公式反解 p≈0.865；能引用 p 与 0.5 的关系说明"加 Agent 的收益方向"。
• 追问/变形/还能这样考：若各 Agent 正确率不同（异质），多数正确率如何用生成函数计算？当 Agent 间存在相关性（共享训练数据）时，独立性假设破坏后结论如何变？如何用"加权投票"（按可信度赋权）改进多数投票？

题目编号：TRACK-03-U40-Q10

• 题型：扩展延伸 ｜ 考点：多 agent 通信协议 / 多 agent + HITL 平台设计 / 容量-失败模式-权衡
• 题干：为投研辅助平台设计"多 Agent 协作 + 人工审批"的一体化平台：多个专业 Agent（检索/计算/校验/汇总）协作完成任务，关键节点插入 HITL 审批。请给出系统设计：容量估算、通信与状态、失败模式与对策、以及核心权衡。假设日活任务 10000 个，每个任务平均触发 6 次 Agent 间消息往返、2 次工具调用，峰值 QPS 为均值的 5 倍；其中 5% 的任务需要人工审批。（本类为设计题，无唯一答案，考察思路；不含具体交易信号；HITL 为合规控制手段。）
• 假设与边界：面向工程与合规；Agent 异构、网络通信；不涉具体产品；强调可扩展、可观测、可审计、可恢复；不鼓励绕过风控。
• 解析：
• 容量估算：日均任务 10000，均值消息往返 6 次 + 工具 2 次 ⇒ 日均消息量 ≈ 10000×(6 + 2) = 80000 条（按往返计，下同）。摊到 24 小时均值 ≈ 80000/86400 ≈ 0.93 条/s；峰值取 5 倍 ≈ 4.6 条/s。若进一步假定活动集中在 8 小时（28800s）：均值 ≈ 80000/28800 ≈ 2.78 条/s，峰值 5 倍 ≈ 13.9 条/s。容量设计按峰值留余量（如 3×），消息总线与 Agent 工作池按 ~40 条/s 设计。人工审批量：10000×5% = 500 个/日，按 Q01 方法（每人 60 条/日）需 ≈ 9 人（500/60≈8.33 ⇒ 9）。
• 通信与状态：统一信封 + 追踪 id（衔接 Q05）；任务状态持久化（事件日志 + 快照，衔接 U39）；幂等键去重（衔接 U39）；审批节点持久化为 pending（衔接 Q04）。
• 失败模式与对策：① Agent 超时/不可达 → deadline + 重试/改派 + 降级（衔接 U36）；② 消息重复/乱序 → 幂等去重 + 序号重排；③ 结论冲突 → 投票/加权/仲裁（衔接 Q06/Q09）；④ 审批积压 → 分级免审 + 异步 + 扩容（衔接 Q01/Q04）；⑤ 审批超时 → 默认安全策略（拒绝/降级）收敛；⑥ 工具限流/超预算 → 令牌桶 + 配额 + 降级（衔接 Q07）；⑦ 编排单点 → 多实例 + 租约防脑裂；⑧ 状态不一致 → 对账修复。
• 权衡：Agent 数量↑协作能力↑但通信复杂度与冲突概率↑（注意 p>0.5 才值得聚合，衔接 Q09）；严格审批↑安全但增延迟与人工成本（衔接 Q02）；强一致↑可靠但吞吐受限；消息总线集中↑易管理但可能单点。
• 参考答案：要点：① 容量估算（消息 ~14 条/s 峰值、审批 ~500/日需 ~9 人）；② 统一信封 + 追踪 id + 状态持久化 + 幂等；③ 八类失败模式与对策；④ 权衡（Agent 数-冲突、审批-延迟、一致-吞吐）；⑤ 可观测/可审计/可恢复贯穿。
• 验算/自检：自检——用 Little 定律/流量折算交叉核对容量：若每任务消息数降到 4 次，则日均消息 = 10000×(4+2) = 60000，峰值（8h、5×）≈ 10.4 条/s，验证"可下调总线容量"。构造"某任务在第 4 次消息后失败"用例：验证状态恢复 + 幂等重入不重复副作用、不重复审批。边界：当某 Agent 持续失败时，应改派或降级而非阻塞整任务；当审批长期无人处理时，按默认安全策略收敛（不无限挂起）；当协调者主备切换时，租约保证单主。
• 常见错误：按均值容量备总线/工作池（忽略峰值集中）；消息无幂等导致重入时重复动作；审批无超时默认导致任务永久 pending；Agent 越多越好（忽略 p<0.5 时聚合恶化与冲突成本）；无追踪 id 导致跨 Agent 无法排障。
• 评分要点：容量估算（消息与审批）；通信协议 + 状态持久化 + 幂等；至少 6 类失败模式与对策；明确权衡；可观测/审计/恢复贯穿。
• 追问/变形/还能这样考：如何用"能力注册 + 动态路由"支持 Agent 弹性扩缩？当引入"Agent 自评置信度"时，如何用它决定是否升级到人工审批（自适应 HITL）？如何设计"协作 + 审批 + 补偿"统一为一个可审计的长流程状态机（衔接 U39 与 Saga）？