工具返回值如何压缩并尽量保留信息？

核心回答

我会先判断任务需要什么信息，再做结构化精简、原文外置和按需回读，最后才考虑用模型摘要。压缩后的内容应足够支持下一步决策，完整数据则保存在可访问、可追溯的位置。

具体做法是：

1. 先减少不必要的返回：工具支持字段选择、筛选、分页、去重和聚合，避免把无关数据送进模型。
2. 保留关键内容和结果说明：任务所需字段、数字与单位、条件和例外，以及工具状态、数据范围、总量和是否截断。
3. 大结果外置：给模型摘要或预览，同时提供原始结果的标识、版本和读取方式，需要细节时再查询。
4. 用任务验证压缩质量：检查结论、数值和引用是否一致，重要细节能否找回。自然语言摘要不能保证任意信息都不丢失。

例如工具返回五六千只股票，而用户要求全量数据，我会生成完整的表格文件或提供分页结果，再让模型说明范围和使用方法。只给一段摘要或前几十条，不能算满足了全量要求。

展开说明

1. 压缩目标是支持任务，不只是减少字符数

先看工具结果接下来用于什么：做统计、比较几个对象、定位异常，还是向用户交付全部记录。不同任务需要保留的信息不同。用于精确计算的数据应交给程序计算，不能先让模型总结，再从总结里重新算总额。

预算也要看整次模型请求，包括指令、历史、工具定义和其他上下文，并为输出预留空间。单条结果过大可以在工具返回后处理；很多结果累积过长，则还需要模型调用前的上下文管理。触发条件应按实际模型窗口、任务和结果分布设置，没有通用的固定字符数。

2. 优先做可检查的结构化精简

如果问题只涉及订单号、金额和状态，就让工具只返回这些字段。若任务是按地区汇总，可由查询或程序返回汇总结果，并保留统计口径、时间范围和原始记录入口。去重时也要明确判断依据，不能把内容相似但时间、对象或版本不同的记录随意合并。

返回结果可以包含：调用标识、状态、筛选条件、数据时间、总记录数、当前页或覆盖范围、任务所需数据，以及 truncated 和原文引用。并非每个工具都必须用同一套字段，但模型应能分清“完整结果”“部分结果”“合法空数据”和“调用失败”。错误码和失败原因不能被一句“暂无相关信息”替代。

当前 Deep Agents 文档展示了把大工具结果保存到后端、向模型返回位置和预览的做法。DeepSeek Harness 也有确定性裁剪工具结果、保留原始事件与调用关联的设计。首尾截断可以控制上下文大小，但中间内容仍可能是关键证据，因此必须清楚标注省略范围并支持回查。

3. 原文外置以后，要真的能取回来

原始数据可以保存在文件、对象存储或查询结果集中，摘要关联稳定的结果标识、数据版本和记录范围。读取工具支持按记录 ID、字段、页码或行区间获取，模型不必每次重新加载全量。

引用应指向此次调用的数据快照或明确的版本。若只能重新查询实时系统，应说明数据可能发生变化；否则第一次统计和第二次回读可能不再对应同一批数据。原始结果的保留时间要覆盖任务需要，读取时沿用用户和任务的访问范围，不能因换成文件链接就绕过权限。

“保存在上下文外”解决的是容量问题；模型需要细节时仍要主动读取。只有一个路径，却没有相应读取能力或文件已经被清理，就不能算可恢复。

4. 需要语义摘要时，保留条件和证据位置

对长网页、日志或检索材料，可以按当前子任务提取相关事实，再给出简短摘要。应保留来源、时间、数字单位、否定词、适用条件、重要例外，以及信息冲突或尚未确定的部分。关键结论关联到原文段落、记录或行区间，便于引用和核对。

摘要可以写成“发现了什么、依据在哪里、还有什么缺口”，不必复述全部过程。原文中的猜测不能被压成确定事实，工具返回的指令性文字也不应升级成系统指令。压缩本身不承担授权和提示注入防护的全部职责。

历史摘要还要保留工具调用与结果之间的必要关联，避免留下一个孤立结果，让后续模型误认它回答了另一个问题。对仍在使用的关键片段，可以直接保留原文；没有必要对所有内容连续多轮摘要，积累细节偏差。

5. 全量数据和较小窗口怎样处理？

如果用户要求全量股票列表，应先确认范围、日期和所需字段，再由工具或程序生成完整 CSV、表格或分页输出。模型负责解释结果和给出入口，可以展示少量样例，但应明确样例不是全部。若结果需直接在界面展开，则由分页或文件预览承担大量记录展示。

换成较小上下文窗口的模型时，重新计算输入预算，减少一次读取量、缩小当前子任务范围，必要时分批处理并通过稳定 ID 合并。跨批统计、去重和完整导出仍由程序处理，不能靠多段摘要拼接来承诺逐条不丢。

验证可用一组代表性工具结果：包含长表格、关键细节在中间、否定条件、空数据、部分失败和版本变化。分别比较压缩前后的任务答案、关键字段与统计值，检查引用回读是否成功，并观察压缩带来的额外延迟。压缩率只是辅助指标，不能代替任务正确性。

常见追问

能保证压缩后完全不丢信息吗？

任意自然语言摘要不能作这种保证。若要求逐条无损，就保留完整原始数据，通过结构化查询、分页或文件交付使用它；摘要仅作为索引和阅读入口。对于特定任务，可以通过字段约束和校验保证所需信息完整，但要明确保证的范围。

为什么不直接截取前几千个字符？

可以把截断作为有标记的预览，但不能默认它足以支持回答。结论、异常和限定条件可能在中间或末尾。应保留总量、截断说明和原文入口，再根据任务读取有关位置。

工具结果已保存到日志，为什么模型还会遗漏？

模型只依据当前提供的上下文作答。日志里有原文，并不等于模型已经读取；摘要还需要给出能定位的引用，工具也要支持按需回查。对于必须核对的结论，可以在生成最终答案前显式读取证据。

对应教程

参考资料

DB-GPTPython

基于 DB-GPT

核心回答

DB-GPT 的数据分析与报告链路采用完整结果产物化、工具返回受限预览、报告按产物取数：sql_query 先捕获本次查询返回的全部列和行，再只展示前 50 行，并默认限制表格预览为 20,000 个字符。模型拿到 artifact_id 后，可以定位所需结果；报告渲染器从产物读取数值和表格，避免让模型把大量单元格重新抄进提示词或报告参数。

这里压缩的是进入模型的表示，原始执行结果另行保存。预览负责识别数据，产物负责提供完整依据；缺少汇总指标时交回分析环节计算，不能从前 50 行猜全量结论。

完整结果与两层预览分别保存什么？

查询成功后，sql_query 将 columns、完整 rows、执行的 SQL、数据库名和耗时交给 capture_sql_execution，取得 artifact_id，然后才生成给模型看的 Markdown 表格。超过 50 行会注明总行数，过宽的表格还会触发字符截断。这两个限制独立生效：即使不足 50 行，长文本列也可能超过字符预算。查询捕获与预览源码。

产物内部还有另一层预览。summarize_tabular_artifact 遍历完整结果，规范化为 JSON、计算 SHA-256 并写入文件，同时只保留最多 100 行、256 KiB 预算内的内联预览。SQLArtifact 保存总行数、预览是否截断、完整结果哈希及内容地址。完整文件与内联预览因此是两份不同用途的表示，不能把内联数组长度当成查询总行数。完整结果捕获源码。

这一保存链需要当前运行挂有产物接收器；没有接收器时，捕获函数返回 None。另外，“完整”指本次查询实际返回的结果，若原 SQL 自带 LIMIT，保存它并不会补出未查询的数据。

报告怎样只取需要的信息？

报告子代理有自己的消息历史，通过共享的运行状态访问已捕获产物，不需要重放主代理所有分析过程。它先调用 report_evidence_manifest 查看目录，再按真实 artifact_id 请求详情；详情选择限制为每次至多 12 个产物。需要某个嵌套结果时，传入 selectors，用 field、path 定位具体字段或数组位置。

目录和详情仍有预览预算。选择器会先从完整产物解析目标值，再对返回给模型的内容做有界预览；一次选择整张大表，仍可能被截断。因此要继续缩小读取范围，而不是把“预览没显示”解释为“结果不存在”。read_artifact_result 优先读取 artifact:// 对应文件，并检查内容哈希；这使后续取数对应此次执行保存的内容，而非重新查询数据库的最新状态。

最终报告中的一个指标用 artifact_id 和结果路径引用，一个表格用产物 ID 与列配置表达，由渲染器读取原始行并展开单元格，模型无需逐格输出。报告代理取数约定与表格展开源码给出了这两种交接方式。

例如一次查询返回 300 行分组统计，聊天预览只显示前 50 行。若报告需要展示全部记录，就引用保存的表格产物；若要核对后面的某一行，就按该产物的实际结构定位读取。若报告还需要一个未计算的总体比例，则通过 request_report_calculation 提交公式和输入产物 ID，让主代理补算缺失项，再继续报告，不能把预览里的局部比例当成总体比例。

这套方法的取舍

它不额外调用模型生成查询结果摘要，数字、列和来源由程序保存，后续读取也能沿产物回查。代价是文件存储、额外读取和产物生命周期管理；行数与字符预算也不能代替整次请求的 Token 预算。预览适合判断结构和选择证据，全量统计仍应在完整结果上由查询或程序完成。验证时应覆盖关键记录在第 50 行之后、少行宽表、空结果和读取文件缺失等情况，比较原始结果与报告引用值，而不只检查返回文本是否变短。

参考资料

• 国内：JavaGuide：上下文工程：依据工具观察中保留参数、错误和原始引用的解释，说明查询预览为什么仍需关联执行信息与产物入口。
• 国内：ranxi2001：记忆与上下文：参考中间结果外置、按需恢复与压缩后检查任务不变量的讨论，说明完整结果、模型预览和数值验证各自的职责。
• 国内：DeepSeek Harness：压缩与裁剪：参考原始工具事件与裁剪后表示保留关联的设计，解释缩短模型可见内容不等于删除底层执行依据。
• 国内：Datawhale：上下文工程，第 9.5 节：借鉴先检查数据规模与列结构、再定向读取文件的示例，说明预览应服务于定位，不能代替对完整数据的处理。
• 国外：Anthropic：Effective context engineering：参考轻量引用与运行时按需加载，以及额外探索的延迟代价，解释产物 ID 取数如何减少一次性输入及其取舍。
• 国外：LangChain：Deep Agents context engineering：参考大工具结果外置后返回位置与预览的机制，解释结果外置与历史消息摘要是不同层次；本文的具体行数和保存行为以 DB-GPT 源码为准。