8.7 子 Agent 结果必须包含证据引用和可恢复轨迹
任务描述需要自包含：已知事实、已排除路径、允许工具、执行约束、预期输出都要明确。结果建议至少包含：
task_id: search-memory-leak-042
status: completed
result:
suspect: CacheManager::release()
verification: incomplete
supporting_evidence:
- evidence_id: E042
location: src/cache/manager.cpp
rejected_paths:
- normal_ref_counting_path
open_questions:
- 并发取消条件下是否释放资源
trace_ref: child-run-042
这个结果的价值在于：主 Agent 不需要加载完整调查历史，就可以依据证据引用继续验证。如果新测试推翻了原结论，则按 trace_ref 找回相关阶段，并对受影响的结论重新检查。
8.8 进程崩溃与外部副作用：恢复不能仅靠上下文
假设主 Agent 在第 87 轮调用 GitHub 创建 PR。PR 创建成功后，进程在写入成功事件之前崩溃。恢复时若简单重放最后一条工具调用，就可能再创建一份 PR。
TRACE 因此应为具有外部副作用的工具维护以下状态：prepared → executing → observed → committed，并为操作绑定 operation_id。恢复时先读取 Checkpoint 和 Event Log，再查询工具侧的实际完成状态；若支持幂等键则据此安全重试；若无法确认是否执行，则暂停核对，不盲目重放。
| PREPARED 记录意图 operation_id |
EXECUTING 发起工具调用 幂等键（若支持） |
OBSERVED 保存返回结果 外部 PR 编号 |
COMMITTED 提交完成事件 更新任务快照 |
| 核实已执行 补写结果事件，不重复执行。 | 状态未知 安全查询 / 幂等重试；无法确认则暂停。 |
推理回溯与执行回滚必须区分：重新进入某个历史决策节点，并不自动撤销已经发生在外部世界的操作。
8.9 每轮运行的完整闭环
把上面的模块合在一起，TRACE 每轮可以按这个顺序运行：
# 简化伪代码：展示状态依赖和提交顺序
def agent_step(task_id, user_input):
state = task_store.load_snapshot_and_events(task_id)
required = select_mandatory_state(state, user_input)
candidates = retrieve_history(state, user_input)
context = assemble_with_budget(required, candidates, state.recent)
proposal = llm.decide(context) # 模型提出行动
validate_tool_permissions(proposal)
intent = event_store.prepare(proposal) # 执行前登记
result = execute_with_recovery(intent)
artifact = artifact_store.put_verified(result.raw)
observation = extract_observation(result, artifact)
event_store.commit(observation)
invalidate_affected_decisions(observation)
if should_compact(task_id):
candidate = build_snapshot(task_id)
if validate_snapshot(candidate):
checkpoint_and_start_new_epoch(candidate)
else:
apply_safe_fallback_or_pause(task_id)
这段代码主要用于表达执行顺序。真实系统还需要处理并发、持久化事务边界、模型 API 协议、取消操作、工具超时、权限和版本冲突。
8.10 如何验证 TRACE 真正有效？
设计完整不代表性能更好。TRACE 引入事件日志、依赖图、证据检索和恢复协议，都会增加实际成本。因此需要建立至少五组基线：完整历史、滑动窗口、普通摘要、任务感知摘要、任务感知摘要加外部证据存储，再与完整 TRACE 比较。
建议使用一个可控的 100–200 轮故障诊断任务：早期证据支持排除 H1，后期注入新的 E087，使 H1 的原始排除前提不再充分，要求 Agent 在不重复全部调查的前提下重新判断。测量：
| 维度 | 指标 | 想回答的问题 |
|---|---|---|
| 任务质量 | Task Success Rate、证据支持率 | 压缩后还能否正确完成任务？ |
| 历史恢复 | 关键证据召回率、失效决策检测率 | 能否及时找到足以挑战旧结论的新证据？ |
| 重复成本 | 重复工具调用率、无效回溯次数 | 决策轨迹是否减少了反复走老路？ |
| 缓存效率 | 实际 Prefix Cache 命中、Prefill Token 数 | Epoch 是否真的减少计算？ |
| 端到端成本 | 总 Token、TTFT、总延迟、存储检索开销 | 新系统的综合收益是否为正？ |
| 恢复可靠性 | 中断恢复成功率、重复副作用次数 | 崩溃后能否安全继续任务？ |
还需要做消融实验：逐一移除决策依赖图、历史检索、子 Agent 轨迹、Epoch 机制和压缩校验，以确认每个组件分别贡献了什么。不能把原书实验 2-10 的性能数字当作 TRACE 的实验数据。
9. 结语：把上下文设计为可重建的工作视图
回看我们讨论的问题，答案逐渐清晰了。
Agent 的上下文应该优先保留影响当前决策的事实、约束和活跃假设。失败分支、历史证据和原始工具输出可以脱离当前窗口保存，但必须提供稳定、可验证的引用。当新证据挑战历史结论时，系统应当能够重新加载有关信息，并对受到影响的决策进行选择性复核。
KV Cache 则在另一层发挥作用：静态前缀尽量稳定，在一个 Context Epoch 中以追加为主，达到合适条件后允许受控地压缩与重建。这是对缓存效率、信息完整性和任务正确性的工程权衡。
最终形成的是三种状态的分工：
- Execution State：已执行什么、外部副作用是否完成、如何恢复。
- Decision State：为什么作出这个判断、依赖什么证据、何时需要重新评估。
- Inference State：当前 LLM Context 与暂时驻留的 KV Cache。
对于短任务，简单摘要可能已经足够；对于持续百轮、证据复杂且要求可恢复的 Agent，状态管理会逐渐成为比截断 Token 更重要的基础设施。
TRACE 的价值目前是一种可检验的架构假设：让推理上下文可以丢弃和重建，让重要的任务状态和决策证据具备可靠的持久性。要证明它成立，仍需要在真实长任务中测量正确率、重复调查、缓存命中、恢复成功率和综合成本。
参考资料
- 李博杰，《深入理解 AI Agent》，第 2 章「上下文工程」，特别是 2.7「上下文压缩策略」。本文关于六类压缩策略及实验 2-10 的数据取自此处。
- Packer et al., MemGPT: Towards LLMs as Operating Systems, 2023。用于理解分层上下文与外部记忆。
- Liu et al., Lost in the Middle: How Language Models Use Long Contexts。用于理解长上下文中信息位置对使用效果的影响。
- vLLM Automatic Prefix Caching。用于了解基于前缀块哈希的 KV Cache 复用约束。
- LangGraph Durable Execution。用于理解检查点、执行重放与副作用恢复。