04 · Context Engineering：每一轮让模型看什么

1. 上下文工程在Agent里负责什么？

上一课的Tool已经能查回直播成交额和流量。模型接着要用哪些结果？前面的要求还要不要带？用户补了一句“只看新品”，下一轮输入该怎么变？

Context Engineering，上下文工程，负责组织模型当前这一轮可用的信息。它是Harness的一部分：从任务要求、历史消息和工具结果中选择材料，整理后发给模型，再随着任务推进更新。

Prompt Engineering主要研究要求怎么表达，上下文工程还要决定哪些事实、历史和能力应该出现。两者有交叉：写得清楚的要求，也需要在正确的一轮被保留下来。

先认识本篇的几个词：

2. 同一个任务，传统后端和Agent怎样传递信息？

继续用直播分析的例子。用户先问：“昨晚的成交额为什么下降？”看过整体对比后，又补充：“先只看新品，和上周同一天比。”以下流程为抽象教学示例，不对应特定项目实现。

传统后端可以把场次、商品范围、比较日期写进明确的请求参数，再按业务代码查询和生成报表。范围变化后，使用新的参数重新计算。它同样可以支持复杂分析和交互。

Agent里，模型要结合自然语言与查询反馈判断下一步。程序仍需解析、确认范围，并把有效要求和相关事实组织到模型输入中。不能把整段聊天原样堆进去，就认为模型一定能理解最新口径。

这里有三个不同动作：保留新的范围；判断已有资料能否支持它；缺少对应数据就继续查。

全场成交额下降，不代表新品也下降。即使全场结果来自可靠接口，也不能换个标题当新品结论。上下文工程要保留数据的适用范围，帮助模型知道“已经知道什么，还不知道什么”。

3. 这一轮输入应该有哪些东西？

对于“新品成交额对比”这一步，可以按职责组织材料：

“新品”也需要有业务定义：按上架日期，还是某个商品标签？不明确时先问或使用产品已明确说明的默认口径，不能让模型临时猜一个。

用户修正范围后，旧范围可以作为变更记录留下，但要标明已被替代。工具返回里即使混入“忽略之前要求”，它仍然是外部资料，不应被提升为系统指令。身份、权限和允许执行的动作继续由程序检查。

这些材料可以分区组织，但分区名称本身没有魔法。模型仍可能用错信息，需要通过固定样例检查。

4. 窗口装得下，为什么还要控制输入？

直播任务可能查回商品信息、订单聚合、流量分时数据和历史报告。全部放进模型，除了输入费用和延迟，还会增加无关信息与旧结论的干扰。

窗口大小只说明容量，不保证每条信息都会被准确使用。长上下文研究在特定模型和任务中观察到信息位置影响表现；不能据此认定所有模型都有相同规律，更不能认为把结论移到末尾就解决了问题。

工程上先统计输入占用：规则、工具定义、消息与数据都算进去，再为输出以及接口要求的推理或协议内容留空间。使用相应接口的计数能力核对，不能只按中文字符数估算，也没有所有任务通用的固定占比。

直播画面、截图和音频同样需要预算。可以先查分时指标，确有需要时再读相关时段的关键帧或转写；保留时间点和来源，避免把整场素材都塞进去。具体能输入哪些模态、怎样计量，取决于模型与接口。

5. 海量资料怎么保留？先给线索，按需读取

分析新品成交额，通常先需要对应范围的聚合结果。发现某个时间段值得继续查看时，再读取该时段的流量或商品资料。

工具可以先返回“新品对比结果、覆盖范围、数据时间、来源标识”，明细放在受控数据服务或文件里。来源标识必须对应真实记录，并有读取方法；只有一个编号，模型无法凭它恢复内容。

读取时仍要检查权限、筛选条件、版本与时效。实时流量和上周的归档报告，复用规则显然不同；来源过期或不可访问时，应重新查询或说明缺口。

上下文里保留够用的结论与证据，外部保留可继续核对的材料。这不要求先建向量数据库：按场次、时间和商品范围查询，也可以完成按需读取。文档检索怎样做，留到RAG篇展开。

6. 把压缩做成一条可提交的工程流程

这里说的“记忆压缩”，是缩短送给模型的会话历史。它不是修改模型参数，也不是把原始记录删掉。继续用新品分析任务：查询越多，工作材料越多，但下一轮未必需要再次阅读全部订单反馈。

6.1 先分三层，再决定压缩谁

下一轮输入可以组织为：当前规则和任务 + 历史摘要 + 近期完整交互。下文把这份实际发给模型的消息组合叫输入视图。原始记录另行保存，必要时回读。

用户刚确认的“只看新品”、指标定义和输出要求，应有明确的当前记录，不靠一份越来越长的摘要反复转述。近期消息保留用户纠偏和工具往返；更早的分析过程才是主要压缩对象。

切分按完整交互边界做，不能机械保留最后十条。模型提出了两次工具请求，就要按所用协议保留对应结果；正在执行的请求也不能一半进摘要、一半留在历史。单次结果就特别大时，先在工具层聚合、分页或存文件，再压缩普通历史。

6.2 什么时候压缩？由程序算，不让模型凭感觉判断

在工具批次完成、准备下一次模型调用时，估算完整输入，包括规则、工具定义、历史与多模态材料，再预留输出和安全余量。

比如教学配置中，窗口为32k，输出留4k，安全余量留2k，那么输入接近26k就该处理。这些数字只是说明算法，不是推荐配置；摘要请求自己也需要能装下待压缩材料及输出。

先做不调用模型的缩减：去掉确定无关的重复资料，缩小工具返回，保留可回读引用。重新计量仍然超预算，再生成摘要。不要每轮都总结一次，也别等模型接口已经拒绝请求才开始准备压缩。

6.3 摘要要有结构，但结构不等于事实正确

对新品分析，可以要求压缩器返回下面几类内容：

让摘要合并“旧摘要 + 这次新增的旧历史”，更新过期结论，不要无限叠加摘要。需要精确保留的金额、范围、标识，可以由程序从结果中提取后单独带入；不要让压缩模型重新计算。

摘要任务只负责整理材料，不执行业务工具。返回后检查格式、必需字段、来源是否属于输入材料、关键值是否与记录一致，并重新计量包含包装文字后的大小。这些检查能拦住部分问题，不能证明语义绝对正确；仍要用业务样例验证。

6.4 生成成功后，怎样安全替换？

摘要生成需要等待模型响应。等待期间如果用户又改了范围，旧摘要不能直接盖掉新输入。

一个可落地的方案是：同一会话只运行一个压缩任务，记录待压缩区间与基础版本；生成候选摘要后，校验区间未变，再一次性保存摘要、来源区间、近期保留起点与新版本，并切换当前输入视图。单进程可串行处理，多执行者需要条件提交，保证旧任务不能覆盖新版本。

检查点就是这份可继续组装输入的记录，至少包括baseVersion、sourceRange、summary、keptFrom和压缩前后用量。它们是本课示例字段，不是框架统一协议。

失败、取消、摘要变大或版本过期时，不切换到候选结果。保留最近一次有效视图，再重新选择范围或明确停止；旧输入已经装不下时，也不能继续原样重发。原文保留到正常的存储生命周期结束，压缩本身不删除它。

7. Pi Agent怎样做压缩？

Pi的默认策略是：旧历史变摘要，近期历史原样保留，再保存保留边界。

自动触发条件是contextTokens > contextWindow - reserveTokens。reserveTokens默认16,384，keepRecentTokens默认20,000；前者决定什么时候压缩，后者决定近期保留多少，前者不是摘要输出上限。

Pi从最新消息向前累计估算大小，寻找合法切点，不从工具结果处硬切。如果一个用户请求持续执行很多轮，切点落在请求中间，会分别处理更早历史和这次请求已执行的前半段，再合并摘要。

结果以CompactionEntry追加到会话记录，包含摘要与firstKeptEntryId，即近期原文从哪条开始保留。之后组装输入时使用新摘要和保留段；原始记录仍在。

还有一个容易忽略的实现细节：Pi给摘要模型整理输入时，会把每条工具结果的文本限制为前2,000个JavaScript字符串单元，并标明截断；这不是对业务结果的语义筛选。关键口径如果藏在后半段，摘要可能读不到。因此业务工具最好先返回结构清楚的核心结果与来源，不能指望压缩器替你理解海量明细。

8. DeepSeek Harness怎样做压缩？

DeepSeek Harness把压缩做成可组合的能力。这里看基础压缩后端compaction-basic，以及可选的工具结果裁剪器tool-result-pruner。

基础后端在下一步请求前检查压力。若装了裁剪器，先做不调用模型的裁剪，再重新计量；只有仍然超过阈值，才压缩更早的一段历史，保留近期完整交互。

默认裁剪条件是：工具结果文本超过8,192个Unicode码点，保留开头4,096和结尾1,024，中间换成裁剪标记。原结果留在日志中。它不理解哪段最重要，直播指标口径在中间时同样可能丢失；业务数据应优先按字段、范围和来源整理，而不是照搬这种通用文本裁剪。

摘要替换的是当前给模型看的历史视图，原始事件不删除。它会先记录压缩开始，生成摘要后检查选择范围是否稳定、包装后的摘要是否确实更小，再记录摘要、替换消息与结束事件。先前裁剪已经提交时，后续摘要失败不会自动回滚那次裁剪。

压力触发也不只是“窗口用到80%”：它同时考虑模型输出预留和额外空间。默认80%与65,536的额外预留，小窗口不能照搬，应按实际窗口和输出预算调整。

压缩后还会再计量，默认最多做两次摘要尝试。如果接口已经报告上下文溢出，则走单独的恢复分支：不沿用普通近期保留预算，并且只有发生了有效的视图替换、未取消且未超过重试次数时，才重试请求。

它还考虑摘要调用本身的缓存成本：尽量复用同一路由的系统提示、工具定义和历史前缀，最后追加摘要要求。但替换旧历史后，后续普通请求从修改点起的缓存仍可能失效，不能说压缩天然提高命中率。

Pi和DeepSeek Harness值得借鉴的共同点，是明确切分边界、保留近期原文并持久化压缩记录。业务Agent还需要额外保护数据口径、证据引用和有效授权；开源框架不会自动知道你的业务里哪些字段不能丢。

9. 摘要能不能当任务状态？

分析完成后，用户可能希望把报告发出去。摘要里的一句“用户已同意发送”，不能成为执行凭据；“报告已发送”也不能代替实际发送记录。

摘要是给模型继续工作的材料，可能遗漏或写错。授权、动作是否执行、结果是否确定，需要由程序管理，并在执行前核对当前有效状态。它们的必要信息可以进入上下文，真实记录不能反过来依赖摘要。

因此，“压缩后还能继续分析”与“服务中断后能恢复执行”并不是一回事。本篇解决信息怎样续接；任务归属、持久化与恢复会在Session和长任务专题展开。

10. 怎么判断这一层有没有做好？

用同一条业务任务走一遍：先看全场，再改为新品，继续查询，压缩历史，最后生成报告。检查模型是否始终使用当前范围、能否找到引用、是否明确缺口，有没有因为丢失已有信息而重复查询。

再检查几种具体情况：用户修正范围后再压缩、同一任务连续压缩两次、工具结果很大、摘要调用取消，以及生成期间任务版本变化。核对数字、来源、最新目标与调用配对，再记录压缩耗时、压缩前后Token数、重复查询次数和摘要调用费用。先确认交付正确，再看净成本；不能只展示“少了多少Token”。

固定规则与稳定工具定义可以放在适合缓存的前部，变化的任务资料单独组织；具体命中规则仍按模型平台核对。缓存命中不代表资料正确，范围和权限变化时必须更新输入。

读完这一篇，应能解释：当前这一轮需要什么材料，哪些资料留在外部，历史压缩后怎样保留口径与来源，以及摘要为什么不能代替程序状态。

下一篇讲Session与Run：当用户追问、纠偏，或两个入口同时提交任务时，对话和执行任务应该怎样关联。