Prime Agent 拆解：它只给模型留了一个工具，却拿下了 2 万 Star
2 万 Star 的 Prime Agent 是一个"自改进 RLM Harness"：它只给模型留一个内置工具（持久 Python kernel），把文件操作、命令执行、子代理派生、上下文管理全变成代码；架构上用 daemon + worker + kernel 三层进程支撑"断开终端也继续跑"，并用 /refine 只改补充状态、从不触碰基础 system prompt。
综述
Prime Agent 在 GitHub 上大约 2 万 Star，自称是一个「自改进 RLM Harness」——面向编码与研究的通用 Agent，重点是长任务。
它建立在一个并不常见的判断上：Agent 的能力上限，越来越多地由 harness（承载模型的那层壳）决定，而不是模型本身。
它的两个核心抽象是：
- RLM（Recursive Language Model）：把上下文当变量（prompt-as-a-variable）、把递归子代理当函数调用，全部放在一个持久的 Python REPL 里执行
- Continual Harness：把补充提示词、记忆、技能描述、可复用子代理规格存成持久状态，Agent 可以用"小的、有证据支撑的更新"去改进它
另外一件值得单独说的事：它的 README 里明确写着，Agent 和 TUI 都构建在 pi 之上。
专业分析
一、它只给模型留一个工具：ipython
大多数 Agent 框架的思路是"工具箱"：读文件一个工具、写文件一个工具、跑命令一个工具、搜索一个工具。Prime Agent 反过来——默认运行时只暴露一个内置模型工具：ipython。
读文件、改文件、执行项目命令、转换结果、调用技能、派发子任务，全部从这个持久 kernel 里发起。带来的直接后果是：
# 状态跨工具调用、跨上下文压缩存活
config_files = list(Path(".").rglob("*.toml"))
large_files = [p for p in config_files if p.stat().st_size > 10_000]
# 长命令不阻塞：拿住句柄先结束这一轮
checks = bash("npm test")
checks.pid变量、import、解析结果、任务句柄，在后续回合里还在。这不是"给模型加个代码解释器"那么轻——它把 Agent 的全部操作面收敛到一个编程环境里，从而让"组合能力"变成写代码而不是寻找工具。
对长任务来说，这一点是决定性的：状态有地方活下来。
二、三层进程：终端一断开就消失的 Agent，不叫长任务 Agent
架构上它分得很清楚（这是它最工程化的部分）：
交互式 TUI / JSON / RPC 客户端
↓ AgentConnection（客户端执行边界）
Daemon supervisor —— 路由、附件、worker 健康、跨 Agent 消息投递
↓
Session worker（一个根会话树）
├─ AgentSessionRuntime → Root AgentSession（provider 调用、队列、工具、压缩、目标）
├─ Scheduler（调度）
├─ Root Python kernel（模型侧控制环境）
└─ RLM child runtimes（子会话 + 可选 kernel）
↓
模型 provider ＋ 会话 JSONL ＋ artifacts职责边界写得很硬：客户端只管渲染和键盘，不拥有执行；supervisor 管路由和健康；worker 拥有队列、调度、kernel 和所有后代。
于是终端关掉只是 detach，worker 继续跑着：
prime-agent list # 看有哪些还活着的 Agent
prime-agent attach <id> # 重新接上文档里有一句很实在的话值得引用：worker 和 kernel 是"为了生命周期与故障隔离"而分进程，不是安全沙箱——它们通常和客户端拥有相同的操作系统权限。愿意把这句话写进文档的项目，比含糊暗示"我们有沙箱"的更可信。
三、子代理是 rlm.spawn()：不是"叫另一个聊天窗口"
RLM 里子代理不是概念，是函数调用：
handle = rlm.spawn(...) # 真的派生一个子会话（并行或后台）关键是上下文分配：父代理保持自己的上下文聚焦，Python 拿着工作状态，子代理只收到它那个子任务需要的那部分。 这解决了一个普遍问题——多 Agent 系统里，子代理往往被塞进一大堆用不上的背景，既贵又慢。
同一条线上还有两个细节：运行中的 Agent 之间可以直接发消息、互相编排，不必都经用户中转；以及长命令的句柄机制——一个没 await 的进程组跑完时，Agent 会收到一条携带 PID 和退出码的 Shell 消息。
四、最克制的一处：/refine 不许碰基础提示词
"自改进"这个词容易让人紧张。Prime Agent 的处理方式值得单独拎出来：
/refine会审阅当前轨迹，对补充性 harness 状态做小的、有证据支撑的更新- 它从不改写不可变的基础 system prompt
- 每次改动都记录快照，支持回滚
- 补充状态默认只存在本地会话
这是一条很聪明的边界：允许经验沉淀，禁止自我重写人格。 换句话说，它能学会"这个项目里 npm 命令该这么跑"，但不能学会"我应该是谁"。对做 Agent 的人来说，这条边界划在哪里，几乎决定了一个自改进系统是可控还是失控。
关联信息与影响
把它放回生态里看，有几层关系值得注意。
它与 pi 的血缘关系是公开的：Agent 和 TUI 构建在 pi 之上，文档体系（sessions / skills / rpc / sdk / themes 这一整套）也几乎同源。这意味着一个事实：harness 层已经开始出现"底座—应用"的分工——底座负责会话、工具、模型接入，应用负责把能力组织成特定形态（这里是长任务 + 自改进）。
与多 Agent 框架（CrewAI / AutoGen 这一类）相比，它走的不是"角色编排"路线，而是"一个强控制环境 + 可派生可控子代理"。差异在于：前者定义谁和谁说话，后者定义工作的执行面和状态边界。
需要泼的冷水有两条：
- 递归子代理会放大成本与调试难度。子代理只拿必要上下文是优点，但当它们并行、后台、跨会话存活时，"到底哪一层在花钱、哪一层卡住了"会变成新的运维问题。
- "自改进"的实际收益还没有公开的量化证据。README 描述的是机制而非结果——在没有第三方复现之前，把它当成"经验沉淀机制"比当成"自我进化"更稳妥。
未来展望
短期，这类项目的价值是给长任务 Agent 画出一张工程图纸：进程怎么分、状态放哪里、断开怎么办、上下文如何分配给子代理。这套图纸会被大量借鉴——因为它解决的是所有人都会撞上的问题。
中期，如果"底座—应用"的分工成立，harness 层会像 Web 框架一样分层：底座管协议与状态，中间层管能力组织，应用层管具体工作流。到那时，"你用什么 harness"会比"你用什么模型"更能决定产品的完成度。
长期要看的则是自改进的边界会不会移动。目前它只敢改补充状态；一旦有人证明了"改更多东西也安全可控"，这条线才会真正松动——而这个证明，比任何跑分都需要更长时间。
信号强度
- 在做 Agent 产品的团队：值得把它当成架构参考，尤其"客户端不拥有执行""worker 与 kernel 分离"这两条，能省掉很多后来才发现的返工。
- 写长任务 Agent 的开发者：重点看三样——持久 REPL 的状态存活、
bash()的句柄机制、子代理的上下文分配策略。 - 关心 AI 安全的人：
/refine那条边界（可改补充状态、不可改基础提示词、快照可回滚）是目前公开项目里最值得抄的一条折中方案。 - 普通用户：现在不需要动它。但它代表的方向会影响你明年用的每一个 AI 工具——能自己接着往下干的 Agent，和每次都要你从头讲一遍的，是两种东西。
最值得看的设计取舍有三个：① 工具收敛成一个 Python REPL，状态跨压缩存活；② 子代理是 rlm.spawn() 派生出来的真子进程，只拿子任务需要的上下文；③ 自改进被严格限制在"补充状态"里，基础提示词不可改写、快照可回滚。它构建在 pi 之上——这不是又一个小工具，而是 harness 层的路线示范。
本文基于 AI 情报库收录的条目展开深析；事实性信息以原始报道为准，分析与展望为编辑观点。
原始报道：https://github.com/PrimeIntellect-ai/prime-agent（GitHub）
