RLM 把「上下文」当成 REPL 里的一个变量，让模型写代码去查、去筛、去递归求解——这是它和普通 Agent 最本质的区别 。——FreeLamp.com 译
Prime Intellect 发布了 Prime Agent，一个面向编程工作流和长时自主任务的 Agent，底层基于 递归语言模型（RLM） 。SuperQode 通过 Agent 客户端协议（ACP）接入 Prime Agent，提供了一个 `:prime` 命令面板，覆盖模型、递归深度、目标、自主门控，以及 Agent 的后台服务。
Prime Agent 是 SuperQode 支持的 第二个 RLM harness 。第一个是 RLM Code——它在 2026 年 2 月发布，是史上第一个基于 RLM 的编程 Agent。这篇讲清楚：RLM 是什么、RLM Code 提供了什么、Prime Agent 做了哪些不一样的事、集成怎么搭的、现在还差在哪。
一个关键分工：Prime Agent 自己管自己的凭据、模型目录、执行内核和递归；SuperQode 提供的是 连接、命令面板和策略上下文 。
本文看点
01
RLM：上下文变成变量
02
RLM Code vs Prime Agent
03
集成细节与还差的缺口
01
WHAT IS RLM
什么是递归语言模型（RLM）
给模型塞大输入的传统做法，是把输入直接放进 prompt。当输入是一个代码仓库、一周的日志、或几十万 token 的转录时，这条路就走不通了——你为模型基本不看的 token 付了钱， 能留给关键部分的注意力反而变少 。
RLM 的思路（出自 2025 年的论文）把这个安排反了过来：上下文不放进 prompt，而是作为 Python REPL 里的一个变量 保存起来。模型拿到的是关于这个变量的元数据（长度和一小段预览），然后写代码去探查它——切块、过滤、搜索、总结选中的部分。某个子问题需要语言模型时，代码递归地去调用一个。
结果就是 Agent 的四个性质变了：上下文从「要花掉的预算」变成「要被查询的数据」；模型的主要动作从「选工具」变成「写代码」；递归成了自然操作；输出变得无界，因为 结果存在变量里而不是回复里 。
RLM 可以用在大代码库上，作者团队在 AI Engineer World's Fair 上做过一次在线分享。
02
RLM CODE
SuperQode 与 RLM Code
RLM Code 始于 2026 年 2 月，比 Prime Agent 早了大约六个月。它直接实现了论文里的语义：上下文作为 REPL 变量、只有元数据的根观测、用 llm_query() 做递归调用、用 FINAL() / FINAL_VAR() 结束。
HarnessSpec
runtime:
backend: rlm-code
config:
rlm_code:
profile: lid
有三个特性对后面的对比很重要。
上下文留在窗口外
用三个 profile 控制严格程度： reference （完整历史、不做分解）、 repo_evidence （根观测压到元数据）、 lid （根观测不透明、历史卸载到 history_N 变量，根模型被完全禁止累积上下文）。
沙箱化执行
策略层在 monty / docker / apple_container / command / local 间选择。其中 monty 是用 Rust 写的 Python 解释器：无文件系统、无网络、无 import、无 eval/exec，时间和内存由虚拟机限制，执行状态可冻结成字节再恢复。在这里递归边界和沙箱边界是 同一条线 。
天生被度量
奖励 profile 给每个动作打分；轨迹相似度指标（归一化 Levenshtein 距离、trigram 包含、trigram Jaccard、长度比）用来比较 harness 自身。RLM Code 是一台仪器，它要回答的问题是——「这个 harness 泛化了吗」 。
除 RLM Code 之外，SuperQode 一直有自己的递归工具 context_handle 和 spawn_harness ，在它自己的 Agent 循环里把大工件留在 prompt 之外。
03
PRIME AGENT
Prime Agent 是什么
Prime Intellect 最近发布 Prime Agent，MIT 许可、面向生产。它用了同一个核心思路，但一路上做了不同的工程决策。
持久化的 IPython 内核是暴露给模型的 唯一工具 。文件、shell 命令、技能、子 Agent，统统通过写 Python 来访问。大多数编程 Agent 提供的独立 read / grep / edit 工具被去掉了。
RLM Code 的递归是从代码里调用一个模型，Prime Agent 则直接派生整个 Agent：
handle = await rlm.run(\"review the auth module for injection risks\")
这个调用在子 Agent 被接纳后立刻返回。子 Agent 是后台服务里的一个 完整 Agent 会话 ，有自己的模型和会话目录，在派生的回合结束后通过 agent 消息回报。运行中的子 Agent 可以被列出、删除。
Prime Agent 还维护着一个「持续 harness」：prompt、记忆、技能、子 Agent 定义都放在一个结构里，Agent 在会话期间创建、更新、删除它们，带版本化条目和记录的 refine 事件。 Agent 在运行时会重写自己的操作指令。
Prime Agent 是一个 TypeScript monorepo，同时分发 Python 包 prime-agent-runtime ，它跑在 IPython 内核里而不是宿主机上。
04
DIFFERENCES
两个 harness 的差异
「RLM Code 把递归当作有界、可评分、沙箱化的计算；Prime Agent 把递归当作 带可变状态的实时进程编排 。」
1
RLM Code 作为 Python 包在进程内运行；Prime Agent 作为独立 TypeScript 进程运行，里面挂一个 IPython 内核。
2
RLM Code 用深度、分支宽度、每步子数约束递归，在子线程池里同步执行；Prime Agent 派生活的子 Agent 会话，可寻址、可丢弃、消息通信。
3
RLM Code 把上下文彻底留在窗口外；Prime Agent 正常接纳上下文，越过阈值再压缩。
4
RLM Code 默认沙箱；Prime Agent默认不沙箱。
5
RLM Code 运行时从不改自己，改进留给外层循环；Prime Agent在会话中编辑自己的 harness 状态。
6
RLM Code 产出可回放、可评分的轨迹，但不流式；Prime Agent 通过 ACP实时流式。
一句话：一个预防上下文压力，另一个吸收上下文压力；一个报告「harness 是否泛化」，另一个报告「会话里发生了什么」。两者都合理，谁也不能替代谁。
05
INTEGRATION
集成是怎么做的
Prime Agent 原生说 ACP，SuperQode 早就有 ACP 客户端，所以集成很小，大部分工作在找两个世界观不一致的地方。
连接只花了一个文件
SuperQode 的 Agent 目录是 TOML，Prime Agent 的条目就一个文件：
identity = \"primeintellect.ai\"
name = \"Prime Agent\"
short_name = \"prime-agent\"
protocol = \"acp\"
type = \"coding\"
tags = [\"open-source\", \"coding\", \"acp\", \"rlm\"]
run_command.\"*\" = \"prime-agent --mode acp\"
在写任何集成代码之前，SuperQode 就用现有 ACP 客户端驱动了 Prime Agent，直接可用。Prime Agent 报 loadSession: false ，SuperQode 靠这个能力 gate 会话恢复，正确回退到全新会话。Prime Agent 还出现在 :connect 的 Subscriptions 组里，挨着 Codex、Cursor、Muse Code、Grok。
模型选择没法走协议
ACP 选模型的方法是 session/set_model + 广告的 availableModels 列表。但对运行中的 Prime Agent 做能力探测，返回的是空的：
ACP probe
available models : []
config options : []
available modes : []
Prime Agent 什么都不广告，因为模型在进程启动时就固定了。所以 :prime model 不能切换活会话。SuperQode 改为把选择 pin 住，下次启动时作为 \——provider 和 \——model 参数应用。模型目录从 prime-agent model list 读取——这里有个怪癖：它把表格打印到 stderr 而不是 stdout（stdout 留给协议输出），第一版解析只读 stdout，一个模型都没找到。
RLM 控制是启动时设置
/goal、/autonomous、/rlm-max-depth 是会话内部命令，从进程外看根本不是命令。目标和 autonomous 模式可以作启动 flag；递归深度连 flag 都没有，从 RLM_MAX_DEPTH 环境变量读。SuperQode 把三个都 pin 住，启动时应用：
:prime depth 3
:prime goal \"get the release green\"
:prime autonomous \"pytest -q\"
:prime connect
depth 需要给 ACP 客户端加个按连接的 env 覆盖（不碰 SuperQode 自己的环境），还得进缓存 key。 :prime depth 0 直接关掉递归——allowRecursion 的计算是 depth \< maxDepth ，为 0 时子 Agent 指令从系统 prompt 里整个删掉。
观察递归
后台服务给每个会话报告 runtime 类型和 RLM 深度， :prime agents 能渲染出活的递归树：
main running active
└─ reviewer running idle depth 1
└─ test-runner running idle depth 1
1 root, 2 RLM subagent(s)
使用它
Prime Agent 自己管凭据，SuperQode 不碰 Prime Intellect 的认证、不复制 token。 :prime login 把终端交给 Prime Agent 自己登录：
curl -fsSL https://app.primeintellect.ai/prime-agent/install.sh | sh
prime-agent
# then run /login
订阅登录支持 ChatGPT Plus/Pro、Claude Pro/Max、GitHub Copilot；API key 支持 Anthropic、OpenAI、Google、Groq、OpenRouter 等。本地模型走 \~/.prime/agent/models.json ，Ollama / LM Studio / vLLM 无需 API key 或网络就能跑：
json
{
\"providers\": {
\"ollama\": {
\"baseUrl\": \"http://localhost:11434/v1\",
\"api\": \"openai-completions\",
\"apiKey\": \"ollama\",
\"compat\": { \"supportsDeveloperRole\": false },
\"models\": [{ \"id\": \"qwen3.5:9b\" }]
}
}
}
apiKey 是格式必填、被 Ollama 忽略；supportsDeveloperRole 设 false 是给拒绝 developer 角色的服务器用的。集成期间端到端验证了「SuperQode 驱动的 RLM 编程 Agent 完全跑在本地模型上、 零成本 」，推翻了「Prime Agent 不能离线」的假设。
prime 命令面板
1
:prime connect [model] 连接 Prime Agent
2
:prime models [search] 从目录选模型
3
:prime model \<provider/id> 直接指定模型
4
:prime local 注册本地模型服务器
5
:prime depth [n] 下次启动的递归深度
6
:prime goal [text] 设定持久目标
7
:prime autonomous [gate] 自主模式与完成门控
8
:prime agents / schedule / packages 会话树、定时、能力包
9
:prime status / doctor / update / login 状态、健康检查、更新、登录
06
RPC COMING
还差什么：RPC 即将到来
Prime Agent 的 IPython 内核以启动它的用户权限运行，不发 ACP 权限请求，所以 SuperQode 的审批提示在这条路上永不出现——一个 Prime Agent 会话等价于 直接跑 Python 和 shell 命令 。不可信的仓库需要外部隔离（容器或专用 worktree）。这和默认沙箱的 RLM Code 形成最鲜明的对比。
Prime Agent 不通过 ACP 发 token 用量，所以会话在 SuperQode 里没有 token 和成本统计——这些数据在 RPC 传输里有，但 SuperQode 还不支持 RPC。ACP 模式一个进程一个会话，并行工作要并行进程；会话恢复也不可用（loadSession: false）。
Prime Agent 没有 login 子命令，/login 只在交互终端里。所以 :prime login 只能挂起 SuperQode、把终端交出去。
/refine、/compact、/heartbeat 这些会话内命令在 ACP 上够不着，而且失败是静默的。你把它们当 prompt 发出去不报错，文字会到模型，一个有能力的大模型会「演」得好像命令已经跑了——集成期间用 /context 观察到了这个失败模式，它返回的是模型编造的、看似合理的会话摘要，而不是命令的真实输出。 这个坑值得记录，因为它伪装成成功。
07
PYTHON SDK
值得补的缺口：Python host SDK
官方 host SDK 是 TypeScript 包里的 createAgentSession() ；它分发的 Python 包 prime-agent-runtime 是内核侧客户端，不是 host SDK，目前不存在 Python host client。
Prime Agent 刻意暴露 ACP、RPC、JSON 三种模式用于嵌入。RPC 模式才带着正经使用需要的面：refine（带回滚）、compact（带自定义指令压缩）、get_session_stats（token 成本）、observe（子会话实时观测）、heartbeat 和 schedule。每一个都能被任何能说「管道上的 newline-delimited JSON」的语言调用。
纯 Python 重写 Prime Agent 的 RLM 引擎是场跑不赢的军备竞赛；一个 typed 异步 Python client 通过 RPC 驱动已发布的二进制，是有界的工作、有现成的消费者：
async with PrimeSession(model=\"ollama/qwen3.5:9b\") as session:
await session.prompt(\"port the auth module to the new API\")
result = await session.refine(instructions=\"...\")
stats = await session.get_session_stats()
Prime Agent 会 refine 自己的 harness，但从不评估这次 refine；RLM Code 提供整套评估装置，却不做自我改进；SuperQode 握着晋升门控。Prime Agent 提议、RLM Code 度量、SuperQode 门控——这个循环任何单一项目都搭不起来。
∞
THREE ROUTES
RLM 正在进入编程 Agent：三条路线
SuperQode 现在跑三条 RLM 路线：需要封闭、可度量的运行，用 RLM Code；需要长时间一直跑，用 Prime Agent；工作属于 SuperQode 自己的循环、必须本地离线，用递归工具。
「RLM Code 是仪器，Prime Agent 是引擎，递归工具是本地工作台。把三者放在同一个 HarnessSpec、同一个策略层、同一个证据模型下，才是 把 harness 当工程产物而非要锁定的产品 。」
TRANSLATED FROM
翻译自：Prime Agent in SuperQode: Second RLM based coding harness after RLM Code
**原文链接：**https://medium.com/@shashikant.jagtap/prime-agent-in-superqode-second-rlm-based-coding-harness-after-rlm-code-b903f8839014
END
本文由 FreeLamp.com 译，专注 AI 与底层技术架构的深度观察。
如果你觉得今天这篇有收获，欢迎 点赞、在看、转发 三连，我们下篇见。
解构 Agent 自我演化底座：DeepSeek Harness (Cordis) 与 Prime-Agent 的架构级深度比对 当 Agent 成为主力：Optiver 如何重新设计软件开发生命周期 Amazon Bedrock AgentCore 深度解析：AWS 的生产级 AI Agent 平台 10 个能够助你从Claude Code新手进阶为专家的 GitHub 核心仓库
