模式矩阵 /模式白皮书/R5

R5 · Talker-Reasoner · 双模架构

它解决什么问题

很多推理模式默认了一个不该默认的前提——用户能等。给 Agent 时间想清楚 24 秒，在异步任务里没问题，但在实时交互场景里是灾难：对话场景 200 毫秒不回话用户就掉线，voice agent 1 秒沉默就尴尬，实时协作 3 秒没反应就打断节奏。问题的核心不是 Agent 想得慢，而是它在想的时候什么都不说——用户不介意 Agent 用 24 秒思考，介意的是 24 秒里 Agent 一片静默。

Talker-Reasoner 把"实时响应"和"深度推理"两种相互冲突的目标拆到两个 Agent 上。一个 Talker 永远在 200 毫秒内回应、保持对话流畅，一个 Reasoner 在后台慢慢做深度分析，两者通过共享 belief state 协同。它要的不是更高的质量，而是把延迟从用户感知里藏起来——同样的思考时间，体验天差地别。它对前端的实时约束和后端的深思约束同时满足。

为什么坐标是「推理 × 分层」

• 纵轴 · 推理：它把"实时响应"和"深度推理"两种 reasoning modality 分开，是一个双系统的推理架构——对应 Kahneman 的 System 1（快、自动、低耗）和 System 2（慢、刻意、高耗）。这是认知科学在 Agent 上的工程映射，不是单一推理通道。
• 横轴 · 分层：Talker 在前（快、浅）、Reasoner 在后（慢、深），是分层分工而不是 parallel 竞争。两者职责不同、模型不同、时机不同，Reasoner 的输出通过 belief 影响 Talker 的回答，是上下层协作关系。

核心机制

一次双模协同由三段组成：

1. Talker 即时响应：用便宜快模型，看到用户输入立刻回（200-800ms），保持对话流畅、回应情绪、问澄清问题。它的 system prompt 有一条硬约束——不要给具体建议，那是 Reasoner 的事。Talker 处理绝大多数对话轮次。
2. Reasoner 异步深思：用贵的慢模型，被触发后在后台跑深度分析（10-30s），跑完把结构化结论写到共享 belief state。它不阻塞对话。
3. belief state 协同 + 自然过桥：两个 Agent 通过一份共享 state 通信，写要加锁避免 race condition。Reasoner 跑完后，Talker 在下一轮对话里找一个自然时机把分析织进回答，而不是突然蹦出一段结论。

用户输入在 Reasoner 还在跑时怎么处理，有三种姿态可选：QUEUE（排队等 Reasoner 跑完，适合任务场景）、INTERRUPT（立即打断重跑，适合短任务 explore）、PARALLEL（两个 Agent 真并行，Talker 即时回 Reasoner 后台跑，对话场景必须用这个）。把三种做成 config 让产品按场景选，是工业级框架该有的姿态。

适合的生产场景

• 实时对话：教育辅导、客服、个人助手——前端要 200 毫秒级响应，后端又要深度个性化分析，单 Agent 满足不了双约束。
• Voice agent：电话、语音助手，1 秒沉默就尴尬，必须边说边想。
• 需要边聊边收集信息的咨询场景：Talker 跟用户聊倾向、问 follow-up 的同时，Reasoner 在后台基于已有信息做匹配分析,聊完分析也好了。

容易出错的地方

• Talker 自作聪明猜答案：Talker prompt 没把"不要给具体建议"约束死，它就抢着给结论，跟 Reasoner 的深度分析冲突，Reasoner 白跑。这是双模最常见的失败模式。
• Reasoner 没有 timeout 和 cancel：后台任务跑飞了没人管，或者用户中途换话题了 Reasoner 还在跑旧问题，浪费算力。要做 30 秒强制结束加用户换话题时主动 cancel。
• belief state 不跨 session 持久化：用户下次回来 Talker 又从零开始，上次 Reasoner 的分析全丢了。要持久化到 Redis / PostgreSQL。
• 过桥生硬：Reasoner 跑完直接"突然蹦出一段分析"，用户觉得突兀。要靠 prompt 让 Talker 找对话上的自然时机插入。
• 异步任务场景硬上双模：用户提交任务就离开的场景（写文档、批处理），不需要 Talker，直接让 Reasoner 慢慢跑就行，加 Talker 是过度工程。

关键指标

• Talker 响应延迟 p99（健康区 <800ms）：Talker 从收到输入到回话的时间。超过就失去了双模的意义，用户照样感到卡顿。
• Talker 越界率（健康区 <5%）：抽样 Talker 回答里"在给具体建议"的比例。偏高说明 Talker prompt 没约束住，Reasoner 的深度分析被浪费。
• belief 命中率（健康区接近 100%）：用户回到会话时 Talker 能基于上次 belief 给个性化回应的比例。低说明 belief state 没持久化或没读到。
• 单 turn 成本（注意结构）：双模是"两档同时跑"，单 turn 成本比单档贵档还略高（多了 Talker 那部分），但换来延迟大降——这是 cost-latency-quality 三角的另一种 Pareto 选择，要按业务接受度评估。

最小骨架

用户说话 →
    若是首轮：建 belief state，异步触发 Reasoner（非阻塞）
    Talker 立即回应（便宜模型，200-800ms，不给具体建议）
    若 Reasoner 已跑完（belief 状态 = updated）→ Talker 把分析自然织进回应
Reasoner 后台（贵模型，10-30s）：
    深度分析 → 写 belief state（结构化结论 + 建议）
    带 timeout（30s 强制结束）+ cancel（用户换话题时取消）
belief state：跨 session 持久化，写操作加锁
返回 Talker 回应 + 后台维护的 belief

落地四个要点：Talker prompt 把"不给具体建议"约束死；Reasoner 异步任务做 timeout 和 cancel；belief state 持久化到 Redis 跨 session 复用；共享 state 写操作加锁防 race condition。

企业落地一例

某留学申请咨询 Agent，给中国学生辅助选校和文书润色。第一版上线两周收到一类反馈："我问它两所学校哪个更适合我，它停了 30 多秒才回，我以为网络挂了就关掉重问。" 团队复盘发现 Agent 不慢，是思考路径太完整——用户问完，Agent 老实走完整链：取用户画像（800ms）、比对两校特点（1.2s）、跑深度分析（18s）、综合写回答（4s），总共 24 秒一个高质量回答。但 24 秒对对话场景是无限长，用户体验崩盘。第三周加了"正在分析"的 loading 提示，用户还是抱怨"看着转圈就走了"。

第四周彻底重写成 Talker + Reasoner：用户问完，Talker 在 200 毫秒内立刻回应，先快速点出两校核心差异、同时告诉用户"我在后台为你做详细匹配分析"、并反问用户倾向（留美工作还是回国）。用户跟 Talker 聊倾向的十几秒里，Reasoner 在后台跑完了结合 GPA、科研经历、兴趣方向的详细分析，把结论写进 belief state。Talker 在下一轮自然过桥："听到你倾向硅谷工作,那我刚跑完的分析显示……"。同样的 24 秒思考时间，体验从"卡死"变成"边聊边收到分析"。同类的在线编程辅导 Agent 用这套架构（Talker 用便宜模型对话、Reasoner 用贵模型异步分析、PARALLEL 模式、belief 跨 session 持久化、自然过桥、师生双视图 trace），上线第二月学生 NPS 从 6 升到 8.5，教师对 Agent 推荐的 override 率从 35% 降到 12%。

与其他模式的关系

• 复杂度路由（R2）：双模是路由的架构极致。普通路由是"选一档跑"（单时间点决策），双模是"两档同时跑"（双时间维度决策），把"选档"推到了"拆 Agent"。
• 迭代假设验证（R4）：同在循环列。迭代是单 Agent 跟自己循环验证假设，双模是双 Agent 协同分处理"说"和"想"。
• 思维链（R1）：Reasoner 那一侧的深度推理本质就是一条完整思维链，Talker 那一侧刻意不做深推理。
• 分层记忆模式：belief state 跨 session 持久化，和记忆模块"User 层 belief 持久化"是同源思路。

一句话记住它

Talker-Reasoner 的本质不是性能优化，而是把 Agent 的人格拆成两个——一个处理实时、一个处理深度。Talker 给的不是 Reasoner 的预览，是性质完全不同的内容，这是两种心智模式在协作。

本页属于 ADPS 33 模式白皮书。返回 模式矩阵与白皮书目录， 或查看配套 可运行代码目录。