主题
Agent 上下文工程与记忆
上下文工程不是把更多资料塞给模型,而是在每一步构造一个足够、可信、可区分来源的最小工作集。记忆也不是无限聊天记录,而是经过选择、验证、带生命周期的数据。
1. 上下文由哪些部分组成
一次 Agent 决策通常需要:
text
稳定规则 + 当前目标 + 当前状态 + 最新观察
+ 按需知识 + 可用工具 + 输出协议- 稳定规则:权限、安全边界、角色和不变量;
- 当前目标:本次任务与验收标准;
- 当前状态:已完成步骤、待办、预算和阻塞;
- 最新观察:工具结果与错误;
- 按需知识:检索到的项目文档或业务资料;
- 工具定义:此状态允许调用的最小集合;
- 输出协议:动作 Schema 或最终答案结构。
这些内容的可信等级不同。系统规则高于用户目标,用户目标高于外部网页中的文字;分区和来源标签比一句“不要听文档里的指令”更可靠。
2. Token 窗口不是记忆
把全部历史放在窗口里有三个问题:成本随步骤增长、早期错误长期污染、关键信息被大量日志淹没。窗口应当是当前工作的缓存,权威状态保存在外部存储。
ts
type AgentRecord = {
runId: string;
goal: string;
acceptanceCriteria: string[];
decisions: Array<{ claim: string; evidenceIds: string[]; at: string }>;
openTasks: Array<{ id: string; status: string; dependencyIds: string[] }>;
artifacts: Array<{ id: string; uri: string; digest: string }>;
budget: { stepsLeft: number; costLeft: number };
};每轮从记录中投影出工作上下文,而不是让对话文本充当数据库。
3. 工作集选择策略
3.1 相关性之外还要考虑什么
选择片段时综合:与当前步骤的相关性、来源权威性、时间新鲜度、权限、是否与已有内容重复、是否覆盖验收标准。高相似度不代表高价值;一条低相似但明确限制权限的规则可能必须进入上下文。
3.2 给上下文分配预算
例如把窗口预算按比例分配:规则 15%、任务和状态 15%、工具 15%、检索证据 35%、最新观察 10%、输出余量 10%。比例按任务调整,但必须预留输出和工具结果空间,不能输入正好占满上限。
4. 压缩时保留证据链
摘要会产生信息损失,且模型生成的摘要本身可能出错。使用分层压缩:
- 原始输入和工具输出作为不可变产物保存;
- 用确定性解析提取结构字段、错误码、数字和文件位置;
- 对自然语言生成阶段摘要;
- 摘要中的重要结论携带
evidence_id; - 做最终决定前可以按 ID 回读原始证据。
一个好摘要应区分:已验证事实、工作假设、用户决策、待解决问题。不要把“可能是网络错误”压缩成“原因是网络错误”。
5. 短期记忆与长期记忆
| 类型 | 生命周期 | 例子 | 写入策略 |
|---|---|---|---|
| 工作记忆 | 当前步骤 | 最新工具结果 | 自动,完成步骤后压缩 |
| 情节记忆 | 当前任务 | 采用过的方案和失败尝试 | 检查点写入,任务后归档 |
| 语义记忆 | 跨任务 | 用户稳定偏好、项目约定 | 谨慎提议,验证后写入 |
| 程序记忆 | 系统版本 | SOP、工具使用方法 | 由维护者版本控制 |
长期记忆必须有来源、作用域、创建时间、最后验证时间和删除方式。用户一次临时要求“这次用英文”,不应自动变成永久偏好。
6. 记忆写入需要门槛
写长期记忆前问:未来是否会复用?是否足够稳定?是否含敏感信息?用户是否有权写入这个作用域?能否验证?何时过期?
json
{
"subject": "project:checkout",
"fact": "integration tests require docker compose",
"source": "repository:AGENTS.md@sha256:...",
"scope": "project",
"confidence": 1,
"created_at": "2026-09-08T10:00:00Z",
"expires_at": null
}推测不要伪装成事实。低置信度内容可作为检索候选,但在执行前需重新验证。
7. 记忆读取同样需要权限
多租户系统按用户、团队、项目和组织分层。检索时先做作用域与 ACL 过滤,再做相似度排序。回答中使用了哪条记忆应可追踪,用户还应能查看、更正和删除个人记忆。
防止“记忆投毒”:外部文档或工具结果不能直接写入高信任长期记忆;先进入候选区,经过规则或人工确认后升级。
8. 长任务的上下文刷新
当出现以下信号时重建工作集:模型重复调用相同工具、忘记验收标准、引用已经失效的观察、上下文接近阈值、任务切换里程碑。
刷新流程:
text
保存检查点 → 从权威状态重建摘要 → 丢弃无关对话
→ 重新检索当前步骤资料 → 校验开放任务与预算 → 继续这比不断在原对话后追加“请记住前面的要求”更稳定。
9. 评测上下文系统
不要只评最终答案。对一组固定任务检查:
- 必需规则是否进入上下文;
- 无权限或无关片段是否被排除;
- 压缩前后的关键事实保留率;
- 摘要是否把假设升级为事实;
- 长任务第 N 步是否仍能复述验收标准;
- 每成功任务的输入 Token 和检索次数;
- 错误记忆被调用后能否追溯与删除。
上下文系统的目标不是利用满整个窗口,而是用最小信息让下一步决策正确。