从 Prompt 到 Context Compiler：智能编码 Harness 的上下文工程笔记

1. 上下文不是聊天记录的同义词#

完整聊天记录具有审计价值，但并不适合直接成为每轮推理输入。历史越长，重复信息、过期判断和无关工具输出越多，模型越难抓住真正影响下一步行动的内容。

一个更清晰的上下文可以分成几层：

• 系统契约：角色、权限、禁止事项和完成标准；
• 工作区事实：仓库结构、技术栈、项目规则和当前分支状态；
• 任务状态：目标、已完成步骤、未解决问题和下一步动作；
• 检索证据：与当前问题直接相关的代码、日志、文档和配置；
• 近期交互：用户最新补充、关键决策以及刚刚返回的工具结果。

这些信息的优先级、有效期和可信来源不同，不应该被压成一段没有边界的长文本。

2. Context Compiler 要解决什么#

我把 Context Compiler 理解为一层输入编排器。它不负责替模型思考，而是负责在模型思考前完成几件确定性的工作：

1. 根据任务阶段选择需要的上下文来源；
2. 对检索结果去重、排序并保留来源位置；
3. 区分用户确认的事实、代码事实和模型推测；
4. 在 token 预算内优先保留高信号信息；
5. 将工具执行后的新状态写回任务记录，而不是只留在临时对话中。

压缩也不等于简单摘要。路径、错误码、约束和尚未验证的假设如果在摘要中消失，后续 Agent 就可能基于不完整信息继续行动。

3. 记忆应该服务任务，而不是替代事实源#

对智能编码 Agent 来说，记忆可以保存用户偏好、常用流程和过去解决问题的方法，但代码仓库、测试输出和运行日志仍然是当前事实的权威来源。

我会把信息区分为：

• 可以长期复用的工作偏好；
• 只在当前任务有效的临时状态；
• 必须重新读取的易变事实；
• 只能作为候选、不能直接执行的历史经验。

这样可以减少“记住了旧结论，却没有检查当前代码”的问题。

4. Harness 的核心是执行闭环#

在个人 Harness 的二次开发实践中，我更关注下面这条循环：

1
理解目标 → 编译上下文 → 选择工具 → 执行动作
2
    ↑                              ↓
3
验证结果 ← 更新任务状态 ← 记录结构化反馈

每个工具结果都应该回答：动作是否成功、改变了什么、还缺什么证据。只有把验证结果重新进入上下文，Agent 才不是“调用工具的聊天机器人”，而是一个可以持续修正计划的执行系统。

5. 我的检查清单#

• 当前输入里是否混入过期状态？
• 关键结论能否回到代码、日志或文档来源？
• 工具输出是否经过裁剪，但没有丢失错误信息？
• 用户偏好与项目事实是否被分开管理？
• 压缩后是否仍保留未完成事项和验证边界？
• 下一轮能否明确知道为什么要执行某个动作？

对我而言，上下文工程的目标不是让模型“看到更多”，而是让它在正确的时刻看到足够、可信且可行动的信息。