用过编码智能体的人大多熟悉一种挫败感：昨天已经交代清楚的代码风格、目录约定与依赖偏好，今天开一个新会话，又要从头讲一遍。会话结束时上下文被清空，状态归零，智能体对你的项目依然一无所知。这不是模型能力问题，而是运行环境没有记忆。
开源项目 prime-agent 尝试回答的正是这个问题。它由 PrimeIntellect AI 团队开发，采用 MIT 许可证，技术栈为 TypeScript 与 Python，目前在 GitHub 上已有约 1.96 万星、2100 余次 fork。它提出的核心概念有两个：RLM 与 Continual Harness。前者是运行时范式，后者是持久化机制，两者组合起来，构成一种「越用越顺手」的智能体形态。
先厘清 RLM：它不是一种新模型架构
RLM 全称 Recursive Language Model，即递归语言模型。需要强调的是，它并不是新的模型结构，而是一种运行时范式——把语言模型与程序化执行深度结合的工作方式。项目对它的表述可以概括为四条对应关系：上下文是变量，工具调用是函数，子智能体是可以被递归调用的子程序，整个交互过程发生在一个常驻的 Python REPL 之中。
这四条对应关系里，最有价值的是「上下文即变量」。在传统用法中，上下文是一段静态字符串，被拼接、被截断、被反复重发，开发者很难对它做精细操作。而在 RLM 范式下，上下文是可编程对象：可以被读取、被计算、被裁剪、被作为参数传递给子过程。这意味着「上下文管理」从提示词技巧变成了工程问题，可以在代码层面被测试与优化。
「子智能体即子程序」同样值得单独说明。主智能体可以通过 rlm(...) 这样的函数调用把任务交给专门的子智能体——代码审查、文档生成、测试编写——并像接收函数返回值一样拿到结果；也可以借助 asyncio 之类的机制并行发起多个调用。这种设计把多智能体协作从「架构图上的概念」变成了「代码里的普通函数调用」，降低了工程复杂度。
Continual Harness：把经验沉淀成可回滚的状态
如果说 RLM 解决的是「怎么执行」，Continual Harness 解决的是「怎么记住」。它在工具与智能体之间插入了一个持久化层，把会话中形成的经验收敛成四类状态：补充提示（用于修正行为的指令）、记忆（工作习惯、项目约定、项目上下文）、技能（可导入的 Python 包）、子智能体规格（专用子智能体的配置）。
这四类状态覆盖了不同的时间尺度。补充提示处理的是即时行为纠正；记忆处理的是跨会话的偏好与约定；技能处理的是可复用的流程封装——把重复操作打成 Python 包，可在项目级或个人级复用，也能在团队内共享；子智能体规格处理的是专用能力配置。把它们分层管理，避免了把所有东西都塞进一段越来越长的系统提示里。
更关键的是更新方式。项目通过 /refine 命令触发 harness 的改进，而它的自我改进被刻意设计成保守的：从会话轨迹中寻找能够改善 harness 状态的可复用模式，然后应用「小步、有证据支撑」的更新，并保留快照以便回滚。这个约束很重要——不加限制的自我改写会带来不可预期的行为漂移，而可回滚的小步更新，把「自我改进」从浪漫叙事拉回了工程可控的范畴。
进程模型与使用方式
在进程结构上，prime-agent 采用 Daemon、Worker、Kernel 三层模型：守护进程负责长时运行与任务存续，工作进程承载具体执行，内核层提供执行环境。这个分层带来一个实际好处——Daemon 模式让任务在终端断开后仍能继续运行，用户可以从另一个终端通过 attach 重新接入并查看进度，长时任务不必担心会话中断。
使用层面，它提供命令行交互：/login 配置模型供应商，/goal 查看持续目标，/refine 触发 harness 改进，autonomous 模式则允许设定轮次上限、Token 预算与时间限制，并定义质量门禁来校验结果。项目还给出典型的适用场景：跨会话的大规模重构、科研与批量实验、多智能体编排、把重复流程封装为技能、以及在无人值守条件下的自主执行。
与常见做法的差异
把它与两类常见做法对比，差异会更清楚。一类是纯提示词驱动的会话式助手，状态随会话结束而消失，跨会话经验依赖用户手动复述；另一类是把记忆做成外部知识库或向量检索的增强方案，检索能带来上下文，但难以直接改变智能体的行为方式与工具配置。prime-agent 的做法是让状态直接影响运行环境本身——提示、记忆、技能与子智能体规格都是可执行的配置，因此经验能够改变后续行为，而不只是被检索出来供参考。
中立思辨
这套设计同样有明显的风险面，需要辩证看待。其一，持久化状态本身是一个新的攻击面与失效点：如果某次会话把错误约定写进了记忆或技能，错误会被固化并跨会话传播，而快照回滚只能救回被识别出的问题。其二，可审计性面临挑战——当行为由累积状态与模型共同决定时，复现一次具体输出比复现一次纯提示词调用要困难得多，这对需要留痕的企业场景并不友好。其三，项目目前约 1.96 万星、处于快速迭代阶段，API 稳定性、长期高负载下的状态一致性与多用户隔离能力，都还需要时间验证。其四，把上下文作为可编程变量虽然强大，但也把责任转移给了使用者：写得好是效率倍增，写得差可能比不用更混乱。
此外，其自我改进机制在多大范围内经过了系统性评测、以及在企业级部署下的权限与数据隔离方案，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
趋势研判
把视角拉远，prime-agent 代表的是一条正在成形的共识：编码智能体的竞争面，正从模型能力转向运行环境（harness）。当各家模型在通用编码任务上的差距逐步收窄，决定实际体验的往往是上下文管理、记忆持久化、工具调度与安全边界这些工程细节。
短期，这类「可积累的 harness」会先在个人开发者与小团队中验证价值，因为它们的项目约定稳定、反馈循环短；中期，随着记忆与上下文管理被抽象为可替换的组件，团队会像今天选数据库一样选 harness，而不是被单一工具绑定；长期，「上下文压缩、记忆持久化与多供应商路由」很可能成为智能体基础设施的基础原语，正如容器与消息队列之于微服务。对开发者的务实建议是：先想清楚哪些经验值得被持久化——约定与技能通常值得，一次性的临时判断通常不值得；把持久化状态当作代码来管理，纳入评审、版本与回滚流程，而不是让它悄悄在后台生长。