Prime Agent 把 Coding Agent 从工具调用推向可恢复工作流

Prime Agent 的价值不在多给工具，而在把长任务变成可恢复、可分派、可沉淀经验的工程工作流。

一个 Coding Agent 真正难处理的任务，通常不是改一行代码，也不是调用几个工具。难的是它已经跑了半小时，手里有一堆中间结论、脚本、日志、子任务和未完成的判断，然后用户关掉终端、换个问题、或者让它继续查另一条线索。

很多 Agent 系统会把这个问题简化成上下文窗口问题：窗口再大一点，摘要再聪明一点，历史再压缩一点。Prime Agent 的思路更像工程系统：别指望模型记住一切，把长任务拆成可恢复的会话，把中间状态放进可编程环境，把验证过的经验沉淀为下一次能复用的补充状态。

这也是它和普通工具式 Coding Agent 的分界线。工具越多，只能扩大一次任务的操作半径；工作流能自恢复、自分派、自积累，才会改变 Agent 处理复杂任务的方式。

项目地址：https://github.com/PrimeIntellect-ai/prime-agent

长任务失败，往往不是模型不会写代码

短任务里，Agent 的能力很容易判断。能不能读文件，能不能改代码，能不能跑测试，能不能解释报错。问题规模一旦拉长，评价标准就变了。

一个真实的工程任务可能会经历这些状态：

读了半个仓库，才发现入口不在主服务，而在一层生成代码后面。
跑了三轮测试，失败原因分别来自配置、mock 和真实逻辑。
两个子方向都值得查，但其中一个最终证明是噪音。
中途产生的脚本、日志切片和调用图，比聊天记录本身更有价值。
下一次再做类似审查时，团队不想让 Agent 从零摸索。

普通工具式 Agent 会把 read、edit、bash、search 这些工具直接暴露给模型。这个模式对短任务很顺手，但它有一个天然问题：每次工具结果都往对话里塞，模型要在聊天上下文里同时承担控制流、数据存储、状态恢复和任务调度。

Prime Agent 选择了一条更绕但更适合长任务的路。它默认只给模型一个 ipython 工具，让模型在一个持久 Python REPL 里组织工作。文件读取、shell 命令、临时分析脚本、MCP、skills、子 Agent，都可以通过 Python 组合起来。

图：Prime Agent 将工具调用收束到可恢复的 REPL 工作流

这个设计的关键不在 Python 本身，而在控制权的位置发生了变化。模型不再把每一步工具调用都当成对话片段处理，而是可以写循环、建索引、保存变量、生成临时脚本，并在需要时把独立调查分派出去。

图：Prime Agent 把工具调用、中间状态和子任务统一放进可恢复工作流。

RLM 的价值：让模型递归调用模型，而不是硬扛上下文

RLM 是 Recursive Language Model。它不是一个新模型，也不是某家 provider 的接口。更准确的说法是：它是一种 Agent 运行方式，让父 Agent 可以把语言模型当作可递归调用的工作单元。

在 Prime Agent 里，父 Agent 遇到可拆分任务时，可以通过 rlm(...) 启动 child Agent。child Agent 拥有自己的上下文、会话目录和执行过程，完成后再把结果通过消息或文件交回父 Agent。父 Agent 不必把所有中间探索都塞进主上下文。

图：RLM 让父 Agent 把独立调查拆给 child run

这和多开几个聊天窗口不是一回事。Prime Agent 的 child run 由 runtime 管理，有 admission、session 目录、深度限制、模型参数和回收路径。rlm() 调用本身只确认子任务被接收，后续结果通过异步方式回来。这一点对慢任务很重要，因为有些调查不该阻塞主 Agent，也不该把半成品结论同步塞回主上下文。

RLM 带来的收益可以拆成三层：

层次	解决的问题	Prime Agent 的处理方式
控制流	大任务无法靠线性对话推进	父 Agent 保持主线，子 Agent 分担独立调查
状态	中间结果容易丢失或污染上下文	REPL、session artifacts 和结果文件保存过程状态
协作	多个调查方向需要并行推进	`rlm(...)`
以 callable 的形式启动 child Agent

对工程任务来说，主 Agent 最重要的职责不是亲自看完每一行材料，而是决定哪些线索值得继续、哪些结论已经验证、哪些风险需要回到主线。

Self-improving 不是模型自己长脑子

Prime Agent README 里把自己称为 A Self-Improving RLM Agent。这个词容易被误读。这里的 self-improving 不是模型权重自动更新，也不是让系统偷偷改底层 system prompt。

它指的是一套可审查的经验沉淀机制。Prime Agent 有 Continual Harness。一次任务中，如果某个做法被真实仓库、真实命令和真实反馈证明有效，/refine 可以把它整理成 prompt note、memory、skill description 或 subagent specification。这些内容作为 supplemental state 注入后续会话，而不是覆盖 immutable base system prompt。

图：经验沉淀通过可审查状态进入后续会话

这套机制比泛泛的记忆更适合团队流程。记忆如果没有边界，迟早会变成垃圾场。Prime Agent 强调的是小步写入、证据支撑、可审查、可回滚。一次 release audit 的检查顺序、某类仓库的常见失败模式、线上问题复盘时的日志定位路径，都可以沉淀下来。下次遇到类似任务，Agent 不必从零开始撞墙。

这里的工程取舍很清楚：它没有承诺模型本身变聪明，而是把可复用的工作方法变成系统状态。这比“让模型记住一切”更可控，也更容易被团队接受。

哪些任务值得用 Prime Agent

Prime Agent 的运行时更重，复杂度也更高。它不适合所有场景。判断标准可以很朴素：如果 5 到 10 分钟能说清楚、查清楚、改完，用普通 Agent 更轻；如果任务会持续几十分钟到几小时，需要恢复状态、分派子任务、跑实验、沉淀经验，Prime Agent 才开始显出价值。

任务类型	典型场景	Prime Agent 的优势
陌生代码库调研	找入口、模块边界、调用链、测试方式和风险点	REPL 保存分析脚本和中间结果，子 Agent 分线调查
复杂 bug 根因分析	日志、配置、测试、历史改动交叉验证	状态留在变量、文件和 artifacts 里，后续不用重查
跨模块重构	盘点影响面，分批修改，跑检查，修回归	daemon worker 支持长时间执行和 attach 恢复
质量治理和代码审查	API、测试覆盖、性能、安全、迁移风险分线排查	`rlm(...)`
适合把独立审查交给子 Agent
研究和评测	benchmark、provider 对比、实验结果整理	Python REPL 适合保存数据、脚本和分析过程
团队流程复用	release audit、故障复盘、仓库迁移、规则生成	`/refine`
把验证过的经验沉淀为 Harness 状态

反过来，有几类任务不该强行使用 Prime Agent：

简单问答、短摘要、单文件小修，用普通 Claude Code、Codex 或 ChatGPT 就够。
固定 ETL、格式转换、批处理脚本，更适合写成确定性的普通程序。
不可信仓库、不可信 skill、不可信 extension，不该直接放到同一用户权限环境里跑。
对安全隔离要求极高的任务，需要外部容器、沙箱或受限用户环境兜底。

Prime Agent 不是 sandbox。IPython kernel 和 shell magic 都以用户 OS 权限运行。它能做的事越多，供应链和误操作的风险面也越大。

Prime Agent 把 Coding Agent 从工具调用推向可恢复工作流

长任务失败，往往不是模型不会写代码

RLM 的价值：让模型递归调用模型，而不是硬扛上下文

Self-improving 不是模型自己长脑子

哪些任务值得用 Prime Agent

推荐阅读