第28篇：对话历史的截断策略：传意图不传数据本文是"智能助手架构设计与实现"系列第 28 篇。前文我们拆解了大模型 JSON 输出的四层容错解析策略。本篇聚焦大模型交互中另一个容易被忽视但影响深远的工程问题——对话历史管理，讲解为什么历史消息中只传意图摘要而不传完整业务数据，以及 500 字符截断 + 20 轮限制如何平衡上下文理解、数据安全与 Token 成本。一、问题背景：多轮对话的上下文困境1.1 为什么需要对话历史？单轮对话很简单：用户发消息 → 大模型返回意图 → 执行 Skill → 渲染答复。但真实场景中，用户经常需要多轮交互：用户：查看所有项目 助手：共找到 5 个项目：项目A、项目B、项目C... 用户：第2个项目的详情 助手：项目B的详细信息... 用户：它的附件有哪些？ 助手：项目B下共有 3 个附件...第三轮中的"它"指代"项目B"，大模型需要前两轮的上下文才能理解。如果不传历史消息，大模型不知道"它"是什么，无法正确提取project_id。1.2 朴素方案的致命问题最直觉的方案是把每一轮的完整消息（用户输入 + 助手答复）都存入历史，下次调用时全部传给大模型。但这有两个致命问题：问题一：数据泄露助手答复中包