第三部分：记忆与知识¶
到了这个阶段，你的智能体已经不只是会推理，也不只是能安全地走到动作边界。在同一个支持场景里，接下来会出现一个新的诱惑：给它加上记忆，这样它就不用每次运行都从零开始，也能保留用户历史。
这一部分的快速路线
如果你想快速读完关键部分，可以这样走：
这三步合在一起，才构成一个可以被当作工程系统讨论的记忆层，而不是一句“给智能体加记忆”。
第三部分规范案例路线（Part III canonical case routes）
在记忆/检索层（memory/retrieval layer）中，三个规范案例（canonical cases）会检查不同风险。支持分诊（Support triage） 检查临时工单状态（temporary ticket state）、重复工单上下文（duplicate-ticket context）和已批准 playbook 检索（approved playbook retrieval）。内部知识助手（Internal knowledge assistant） 检查来源归因（source attribution）、新鲜度窗口（freshness window）、租户边界（tenant boundary）和记忆来源（memory provenance）。事故协调（Incident coordination） 检查事故时间线（incident timeline）、负责人交接摘要（owner handoff summaries）、升级状态（escalation status）和事件后经验（post-incident lessons）。
这一部分解决什么问题¶
这一步是对的，但也正是在这里，很多系统开始悄悄积累技术债。对于这个支持智能体来说，如果记忆层不是受控层，原本有价值的状态很快就会变成持久错误来源。
- 什么都往记忆里存；
- 不区分用户画像记忆和工作上下文；
- 把不可信文本不加检查地重新塞回提示；
- 直接在热路径写记忆，一次错误立刻变成持久状态。
这一部分我们会拆解，怎样让记忆真正有用，而不是把它做成一个长期存在的注入源、泄漏源和怪异行为来源。
本部分内容¶
- 第 5 章：为什么智能体需要记忆，以及为什么记忆很危险
- 第 6 章：短期记忆、长期记忆与用户画像记忆 这一章继续同一个支持场景，讲的是团队应该把运行结束后的哪些东西留下来，哪些东西绝不能固化进记忆。
- 第 7 章：检索、压缩与后台更新
这一部分之后去哪里¶
读完这一部分之后，下一步自然就是 第四部分：同一个智能体不仅要记住上下文，还要通过受控工具、沙箱和执行契约去真正做事。