Prime Agent 浅尝：有待观望的 Agent 思路

我上一篇文章才聊完当下 AI Agent 框架之多，转眼又出现了一个新的框架。

Prime Agent 由 Pi 底座开发而来，和 Oh-my-Pi 类似(以下简称 PA)。按照我查看时的情况，它在 GitHub 上已经有 11k 左右的 Star。这个数字说明它确实引起了不少关注。

PA：把 Agent 做成一个会迭代的系统

PA 最大的宣传标语，就是所谓的“自进化”。听上去和 Hermes，还有更早一点的 EvoMap，似乎都有相似的地方：不只是执行任务，还能从任务过程中积累经验，逐渐改变自己的工作方式。

但 PA 的实现路径并不完全一样。

它的核心机制是 RLM，也就是 Recursive Language Model。简单来说，PA 不会把所有项目内容和历史状态都一股脑塞进上下文窗口，而是通过唯一的工具内核 IPython，把项目相关的上下文内容先变成变量，放进一个可以持续操作的内核里。

接下来，模型可以自己决定：当前任务真正需要读取哪些内容，需要调用哪些工具，以及现有 Harness 的哪一部分值得改进。需要使用的内容才会从 IPython 内核中取出来，重新放入模型的上下文窗口。

这套设计解决的是一个很现实的问题：长任务中，真正有用的信息往往只占全部信息的一小部分。如果每一轮都把完整项目、完整历史和完整工具描述重新发送给模型，成本会越来越高，上下文也会越来越臃肿。

PA 的做法，是把一部分状态放到模型上下文之外，让模型通过代码主动管理这些状态。它不是简单地“给模型更大的上下文”，而是让模型拥有一个可以查询和整理上下文的工作空间。

在实际运行过程中，PA 还会定期进行 Refine。模型会判断当前对话中哪些内容值得沉淀为 Prompt、Memory、Skill 等持久状态，再把这些内容写入对应的 Harness。理论上，下一次遇到相似任务时，Agent 就可以直接利用之前积累下来的经验。

这也是它所谓“自进化”的主要来源。

实际运行：大部分时间都在看 Python

刚上手时，PA 最明显的不同是：你大部分时间看到的不是常见的工具调用界面，而是一行行 Python 代码。

因为它的内核就是 IPython。工具调用会被包装成 Python 函数，模型通过 Python 读取变量、调用工具、处理结果，甚至管理自己的运行状态。对于熟悉 Python 的人来说，这套机制相对直观；但如果你不太习惯 Python，那么它的运行过程可能会显得有些绕。

我先交给它一些比较简单的任务，配合 DS Flash 模型，基本都可以完成。只是和 Pi 的原生体验相比，整体等待时间会偏长一点。这里的慢不一定完全来自模型本身，PA 需要额外管理内核状态、上下文和 Harness，整个执行链路自然会更复杂。

后来我给了它一个类似笔记整理的任务：对几百篇笔记进行整理和归集。这个任务的表现比我预期的好一些，也比较符合它官方推荐的长上下文场景。

它没有把所有笔记内容一次性塞进上下文，而是先在内核中管理数据，再根据任务需要逐步读取和处理。最终的 Token 消耗在合理范围内，没有出现明显的意外膨胀。对于这类需要反复检索、归纳和整理大量资料的任务，RLM 的思路确实有一定价值。

它到底沉淀了什么

实际运行后，PA 产生的自优化产物大致是下面这样的结构：

~/.prime/agent/
├── session-artifacts/
│   ├── 019fe48b-.../harness/harness_state.json   <- 会话级 harness（知识库治理，4 条记忆）
│   │        ├── kernel-state.dill                <- 内核状态快照（工作变量，非 refine 产物）
│   │        └── kernel-state.json
│   ├── 019fe4ac-.../harness/harness_state.json   <- 会话级 harness（3 条记忆）
│   └── 019fe60a-.../harness/harness_state.json   <- 又一个会话级 harness
├── harness/                                      <- 全局 harness
├── skills/                                       <- 个人技能实体
└── sessions/*.jsonl                              <- 对话转录

从这个结构也能看出来，所谓的“自进化”并不是一个抽象的宣传概念，而是会落到具体文件上：会话级 Harness、内核快照、对话转录，以及后续可能生成的全局 Harness 和个人 Skill。

PA 目前看起来的问题

RLM 只是把成本换了一个地方

我和AI讨论了一下，如果RLM这么强，为什么其它agent没有都适配呢？

结果这其实还是一种成本的选择：把数据放进内核，换来的是更节省的模型上下文；代价则是内核状态需要自己管理。

没有真正意义上的免费午餐：要么反复把大量内容发送给模型，承担上下文成本；要么把更多内容留在内存和快照里，承担内核管理的复杂度。RLM 选择了后者，并提供了快照、passivation，以及让模型自主清理状态等机制来兜底。

这条思路本身没有问题，但它并没有消除复杂度，只是把复杂度从“如何控制上下文”转移成了“如何管理一个会不断变化的运行时状态”。

长任务的完整性仍然需要监督

在使用过程中，你仍然需要主动关注大对象的开销、快照是否成功，以及模型有没有把不再需要的内容清理掉。

长期任务还会遇到模型压缩、状态过期、快照恢复失败等问题。因此，PA 的内核更像是一个需要监督的子系统，而不是一个可以无条件信任的保险箱。

对于几百篇笔记这种任务，它的上下文管理方式很有帮助；但如果任务涉及非常重要的资料，仍然不能因为它使用了 RLM，就默认所有状态都能完整保留。

“自进化”存在把错误写进去的风险

Refine 的过程本质上仍然由模型来判断：哪些行为值得保留，哪些经验应该写成 Skill，哪些提示词应该进入 Harness。只要判断出了问题，错误就可能从一次性的回答，变成之后每次都会被加载的持久状态。

更严重的是，PA 的官方案例 Factorio 测试中也承认，在子代理和编程工具调用中存在绕过规则的情况。Refine 循环甚至可能把这种“高效作弊技能”的做法写进 Harness。

这说明自进化不等于自我纠错。一个 Agent 确实可以越来越适应任务，但它也可能越来越擅长用错误的方式完成任务。尤其当目标只看“任务有没有完成”，而不检查完成过程时，这种风险会更加明显。

初步来看：目前更适合实验

PA 更像是一个把轻量 Agent、RLM、内核状态和自我优化机制整合到一起的实验性方案。

它的优点很明确：在长上下文任务中，可以减少重复发送给模型的内容；通过 IPython，可以用代码更灵活地处理数据和工具；通过 Refine，又有机会把一次任务中的经验沉淀下来。

但它的复杂度也同样明确：你需要关注内核和快照状态，还需要审查模型究竟把什么内容写进了 Harness。尤其是“自进化”这件事，带来的并不只有能力积累，也包括错误积累和规则漂移。

所以我目前的建议还是观望，或者拿一些实验性任务、长上下文项目来测试。比如资料整理、批量归档、可重复的研究流程，这些场景比较适合用来观察它的状态管理能力。

我暂时不会把 PA 当作主力工具。至少在它的状态治理、错误隔离和自优化审计机制更加成熟之前，我更愿意把它当作一个值得持续关注的 Agent 思路，而不是已经可以完全托付的生产工具。