版本 5：上下文隔离与分层记忆

让长任务和重复使用更稳定，而不是把所有历史塞给模型。

它解决什么问题

随着计划和工具轨迹增长，模型会被无关内容干扰；重复客户研究又在浪费已验证事实。版本 5 把上下文选择、短期任务状态、长期知识和最终产物分开治理。

核心定义与工作原理

Planner 只看目标、约束和任务摘要；Executor 只看当前子任务、必要证据与工具说明；Editor 看结构化证据包而非完整轨迹。Working Memory 随任务结束清理，Episodic Memory 保存可复用经验，Semantic Memory 保存带来源和有效期的事实，Artifact Store 保存报告版本。

架构视图（Architecture View）

分析时固定追问：谁拥有控制权，状态存在哪里，模型能决定什么，失败从哪里恢复，人工在哪个边界介入，运行证据如何被观察。

产品视图（Product View）

用户会感到系统更连贯、少重复询问，但必须能查看、纠正和删除记忆。指标包括上下文令牌、检索命中率、陈旧事实率、用户纠错率、跨会话复用收益和数据删除完成率。

简单实践

为四个角色各列“必须看、可以看、绝不能看”。设计一条记忆写入策略：只有经过验证且带来源、租户、时间和置信度的数据才能进入长期记忆；再设计过期与纠错流程。

实践只要求架构图、状态或消息契约、失败路径和产品指标，不要求安装依赖或运行代码。

正常场景

任务按约定入口进入，编排层保留业务状态，各节点或 Agent 产出结构化结果，质量门控制下一阶段，用户获得可理解的进度与最终产物。

失败与恢复场景

模型超时、工具失败或子任务质量不足时，区分可重试、可降级和必须人工接管的错误。恢复应依赖业务状态或检查点，而不是把整段任务盲目重跑。

什么时候使用

核心抽象与任务形态一致。
团队能运维它的状态、观测和升级路径。
能满足审批、权限、恢复与成本约束。

什么时候不要使用

短对话和一次性任务不需要复杂记忆系统。不要把聊天记录等同于记忆，不要在租户间共享私有事实，也不要让旧记忆覆盖新来源。

Trade-offs

获得	代价
更清晰地表达目标架构	增加建模和治理成本
复用运行与生态能力	接受版本、依赖和迁移成本
提升自主性或协作能力	增加时延、成本与故障面

产品视角

用户与业务问题：解决哪个可量化瓶颈？
产品价值：提升成功率、速度、可控性还是覆盖范围？
用户体验：进度、等待、切换和失败是否可理解？
自主性边界：哪些判断交给模型，哪些由代码或人决定？
数据与权限：状态、敏感数据和工具权限如何隔离？
失败与降级：能否重试、续跑、切回简单流程或人工处理？
产品指标：完成率、P95 时延、单任务成本、人工介入率、恢复成功率。

框架中的对应实现

Context builder、private state、memory service、vector/structured retrieval、artifact store 与 provenance metadata。

Workflow、Graph Orchestration、Supervisor、Handoff、Context Isolation、HITL、Durable Execution、Evals。

检查清单

[ ] 产品约束先于实现选择
[ ] 区分代码控制与模型控制
[ ] 明确状态事实源、预算和恢复点
[ ] 覆盖权限、审计和可观测性
[ ] 记录组织成本与退出方案

延伸练习与参考资料

用同一产品场景改画另一种架构，比较运行语义而非 API 长短；继续阅读对应框架的官方架构、持久化、HITL 与观测文档。