保持和培养每个学生的自尊心，取决于教师如何看待学生的个人学习成绩。—— 苏霍姆林斯基

当一个 Agent 不只会接指令，而是开始“长期工作”：Prime Agent 想把自主性这件事做深一点

很多人第一次接触 coding agent 时，都会有一种新鲜感：它能写代码、能跑命令、能改文件，甚至还能帮你梳理思路。可真正多用几次之后，另一个问题很快就会浮上来——它能不能持续工作，而不是只完成一次对话里的几步动作？

一次性回答和长期推进，其实是两种完全不同的能力。

前者更像一个聪明的即时助手，后者则更接近一个真正参与工作流的执行者：它要记得上下文，保存状态，拆分任务，后台运行，复用经验，还得在中断、恢复、重新接管之后继续向前。也正是在这条路线上，PrimeIntellect-ai/prime-agent 显得格外有辨识度。

它的 description 很直接：A self-improving RLM agent for coding workflows and long-running autonomous tasks.

这句话里有两个关键词特别醒目：

  • self-improving
  • long-running autonomous tasks

Prime Agent 不是只想做一个“能写点代码的聊天代理”，而是在试图把 Agent 变成一个能持续运行、能够演化、并且更适合长任务场景的工作系统。

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

它从一开始就没有把自己定位成“聊天窗口里的代码助手”

README 对 Prime Agent 的介绍非常鲜明：它是一个 open-source coding and research agent for general and long-running work。

这句话其实已经把边界拉开了。它不是只面向短平快的问答，也不是专门做某个窄场景工具，而是把目标放在了更一般化、也更持久的工作类型上，尤其适合 coding 和 research 这类容易拖长、容易分叉、容易中断后重连的任务。

为了支撑这个定位，README 说它围绕两个核心抽象来设计：

  • Recursive Language Model（RLM）
  • Continual Harness

这两个词不是装饰性的命名，而是整个项目思路的骨架。

RLM：把上下文当变量，把子 Agent 当函数调用

README 对 Recursive Language Model 的解释很有意思。

它把 context 视作变量，也就是 prompt-as-a-variable；同时把 tools 和 recursive subagents 看作函数调用，也就是 programmatic tool use 的一部分。

这种设计思想一下子就把 Prime Agent 和传统“聊天式代理”区分开了。

因为很多 agent 系统仍然隐约停留在一种自然语言驱动的范式里：提示词写长一点、上下文补全一点、工具链再接几条，事情大概就能继续往前走。但 Prime Agent 明显更偏向一种“程序化代理”思路——不是靠一整个模糊的大 prompt 把事情糊过去，而是把上下文、工具、子任务、控制流都逐渐收进可编排结构里。

README 甚至直接说：

  • Everything is programmatic
  • persistent IPython 是内建 model tool
  • file operations、shell commands、tool use、subagents、context management 都通过代码发生

这句话特别有力。它几乎是在宣布：这里不是一个“语言驱动的玩具桌面”，而是一套更接近程序运行环境的 Agent 机制。

Continual Harness：不是只记会话，而是让经验成为可持久的状态

Prime Agent 的第二个核心抽象是 Continual Harness。

README 里对它的描述是：它会把 supplemental prompts、memories、skill descriptions 和 reusable subagent specifications 存成 durable state，而 Prime Agent 可以随着时间推移继续使用这些状态。

这件事的分量其实很大。

因为这意味着，Agent 并不是每次启动都重新做人。它可以把一些工作中真正有用的附加信息沉淀下来，不必每次都从零开始重新理解自己的做事方式。

README 还特别提到：

  • Prime Agent 结合了 persistent Python control environment
  • 再加上 durable harness state
  • 这样一来，有价值的 working context 和 reusable operating patterns 就能超出单个 chat window 的生命周期

说得更直白一点：Prime Agent 不只想“记住你刚才说了什么”，而是想“保留它工作过之后形成的可复用操作能力”。

它不只会执行任务，还试图在执行之后变得更会执行

“self-improving” 这部分，在 README 里最直接的体现是 /refine。

README 说，/refine 会回看当前 trajectory，并且可以对 supplemental harness state 做小而有证据支撑的更新。它不会重写 immutable base system prompt，但可以逐步微调那些附加的、可演化的部分。

这个设计很克制，也很聪明。

它没有上来就说“Agent 会自动重写自己”，而是限定在：

  • review 当前轨迹
  • 做 small updates
  • 这些更新要 evidence-backed
  • 修改的是 supplemental harness state，不是 immutable base system prompt

这样一来，“改进”就不是一个失控的大词，而是被束缚在一种相对稳妥的框架里。它不是大刀阔斧重塑人格，而更像工作复盘后给自己添几条有用的经验卡片。

技能在这里不是提示词片段，而是可导入的 Python 包

Prime Agent 对 skills 的理解也很有辨识度。

README 明确写道：Skills are executable。skills 是 importable Python packages，而且内建的 skill creator 还能把 recurring workflows 变成 project 或 personal skills。

这一点很值得注意，因为它和很多把“skill”理解为一段模板提示词的系统完全不同。

在 Prime Agent 这里，skill 更像一种真正可以被工程化管理、可导入、可复用的能力对象。它可以来自经常重复的工作模式，也可以被整理成适合个人或项目级别使用的形式。

这让“技能沉淀”不再只是写个笔记，而是向着可执行、可复用的形态更进一步。

这个 Agent 的一个重要气质：它真的打算陪任务跑很久

README 有一整节就叫 Built for Long-Running Work。

这不是一句口号，因为它后面列出来的东西都非常具体：

  • Continual Harness
  • Direct agent-to-agent communication
  • Daemon-backed continuity
  • Heartbeats and schedules
  • Persistent goals
  • Bounded autonomous mode

这些特性放在一起看，像是在拼一套“长任务生存套装”。

Daemon-backed continuity

README 写得很清楚：active sessions、IPython state、schedules 和 subagents 都能在 terminal detach 后继续运行，并在之后重新 attach。

这意味着它不是那种“终端一断，世界归零”的工具。任务可以继续推进，用户回来时再接上。

Heartbeats and schedules

Prime Agent 提供 /heartbeat、rlm_heartbeat 和 prime-agent schedule，可以周期性地重新进入 session，或者在特定时间点回来接着干。

这让 Agent 的存在方式更接近一个定时运转的工作实体，而不是只能在眼前这次交互里活着。

Persistent goals

/goal 可以让一个 objective 及其进度跨 turns 持续存在，直到完成、暂停或清除。

这非常像真正的任务系统：目标不是一句说完就蒸发，而是被持续挂在墙上，直到它被收尾。

Bounded autonomous mode

/autonomous 则允许 Agent 在设定好的 turn、token、time budgets 内继续运行，并可配合 user-defined quality gates。

也就是说，它不是简单粗暴地“无限自动化”，而是强调 bounded。自动，但有边界；自主，但有预算和门槛。

子 Agent 不只是辅助线程，而是系统的一等公民

Prime Agent README 里有一句非常关键的话：

Subagents are built in

它通过 rlm(...) 生成真正的 child agents，用于并行或者后台工作，并以程序化方式返回结果。

这不是那种“模拟一下多个角色对话”的轻量玩法，而是直接把子 Agent 当作系统中的可调用单元。更进一步，README 还提到：

  • 运行中的 agents 可以直接互相通信
  • retained subagents 可以被发现、交换消息、引导 active work
  • agents 能彼此编排，而不必所有沟通都经过用户

这让 Prime Agent 的整体图景更接近一个小型代理网络，而不是单一智能体。复杂任务不必完全靠一个主体线性推进，它可以拆开、并行、后台化、再汇总回来。

安装和启动方式很直接，但警告也写得很坦诚

README 的 Getting Started 很简洁。

在 macOS 或 Linux 上安装最新稳定版：

1
curl -fsSL https://app.primeintellect.ai/prime-agent/install.sh | sh

README 说明，这个 installer 会下载版本化 release、校验 SHA-256 checksum、安装 prime-agent 命令，并且可以准备 Agent 所使用的 IPython runtime。

启动方式也很直接：

1
2
cd /path/to/project
prime-agent

首次启动时，需要运行 /login 来选择 subscription 或 API-key provider。

但这里最值得注意的，反而是 README 给出的警告。它明确说：

  • Prime Agent 会执行 model-generated Python 和 project commands
  • 执行权限与当前用户权限一致
  • worker 和 kernel processes 提高了 lifecycle isolation 和 recovery
  • 但它们 不是安全边界

这段话非常重要。它没有把“隔离”说得很神，而是直白承认：这是工程上的生命周期隔离与恢复机制，不等于安全沙箱。对一个真正会执行代码、跑命令、改文件的 Agent 来说，这种坦诚尤其必要。

CLI 命令设计，明显是围绕“持续会话”来展开的

README 给出的常用命令也很能体现产品思路：

1
2
3
4
5
6
7
prime-agent agents
prime-agent attach <agent>
prime-agent --resume <path|id>
prime-agent status
prime-agent doctor [--fix]
prime-agent update [--force]
prime-agent shutdown [--force]

这一组命令读下来，很容易捕捉到 Prime Agent 的工作方式：

  • session 可以运行、闲置、保存
  • 可以 reattach
  • 可以 resume
  • 有后台服务状态
  • 有 doctor 修复逻辑
  • 有统一 shutdown

这已经不是简单“启动一个 CLI 工具”了，而更像在管理一个本地 agent runtime。

文档结构也在暗示：它不仅是产品，更是一套编程模型

README 的文档入口包括：

  • Quickstart
  • Usage and CLI reference
  • Long-running and background agents
  • RLM programming model
  • JSON mode
  • RPC mode
  • Skills
  • Provider setup
  • Architecture overview
  • Development

仅从目录上就能看出，Prime Agent 不只是一个 end-user 工具，也是在提供一套面向开发者的编程与集成模型。尤其是：

  • RLM programming model
  • JSON mode
  • RPC mode
  • Architecture overview

这些条目说明它不是只想让你手动敲命令使用，也在认真提供面向自动化和外部系统接入的通路。

prime-agent-core：它把“有状态 Agent 运行时”拆成了可编程包

如果说顶层 README 展示的是产品视角，那么 packages/agent/README.md 更像在打开引擎盖。

这个包叫 Prime Agent Core，副标题很简短：Stateful agent runtime。

这里的重点就是 “stateful”。

README 开头就给出了一个非常简洁的使用示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
import { Agent } from "prime-agent-core";
import { getModel } from "prime-agent-ai";

const agent = new Agent({
  initialState: {
    systemPrompt: "You are a helpful assistant.",
    model: getModel("anthropic", "claude-sonnet-4-20250514"),
  },
});

agent.subscribe((event) => {
  if (event.type === "message_update" && event.assistantMessageEvent.type === "text_delta") {
    process.stdout.write(event.assistantMessageEvent.delta);
  }
});

await agent.prompt("Hello!");

这段代码透露出的感觉非常清楚：Prime Agent Core 并不想隐藏一切，而是愿意把 Agent 作为开发者可直接操作的运行时对象暴露出来。

它对消息流、事件流、工具执行流的拆解非常细

packages/agent/README.md 里最有工程味道的一部分，是它对事件模型的解释。

比如，prompt() 调用会经历：

  • agent_start
  • turn_start
  • message_start
  • message_update
  • message_end
  • turn_end
  • agent_end

如果涉及工具调用，还会进一步出现：

  • tool_execution_start
  • tool_execution_update
  • tool_execution_end

而且 README 不只是列名字，还详细画出了流程顺序。你几乎能从这份文档里直接拼出一个前端 UI、一个日志监听器，或者一个状态同步层。

这说明 Prime Agent Core 的设计并不是“黑箱跑完给你一个结果”，而是把内部运行生命周期拆成了可观察、可订阅、可响应的事件序列。

它在工具执行上，也认真区分了 parallel 与 sequential

README 说明，工具执行模式是可配置的：

  • parallel（默认）
  • sequential

其中 parallel 模式会先顺序 preflight，再并发执行允许的工具，并按完成顺序发出 tool_execution_end；而 sequential 模式则逐个执行。

另外还支持：

  • 全局 toolExecution
  • per-tool executionMode
  • beforeToolCall
  • afterToolCall

其中 beforeToolCall 在参数验证后、执行前运行，可以阻止执行；afterToolCall 在执行后、最终事件发出前运行，可以补充后处理信息，甚至配合 terminate: true 控制是否跳过自动 follow-up LLM call。

这类设计细节会让人很明显地感觉到：Prime Agent Core 不是只提供“能调工具”，而是在认真设计工具调用生命周期。

它把 steering 和 follow-up 也做成了一等控制能力

Prime Agent Core 还有一组很有意思的概念：

  • steering
  • follow-up

README 解释得很清楚：

  • steering messages 可以在 tools 正在运行时打断和改向
  • follow-up messages 可以在 agent 原本准备停下后继续排队追加工作

而且它提供：

  • steer(...)
  • followUp(...)
  • clearSteeringQueue()
  • clearFollowUpQueue()
  • clearAllQueues()

这个设计特别像是在给 Agent 会话增加一种“软中断”和“延迟续命”机制。用户不必粗暴取消再重来，而是可以在运行过程中插入方向调整，或者在收尾之后自然续上下一段任务。

它的核心状态模型，也非常公开透明

README 给出了 AgentState 的接口结构：

  • systemPrompt
  • model
  • thinkingLevel
  • tools
  • messages
  • isStreaming
  • streamingMessage
  • pendingToolCalls
  • errorMessage

这让整个运行时模型非常清晰。你知道一个 Agent 在维护什么状态，也知道哪些部分是动态的、只读的、与流式执行相关的。

从开发体验上说，这种清晰度很有价值。因为它意味着你操作的不是神秘容器，而是结构明确的状态对象。

Tools 的定义方式，也在强调“类型安全”和“控制力”

在 prime-agent-core 里，工具通过 AgentTool 来定义，示例中使用的是 TypeBox：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
const readFileTool: AgentTool = {
  name: "read_file",
  label: "Read File",
  description: "Read a file's contents",
  parameters: Type.Object({
    path: Type.String({ description: "File path" }),
  }),
  executionMode: "sequential",
  execute: async (toolCallId, params, signal, onUpdate) => {
    const content = await fs.readFile(params.path, "utf-8");
    onUpdate?.({ content: [{ type: "text", text: "Reading..." }], details: {} });
    return {
      content: [{ type: "text", text: content }],
      details: { path: params.path, size: content.length },
    };
  },
};

README 还强调：

  • 工具失败时要 throw error
  • 不要把错误消息伪装成正常 content 返回
  • 抛出的错误会被 agent 捕获，并作为 isError: true 的 tool error 报给 LLM

这些约束说明它在工具协议上是有清楚边界感的。

prime-agent-ai：它不是附属组件，而是一个相当完整的多提供商 LLM 工具箱

除了 agent runtime，本仓库中的 packages/ai/README.md 也非常值得看。

这个包叫 Prime Agent AI，副标题是 LLM provider toolkit。README 对它的总结包括：

  • Unified LLM API
  • automatic model discovery
  • provider configuration
  • token and cost tracking
  • simple context persistence
  • hand-off to other models mid-session

这几项放在一起，几乎已经是一套相当完整的模型接入层了。

而且 README 明确说明：这个库只包含 支持 tool calling 的模型，因为这对 agentic workflows 是必需的。

支持的 providers 数量非常多，能看出它在认真做“跨模型、跨平台”这件事

README 列出的 providers 非常长，包括：

  • OpenAI
  • Prime Inference
  • Azure OpenAI
  • OpenAI Codex
  • DeepSeek
  • Anthropic
  • Google
  • Vertex AI
  • Mistral
  • Groq
  • Cerebras
  • Cloudflare AI Gateway
  • Cloudflare Workers AI
  • xAI
  • OpenRouter
  • Vercel AI Gateway
  • MiniMax
  • GitHub Copilot
  • Amazon Bedrock
  • OpenCode Zen
  • OpenCode Go
  • Fireworks
  • Kimi For Coding
  • Xiaomi MiMo
  • 以及任意 OpenAI-compatible API，如 Ollama、vLLM、LM Studio

这个列表最直接传达出的信息是：Prime Agent 并没有把自己锁死在单一模型供应商上。它在基础设施层就已经认真准备好“换模型”“跨 provider”“中途 hand-off”的能力。

它对流式输出、工具调用、推理内容、错误与中断都做了统一接口

prime-agent-ai README 给出的 Quick Start 很能体现设计思路。

通过 stream()，你可以收到一整套事件：

  • start
  • text_start
  • text_delta
  • text_end
  • thinking_start
  • thinking_delta
  • thinking_end
  • toolcall_start
  • toolcall_delta
  • toolcall_end
  • done
  • error

这意味着，文本、thinking、tool call 都不是混成一团的黑流，而是被拆成了明确事件类型。

它还支持：

  • 图像输入
  • reasoning / thinking 能力
  • partial JSON tool arguments streaming
  • TypeBox schema validation
  • abort 后继续对话
  • provider payload debugging
  • context serialization

这类能力加总起来，呈现出一种非常“工具箱型”的气质。它不是为了单一运行路径而设计，而是在为更复杂的 Agent 应用准备底层能力。

Cross-provider handoff 是它非常有辨识度的一点

README 明确提到，它支持在同一会话中跨 provider handoff，并且会自动处理兼容性：

  • user 和 tool result messages 原样透传
  • 同 provider / API 的 assistant messages 原样保留
  • 不同 providers 的 assistant thinking blocks 会转成带 <thinking> 标签的文本
  • tool calls 和常规文本保持不变

这意味着你可以：

  • 先用一个快模型做初步响应
  • 中途切到更强的模型做复杂推理
  • 再切到另一个模型接着处理
  • 在 provider 出现问题时继续保留会话连续性

对一个强调 long-running work 的系统来说，这种跨 provider 连续性非常重要。因为长任务往往不能假设某一个模型、某一条 API 路径永远稳定可用。

它甚至给测试和演示准备了 faux provider

prime-agent-ai 里还有一个很有工程趣味的能力：registerFauxProvider()。

这个 faux provider 是一个临时内存 provider，用于 tests 和 demos，可以：

  • 脚本化 assistant replies
  • 模拟 thinking
  • 模拟 tool calls
  • 模拟 usage
  • 控制 tokensPerSecond
  • 支持多 faux models 做 model-switching 测试

这种能力说明项目在开发体验上是下过功夫的。它不只是想着“线上怎么跑”，也在认真处理“本地怎么测”“不接真实 provider 怎么做 deterministic flow”。

从整个仓库的结构和文档来看，它在追求一种“真正可长期运作的 Agent 系统”

把顶层 README、prime-agent-core 和 prime-agent-ai 放在一起看，Prime Agent 的路线非常清晰：

  • 顶层产品关注 coding workflows 与 long-running autonomous tasks
  • RLM 强调上下文与子 Agent 的程序化抽象
  • Continual Harness 强调 durable state 与可演化补充状态
  • Core 提供 stateful runtime
  • AI 包提供 provider abstraction、streaming、tooling、handoff、reasoning
  • 整体能力围绕 持续运行、后台恢复、技能沉淀、并行子任务、自主边界控制 逐步展开

这不是一个“只会在会话里帮你写一段代码”的 Agent 项目。它更像是在构建一个能长时间存在、能多轮迭代、能在中断后恢复、还能在过程中逐步学会更好做事的工作代理系统。

它最吸引人的地方，不是“自动化”本身，而是对“持续性”的认真

很多 Agent 项目喜欢强调 autonomous、multi-agent、tool use、reasoning，但 Prime Agent 给人的独特印象，恰恰来自另一件事：

它非常认真地对待“任务不会在一次交互里结束”这个现实。

因此它才会把这些能力摆得这么重：

  • durable harness state
  • daemon-backed continuity
  • attach / resume
  • persistent goals
  • heartbeats
  • schedules
  • retained subagents
  • bounded autonomous mode
  • self-improving refine flow

这些词看起来分散，实际上都在服务同一个目标：让 Agent 像一个真正参与工作流程的长期执行者，而不是一次性响应器。

如果用一句话来概括 Prime Agent，它更像一个“会工作的系统”，而不只是一个“会回答的模型”

Prime Agent 的 README 没有把自己包装成无所不能的智能神话。它反而更像一个认真搭建中的系统工程：有状态、有运行时、有 provider 层、有工具层、有后台连续性、有子 Agent 机制，也有清晰的安全提醒和边界约束。

它想做的不是让模型看起来更像人，而是让 Agent 在真实工作里更像一个能持续运转的程序化执行体。

所以，如果一定要概括这个项目最鲜明的气质，我会更愿意这么说：

Prime Agent 不是在教一个模型多说几句，而是在试图让一个 Agent 学会长期把事情做下去。