Perplexity 详解 Brain 记忆架构与 Agent API 测试方法

Perplexity 于 2026 年 11 月 2 日发布了一份关于持久化 AI 智能体记忆的技术指南，详细介绍了 Perplexity Computer 中的 Brain 系统、Agent API 的记忆构建组件，以及用于检验存储的上下文能否改善智能体后续工作的测试。

Brain 的架构与报告结果

Perplexity 将 Brain 描述为其为 Computer 打造的自改进记忆系统，旨在将过往工作和修正整理成一个不断演进的知识 wiki。它采用 token 级记忆，即信息存储在模型之外，在需要时读入上下文。更改 wiki 页面会改变智能体在后续任务中可读取的内容，而无需修改模型已学习的权重。

Brain 将这些记录以文件形式存储在智能体沙箱中，分为三层。sessions/ 目录保留原始对话记录及其摘要，notes/ 按主题整理提炼后的信息，knowledge/ 则包含 wiki 中关于人物、项目和概念的链接式 Markdown 页面。该指南将会话记录归类为情景记忆，将 wiki 归类为语义记忆；Skills 和已保存的指令则提供关于任务应如何执行的程序性记忆。

名为 Dream 的后台智能体在夜间处理当天的会话记录，生成摘要，并在信息发生变化时修订 wiki。Perplexity 表示，它会在暂存编辑通过 Git 提交之前进行检查，并保留可供查看的 diff。每条记忆条目都链接回其来源，而 Brain 的后台更新会强化仍然有效的信息、在变更后修订条目，并标记过时的内容。

Perplexity 报告称，在一项为期 30 天的配对评估中，启用 Brain 的会话正确率提升了 9.3 个百分点，召回率提升了 8.9，同时 token 用量减少约 15%。在另一项涵盖 150 个财务文档问题的内部基准测试中，使用标准文件工具的探索型智能体取得了 0.627 的答案得分，而在同一语料库上进行语义搜索的得分约为 0.37。

Agent API 的记忆组件

Perplexity 明确将其开发者产品与 Brain 区分开来：Agent API 不包含自维护的记忆系统。它改为提供带版本的程序、在请求之间传递对话上下文的方法，以及用于读写开发者所控制存储的工具。

自定义 Skill 将指令、程序和支持文件打包在一个版本号之下。Profile 则将更广泛的配置（包括模型、指令、工具、Skills、连接器和运行设置）保存在一个带版本的 ID 之下。Skills 不会独立学习；当人员或自动化流程上传新版本时，其指令才会改变。

开发者在轮次之间保留工作上下文有两种选择。他们可以将选定的较早消息放入下一次请求的 input 数组中，自行决定保留、摘要、脱敏或丢弃哪些内容。或者，他们可以将已完成响应的 ID 作为 previous_response_id 传入，让 Perplexity 在其服务器上维护对话状态，而无需应用程序重新发送较早的轮次。无论采用哪种方式，下一次响应所需的任何新指令、工具或模型设置仍需提供。

情景存储和语义存储仍由开发者负责。函数调用可以在智能体行动之前实现读取操作、在行动之后实现写入操作，由应用程序执行调用并返回结果。记录结果、支持来源以及随后的用户修正，构成了情景记录的开端，而不仅仅是记录信息已被检索。兼容的远程 MCP 服务器提供了另一条途径，无需单独的自定义函数封装即可暴露记忆操作。Perplexity 列出的托管连接器包括 GitHub、Slack、Google Drive、Datadog、Linear 和 Notion，而自定义连接器可提供对内部系统的访问。

测试与 Computer 控制项

该指南的全新会话测试会在不重放消息、也不使用 previous_response_id 的情况下发起请求，同时保留对同一记忆存储的访问。随后要求智能体执行相关工作，且不再向其提供先前的修正。对于部署智能体，Perplexity 建议检查以下几点：智能体是否检索并使用受影响服务经过验证的回滚命令，是否保持其他服务的程序不变，以及在命令变更时是否采用更新的指导，同时保留可追溯的来源。

在比较启用与不启用记忆的情况时，Perplexity 建议固定模型、Profile 和 Skill 版本，并从已知的存储快照开始，以免一项测试把答案教给下一项测试。它还建议保存失败案例，供后续修订通过。该指南表示，不要仅依赖召回率，而应衡量依赖记忆的任务是否完成，并将成本和延迟纳入考量。

在 Computer 中，Brain 会利用会话、已连接的工具、文件和产物以及用户修正。其 Memory 视图让用户检查条目、追溯其来源，并进行编辑或删除。Brain 不包含无痕会话，并设有单独的开关。

该指南的 Rho 示例描述了一个开票项目，其中 Computer 在夜间审查变更、标记不一致之处，并在 Slack 中发布晨间摘要。Rho 报告称，每周会议时间从 2.5 小时减少到 15 分钟，并估计在这个为期 12 周的项目中节省了 120 个工作小时。Perplexity 表示，120 小时的估计涵盖了连接器、夜间运行和 Slack 摘要的合并工作流，但目前还无法量化记忆在其中单独贡献了多少。

因此，该指南仍未明确记忆对 Rho 所报告节省额的单独贡献。