S5.1.1 Task 5.1

前 10 轮：96% 准确率。31 轮后：58%。因为没有持久化事实块。

一个研究系统的协调器准确率随对话长度稳步下降：前 10 轮 96%，第 20 轮降到 88%，第 30 轮 71%，31 轮之后只有 58%。系统使用了渐进式摘要但没有持久化事实块。早期子代理的发现在后续响应把它们挤入摘要历史后就丢了。

修复是架构级的：一个持久化的 Case Facts 块，放在每次 prompt 的固定位置，在可摘要的对话历史之外。这个区域存放关键值——金额、日期、ID、约束、决策——无论对话多长都能在上下文压缩中存活。

Case Facts 模式

=== CASE FACTS (DO NOT SUMMARIZE) ===
Customer: Jane Smith (CUS-2024-0312)
Order: #ORD-2024-0819, $127.50
Issue: Defective product, return requested
Deadline: 48-hour resolution (by Mar 31)
Constraints: Premium tier, expedited processing
Status: Awaiting return label generation
=========================================

这个块的特点：

  • 固定位置 — 始终在 prompt 的同一位置（开头或 system message），处于高注意力区域
  • 受保护 — 标记为不可摘要
  • 持续更新 — 随对话推进，新事实被提取并添加进来
  • 结构化 — 命名字段，不是叙述性散文

多问题跟踪

单问题案例：94% 解决率。4+ 问题案例：52%——41% 的客户反映”客服完全跟丢了”。

基础 Case Facts 块保留了身份和订单信息，但没有区分不同问题。扩展方案：结构化的 Issue Tracker。

=== ISSUE TRACKER ===
Issue 1: Defective headphones - RESOLVED (refund processed $49.99)
Issue 2: Missing charging cable - PENDING (replacement shipping)
Issue 3: Warranty registration failed - IN PROGRESS (tech team notified)
=====================

每个问题有自己的状态、解决方案和待办操作。代理扫一眼这个块就能知道每个问题的进展，不需要从摘要后的对话历史中重建。

长会话的 Scratchpad 模式

一个 Claude Code 会话执行了 40+ 次工具调用做重构，开始做出与早期决策冲突的修改——重命名一个已经重命名过的函数。对话上下文已被压缩，早期决策丢失了。

Scratchpad 文件充当持久化事实存储：

# Session Decisions
- Renamed getUserById → fetchUserProfile (auth/users.ts)
- Interface IUser → UserProfile (shared/types.ts)
- CONSTRAINT: Do NOT modify /auth/* (rewrite in progress by Team B)

代理把决策和约束写入文件，需要时读取。和对话历史不同，scratchpad 不受上下文压缩影响。

200+ 文件迁移的两层 scratchpad： 当 scratchpad 增长到 4,000+ token（占上下文预算 15%）时，拆分为：

  1. 活跃约束（约 500-1,000 token，始终在 prompt 中）— 仍然生效的接口变更、命名规范、跨文件依赖
  2. 已完成决策（文件，按需读取）— 代理仅在处理相关文件时才引用的历史决策

子代理结构化输出

子代理返回 3,000 token 的叙述性响应，4 个响应就填满了协调器的上下文。结构化输出（约 500 token），包含关键声明、引用和置信度评分，在同样的预算下能容纳 10+ 个子代理响应。

持久化的 Research Synthesis 块将发现分为：

  • 已确认 — 多来源支持
  • 有争议 — 不同来源的冲突声明
  • 空白 — 已识别但未研究的领域

这让协调器对发现可靠性有明确认知——不只是发现了什么，还有每条发现有多可信。

多代理流水线的 Pipeline Status

对于 100+ 文档处理（OCR → NLP → 验证阶段），Pipeline Status 块跟踪每个文档的阶段、结果摘要和错误。子代理返回结构化状态更新；协调器维护统一视图。

不管用的方案

“记住所有细节”指令。 无法覆盖摘要系统。摘要在系统层面作用于对话历史——prompt 指令无法阻止压缩。

更大的上下文窗口。 延迟了问题但引入了 lost-in-the-middle 效应。早期需求被埋在不断增长的上下文中间，注意力最弱的地方。Case Facts 块把关键信息放在固定的、高注意力的位置，不受上下文大小影响。

拆分会话。 在分段边界处割裂了上下文。段间只传递”最终输出”会丢弃推理过程、约束和中间决策。持久化 scratchpad 提供持续意识而不会碎片化。

一句话总结： 把关键值提取到 prompt 固定位置的持久化 Case Facts 块中——它能在上下文压缩中存活，防止准确率从 96% 跌到 58%，消除客户最大的投诉：被迫重复说过的信息。