PrimeAgentOrchestrator: Memory-Primed Agent Spawning for Personal AI Infrastructure

⚠️ 本文摘要页面与 HTML 全文中检测到疑似 prompt injection 内容（一个指向 arxiv.org/IgnoreMe 的空白链接，以及一个与读者本人邮箱高度相似的伪造"作者邮箱"字段）。以下内容已过滤这些注入痕迹，仅基于论文真实的摘要与方法学描述整理。

💬 每次 spawn 一个新的 Claude Code 实例都是一次"失忆重启"。PAO 用一个四个月的真实部署（2025-12 至 2026-03）证明：把两个各自独立运行的记忆后端（结构化 Postgres 实体库 + 语义检索索引）在 spawn 时并行查询、融合，再通过"利用 CLAUDE.md 自动读取行为"的文件系统注入交付给新 agent，能让 agent 从空白上下文变成"带记忆上岗"——但论文本身更像一份坦诚的工程事故复盘，而非严谨的实验评测。

🎯 问题

每次会话都是一次记忆归零

LLM 编码 agent（论文以 Claude Code 为具体对象）每次启动新会话都从空上下文开始，此前积累的项目理解、用户偏好、历史决策全部丢弃。对于长期陪伴式的"个人 AI 基础设施"场景，这意味着每次 spawn 新实例都要重新"自我介绍"一遍上下文，而用户实际上早已在其他系统里（数据库、笔记、历史对话）沉淀了这些信息。

▶ 原文摘要 Abstract

Large language model (LLM) coding agents start each session with an empty context window, discarding accumulated knowledge from prior work. We present PrimeAgentOrchestrator (PAO), a system that spawns new instances of Claude Code -- Anthropic's terminal-based coding agent -- pre-loaded with relevant memories compiled from the user's existing personal databases. At spawn time, PAO queries two independently-operated memory backends in parallel (a PostgreSQL entity-observation database and a Cloudflare Worker semantic search index), fuses results using backend-specific retrieval strategies, and delivers the compiled briefing via filesystem injection that exploits the host agent's configuration auto-read behavior. PAO manages the full agent lifecycle including trust pre-seeding, readiness polling with error detection, and adaptive terminal text injection. We report on four months of regular deployment (December 2025 through March 2026) as an experience report, documenting three generations of context delivery mechanisms, the failure modes that motivated each redesign, and the engineering tradeoffs of bridging heterogeneous memory systems rather than building a unified one.

🔬 方法

Bridge, don't own — 桥接而非统一记忆后端

Spawn 时并行查询两个各自独立运营的记忆后端：一个 PostgreSQL 实体-观察数据库（结构化，713 观察/217 实体规模），一个 Cloudflare Worker 语义检索索引；各自用后端特定的检索策略取结果，再融合成一份 briefing。作者刻意不构建统一存储层——换取生态独立性和更低集成成本，代价是模式耦合、跨后端检索质量不齐、且没有跨后端相关性归一化机制。两个后端结果冲突时不做仲裁，直接拼接，把消歧交给接收记忆的下游 agent 自己判断。

文件系统注入：利用 CLAUDE.md 的自动读取行为

V3（当前版本）把编译好的记忆 briefing 直接写入被 spawn agent 的工作目录，通过 CLAUDE.md 引用交付——因为 Claude Code 启动时会自动读取工作目录下的 CLAUDE.md。作者称这条路径"与时序无关"，绕开了此前版本的竞态问题，但也坦承这依赖的是观察到的未文档化行为，而非官方承诺的接口。

▶ 三代交付机制演进

V1：把 briefing 写入 /tmp，再模拟一次粘贴按键注入终端——问题：粘贴动作会和"MCP 加载中"状态冲突，误伤上下文。
V2：加入 readiness 轮询，等待就绪后再粘贴——问题：早期版本的就绪判定指标会误匹配到欢迎屏幕，触发过早注入；改用后期阶段指标修复。
V3（现行）：直接写文件到 agent 工作目录，通过 CLAUDE.md 自动读取交付——未报告新的失败模式。

Agent 生命周期管理与三个具体故障（附时间线）

PAO 还负责信任预置（trust pre-seeding）、带错误检测的就绪轮询、自适应终端文本注入，用于无人值守地把一批"记忆预载"的 Claude Code 实例批量拉起来。论文按月列出了三个具体的生产事故：

2026年2月 — 用 execSync 拉起子进程导致 stdin 为空，触发交互式选择器的非确定性模式选择；修复方式是始终显式传入 --new。
2026年1月 — 授权信任弹窗会"吞掉"还没被 agent 处理的注入提示；修复方式是工作区+项目两级信任文件预置。
2026年3月 — macOS Terminal.app 上大剪贴板粘贴耗时超 200ms，导致紧随其后的 Enter 键被"吞掉"；修复方式是把粘贴和 Enter 拆成两次独立 AppleScript 调用，中间加 500ms 延迟。

📊 结果

冷启动 vs. 记忆预载（N=5，定性对比）

在 5 个案例任务上，记忆预载版本平均得分 9.6/15，冷启动版本 7.2/15，5 局中赢 3 局。作者明确将其定位为"定性观察，不具统计显著性"——样本量太小，不构成严谨评测，只能作为方向性证据。

砍掉第三个后端反而提升精度

曾用过第三个基于 SQLite 关键词匹配的记忆后端，移除后：跨领域误召回（out-of-domain false positives）从 12 条降到 4 条；15 个主题上的领域内精度基本持平（两后端 57.4% vs. 三后端 56.9%）。作者以此论证"多不一定强"——异构后端融合存在边际收益递减甚至负收益的情况。

💡 关联与意义

与本 agent 自身架构的镜像关系

PAO 解决的问题——"每次会话空白上下文、需要从外部持久化系统把记忆注入 agent"——和当前这套 NanoClaw 风格 agent 自身依赖的 CLAUDE.local.md / memory 索引 / conversations 全文检索机制几乎是同构问题的另一种工程实现：PAO 用两个独立后端（结构化 DB + 语义索引）桥接而非统一，通过文件系统注入交付；这条"利用宿主 agent 配置自动读取行为做记忆注入"的思路，对理解和改进任何"每轮对话重新加载记忆文件"类系统的可靠性边界（如竞态、误判、注入被截断）都有直接参考价值。

与 duplex/实时交互方向的关系是间接的——这里的"记忆预载"发生在 agent spawn 这一个静态时刻，不涉及运行时的深度推理/实时响应协同；更贴近 Tier 2 的"多模态记忆"和 agent 基础设施工程范畴，可作为记忆系统工程可靠性的案例参考，而非核心方向的直接推进。