背景：长任务智能体卡在三道坎上
短任务智能体的工程问题相对清楚：给一个目标，跑几轮工具调用，返回结果。难的是另一类工作——一次大型重构、一轮需要跑几十个小时的评测、一个要跨天推进的文献调研。这类任务会同时撞上三道坎。
其一是上下文。任务越长，塞进窗口的内容越多，而塞得越多越容易在尾部丢失关键信息。常见的应对是扩大窗口或做摘要，前者受硬件与成本约束，后者是有损压缩，被压掉的部分不会自己回来。第二道是状态。多数智能体在会话结束时把积累的经验一并丢弃，下一次启动又从零开始，同一个错误可以重复犯很多次。第三道是常驻。真实的长任务不会等人守在终端前，机器要合盖、网络会断、进程会被杀，而任务不该因此归零。
Prime Agent 的设计可以看作对这三道坎的一次整体回应，而不是逐条打补丁。它给出的两个抽象分别对准上下文与状态，第三道坎则由守护进程与子系统生命周期管理承担。理解这个分工，是读懂它后面所有工程细节的前提。
Prime Agent 本身不提供推理能力。安装后首次启动需要用 /login 选择订阅或 API Key 供应商，也就是说模型来自外部。它优化的对象是模型外围那套脚手架——上下文如何组织、状态如何沉淀、子智能体如何编排、会话如何存活。这个定位与近几个月一批 Harness 层工作方向一致，但 Prime Agent 的选择相当激进：它把脚手架本身做成了可写的状态。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
两个抽象：一个管算什么，一个管记住什么
官方把整个项目压成两句话。前一句讲 RLM：递归语言模型把上下文当作变量，把递归子智能体这类工具当作函数调用，都在一个持久 REPL 里进行。第二句讲 Continual Harness：把补充提示词、记忆、技能描述、可复用的子智能体规格存成持久状态，Prime Agent 能用小的、有证据支撑的更新去精炼它，默认本地于会话。
这两句话的分工很干净。RLM 决定「这一步怎么算」——上下文是可传递的值，工具是可以调用的函数，于是整个任务变成一段可以被程序操纵的计算。Continual Harness 决定「这次学到的东西下次还在不在」——它没有把经验写回权重，也没有改写系统提示词，而是另开一层可持久化的状态专门承接经验。
值得注意的是，这两个抽象在官方叙述里是并列的，但在工程上并不对称。RLM 是执行模型，改动它等于改框架；Continual Harness 是数据层，改动它是一种日常操作。后面会看到，这个不对称正是 Prime Agent 敢说「自改进」的底气所在。
| 维度 | RLM（递归语言模型） | Continual Harness（持续脚手架） |
|---|---|---|
| 解决的问题 | 长上下文与复杂任务的推理组织 | 经验与工作模式跨会话沉淀 |
| 核心隐喻 | 上下文是变量，子智能体是函数 | 脚手架状态是可增删改的数据 |
| 运行载体 | 持久 Python REPL | 会话本地的持久状态存储 |
| 变更频率 | 框架级变更，随版本发布 | 任务级变更，由 /refine 触发 |
| 可回滚性 | 依赖版本升级与迁移路径 | 快照与精炼历史，可回滚 |
| 关联论文 | 官方博客 RLM 条目；技术报告 arXiv 2608.23552 | arXiv 2605.09998 |
RLM：上下文即变量，子智能体即函数调用
传统智能体的工具调用是一份固定的菜单：模型输出一个结构化的调用请求，框架解析、执行、把结果塞回上下文。RLM 换了一种组织方式——持久 Python REPL 本身就是模型的主要工具，文件操作、shell 命令、工具使用、子智能体与上下文管理统统以代码形式发生。
这个转变的意义在于，上下文从「一段要被塞进窗口的文本」变成了「一个可以赋值、传递、裁剪的变量」。当上下文是变量，压缩就不再是改写提示词的艺术，而是管理变量生命周期的工程问题；当子智能体是函数，编排就不再是配置文件的语法问题，而是函数调用与返回值的语义问题。
官方给出的子智能体入口在 README 中写作 rlm.spawn，用于生成真实子智能体处理并行或后台工作，并以编程方式返回结果。需要说明的是，部分第三方技术解析把该入口简写为 rlm 函数直接调用，与 README 的写法不一致，本文以 README 为准。子智能体之间可以直接发现彼此、交换消息、引导正在进行的工作，而不必把所有协调都经由用户中转。
这样一来，一个复杂任务在形式上就接近一段程序：主流程持有目标，把子任务分派给若干子智能体，收集返回值，再决定下一步。这也是「递归」这个名字的实际含义——智能体组合智能体，结果作为一等公民流回父上下文。
/refine 能改什么，以及它永远不能改什么
/refine 是整套设计里被谈论最多、也最容易被误读的机制。它的官方描述是：审查当前轨迹，对补充型脚手架状态施加小的、有证据支撑的更新。
三个限定词都很关键。其一是「小的」——它做的是增量修正，不是重写策略。其二是「有证据支撑的」——改动要能从刚发生的轨迹中找到依据，而不是凭空生成一条新规则。其三是「补充型」——它只碰补充层，永不重写不可变的基础系统提示词。
第三条是整个机制的安全阀。基础提示词承载的是这套智能体的行为底线与角色定义，如果被纳入可写范围，一次糟糕的精炼就可能让系统偏离原始设计，而且这种偏离很难被察觉。把它钉成只读，等于给自我改进划定了一个不会滑走的锚点。在此之上，官方还记录了精炼历史与快照，支持回滚。
官方同时明确了一处容易混淆的边界：/refine 不取代打包与评审新的可执行技能。换句话说，它擅长把一次教训变成一条备注，但不擅长把一套稳定流程变成一个可被测试、被版本管理的技能包。这两件事的产出物不同、评审强度也应该不同，混在一起会让「经验」这个东西既不可测也不可审。
一套允许运行时修改自身行为准则的系统，如果没有快照与回滚，那么每一次精炼都是一次不可逆的写入。Prime Agent 把快照和精炼历史写进了机制本身，而不是留给用户自己去做备份。这个选择说明团队把「自我改进会改坏」当作默认情况来处理，而不是当作例外。对于任何打算让智能体在生产环境里长期运行、并允许它沉淀经验的团队，这条设计原则比具体命令更值得抄。
可演化的四层状态与那道只读边界
Continual Harness 把可持久化的状态分成四类：补充提示词、记忆、技能描述、可复用的子智能体规格。把它们并列起来看，能看出一条从抽象到具体的梯度。
| 状态类型 | 承接什么 | 颗粒度 | 工程含义 |
|---|---|---|---|
| 补充提示词 | 本次或此类任务追加的工作方式说明 | 粗 | 最接近传统提示词工程，但受只读底座约束 |
| 记忆 | 事实性、经验性的记录 | 中 | 相当于长期记忆外部化，避免重复犯同类错误 |
| 技能描述 | 某类工作该怎么做的方法说明 | 中 | 与可执行技能配套，描述可演化而代码需评审 |
| 子智能体规格 | 可复用的子智能体配置 | 细 | 把一次有效的分工固化成下次可直接复用的模板 |
| 基础系统提示词 | 行为底线与角色定义 | — | 不可变，/refine 永不触碰 |
官方另有一处限定容易被忽略：这些状态默认本地于会话。这意味着「越用越强」这句话的适用范围是单个会话内部，跨会话的复用依赖用户如何组织与迁移这些状态，而不是框架自动完成。把这条限定读进去，才能对效果的传播范围有合理预期。
守护进程：让会话活过终端断开
长任务的第三条坎是常驻。Prime Agent 用后台守护进程来解：活跃会话、Python REPL 状态、计划任务与子智能体在终端断开后继续运行，之后可以重新挂接。
命令行侧围绕这个能力给出了一整套运维入口：prime-agent agents 浏览运行中与已保存的会话，attach 重新挂接到某个运行中的会话，--resume 直接恢复某次会话，status 检查后台服务状态，doctor 带 --fix 参数检查并修复后台服务，update 更新，shutdown 停止所有智能体、worker 与后台服务。这套命令的密度说明团队把「会话是需要被管理的对象」当作前提，而不是把会话当成一次性的进程。
仓库提交记录里还能看到更细的工程动作。worker 恢复日志做了 checkpoint 批处理，把两次 fsync 降为一次，既保证 checkpoint 持久化的原子性，也收窄了崩溃窗口；已保存会话上下文的读取改为窗口优先，从窗口化存储读取恢复设置而非全量解析历史，官方记录这一项让 worker 恢复的 CPU 开销降低了约 140 毫秒。这些改动单个看都不起眼，但堆在一起才构成「断开再连上还能接着干」的实际体验。
子智能体、kernel 与命名空间快照
RLM 的子智能体不是轻量级的提示词分支，而是持有 kernel 的真实进程。这个设计带来了能力，也带来了成本。
从提交记录可以看到几条具体机制。子智能体在 Rust 实现中是 worker 进程，父级没有进程内访问路径，通信走冻结的 wire 协议。每个子智能体持有 kernel，停止 kernel 时会携带最终的命名空间快照关闭，并可通过 pending-stop gate 在下一次启动 kernel 时复活，从而保证下一次 kernel 使用是从一份刷新过的快照全新开始。对于已经 settle 的子智能体，系统会释放其 kernel，官方记录的单体开销约为 27MB。
27MB 这个数字是有意义的。它意味着并行子智能体的规模存在可量化的内存上限——开十个并行子智能体就要为 kernel 付出约 270MB 量级的常驻内存，这还不包括模型调用本身的开销。把并行度当成免费午餐的团队，会在这里初次遇到账单。
另一处值得注意的设计是门控：如果会话注册了 cron 或心跳作业，kernel 释放会被推迟。这说明常驻任务与资源回收之间存在显式的优先级排序，团队选择让计划的连续性优先于内存回收。
技能是可导入的 Python 包
Prime Agent 的技能不是一段提示词，而是可导入的 Python 包，内置技能创建器可以把重复出现的工作流变成项目级或个人级技能。仓库根目录下有独立的 skills 目录，每个技能带 SKILL.md；提交记录里有一条专门说明 SKILL.md 已被改为与实际发布行为一致，而不再承诺未实现的能力。
把技能做成代码包，带来的是三件提示词做不到的事：可以被版本管理、可以被测试、可以被静态检查。这也解释了上一节那条边界——/refine 可以改技能描述，但不能替代把技能打包并评审。描述可以演化，代码要过评审，两件事的严谨程度本就不同。
从工程治理的角度看，这套切分相当务实：把不确定性高的部分（经验、描述、记忆）放进可快速演化的层，把需要确定性的部分（可执行代码、底座提示词）放进需要评审的层。它没有消灭风险，但把风险放到了正确的位置上。
长任务装置：目标、心跳、计划与有界自治
面向长任务，Prime Agent 在 TUI 与自治运行两种形态下都提供了一组装置：持久目标 /goal 让一个目标及其进度跨轮次保持活跃，直到完成、暂停或被清除；/heartbeat 与 rlm_heartbeat 以及 prime-agent schedule 可以按周期或在指定时间重新进入会话；/autonomous 在配置好的轮次、token 与时间预算之内继续推进，并可以运行用户自定义的质量门禁。
关于质量门禁，官方写了一句在同类文档里不多见的话：通过的门禁只检查该门禁所验证的东西；达到上限并不意味着任务成功。这实际上是把评测可信度的问题提前摆到了台面上——一个跑通的测试只覆盖它写的那部分断言，一个跑满预算的自治过程只说明它没停下，不说明它做完了。
这句话值得被写进每一个上自治模式的团队的操作手册。自治模式最容易产生的错觉，是把「没有报错」等同于「做对了」。Prime Agent 至少在文档层面拒绝替用户维持这个错觉。
| 装置 | 作用 | 官方写明的边界 |
|---|---|---|
| /goal | 跨轮次保持目标与进度 | 需显式完成、暂停或清除才失效 |
| /heartbeat 与 rlm_heartbeat | 周期性重新进入会话 | 注册心跳作业会推迟 kernel 释放 |
| prime-agent schedule | 在指定时间重新进入会话 | 与 cron 存储共享，同样影响资源回收 |
| /autonomous | 在轮次、token、时间预算内继续 | 通过的门禁只验证其自身；达到上限不等于成功 |
| 自动压缩 | 上下文接近上限时压缩 | 默认 95% 触发，保留历史与摘要空间 |
| 保留子智能体 | 长期保留子智能体供后续复用 | 占用 kernel 资源，settle 后可释放约 27MB |
自动压缩：把上下文管理变成参数问题
当上下文是变量，压缩就成了变量生命周期管理。Prime Agent 把这件事暴露成了可调参数：/settings 以五个百分点为步长提供全局自动压缩百分比，默认 95%；底层 compaction.thresholdPercent 接受 1 到 100 的整数，也接受小数；项目级设置可以覆盖全局值。
官方文档还说明了几个容易踩坑的细节。有效触发点会为保留的历史与摘要预留空间，模型自身的输入与请求输出上限始终优先。手动压缩预算不受此设置影响。对于需要按模型提前压缩的场景，可通过 provider 作用域下的 modelOverrides 中的 contextWindow 选项设置该模型的有效上下文窗口，这个设置只影响指定模型，不改变全局压缩百分比。
这些条款看起来琐碎，但正是它们把「上下文工程」从经验活儿变成了可配置项。一个团队如果要在长任务上稳定复现结果，需要记录的不是某次提示词怎么写的，而是这批参数是怎么设的。
Rust 重写：九个 crate 与保留会话的迁移
Prime Agent 近期经历了一次完整实现语言的切换。仓库提交记录中有一个 Rust 移植条目，覆盖范围包括 agent loop、TUI、守护进程、kernel 编排、ACP transport、目录系统与完整的对等表面。重写后的代码被拆成九个 crate。
| crate | 职责 |
|---|---|
| pa-core | 会话引擎：工具、技能、提示词、压缩、精炼、kernel 与 RLM 管理、子智能体、设置 |
| pa-daemon | supervisor 与按会话的 worker，以及 wire 协议 |
| pa-tui | 基于 ratatui 的交互式界面 |
| pa-agent | 智能体循环 |
| pa-ai | 供应商接入层 |
| pa-models | 在线模型目录 |
| pa-cli | 二进制入口与组合根 |
| pa-types | 共享的 wire 类型 |
| pa-telemetry | 事件与汇出 |
版本侧，变更日志的最新发布条目为 v0.10.1，提交日期为 2026 年 10 月 21 日；仓库累计提交数超过五千次。分发侧除了官方安装脚本，还准备了 Homebrew 打包路径，安装载体中包含 kernel 运行时边车、技能、内置目录与许可证与说明文件。更新流程提供从旧实现到 Rust 实现的迁移路径，卸载旧版、安装新版并保留会话。
值得单独一提的是遥测退出机制。项目提供了 DO_NOT_TRACK、PRIME_AGENT_TELEMETRY 与配置项三条退出通道，仓库内的 cargo 配置默认设置了 DO_NOT_TRACK。对于要在受监管环境里使用的团队，这是能否进入选型清单的前置条件之一。
安全声明：它不是沙箱，责任在外部
官方在 README 里放了一段加粗警告，措辞相当直接：Prime Agent 以你的用户权限执行模型生成的 Python 与项目命令；其 worker 与 kernel 进程改善了生命周期隔离与恢复，但它们不是安全沙箱；请审阅改动，只使用可信的仓库、指令与技能；如需运行不可信的代码或指令，请在外部沙箱或受限环境中进行。
这段声明的实际含义是：隔离责任被明确推给了使用者。项目提供的是生命周期隔离与故障恢复，不是权限边界。它与「以用户权限执行代码」「守护进程常驻后台」这两件事叠加之后，形成了一个需要认真对待的组合——一个长期运行、能执行任意代码、并且边界由外部提供的进程。
官方给出的缓解建议也很具体：在可丢弃的克隆、干净的 worktree 或任何可以检查与还原的检查点上运行。这条建议应当被理解为使用前提，而不是可选的最佳实践。
还有一处口径差异需要标注。有第三方目录站依据较早的仓库快照称其说明文档未提及 Windows 支持，而当前 README 已给出 Windows 的 PowerShell 安装方式，并说明安装器会下载最新稳定版 Windows x64 构建并在安装前校验校验和。本文以 README 当前内容为准，并提示这类第三方快照存在滞后。
其一，把隔离做在外部：容器、虚拟机或专用凭据环境，不要依赖 Prime Agent 自身提供边界。其二，使用可丢弃的工作副本：可丢弃的克隆或干净 worktree，确保任何误操作可还原。其三，明确 /autonomous 的门禁覆盖范围：通过的门禁只验证它自己写的东西，达到预算上限不等于任务完成。三者缺一，长任务运行的风险敞口都会显著扩大。
本文推算：六条增量判断
以下六条为本文基于公开材料的推算，并非官方结论，供判断时参考。
其一，可演化与只读的二分，比「自改进」这个说法更重要。真正决定这套系统能否被信任的，不是它能改多少东西，而是它把什么钉死了。底座提示词只读、快照可回滚、精炼有历史，这三条共同构成了信任基础；缺任何一条，经验沉淀都会变成不可控的漂移。
其二，RLM 把上下文工程从提示词技巧变成了编程问题。当上下文是变量、子智能体是函数，压缩策略就自然落到了参数与生命周期管理上——95% 的默认阈值、1 到 100 的可调范围、按模型的 contextWindow 覆盖，这些参数化设计本身就是这一判断的证据。
其三，常驻能力的代价是权限模型的外移。守护进程让任务活过终端断开，但同时意味着一个长期存在、拥有用户权限、能执行任意代码的进程。它把隔离责任推给使用者，这不是缺陷，但必须是选型时的显性条件而非隐性假设。
其四，质量门禁的自我限定是这份文档里被低估的一句。官方主动声明「通过的门禁只检查该门禁所验证的东西」，等于把评测覆盖不足的问题暴露在运行时，而不是留给用户事后发现。这种克制在同类工具中不常见，也说明团队跑过足够多的长自治负载。
其五，Rust 重写与保留会话的迁移路径同时出现，说明项目把会话状态当资产而非缓存。在快速更换实现的同时保住用户会话，代价是要维护庞大的对等表面；这个取舍在短期内是成本，在长期是切换成本的分摊方式。
其六，子智能体的内存开销给出了并行度的价格。约 27MB 的 kernel 单体开销意味着并行规模存在可量化的上限，把并行当成免费加速的团队会在这里遇到一道明确的约束条件。这条约束在多数介绍里不会出现，但它直接决定能同时开多少路。
冷静判断：它解决了什么，把什么留给了你
Prime Agent 解决的是三件具体的事：长上下文的组织方式、经验跨轮次的沉淀方式、以及会话跨终端断开的存活方式。这三件事在多数智能体框架里要么缺位，要么以补丁形式存在，Prime Agent 把它们做进了抽象层。
它没有解决、也明确不打算解决的是边界问题。不是沙箱这句声明把隔离责任完整地交给了使用者，这与它面向长时间自治运行的定位形成了一对需要认真权衡的组合。团队没有掩饰这一点，反而把它放在 README 的显著位置，这个态度值得肯定。
还有几处口径需要在采用前自行核实。项目星数在不同第三方来源之间存在差异，从一万四千余到约两万两千不等，官方 README 未标注，建议以仓库页面实时读数为准。有第三方技术解析称其智能体与界面构建在另一个极简 harness 之上，本文未能在官方 README 中找到对应声明，故不作为结论引用。另有中文技术解析将 RLM 的概念论文指向另一 arXiv 编号，本文未取得独立核验，一并标注存疑。
对团队的实操建议是分三步走。先在不联网、可丢弃的副本上跑短任务，验证 /refine 的改动是否符合预期、快照是否可回滚；再上带心跳与计划的中等任务，观察守护进程在断开重连后的恢复质量；最后才考虑 /autonomous，并且一定要自己写门禁、自己记录门禁覆盖了什么。跳过前两步直接上自治模式，几乎必然会在权限与隔离上付出代价。