用途与实际影响
这项功能怎样使用
为什么需要它
把全文和整场聊天往返搬运很容易占满主对话;过度缩短又可能丢掉限制。工具保留指定文字,并明确说出有没有有损处理。
举个实际例子
这份技术文档只需要恢复步骤和对应限制;第一轮列出处,第二轮把顺序整理成清单。工具先选相关片段,再把前轮编号、结果状态和短预览带入第二轮。需要完整出处或回执时,调用者要另外明确提供。
最后我会得到什么
得到带原文位置的简明回答;继续追问有明确上一轮起点。若长材料被缩短,答复会说哪些内容没纳入,不假装模型读了整份。
正常时
关键限制和引用位置保留下来,答案能回原文核对。
发现问题时
材料太长而不得不省略时明确说出,再决定缩小范围或补材料。
入口不可用或证据不足时
选中文件不是可读文本或追问已超出这项工作范围时停下,不猜原文。
从哪里开始
在已接入 Toolkit 的主 AI 对话中给出长材料和具体问题,必要时用同一有界工作继续追问。
需要准备什么
- 选定的长文档或文本
- 必须保留的限制与出处
- 后续追问内容
从开始到拿到结果
- 1
挑出与目标相关的原文
系统定位长文里对应步骤与限制,保留出处,并标明有没有因长度省略内容。
- 2
整理相关片段
系统保留可追溯片段,并明示是否因长度做了有损选择。
- 3
取回并追问
给出短结果与出处;确需第二轮时带上上一轮标识,完整原文或无限记忆不会自动随行。
技术实现与依据
这里保留实现、关键条件、精确入口、历史记录和验证结果。
源码及离线回归通过关键规则与设计选择
context.pinned 保存不能被压掉的要求。
PDF/Office 先用相应读取器;这里的 source 接口不是万能文档解析器。
continuation 默认最多 3 轮、硬上限 8 轮,只自动带前轮编号、结果状态和预览;需要原文与回执须另外提供。
本模块用到的名词
- 有损整理
- 部分输入被省略,必须告诉调用者,不能声称完整读过全文。
- 可携带续问
- 用显式结果衔接新请求,而不是依赖某家 API 看不见的会话。
专业定义
先找有关段落,再带着短结果接着问
解决什么
估算的 token 是输入整理尺度;不是计费量,也不是 Codex 实测上下文。没有选中的资料,模型不能被当成读过全文。
当前怎样实现
- context.py 进行确定性整理,区分中日韩与 ASCII token 估算,按 target_tokens 收敛并报告前后估算、duplicates_removed 与 lossy。
- sources.py 根据目标分块、打分,使用 top_k / max_chars 选择 UTF-8 段落,返回源摘要和行号;引用的字节完整性仍由输入生命周期负责。
- continuation.from_job_id 指定已经完成的前轮,max_turns 约束链长。_prepare_continuation 追加 previous_result,只有 job_id、result_status、output_preview;不会自动附加完整 receipt(执行回执)。delegation_receipt / delivery_receipt 仍作为每次任务的独立结果回执保存。
执行流程
- 1
给出目标和固定要求
- 2
读取已捕获文件并选择相关片段
- 3
按预算整理后调用模型
- 4
返回短结果和出处
- 5
确有必要时显式续问
边界
- 不提供无限会话或长期隐式记忆。
- 估算节省量不等于 Codex 账单节省量。
失败与恢复
- 来源读取或格式失败
- 返回明确错误,改由对应读取器处理后再提供文本。
- 续问轮数超限
- 停止,由主 AI 决定是否形成新的有界任务。
真实入口
src/llm_backend_toolkit/context.py确定性整理
src/llm_backend_toolkit/sources.py文本片段与出处
src/llm_backend_toolkit/jobs.py续问链与交付回执
如何验证
- 9月7日370项旧回归包含context、sources和续问;当前诊断不重跑模型任务,仍明确有损整理与已读片段边界。
与其他模块的关系
位于输入固定之后、模型调用之前;续问则使用前轮已完成结果。
