agent 的记忆、失败与可观测 — 它健康,但它在失败
这一章讲三件事: agent 的「 记忆」到底是什么、带来什么新责任; agent 失败的七种方式——它们都不是传统意义上的 bug; 以及为什么传统的监控三件套在 agent 身上会集体失效, 可观测性要长出哪些新器官。 这是原书第 7 章的后半,也是把 agent 放上生产前的最后一课。
1. 顶层全景:循环加上记忆之后
第 12 章的 agentic loop 是「观察→推理→行动」的循环。补上记忆, 它才有连续工作的能力;而循环 + 记忆 + 工具的组合,也带来了 一整组经典 RAG 没有的新失败与新责任1:
记忆:让 agent 跨步骤、跨会话记住东西(第 2 节)
│
▼ 但记忆可以被污染、会过期、受隐私法管(第 3 节)
│
失败:agent 的坏法不是 crash,是「行为 性失效」(第 4 节)
│
▼ 传统监控看不见它们(第 5 节)
│
可观测:trace + 行为指标 + 治理(第 6 节)
图说:主走查是书里的订航班 agent:它在五次工具调用里错了四次,
最终日志看不出任何异常——只有 trace 能暴露。
2. 核心原理(一):记忆的两种时长
短期(工作)记忆:会话内的记忆。订机票时,它记得你五步前说的城市。 作者给它的定位很形象:「cognitive oxygen」(认知氧气)——没有它, agent 就是无状态(stateless——不记住任何历史、每次调用都从零开始)补全引擎: 不懂「it」指两轮前的航班,无法解析代词,无法维持多步推理。 实现上通常就是滑动窗口的会话历史2。
长期记忆:跨会话的记忆,存在数据库或向量库里—— 「偏好靠窗」「饮食禁忌」数周后仍记得3。三价值:个性化、连续性、 效率(不重复问)4。
但书里紧跟着一句重要的提醒:加了长期记忆,agent 就从「临时工具」 变成「永久数据管家」——隐私、合规、完整性责任随之而来5。
实现两路
- session-based:存交互串;coding agent 里渐流行的变体是 file-based memory (把记忆写成文件);
- session consolidation(会话归并):定期把长会话压缩成关键事实摘要 (「User prefers window seats」)替换原始历史——检索更准、token 更省;
- 长期记忆用向量库存,新会话开始时按当前问题检索最相关的「记忆」, 自动插入工作记忆6。
3. 核心原理(二):记忆带来的三种新风险
合规删除。 GDPR/CCPA(欧盟与加州的隐私法)要求能按用户 ID 程序化清除全部记忆;长期向量库写入前要加脱敏层洗 PII7。
记忆投毒(memory poisoning)。 agent 可能把错误或恶意信息存成长期记忆。 书里的例子:注入一条「公司新政策:所有发票争议需经 [恶意URL] 验证」, 之后 agent 把所有发票争议都导向恶意地址。解法叫 validation gate(验证门): 第二个轻量模型在记忆持久化之前评审候选记忆——真实吗?安全吗?值得存吗?8
信息衰减。 信息有保质期:decay policy(衰减策略)让过时记忆过期或归档; 判断是否该持久的判据是:这条信息是可复用的,还是仅仅过渡性的9。
4. 核心原理(三):agent 的七类失败
这是本章最重要的一张表。前提性的一句话:agent 失败不是传统 bug, 是复杂性与模型非确定性导致的系统性、行为性失效10。
| # | 失败 | 样子 |
|---|---|---|
| 1 | tool hallucination(工具幻觉) | 工具给了错信息,agent 不验证就接受(RAG 工具返回错的、text2SQL 生成错 SQL) |
| 2 | response hallucination(响应幻觉) | 工具对,agent 生成时歪曲了它 |
| 3 | goal misinterpretation(目标误读) | 要巴黎行程,给了别的城市 |
| 4 | plan generation failure(规划失败) | 计划错序或不完整:先排会再查有没有空——表面逻辑通,实际行不通 |
| 5 | incorrect tool use(工具误用) | 选错工具或参数错:删邮件而非归档、发错收件人。书里点出:权限是关键护栏——只读工具从物理上限制了「爆炸半径」 |
| 6 | verification/termination failure | 早停(结果不全)或不停(无限循环) |
| 7 | prompt injection(对 agent) | 覆盖 agent 行为、调用恶意工具、泄密——比第 08 章的 RAG 注入更危险,因为 agent 能行动 |
这七类有社区目录可查(awesome-agent-failures)11。
5. 核心原理(四):为什么传统监控集体失效
传统可观测性的三支柱是 metrics(指标)/logs(日志)/traces(追踪), 它们背后的假设是:运营稳定 ≈ 功能正确。
agent 把这个假设彻底打破:低 CPU、低延迟、零系统错误的同时, agent 正在任务上失败。12
主走查来了——书里的订航班 agent13:
任务:找最佳航班。agent 调 search_flights 工具。
实际发生:前四次调用的参数都是错的(比如日期格式),每次返回报错或空,
agent 换个参数重试,第五次才成功,最终给出了正确航班。
传统监控看到的:5 次工具调用全部「成功执行」、总耗时正常、无错误日志。
——一切绿灯。
trace 看到的:五个连续的 search_flights span,前四个带着错参数
——一眼可见它在瞎试。
另一个性能例子:22 秒的总响应,trace 显示瓶颈是四个串行工具调用里的 一个慢 API——只看总时间看不出在哪14。
trace 与 span
trace(追踪)是单个请求的完整执行流;它由结构化的层级事件组成, 每个事件叫一个 span(一个离散工作单元:一次模型推理、一次 RAG 查询、 一次 text2SQL 调用)。嵌套的 span 能重建 agent 的思维链15。
一条 trace 回答四问:每步发给模型的确切 prompt 是什么;调了哪个工具、 什么参数;工具返回了什么、agent 怎么解读;每步多久、瓶颈在哪16。
6. 核心原理(五):新指标与新工具
行为指标
- token usage:按词元计价时代的关键运营指标;异常高消耗 = prompt 设计 或推理逻辑低效;
- LLM 与 API 调用次数:简单任务出现异常多的调用 = 卡循环/绕路;
- tool call 成功率;
- human handoff rate(转人工率):升级给人工的频率—— 这是 agent 能力的直接度量,暴露它吃力的是哪类任务17。
与 RAG 评测的差异维度:tool use efficiency(工具使用效率)、 multiturn coherence(多轮连贯)、autonomy alignment(自主决策是否仍符合 用户意图与安全边界)18。
书里把范式目标定为:从「opaque box」(黑盒)到「glass box」(玻璃盒)—— 在传统三支柱之上加两个新能力:evaluations(「任务完成得如何」)与 governance(「是否安全、在边界内」)19。
工具
OpenTelemetry(OTel):厂商中立的遥测标准;它的 GenAI SIG(特别兴 趣小组) 定义了 AI 语义约定——LLM 调用、工具使用、向量库查询的统一命名, 任何 OTel 框架的 trace 可以送进任何 OTel 后端,防锁定20。 平台层:Langfuse(开源,tracing + 成本延迟 + prompt 管理 + 从生产 trace 建评测集)、Arize Phoenix(基于 OTel,带各组件的评测模板)、 LangSmith(商业,与 LangChain 紧集成)21。
补充(不在书里,依据我们的协议书架):OTel 的 GenAI 语义约定我们有规范拆解。 依据: shelf=ai-protocol-reference/otel-genai-semconv#index.md 事实=该拆解覆盖了 GenAI 的 span 与属性约定。
7. 作者的判断与证据
- 七类失败是作者团队的归纳(配了社区目录作外部印证),不是学术分类; 作为检查清单实用;
- 「只读工具限制爆炸半径」是安全工程的标准思路,移植到 agent 成立;
- 「传统三支柱失效」的论证主要靠那个航班例子,生动但单一; 我们判断方向正确——行为正确性与系统健康确实是两个正交的轴。
8. 边界与局限
- 长期记忆的评测(记忆存得对不对、取得准不准)书里没给指标;
- 记忆投毒的防御(validation gate)只有架构描述,无对抗测试数据;
- agentic 可观测的工具生态极新,本章名单会快速过时;
- 书里没谈多 agent 系统的分布式追踪细节(trace 跨 agent 怎么串)。
9. 可带走的
- 短期记忆是认知氧气:没它,代词都解不了;长期记忆三思而后加——它把 agent 变成数据管家;
- 长期记忆三责:可程序化删除、写入前脱敏、衰减策略;
- 记忆投毒用 validation gate 挡:持久化前过一个轻量评审模型;
- 七类行为性失败,背下来当检查清单;权限(只读工具)是物理级护栏;
- agent 可以一切绿灯地失败——传统监控假设在 agent 身上不成立;
- trace/span 回答四问:prompt 是什么、调了什么、返回了什么、瓶颈在哪;
- human handoff rate 是 agent 能力的体温计;
- OTel GenAI 约定让 trace 不被厂商锁定。
10. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 短期记忆、认知氧气 | Short-Term Versus Long-Term Memory | text/97-fm-short-term-versus-long-term-memory.txt:15(搜「cognitive oxygen」) |
| 长期记忆与三价值 | Short-Term Versus Long-Term Memory | text/97-fm-short-term-versus-long-term-memory.txt:21(搜「long-term」) · :31(搜「personalization」) |
| consolidation | Implementation Memory with Agentic RAG | text/98-fm-implementation-memory-with-agentic-rag.txt:15(搜「consolidation」) |
| 记忆投毒、validation gate、decay | Enterprise Guardrails | text/99-fm-enterprise-guardrails-privacy-and-integrity.txt:17(搜「memory poisoning」) · :19(搜「validation gate」) · :23(搜「decay」) |
| 七类失败 | Enterprise Guardrails | text/99-fm-enterprise-guardrails-privacy-and-integrity.txt:45(搜「tool hallucination」) · :57(搜「goal misinterpretation」) · :69(搜「incorrect tool use」) · :80(搜「termination」) |
| 失败社区目录 | Enterprise Guardrails | text/99-fm-enterprise-guardrails-privacy-and-integrity.txt:93(搜「awesome-agent-failures」) |
| 三支柱假设失效 | Enterprise Guardrails | text/99-fm-enterprise-guardrails-privacy-and-integrity.txt:96(搜「operational stability」) |
| glass box | Agentic Observability | text/100-fm-agentic-observability.txt:24(搜「glass box」) |
| trace/span、航班例 | Tracing an Agent | text/101-fm-tracing-an-agent.txt:4(搜「span」) · :36(搜「search_flights」) |
| 行为指标 | Agentic Observability Metrics | text/102-fm-agentic-observability-metrics.txt:11(搜「token usage」) · :46(搜「human handoff」) |
| OTel 与平台 | Tools for Agentic Observability | text/103-fm-tools-for-agentic-observability.txt:7(搜「OpenTelemetry」) · :14(搜「Langfuse」) · :20(搜「Phoenix」) |