上下文工作集：按阅读预算组织材料，明确原文与投影

Flowness 是我们用于安排多个 AI Agent 持续工作的运行环境。同一项任务可能先由一个 Agent 执行，再交给另一个修复或审阅。每次交接都要准备上下文：当前要做什么，用户有什么约束，前一步留下了哪些结果，还有什么反例不能忽略。

本文的上下文工作集是为这一步材料交付写的。它接收角色、材料引用、需要读取的范围和字节预算，返回供 Agent 阅读的内容，以及一份记录：哪些原文已交付，哪些以审计投影出现，哪些仍待读取。它不调用模型概括材料，也不替审阅者作结论。这套代码已经写好，但我们的自动派发还没有用它：2026 年 9 月 7 日，我们拿真实账本试着准备了一份工作集，准备时间超过了派发的时限，当天就在配置里把它关了，此后一直没有打开。

直接把所有文件塞进提示词，做法简单，但长日志和重复记录可能挤占真正需要阅读的内容。另一种常见办法是先生成摘要，代价是摘要的取舍也会影响下一位 Agent 能看到什么。若验收条件被缩成“完成主要功能”，原文里的例外与具体要求就可能消失。

工作集先区分角色。执行者需要任务包、用户约束、已知反例和前置条件；修复者还需要明确的问题、复现材料和修复范围；审阅者关注目标版本、评价标准、实际改动和机器观察。规划者需要用户意图、备选方案以及尚未解决的问题。这里的角色要求由程序明确列出，不依赖本次模型临时判断。

材料的“必读”属性也不完全听从调用者。属于角色要求的类别、明确标记的必读项、已知反例，以及用于支持材料范围声明的依据，都被列入必读。即使调用者把一条反例标为可选，并放在清单最后，它仍会进入必读部分。程序随后把必读材料排在可选材料之前。

这种排序针对的是已登记的材料。若上游根本没有搜索反例，工作集会保留“未搜索”的状态，而不会因为已交付一份材料，就宣布所有反例都已经找齐。

每项材料同时带着来源与读取范围。读取范围可以是整个文件，也可以是明确的行、字节或 JSON 字段。这里说的保留原文，是完整交付这一范围选出的内容；它不意味着每次都发送整个仓库。

构建时，程序从保存的来源读取内容，给所选内容算一个校验值，并记下后续展开入口。以后重新打开工作集，它会再次读取来源、执行相同选择，并重新计算必读项、排序及覆盖情况。如果保存的工作集里出现了一段替换文字，即使还挂着真实来源的引用，也不能直接通过一致性核对。

这能保护交接依据的对应关系，却不保证内容正确。例如机器输出写着“测试通过”，工作集会保留它的生产者信息，不会把这句话改标为独立审阅结论。下一位 Agent 仍需要判断这些观察支持什么。

预算计算针对最终渲染文本的 UTF-8 字节数，包含说明和结构字段，不只数正文字符，也不等同于模型的 token 数。程序按已确定的顺序尝试加入材料：加入后仍在预算内，就选入；普通交付放不下的项目可以暂不展示，并记录实际状态。

看一个教学跟踪。设预算是 4,096 字节，任务包所选原文本身已有 5,000 字节，另有用户约束、反例和前置条件。仅任务包就比预算多出 904 字节，最终文本还会更大，因为它还包含其他材料与交付说明。

普通交付不会悄悄截掉任务包尾部，再把它标为完整。如果调用方明确要求必读原文完整交付，程序会继续纳入这份任务包及其他可用必读材料，即使超过预算，并在记录中标明超额与预算回退。这次选择保住的是所选原文的完整性，不能同时宣称它满足了 4,096 字节的限制。

若任务包本身丢失，则是另一种情况。扩大预算不能恢复不存在的内容。在要求完整交付的模式下，缺少必需材料或无法交代必需类别，会返回不完整错误。下游应先修复材料来源，而不是拿一份空白材料继续执行。

第三版工作集先减少重复表示。同一来源与生产者绑定下，如果一个 JSON 对象已经完整出现，另一项材料只是其中一个字段，就可以指向已展示的对象，再核对该位置能否还原原来的字段值。相同内容若来自不同来源或生产者，仍保留分别的身份，不能因文字一样就合成同一份证据。

审计投影则是更窄的一项规则。当前实现只识别一种格式明确、检查条件完整的“没有查到已声明直接依赖”的查询回执，把它表示为查询报告了什么、搜索范围是什么、仍排除了什么。出现未识别字段、非空结果或不完整覆盖，就保留原文。它没有把“查询结果为空”升级成“任务在现实中没有任何依赖”。

因此，记录分别保存“已交付原文”和“以审计投影表示”的项目。后者得到明确说明，但完整回执没有内嵌在本次阅读内容里，不能把两组编号混作一份完整原文阅读证明。

调用方可以要求所有必读原文完整，也可以要求角色阅读义务得到交代。后一种要求允许策略规定的审计投影，前一种则不允许用投影代替必读原文。如果两个要求同时打开，完整原文优先。审计投影是否适用于某项材料，由具体阅读策略决定，不能把任意摘要都算作合格替代。

这里还有两个容易混淆的状态。全部必读原文已送到，仍不等于上游已经找全所有相关资料；所有角色类别有了范围说明，也不等于 Agent 理解了其中的内容。工作集把这些状态分开，让后续系统知道究竟还缺搜索、缺原文，还是需要真正开展判断。

已有测试文件包含长判据不被截断、低排序反例仍进入必读、缺少审阅改动材料时报错，以及工作集保存后重新核对来源等情况。这些案例说明实现要保护哪些交接行为，本文没有把阅读测试代码写成本轮重新运行，也没有据此推导任务成功率提升。

与一段生成式摘要相比，这种工作集保留了更明确的材料身份与交付范围；与整包发送相比，它允许可选内容暂缓进入阅读窗口。它采用的是来源选择、稳定排序、实际字节计量和显式回退的组合，源码不足以支持独创压缩算法的说法。

对于持续工作的 Agent，节省上下文首先需要知道省掉了什么。工作集让一次交接能够回答：这轮必须看的依据是否真的在场，没在场的部分如何继续读取，以及预算是否已经被突破。有了这些具体信息，下一步才谈得上判断怎样减少阅读量，而不把任务要求一同删掉。

更正（2026年10月26日）：初版没有说明自动派发是否使用工作集，读起来像每次交接都会这样准备材料。实际自动派发从 2026 年 9 月 7 日起在配置里关着工作集；第二段已补上。摘要和导语原先写成 Flowness 按角色组织材料，现在写明这是上下文工作集的做法。“记录所选内容的摘要”改成了“算一个校验值”，因为存下来的是校验值，不是内容概要。最后一节的小标题原作“可确认的效果”，自动派发还没有用它，谈不上效果，已改成这一节实际讲的内容：代码和测试写明了怎样取舍材料。

本篇另备有明亮、适合手机连续阅读的公众号排版稿，配图按照本文机制单独绘制。查看公众号版，或下载 Markdown、HTML、PNG 与 SVG 配图包。