框架如何与 Agent 协作

把记忆生产、材料检索与任务执行分开，让每一层承担明确职责。

框架原理约 4 分钟

Agent 运行时通常围绕一个当前任务工作：理解请求、调用工具、检查结果，再决定下一步。记忆框架处理的是跨越这些任务的长期信息。两者连接时，需要约定交付什么材料、保留哪些限制，以及反馈怎样重新进入记忆。

这里讨论组件职责和协作原则，不提供某个部署的调用教程。公开实现、内部服务和产品可能处于不同版本，也可能采用不同的接口形态；共同的概念不等于相同的参数或功能清单。

一次任务涉及哪些职责#

这些职责可以组合在同一个进程，也可以拆成服务。拆分方式取决于部署，语义边界仍然需要保留。例如索引负责找到候选，不能用相似度分数代替身份确认；运行时收到材料，也不能因此取得所有外部执行权限。

完整记忆库通常比一个任务需要的材料多得多。框架设计中的 ContextPack 指经过任务、时间、预算和权限筛选的一组上下文。它应当把内容和必要说明一起交付，包括来源、适用条件、重要变化和仍未解决的不确定性。

例如任务是安排下周一次讨论，系统可能需要当前时区、可用时间和沟通偏好，不需要同时提供用户所有历史经历。材料过多既增加成本，也会让过时或无关信息进入推理。选择上下文时应说明取舍，不应把“覆盖更多生活领域”当成必须多放个人信息的理由。

ContextPack 是框架层的设计概念，不要求所有实现都有同名数据结构。无论最终用结构化对象、工具结果还是文本片段交付，都应保住与当前任务有关的语义和限制。

不同运行时可能把上下文放进系统提示、工作记忆、技能说明或任务记录。投影应当说明生成依据和适用范围，避免在多个位置维护彼此矛盾的个人画像。源信息发生变化时，需要能够识别和更新旧投影。

长期偏好、可复用流程和主动触发规则也有不同用途。偏好帮助当前回答适应用户；流程描述怎样完成一类任务；触发规则决定何时检查和联系用户。把它们写入同一份长文本虽然方便，却容易模糊来源和执行权限。

运行时完成任务后，可能得到用户修正、明确选择、工具回执或新的观察。这些内容可以成为新的来源材料，再经过正常的归属、提取与关联流程。助手自己生成的建议或成功声明不能自动变成用户事实。

假设助手建议“改到周日下午”，用户没有答复，这只能记录为助手建议；用户明确说“就按周日下午安排”，才形成不同性质的证据；日历工具真正创建成功，又是另一项结果。把这三步分别保留，才能解释计划与实际执行之间的关系。

更换向量索引、模型或存储后端时，首先检查对象标识与来源关系能否保留，再检查时间、分类和删除语义是否一致。旧索引可能仍包含已修正的内容，迁移后的向量也可能与原维度不兼容。这些是需要明确处理的状态，不能以检索请求成功作为迁移完成的唯一判据。

框架的可扩展性来自清楚的输入输出职责。新模型可以提高识别或检索质量，新后端可以改善规模与延迟；是否保持了原有记忆含义，需要通过带修正、变化和缺失条件的案例验证。评估与实现边界提供了可用于这些检查的问题。