Coding Agent 工作时间一长，最先失控的往往不是代码生成，而是上下文：旧错误被当成新事实，失败尝试留在对话中，工具输出不断膨胀，模型开始忘记任务边界。DeepSeek Harness 的 Trajectory、仅追加会话日志、恢复、分叉、检索和回放，为这个问题提供了一个值得观察的运行时视角。创源 AIGC 在本文中只作为可替换的外部模型节点出现，重点不在平台介绍，而在于如何治理 AI、AIGC 和 IT 研发中的上下文污染。文章适合使用 Codex、Claude Code、VSCode AI 插件、Ollama 或 LiteLLM，希望让 Agent 任务可恢复、可解释、可复现的开发者。

截至 2026 年 8 月 18 日，DeepSeek Harness 仍处于开发者预览阶段。公开说明提到，模型看到的系统提示、工具调用与结果、子 Agent 调度和上下文注入等信息会写入仅追加设计的会话日志；Trajectory 视图可以按来源查看，恢复、分叉、检索和回放共享同一事件流。本文依据这些公开设计讨论工程方法，不把当前界面、事件字段或存储实现写成稳定承诺。

一、长对话不是记忆，它只是一条越来越重的历史

很多开发者把“保留聊天记录”当成 Agent 记忆。短任务里，这种做法确实方便：模型能看到前面的需求、代码片段和测试结果。但任务持续几十轮后，聊天历史会混入过期文件、被否决方案、截断日志、临时猜测和模型自己的错误总结。历史越长，并不代表记忆越准确。

在 Coding Agent 场景中，上下文污染通常来自五个方向：

1. 文件已经修改，模型仍引用旧版本代码。
2. 某个假设已被人工否决，却继续出现在摘要中。
3. 工具调用失败，模型把空结果解释成业务事实。
4. 分支 A 的结论被带入分支 B，造成方案串线。
5. 外部文档中的 Prompt Injection 被当成运行指令。

这些问题不能只靠“换一个更长上下文模型”解决。上下文窗口变大，可以装入更多历史，也会装入更多互相冲突的信息。真正需要治理的是：哪些事件应该进入下一轮，哪些只能留作审计，哪些已经失效，哪些必须由人工确认。

我更愿意把 Agent 记忆拆成三层。第一层是事实状态，例如当前仓库提交、接口 Schema、测试结果和人工批准；第二层是运行轨迹，例如模型计划、工具调用、错误和分支；第三层是归档证据，例如完整日志和原始响应。模型每一轮主要读取第一层和少量相关轨迹，不应默认读取全部归档。

三层之间不能随意相互提升。模型在轨迹里提出“可能是缓存问题”，这只是候选假设；只有确定性工具复现或人工确认后，才能进入事实状态。归档里保存的一段旧测试日志，也不能因为包含关键词就直接进入当前上下文，必须先确认它对应的代码版本和运行环境。很多上下文污染，本质上就是把不同证据等级的内容放在了同一层。

事实状态还需要有效期。接口 Schema 可以在提交变化后失效，测试结果在依赖升级后需要重跑，人工授权在任务结束后应当过期。有效期不一定是固定时间，也可以由事件触发，例如工作区提交变化、配置文件变化或任务分支关闭。让事实能够失效，比不断追加新的“最新事实”更容易控制模型看到的内容。

对于个人项目，也可以用轻量方式实现三层结构：state.md 保存当前事实，events.jsonl 保存事件摘要，artifacts/ 保存原始报告。模型默认读取前两者的选定部分，只有遇到具体错误时才读取工件。这样不需要先建设复杂平台，也能避免把完整聊天历史当成唯一记忆。

这也是 Trajectory 与普通聊天记录的差别。聊天记录强调交流顺序，Trajectory 应该强调事件来源、状态变化和因果关系。一个“测试失败”事件需要知道由哪个命令产生、针对哪个提交、退出码是什么、后面是否被新结果替代。没有这些信息，保存再多文本也无法可靠恢复任务。

二、仅追加事件流解决的是“不能偷偷改历史”

仅追加日志的价值，不是让存储看起来更专业，而是避免历史被覆盖。模型修正计划时，不应删除旧计划，而是新增一条“旧计划失效”的事件；人工调整权限，应保留过去的授权记录，再写入新的范围和生效时间。这样才能解释任务为什么从一种状态走到另一种状态。

一个最小事件可以包含下面这些字段。示例是自定义结构，不代表 DeepSeek Harness 当前的正式 Schema：

{
  "event_id": "evt-042",
  "parent_id": "evt-039",
  "branch_id": "fix-pagination-b",
  "type": "tool.result",
  "source": "pytest-runner",
  "created_at": "2026-08-18T10:24:00+08:00",
  "workspace_revision": "git:7d31a9c",
  "input_hash": "sha256:example",
  "status": "failed",
  "summary": "2 tests failed, 18 passed",
  "supersedes": null,
  "data_class": "internal-redacted"
}

parent_id 表示因果上游，branch_id 防止不同方案串线，workspace_revision 说明事件对应哪个代码状态，supersedes 用来声明新事件替代旧事实，data_class 决定事件能否送给外部模型。完整测试日志可以保存在受控工件中，事件只保存摘要和哈希。

仅追加并不等于所有事件永远有效。事件需要状态语义：active 表示当前可用，superseded 表示被新证据替代，rejected 表示被人工否决，expired 表示授权或缓存过期，audit-only 表示只用于复盘。上下文构建器只选择允许进入模型的状态，审计工具仍可以查看完整历史。

还要区分“事实事件”和“解释事件”。测试退出码、文件哈希和权限结果属于事实；模型对错误原因的推测属于解释。解释可以帮助下一轮工作，但不能自动覆盖事实。如果模型说“失败来自网络”，而工具事件显示本地断言失败，下一轮应优先使用工具事实，并把模型解释标记为冲突。

事件顺序也不能只依赖时间戳。并行工具、不同机器和网络延迟都可能让写入顺序与真实因果顺序不同。parent_id 和分支标识用于描述“这条结果由哪个请求产生”，时间戳只用于辅助排序。如果一个测试结果找不到对应的命令事件，或者一个人工批准发生在任务分支创建之前，事件流应当标记不完整，而不是猜测关系。

为了防止重复写入，每个工具动作还需要幂等标识。运行时收到相同动作标识时，先查询已有结果，再决定返回缓存、补写事件或重新执行。特别是代码写入、消息发送和外部 API 调用，不能因为模型重试就产生两次副作用。仅追加事件流要记录重复请求及处理结果，不能简单丢弃。

事件模式本身也需要版本。增加字段通常可以兼容，改变 status 含义、分支规则或数据等级则需要迁移。回放旧任务时，应使用当时的事件解释规则，或者明确经过了哪一版迁移。否则同一个 failed 在旧版本表示工具失败，在新版本可能表示整项任务失败，审计结论会发生偏差。

三、上下文构建器比更长的 Prompt 更重要

Agent 每一轮真正看到的内容，不应该由“把最近消息都拼起来”决定，而应该由一个可检查的上下文构建策略决定。这个策略负责从事件流中选择当前任务、当前分支、当前仓库版本和当前权限范围内的信息。

可以把策略写成一份简单配置：

context_policy: coding-default-v2
include:
  - task.contract
  - human.decision
  - tool.result.active
  - file.snapshot.current
  - model.plan.latest
exclude:
  - event.status.rejected
  - event.status.expired
  - branch.other
  - data_class.restricted
limits:
  max_events: 60
  max_tool_output_chars: 12000
  max_file_snippets: 16
require:
  - workspace_revision
  - source
  - data_class

配置中的数值只是示意。真正的限制应根据任务、模型和本地测试确定。关键是让规则可见：模型为什么看到了某个事件，为什么没有看到另一个事件，压缩发生在哪一步，都可以被复盘。

上下文构建通常要经过四个阶段。第一步按任务和分支过滤，排除其他方案。第二步按状态过滤，剔除过期、拒绝和仅审计事件。第三步按来源和证据等级排序，让人工决定和确定性工具结果优先。第四步才做压缩，把长日志转换成摘要，同时保留原始工件编号。

压缩不能只让模型“总结前文”。模型可能把冲突消掉，把未知项写成确定结论，或者忽略一个看似不重要的权限拒绝。更稳妥的方式是先用程序提取结构化字段，再让模型改写可读摘要。摘要必须包含事实、待确认项、失败、被拒绝调用和当前停止条件，不能只保留成功步骤。

每次上下文注入也应产生事件，记录策略版本、选中的事件编号、被排除的类别、压缩摘要哈希和目标模型。这样，当模型给出异常回答时，开发者可以先检查它究竟看到了什么，而不是只怀疑模型能力。

上下文构建器还需要处理冲突。当两个有效事件对同一字段给出不同值时，不能只选择时间较新的一个。例如人工在早期确认旧客户端需要空数组，后来的模型摘要却写成空对象；两者来源等级不同，人工决定应优先，并产生一条冲突提示。若两个确定性工具结果冲突，则应暂停任务，检查运行环境和输入版本。

我会给每个被注入的事实附上简短来源，例如 HUMAN-12、TEST-31 或 SCHEMA-07。模型输出新计划时也必须引用这些编号。这样人工可以快速检查某个结论来自哪里，模型也不容易把没有来源的判断写成事实。来源编号不需要暴露完整敏感内容，只要能回到受控工件即可。

压缩策略要保留负面信息。测试通过、文件找到和命令成功很容易进入摘要，但权限拒绝、未解决问题和缺失样例更容易被删掉。可以把摘要固定成“已确认、失败、冲突、待确认、禁止动作、下一步”六个区块，任何区块为空也要明确写出。结构化空值比省略更容易被程序检查。

上下文预算用完时，优先减少重复工具输出和历史解释，不应先删除当前任务契约、人工决定或失败证据。如果核心事实仍然放不下，就暂停并拆分任务，而不是继续压缩到无法验证。上下文压缩是一种取舍，不是无限延长任务的手段。

四、案例：一次支付回调故障为什么需要会话分叉

下面用一个完整案例说明分叉的价值。某支付回调服务偶发重复记账，初始日志显示同一个订单在短时间内出现两次回调。开发者提出两个方向：方案 A 认为消息队列发生重复投递，方案 B 认为幂等键生成逻辑在旧客户端下不一致。

不分叉时，两个假设会互相污染

如果所有调查都在一条对话里进行，模型先搜索消息队列配置，再查看幂等代码，又读取数据库日志。几轮之后，摘要可能同时写着“队列可能重投”和“幂等键可能变化”。当新的测试只验证了方案 B，模型仍可能引用方案 A 的旧日志，产生一个混合修复：既修改队列重试，又修改幂等键。

这种混合修复看起来全面，实际扩大了变更范围，也让后续无法判断哪一项改动真正解决问题。更合适的做法是在共同事实之后分叉：

root: 订单出现重复记账
├─ branch-a: 验证消息队列重复投递
│  ├─ 读取投递日志
│  ├─ 检查消费者确认
│  └─ 结论：证据不足，暂停
└─ branch-b: 验证幂等键不一致
   ├─ 对比旧客户端字段
   ├─ 重放脱敏请求
   └─ 结论：复现成功，进入修复

两个分支共享根节点中的已确认事实，但不共享各自的模型推测和中间日志。方案 A 的“证据不足”不会被删除，它留在轨迹中，状态标记为暂停；方案 B 复现成功后，只把可验证事实合并回主线。

分叉必须冻结共同起点

创建分支时要记录仓库提交、数据样例、工具版本和权限。否则方案 A 在旧代码上运行，方案 B 在新代码上运行，结果无法比较。分支不是复制聊天文本，而是从一个明确事件和工作区版本开始创建新的因果路径。

如果主线代码在调查期间发生变化，分支要么保持冻结，要么显式 rebase，并产生新的上下文事件。不能在不记录的情况下把新文件混进旧分支。对于需要外部模型的分支，还应再次检查数据等级，不因为根任务已经授权就默认继承所有输入。

合并的是证据，不是整段历史

方案 B 得到复现结果后，合并回主线的内容包括：触发条件、请求样例哈希、失败测试、修复补丁、通过的回归测试和人工决定。模型的长篇讨论、无关搜索结果和已经否决的假设仍留在分支，只用于审计。

这能显著减少主线上下文。主线不需要重新阅读方案 B 的每个工具调用，只需要看到能够支持修复的证据包。如果未来相同问题再次出现，可以回放方案 B 的输入和检查；如果修复无效，也可以重新打开方案 A，而不是从一条混杂对话中寻找线索。

分支合并最好设置一个明确的门禁，而不是由模型自动总结后写回主线。门禁可以要求：至少一个可复现样例、一个确定性检查结果、一个代码版本哈希、一个人工决定，以及对未解决问题的列表。任何一项缺失，合并结果就只能标记为“参考信息”，不能变成主线事实。

如果两个分支都得出有效结论，也不要把完整历史拼接起来。可以建立一个新的合并事件，列出共同证据、互斥结论、采用的方案和未采用的方案。被舍弃的分支继续保留在原位置，未来仍可检索。这样的合并事件本身也是一个需要复核的工件，不能由摘要模型静默生成后直接改变任务状态。

分支还可以用于安全实验。例如在同一个根事件上创建“只读诊断”和“允许临时修改”两个分支，比较工具调用和修复质量。临时修改分支必须使用独立工作目录，不能把实验差异混入只读分支。实验完成后只合并测试和证据，不合并未经审查的文件变化。

五、恢复任务时，不能只从“最后一条消息”继续

Agent 任务可能因为模型超时、进程重启、开发者下班或权限等待而中断。恢复时若只读取最后一条消息，很容易遗漏未完成工具、未写入事件和已经变化的工作区。

一个可靠的恢复过程至少需要六项检查：

1. 当前仓库版本是否与中断时一致。
2. 是否有工具进程仍在运行或已经产生副作用。
3. 最后一个检查点之后有哪些未确认事件。
4. 权限租约、密钥和外部服务状态是否仍然有效。
5. 上下文策略和插件版本是否发生变化。
6. 人工是否修改了任务目标或停止条件。

只有这些检查通过，才能从检查点继续。工作区已经变化时，可以创建新分支或重新构建上下文，不能把旧计划直接作用于新代码。权限过期时，Agent 应暂停等待重新授权，而不是沿用历史中的批准文本。

恢复事件要明确区分 resume、restart 和 fork。resume 表示从同一状态继续，restart 表示保留证据但重新执行流程，fork 表示从某个共同起点尝试新方案。如果三个动作都叫“继续”，回放时无法判断工具为什么重复运行。

对于写操作，恢复前还要做幂等检查。上一次工具可能已经修改文件，只是模型没有收到结果；如果恢复后再次执行，就会产生重复差异。运行时应通过文件哈希、操作标识和事件状态确认副作用是否完成，再决定继续、补记事件或回滚。

恢复前还需要重新建立“当前事实快照”。快照包括工作区提交、重要文件哈希、依赖锁文件、运行配置和测试基线。若快照与中断时不同，系统可以选择创建恢复分支，或者要求人工确认是否以新状态继续。不能让模型只看到一条“上次做到这里”的消息，就默认所有外部状态仍然相同。

检查点应当有阶段语义，例如 context-ready、analysis-complete、patch-prepared、tests-running 和 human-approved。恢复时只能从满足前置条件的检查点开始。若任务停在 tests-running，可以重跑测试；若停在 human-approved 后工作区发生变化，批准必须失效，不能继续写入。

对于网络和外部服务，恢复策略要记录请求是否已经送出、响应是否已经确认和是否具备幂等键。仅凭本地进程状态无法判断外部副作用是否完成。必要时应进入人工对账，而不是自动重试。恢复能力越强，越要明确哪些状态可以自动修复，哪些状态只能人工确认。

六、Trajectory 也可能成为新的数据泄露面

轨迹越完整，越容易排查，也越可能积累敏感信息。系统提示、文件片段、命令输出、内部路径、客户编号、API Key 和模型响应都可能进入事件流。如果“为了回放”保存所有内容，Trajectory 会变成一个比普通日志更集中的数据仓库。

事件存储需要至少三层控制。第一层是写入前脱敏，密钥、令牌和个人信息不进入日志。第二层是按数据等级控制读取，外部模型、开发者和审计人员看到不同视图。第三层是保留期限，原始工具输出短期保存，摘要和哈希可以长期保留。

Prompt Injection 也会通过历史传播。网页、README、代码注释或测试报告可能包含“忽略之前规则”之类的文本。如果它们进入仅追加事件流，后续每次上下文构建都可能再次把恶意内容送给模型。事件应标记来源可信度，外部内容只能作为数据，不能改变系统指令、工具权限或任务目标。

还要防止“摘要洗白”。一段恶意文本经过模型摘要后，可能不再带有明显的注入特征，却保留了诱导方向。压缩策略应保留来源标签，摘要不能把外部资料变成人工决定。任何会影响权限、数据发送和副作用的结论，都必须来自策略或人工事件。

事件读取也应采用视图，而不是给每个用户一份相同的原始日志。开发者可以看到脱敏代码片段、工具状态和行号；安全审计者可以看到权限决定、数据等级和外发记录；外部模型只能看到经过筛选的摘要。不同视图仍引用同一事件编号，便于对账，但不共享不必要的敏感内容。

如果用户要求删除某类数据，不能简单从仅追加日志中物理删除一行再声称历史完整。可以使用不可逆的删除标记和工件撤销记录，让后续读取器不再返回被撤销内容，同时保留最小的审计证明。删除策略、保留期限和法律或组织要求应在部署前明确，不能把它留给模型自行判断。

安全扫描还要覆盖事件中的模型输出。模型可能在回答里重复密钥、内部域名或客户标识，即使原始工具输入已经脱敏，也会重新把敏感信息写入轨迹。写入事件前要做输出扫描和分级处理；扫描失败时宁可保留摘要哈希并暂停，也不要为了完整保存而原样落盘。

七、在线模型、本地模型和上下文边界如何配合

上下文治理与模型选择是两件事。Ollama 可以运行本地模型，LiteLLM 可以做接口适配和模型别名，DeepSeek Harness 负责会话、事件和上下文注入。模型节点可以替换，但当前分支、事件状态、数据等级和权限不能由模型自行改变。

创源 AIGC 如果进入这套工作流，更适合处理公开或已经脱敏的上下文摘要，例如解释测试失败、整理分支差异或生成待确认问题。完整 Trajectory、内部路径、生产日志和受限代码不应因为“模型需要背景”而整体外发。上下文构建器要先完成过滤和脱敏，再交给外部节点。

在一次非敏感的上下文兼容性观察中，测试记录的接入地址为：https://178.nz/yinc。该记录只说明测试入口，不代表模型覆盖、价格、稳定性或服务承诺。是否纳入实际任务，仍要确认数据等级、接口协议、上下文长度、日志保留、延迟、成本和替代路径。

在线节点不可用时，恢复策略也应提前定义：可以切换到批准的替代模型，可以只运行确定性工具，也可以暂停等待人工。不能为了维持会话连续性，把原本受限的事件发给未审查服务。创源 AIGC 只是一个可替换节点，Trajectory 的完整性和访问控制仍由应用侧负责。

切换模型后还要重新检查上下文格式。不同模型对长日志、结构化事件、中文字段和工具结果的处理方式可能不同，同一份摘要不能假设在所有节点上含义完全一致。适配层应固定输入 Schema、最大长度和必需字段，并用相同的脱敏样例做回放。若替代模型无法稳定引用事件编号，就应降级为只提供解释建议，不能让它继续推进需要证据的任务状态。

模型切换事件本身也要进入轨迹，记录切换原因、原节点状态、新节点逻辑名和重新注入的上下文版本。这样后续出现判断差异时，可以区分是模型变化、上下文变化还是工具结果变化。隐藏切换虽然让界面更连贯，却会损害任务的可解释性。

成本控制也应放在上下文构建器，而不是只放在网关。网关可以统计 Token 和请求，但无法判断哪些事件已经过期、哪些分支不相关。先在应用侧减少无效上下文，再由 LiteLLM 或其他接入层记录调用成本，才能避免用路由优化掩盖上下文污染。

八、怎样评估上下文治理是否真的有效

上下文治理不能只看模型回答是否流畅。一个摘要读起来很自然，仍可能遗漏关键失败或混入过期事实。评估应覆盖准确性、隔离性、可恢复性、成本和安全性。

维度	检查问题	可观察信号
准确性	当前上下文是否对应当前代码	仓库版本、文件哈希、测试事件一致
隔离性	分支之间是否互相污染	其他分支事件未进入模型输入
可恢复性	中断后能否从检查点继续	副作用不重复、未完成项可识别
可回放性	同一输入能否重建关键决策	策略版本、事件编号和工具结果完整
成本	压缩是否减少无关上下文	Token、事件数量和人工查找时间下降
安全性	敏感和不可信内容是否受控	脱敏、来源标签和权限拒绝有效

可以准备一组固定回放任务：正常完成、分支冲突、工具超时、工作区变化、权限过期和注入内容。每次升级 Harness、模型、插件或上下文策略后，用相同输入运行，比较模型看到的事件集合、最终状态、人工暂停点和副作用。

我特别关注“被排除的内容”。上下文构建器不仅要说明选了什么，也要说明哪些事件因为过期、拒绝、其他分支或数据等级被排除。如果一次升级后排除列表突然变短，可能表示更多历史被送入模型，需要人工检查。

压缩质量也可以通过反向检查验证。根据摘要中的事件编号回到原始工件，确认每个结论都有来源；随机抽取被压缩掉的失败和拒绝事件，检查它们是否会改变当前决策。若会，就说明压缩策略过度简化。

还可以设置一组“污染探针”。在测试事件流中放入已经过期的文件片段、被人工否决的结论、其他分支的日志和不可信网页指令，然后检查它们是否进入最终模型输入。探针不需要包含真实敏感数据，只要能够被检测到即可。每次上下文策略升级后运行探针，可以快速发现过滤规则是否退化。

可恢复性则要通过真正中断来验证。让工具执行到一半停止进程，修改工作区，再尝试恢复；让权限在等待期间过期；让外部请求返回未知状态。观察系统是否正确创建分支、重新核验事实、阻止重复副作用。只在顺利完成的任务上测试恢复，无法发现边界问题。

评估结果不要只汇总成一个分数。上下文准确但成本高、成本低但分支污染、恢复成功但重复外部调用，都是不同问题。保留每类失败的具体事件和修复措施，才能判断应该调整模型、策略、事件存储还是工具执行器。

九、什么时候值得建设 Trajectory，什么时候保持轻量

适合建设完整轨迹的场景，是任务跨越多个工具、多个分支或较长时间，且需要恢复、审计和人工交接。例如代码迁移、复杂故障排查、多 Agent 协作、包含外部模型的研发流程。事件流能帮助团队区分事实、推测、权限和副作用。

不需要复杂轨迹的场景也很明确：一次性的小函数补全、没有副作用的公开文本改写、人工几分钟就能完成的任务。为这些任务建设完整事件平台，维护成本可能超过收益。可以只保留任务说明、最终差异和测试结果。

更实际的落地方式是从最小事件集开始：任务契约、人工决定、工具结果、文件版本和最终验收。随后根据重复出现的问题增加分支、检查点、数据等级和回放。不要一开始记录所有模型文本，也不要把“日志越多”当成可观测性越强。

团队还需要明确事件所有者。工具插件负责工具事实，工作区服务负责文件版本，策略层负责权限决定，人工负责业务确认；模型生成的摘要不能替这些所有者发言。所有者关系写清楚后，冲突解析和升级回放会简单很多，也能避免出现“谁都可以修改当前事实”的情况。

对于小团队，可以先用 JSONL、Git 提交和工件目录完成最小实现。等任务数量增长，再引入数据库、检索和可视化。工具复杂度应跟随任务风险和重复度增长，而不是因为 Harness 支持丰富能力就一次性全部建设。

最后可以用五个问题判断：

1. 当前上下文中的事实是否对应同一个仓库版本？
2. 被否决和过期事件是否仍会进入模型？
3. 分支合并时带回的是证据还是整段历史？
4. 中断后是否能识别已完成副作用和待确认项？
5. 外部模型看到的内容是否经过数据等级与来源过滤？

如果这些问题没有清晰答案，继续增加上下文长度只会延迟问题暴露。真正可靠的 Agent 记忆，不是永远记住所有内容，而是在正确的分支、正确的时间，只提供仍然有效的事实。

结语：Trajectory 的价值，是让 Agent 知道自己为什么走到这里

DeepSeek Harness 的 Trajectory、恢复、分叉、检索和回放值得关注，不是因为它们让聊天历史更完整，而是因为它们有机会把 Agent 运行变成一条可解释的事件链。对 Coding Agent 来说，可靠上下文来自版本、来源、状态和权限，而不是消息数量。

创源 AIGC 可以作为外部模型节点，Ollama 可以承担本地推理，LiteLLM 可以处理接口适配，Codex 或其他代码模型可以提供分析，但这些节点都不应拥有修改事件历史和数据等级的权力。上下文由应用侧构建，事实由工具和人工确认，模型只在被允许的范围内作出判断。

当任务可以安全分叉、只合并证据、在中断后恢复、在升级后回放，并且能解释每次上下文注入的来源时，Trajectory 才不再是日志页面，而成为 Agent 的状态基础。对开发者而言，最重要的也不是让模型记得更多，而是让它少记错误的内容，并在需要时知道哪些事实已经失效。

记忆可靠，协作才有可靠起点。