PAO：为 Claude Code 预热记忆的代理编排系统

arXiv 上发表了一篇题为《PrimeAgentOrchestrator: Memory-Primed Agent Spawning for Personal AI Infrastructure》的论文，介绍了作者围绕 Anthropic 终端编码助手 Claude Code 构建的一套「记忆预热」代理编排系统 PAO，并分享了自 2025 年 12 月至 2026 年 3 月共四个月的部署经历，记录了三代上下文投递机制的演进过程。

问题动机：空上下文窗口的代价

论文开篇指出了 LLM 编码代理普遍存在的一个工程痛点：每一次新会话启动时，上下文窗口都是空的，先前工作中积累的知识被全部丢弃，需要重复探索代码库、回忆设计决策与项目约定。PAO 的目标就是打破这种「单次会话孤岛」，让 Claude Code 实例在生成时就已经携带着从用户个人数据库中编译好的相关记忆。

系统架构：双后端并行检索与文件系统注入

PAO 在 spawn 阶段并行查询两个独立运行的记忆后端：

一个 PostgreSQL 实体-观察（entity-observation）数据库，用于存储结构化记忆；
一个 Cloudflare Worker 语义检索索引，用于对非结构化内容做相似度搜索。

两路结果按照各自后端适配的检索策略融合后，通过文件系统注入方式投递——这一设计利用了 Claude Code 主代理自身的配置文件自动读取行为，将编译好的简报写到其启动路径中，从而避免了对 Claude Code 内部代码做侵入式修改。

除检索与注入外，PAO 还在管理整个代理生命周期方面加入了若干机制，包括信任预置（trust pre-seeding）、就绪轮询与错误检测，以及自适应的终端文本注入。

四个月部署：三代上下文投递的演进

作者将文章定位为一份经验报告，重点不在新算法，而在工程实践中的取舍。论文记录了过去四个月中三代上下文投递机制的演化：

第一代是最初的实现；
第二代针对第一代部署中暴露的失败模式做了重做；
第三代在前两代基础上继续迭代。

每一代设计都来自实际运行观察到的失败模式，而非纸面推理。文中还专门讨论了「桥接 PostgreSQL 与 Cloudflare 这类异构记忆系统」与「构建一个统一存储」之间的工程权衡，并给出了选择前者的理由。

评价与局限

作为一份经验报告，论文缺乏传统研究中的基准对比或定量实验，更接近一份关于个人 AI 基础设施的工程笔记。它的价值在于把「如何让 LLM 编码代理跨会话保留知识」这一现实问题落到具体实现，并坦率记录了迭代轨迹，对希望搭建类似个人代理系统的开发者具有一定参考意义。但对更广泛的 AI 行业而言，其影响较为有限。