百度 Unlimited-OCR 对SpecWeave的可行动启示#
R-SWA和Unlimited-OCR的技术思想可以直接应用于SpecWeave多智能体协作系统，无需训练新模型，仅通过Prompt工程和系统架构层面的改进，就能解决长上下文管理、智能体"忘记"规范、大文档处理等实际问题。本章给出两条可立即落地的具体建议。
启示1：实现"规范前置+对话滑窗"的上下文管理中间件#
1.1 问题背景#
在SpecWeave多轮对话和多智能体协作中，随着任务推进，对话历史和上下文越来越长，导致三个典型问题：
问题 |
具体表现 |
|---|---|
上下文窗口溢出 |
早期关键信息（如启动协议、核心规范）被截断，智能体"忘记"基本规则 |
注意力分散 |
无关的早期历史干扰当前决策，智能体容易偏离任务轨道 |
推理变慢 |
上下文越长，首token延迟越高，用户等待时间增加 |
这本质上和OCR长文档面临的是同一个问题——不加区分地保留所有历史，导致关键信息被稀释、计算效率下降。
1.2 具体做法：借鉴R-SWA的三区上下文结构#
在多智能体系统中增加上下文管理层，对每次发给LLM的prompt进行结构化组装，结构固定分为三个区：
区域 |
角色 |
类比R-SWA |
管理策略 |
|---|---|---|---|
System区（静态参考） |
全局核心规则、当前任务相关规范、角色定义 |
参考侧（视觉token） |
任务启动时确定，期间不变化，始终完整放在prompt开头，永不遗忘 |
Anchor区（关键状态） |
已确认需求、已做出决策、当前任务进度、关键路径和文件 |
特殊锚点token |
动态更新但每轮完整保留，硬保留不淘汰 |
History区（滑窗对话） |
最近20-30轮对话历史 |
输出侧滑窗 |
FIFO滑窗保留，更早对话不放入主上下文，主动软遗忘 |
1.2.1 完整工作流程#
初始化：任务启动时加载System区（核心规范、角色定义）和初始Anchor区（任务目标）
每轮对话前：
System区：固定放在最前面，始终完整
Anchor区：根据当前状态更新，完整保留
History区：只取最近20-30轮
每轮对话后：
将本轮对话加入History区
用规则或小模型判断：本轮是否产生了需要提升为Anchor的关键信息（如已确认需求、已做出决策、关键文件路径）
如果有，更新Anchor区
历史回溯：被滑窗移出的对话历史完整存入日志，当用户提到"之前我们说过…"时，通过检索重新调入
1.3 预期收益#
收益 |
具体说明 |
|---|---|
✅ 核心规范永不遗忘 |
彻底解决"智能体跳过启动协议"、"不遵守规范"的问题——System区始终在最前面，每轮都能看到 |
✅ 上下文长度恒定 |
History区固定20-30轮，加上System和Anchor区，总长度恒定，不会因为对话轮次太多导致溢出 |
✅ 注意力聚焦 |
智能体始终聚焦当前任务和关键状态，不被几个小时前的无关历史干扰 |
✅ 实现成本低 |
不需要训练新模型，只是Prompt工程层面的改造，可以快速落地验证 |
启示2：建立"文档编码器+按需检索"的长文档处理机制#
2.1 问题背景#
SpecWeave需要处理大量规范文档（.agents/下的规则、协议、模板）、大型代码库，当前的做法是"把完整文件塞入上下文"，这导致：
问题 |
具体表现 |
|---|---|
上下文装不下 |
大型项目规范文档多、代码文件多，全部塞进上下文很快超出窗口限制 |
早期规范被遗忘 |
即使塞进去了，随着对话进行，位于prompt前部的规范被注意力机制"稀释"，智能体还是会违反 |
处理速度变慢 |
初始prompt越大，首token延迟越高，每次调用都带上一堆无关文档，浪费token和时间 |
这和传统多模态模型"把所有视觉token和文本token混在一起处理，导致视觉信息稀释"是同一个问题。
2.2 具体做法：借鉴DeepEncoder的一次性编码+按需检索#
不要每次都把完整文件塞进上下文，而是分两阶段处理：预处理阶段（类似DeepEncoder的一次性编码）和执行阶段（按需检索）。
2.2.1 预处理阶段（一次性编码，类似DeepEncoder）#
对于规范文档、知识库、大型代码库，在任务启动前或首次加载时预处理：
预处理步骤 |
具体做法 |
类比DeepEncoder |
|---|---|---|
文档拆分 |
将长文档按章节/主题拆分为有意义的片段（而不是固定长度切分） |
将PDF页面编码为视觉token |
摘要提取 |
对每个片段生成摘要、提取关键词 |
视觉token是图像信息的压缩表示 |
建立索引 |
建立向量索引（用于语义检索）+ 符号表（用于精确查找，如类名、函数名、规范条款编号） |
KV cache存储编码后的静态信息 |
调用关系 |
对代码库建立调用关系图；对规范文档建立"规范路由表"（任务类型→需要加载的核心规范） |
- |
2.2.2 执行阶段（按需检索，类似R-SWA参考侧访问）#
执行步骤 |
具体做法 |
类比R-SWA |
|---|---|---|
初始加载 |
初始上下文只加载最核心的入口文档（如AGENTS.md、任务spec） |
只加载当前需要处理的页面视觉token |
按需检索 |
智能体需要具体规范/代码时，通过"查阅文档"工具检索对应片段 |
每步注意力都能访问全部参考侧信息 |
临时参考 |
检索到的片段作为临时参考加入当前轮上下文，使用后下一轮可丢弃（除非被提升为Anchor） |
视觉信息每步可访问但不重复加载 |
规范路由 |
智能体启动时根据任务类型，从"规范路由表"中知道应该加载哪些核心规范，其他规范按需检索 |
- |
2.3 预期收益#
收益 |
具体说明 |
|---|---|
✅ 支持任意大小的代码库和文档集 |
不再受上下文窗口限制——预处理成索引后，再大的项目也能处理 |
✅ 核心信息加载快 |
初始prompt短小精悍，首token延迟低，响应速度快 |
✅ 信息相关性高 |
每轮只引入和当前步骤相关的文档片段，避免信息过载，注意力更聚焦 |
✅ 可扩展性好 |
新增规范/代码不需要改prompt模板，只需要更新索引即可 |
两条启示的核心共性#
这两条启示都来自R-SWA/DeepEncoder的同一个核心思想：根据信息的生命周期和变化特性进行分区，采用差异化的管理策略，而不是不加区分地堆砌所有信息。
Unlimited-OCR |
SpecWeave对应 |
|---|---|
参考侧（视觉token）：静态存储，全可见 |
System区：核心规范始终保留 |
输出侧滑窗：128 token FIFO |
History区：最近20-30轮滑窗 |
锚点机制（隐含）：关键输出连贯 |
Anchor区：关键状态硬保留 |
DeepEncoder一次性编码 |
文档预处理+建立索引 |
每步按需访问参考侧 |
执行阶段按需检索文档片段 |
Unlimited-OCR证明了：不需要模型层面的改动，仅仅是在信息组织和注意力访问模式上做符合任务本质的设计，就能获得巨大的收益。这两条启示都是Prompt工程和系统架构层面的改进，可以快速落地到SpecWeave中验证效果。
章节导航#
← 上一章：可迁移模式与行业启示