上下文构造器怎样装载和重建工作包
一句话收获：上下文构造器管理语义对象，不只是拼接字符串。
这个场景在解决什么问题
这个场景讲的是"上下文构造器"（Context Builder）——它负责把该给模型看的信息，组装成模型每次能读到的上下文。目标（goal）是把稳定规则、任务事实、运行状态这三类东西，都落进代码里统一管理。观察点（observation）是：当上下文越堆越多、出现污染后，执行裁剪、摘要和"可信重建"。
为什么值得单独学？因为很多人以为"上下文就是拼字符串，把东西全塞进去就行"。这个场景告诉你：上下文是有结构的，构造器管理的是"语义对象"（哪条是规则、哪条是事实、哪条是状态），而不是简单拼接；一旦污染，光扩容没用，要从权威状态重建。
先理清这条判断链（文字版）
这个场景的四步讲的是上下文从"装载 → 分配 → 污染 → 重建"的完整生命周期：
- 先按"稳定规则、任务事实、运行状态"三层来装载，并保留各自的来源和版本。
- 再按预算分配容量，必要项保留、低价值历史外存、预留输出空间。
- 当出现污染（旧状态、重复日志、错误摘要并存）时，模型开始引用过期资料。
- 最后从权威状态重建——重读规则、Spec、业务状态、最近回执和未决项，恢复可验证的工作包。
这条链的核心逻辑是：上下文是有限且会被污染的，靠扩容救不了，只能回到权威状态重建。
逐层详解
第 1 步：三层装载
原文：稳定规则、任务事实和运行状态按来源与版本装载。
白话：构造器把三类信息分三层装进去：稳定规则（AGENTS.md、Spec 这类很少变的）、任务事实（这次任务的具体输入）、运行状态（Loop 跑到哪、最近结果）。每一层都记清楚它的"来源"和"版本"。
类比：像整理档案柜——规章制度放一个抽屉（很少动）、本次任务的材料放一个抽屉（每次换）、执行进度放一个抽屉（实时变），每个抽屉都贴来源标签。
举例：一个 Agent 的上下文里，AGENTS.md 标为"规则层 v3、来源是项目根目录"，本次订单任务标为"事实层、来源是用户输入"，当前 Loop 第 3 轮标为"状态层、来源是 Runtime"。三个层次分明。
为什么重要：不同层具有不同更新频率和裁剪优先级。也就是说，规则基本不动、事实每次换、状态实时变，所以它们被裁剪时的优先级也应该不同。
怎么验证（证据点）：
- 规则稳定：规则层内容稳定、有版本。
- 事实当前：任务事实是最新的。
- 状态权威：运行状态来自权威来源。
别踩的坑（边界）：全部装入不证明没有冲突。意思是，把三层都塞进上下文，不代表它们之间没有矛盾——可能规则和状态互相打架。
落地检查：先保留信息身份。也就是说，落地时每一条信息都要保留"它是什么、从哪来、什么版本"这个身份标签，不能只留一段裸文本。
第 2 步：预算分配
原文：为必要目标、状态、工具和输出预留容量，低价值历史外存。
白话：上下文窗口（模型一次能读的字数上限）是有限的，构造器要"精打细算"：给必要目标、当前状态、工具、输出预留容量，把低价值的历史对话挪到外部存储（外存），需要时再取回。
类比：像手机内存不够时——常用的 App 留在内存里（必要项），不常用的照片视频挪到云盘（外存），需要时再下载回来。
举例：一个长任务的上下文快满了，构造器把"当前目标、最新状态、正在用的工具定义、输出格式"留在窗口内，把前面十几轮的旧对话摘要后存入外部存储，只在需要时按引用取回。
为什么重要：上下文窗口是有限资源。也就是说，窗口是有硬上限的，不精打细算就会溢出，所以必须做预算分配。
怎么验证（证据点）：
- 必要项保留：目标、状态等必要项留在窗口内。
- 可回取项外存：低价值历史可被外存并取回。
- 输出空间预留：给输出留了足够空间。
别踩的坑（边界）：简单按最旧消息删除可能丢失关键状态。意思是，如果只是"谁最旧就删谁"，很可能把关键状态误删——删除要看"价值"不是看"新旧"。
落地检查：裁剪依据任务价值。也就是说，落地时裁剪的标准是"这条对当前任务还有没有价值"，而不是简单的时间顺序。
第 3 步：污染出现
原文：旧状态、重复日志和错误摘要同时存在，模型开始引用过期资料。
白话：当上下文里同时混着"旧状态""重复日志""错误摘要"这些东西时，就出现了污染——模型开始引用过期的、错误的资料，但窗口却还没满，所以不会触发长度报错。
类比：像一本被改来改去的会议纪要——老结论、重复记录、写错的摘要都还在，新来的人照着读，读到的却是过时信息，但本子根本没写满。
举例：任务状态已经从"第 3 轮"推进到"第 7 轮"，但上下文里还留着第 3 轮的旧状态和一堆重复日志，模型就开始引用第 3 轮的过时结论做判断，而此时窗口其实还有余量，没有任何报错提示。
为什么重要：上下文腐化不一定触发长度错误。也就是说，污染是"静默"发生的——窗口没满、没有报错，但内容已经坏了，这是最危险的地方。
怎么验证（证据点）：
- 旧状态被引用：模型开始引用过期状态。
- 规则冲突：上下文里的规则出现矛盾。
- 窗口仍未满：窗口还有余量，没触发长度错误。
别踩的坑（边界）：扩大窗口不能修复错误事实。意思是，出现污染后，把窗口开得再大也没用——因为坏的是"事实本身错了"，不是"空间不够"。
落地检查：需要可信重建。也就是说，落地时发现污染，正确做法是回到权威状态重建，而不是继续扩容。
第 4 步：从权威状态重建
原文：重新读取规则、Spec、业务状态、最近回执和未决项。
白话：发现污染后，构造器不再在原上下文上"打补丁"，而是从权威来源重新读取：规则、Spec、业务状态、最近的工具回执、还有未解决的事项，用这些"可信的东西"重建一个干净的、可验证的工作包。
类比：像账本乱了以后，不是在那堆乱账上涂改，而是拿银行对账单（权威状态）重新建一本干净的账。
举例：发现模型开始引用过期状态，构造器清掉被污染的上下文，重新读 AGENTS.md、Spec、数据库里的当前订单状态、最近一次工具回执、以及还没做完的事项，重建出一份可验证的当前工作包。
为什么重要：重建恢复当前可验证工作包。也就是说，重建的目的不是"继续旧对话"，而是恢复一个"每个字段都能被验证"的干净工作包。
怎么验证（证据点）：
- 目标完整：重建后的目标信息完整。
- 状态最新：状态来自最新权威来源。
- 引用可回取：引用的信息都能回取到原始出处。
别踩的坑（边界）：模型摘要不能单独更新正式状态。意思是，模型自己生成的摘要，不能用来"更新正式状态"——正式状态必须由权威系统更新，摘要只是辅助。
落地检查：重建后再运行约束检查。也就是说，落地时重建完成后，还要再跑一次约束检查，确认重建结果满足规则约束。
落地可行性小结
本场景涉及的技术栈和落地要点：上下文构造器（Context Builder）、上下文窗口、三层装载（规则/事实/状态）、预算分配、外存（外部存储）、语义对象、权威状态重建。
真实落地时要注意：每一条上下文信息都要带"身份标签"（来源 + 版本 + 类型），否则没法按层裁剪；预算分配要基于"任务价值"而不是"时间新旧"；要能识别"静默污染"（窗口没满但内容已过期）；重建必须从权威状态（规则/Spec/业务状态/回执）出发，不能用模型摘要去覆盖正式状态。常见坑是：只按最旧消息删除导致丢关键状态；以及污染出现后盲目扩容窗口，而不是重建。
回顾
- 上下文构造器管理的是"语义对象"，不是简单拼接字符串。
- 三层装载（规则/事实/状态）各有不同的更新频率和裁剪优先级。
- 上下文窗口是有限资源，预算分配要看"任务价值"，不是看"新旧"。
- 污染是静默的，窗口没满也可能内容已坏；扩大窗口救不了错误事实。
- 污染后要从权威状态重建，模型摘要不能单独更新正式状态。