用大模型写方案、做分析、改代码，聊到中后段"跑题"，几乎是每个重度用户的共同痛点：设定的角色和任务目标被稀释、错误答案被反复带回来、同样的需求每次都要重新讲。一开始我以为是自己 prompt 写得不够好，后来才明白——问题出在"上下文"本身。最近我把 Tck办公AI 上下文沙盒工作台当主力工具实测了一周，这篇文章就聊聊它靠"记忆与投喂分离"的架构，是怎么从机制上把这个问题治住的。
一、长对话为什么会"跑题"
把大模型想象成一个"记性有限"的人。对话越长，你塞给它的历史消息越多，它记住的"最近信息"占比越大，早期的系统设定、角色、任务目标就被海量后续消息稀释掉了。这就是两个专业名词：
- 上下文漂移（Context Drift）：对话变长，早期设定被稀释，模型逐渐"忘记"最初的约束，输出偏离原方向，人设崩塌、任务跑题。
- 上下文污染（Context Pollution）：无关话题、错误回答、敏感信息混入后持续干扰推理，引发幻觉、答非所问，甚至把敏感数据"遗忘"后又重新输出。
普通对话工具的做法是"把所有历史一股脑塞给模型"，所以这两个问题会随对话持续累积、断崖式恶化。
二、Tck办公AI 的解法：记忆与投喂分离
Tck办公AI 把"模型输入"拆成两层：
- 记忆层（本地永久存储）：所有消息原文完整保存进数据库，永不丢失、不修改，可随时回溯与导出。
- 投喂层（出站报文）：每次请求时，根据当前任务选择的策略，从完整历史里精确裁剪出一个子集发给模型。
一句话：模型只看到"该看到的内容"，完整记录永远留在本地。既保证模型聚焦有效上下文，又不损失任何历史数据。
三、六种上下文截取策略实测
- 首尾保留（headTail）：保留对话头部（系统设定/任务背景）和尾部（当前需求），裁掉中间冗余。从机制上保证初始设定不被稀释，专门治"漂移"。
- 手动截断（manualCut）：把已确认污染或无关的消息划进"隔断区"，不再发送给模型，但记录仍完整保留。支持临时可恢复、永久不可恢复两种模式。
- 滑动窗口（slidingWindow）：只保留最近 N 条消息，过时、失效的上下文自动退出模型视野，避免历史包袱拖累当前推理。
- 过期时间（expireTime）：按时效清理过期上下文，超过有效期的历史不再发送，防止旧信息污染当前任务。
- 字段截取（fieldCut）：在出站报文中静默剔除敏感或无关字段内容，防止敏感信息进入模型上下文，杜绝数据泄露风险。
- 全量上下文（full）：需要完整记忆时随时切回全量模式，把全部历史发给模型，灵活适配不同阶段。
四、和原生大模型对话的轻对比
原生对话：污染后只能新建任务，丢全部项目背景；每次要重新描述需求，重复劳动；漂移导致结果不一致、难复现；无效历史反复进入，模型重复思考费时；冗余堆积，Token 成本翻倍；跑偏后只能推倒重来；单一模型无法多模型对比。
Tck办公AI：在会话窗口内精准裁剪；屏蔽无效对话，背景与需求永久保留；有效上下文聚焦，结果更稳定；历史可回溯可恢复，跑偏可随时改回；剔除冗余，大幅省 Token；干净上下文减少幻觉与偏题；支持多模型切换、同一问题对比。
五、配套能力
- 多模型自由切换：支持配置多个大模型（OpenAI 兼容接口），每个任务独立选模型，支持视觉输入与深度思考。
- 完整报文导出：一键导出全部会话原文为 JSON，包含完整上下文报文，便于留档、分析与复现，不受策略裁剪影响。
- 用量统计：记录每次对话的 Token 用量与耗时，后台看用量趋势、模型分布，帮团队控成本。
- 数据安全：API Key 用 AES-GCM 加密存储；字段截取兜底敏感信息。
六、费用与适用人群
Tck办公AI 系统本身完全免费，无订阅费、无功能限制。需要自备大模型 API，Token 由模型服务商直接收取，系统不代收、不加价。
它更适合长期用 AI 做复杂任务、看重上下文一致性和数据可控的开发者与重度用户。上手的关键是先想清楚：你的痛点到底属于"漂移"“污染"还是"烧钱”，再选对应策略。纯体验分享，仅供参考。
