从会话工具到常驻执行系统：重新理解 Prime Agent 的 RLM、Continual Harness 与长程 Agent 工程化

如果把普通 Agent 比作"下班就失忆的实习生"，Prime Agent 更像一个住进机房、会记笔记、还能自己改工作手册的夜班工程师。它不满足于回答一次问题，而是想把任务跑到天荒地老：断线能续、状态能存、经验能复用。听起来很浪漫，直到你遇上锁文件、崩溃恢复和跨平台兼容------这也正是 Prime Agent 最有意思的地方。

一、真正值得研究的，不是"又一个编码 Agent"

如果只看功能列表，Prime Agent 很容易被归入已经十分拥挤的"终端编码 Agent"类别：能读写文件、执行 shell、调用模型、派生子 Agent、维护记忆、自动压缩上下文，还能在后台继续工作。类似能力在 2026 年已经不稀缺。Claude Code 能跨终端、IDE、桌面端与 Web 工作，具备自动记忆、Skills、Hooks、后台 Agent、Agent Teams 和定时 Routines；OpenHands 有完整的 Agent SDK、沙箱 Runtime、事件历史与上下文压缩；Aider 长期深耕 Git 驱动的交互式代码修改；SWE-agent 则把研究型软件工程 Agent 的接口和评测路径做得非常清晰。

因此，判断 Prime Agent 的价值，不能停留在"它能不能写代码"这一层。它真正提出的问题是：当 Agent 不再是一次请求、一次回复的临时工具，而是需要持续数小时、数天甚至跨多次终端连接运行时，Agent 应该被设计成什么？

这会把问题从"模型是否聪明"迅速推向更传统、也更难的分布式系统与运行时工程：谁拥有 Session？进程死掉以后谁负责恢复？状态写到一半崩溃怎么办？定时任务重复触发怎么办？子 Agent 已完成但父 Agent 重启后如何重新寻址？上下文压缩后，哪些状态必须继续保留？技能被自动改写以后，如何回滚、审计和避免能力漂移？

Prime Agent 的研究价值就在这里。它把这些过去常被视作外围基础设施的问题，直接放进 Agent 框架的核心。

短会话 Agent 的核心是单次推理闭环；常驻 Agent 的核心则是执行权、状态、恢复和重新进入机制。

（一）短任务 Agent 的默认假设正在失效

传统 Agent 框架往往隐含三个默认假设：第一，执行过程与前台会话绑定；第二，关键状态主要存在于模型上下文或少量外部 memory 中；第三，失败以后重跑一次成本可以接受。这三个假设在长程任务里都会变得脆弱。

1、前台会话不再是执行所有者

一个需要跑八小时的评估任务，不应该因为 SSH 断线、笔记本休眠或终端关闭而终止。此时真正的"所有者"必须是后台常驻 worker 或远端执行服务，而不是 TUI。Prime Agent 的 daemon supervisor、session worker、可重新 attach 的客户端，本质上是在建立这种所有权分离。

2、上下文不再等于状态

长程 Agent 的真实状态至少分为四层：模型可见的对话上下文、IPython 中的工作变量与函数、Session 级的持久目标/调度/子 Agent 注册表，以及文件系统中的 transcript 与 artifacts。如果仍把"记忆"理解成往 prompt 里塞几段历史总结，就无法解释真正的恢复问题。

3、失败不再等于重新开始

长时间任务的失败成本很高。网络错误、模型限流、子进程中断、机器重启、写文件中途崩溃都可能发生。工程目标从"尽量不失败"变成"失败以后可恢复，而且恢复后不制造第二次错误"。这也是为什么 Prime Agent 最近的公开 Issue 会集中在 JSONL 尾部修复、并发写入、stale owner、worker identity、Session revival 等主题上。

（二）长程 Agent 的"护城河"更像运行时，而不是 Prompt

很多 Agent 产品早期靠系统 Prompt、工具集合和规划技巧形成差异，但当基础模型能力持续上升、工具协议趋于标准化，Prompt 层差异会快速收敛。真正不容易复制的是运行时语义：状态边界、失败隔离、恢复协议、任务调度、审计、可重入性和权限模型。

换句话说，长程 Agent 最终会越来越像一种新的应用服务器。模型只是其中的决策组件，外围仍需要成熟的软件工程纪律。Prime Agent 的意义不在于它已经把这些问题全部解决，而在于它把问题定义得足够明确：Agent 的长期自治能力必须建立在可恢复的执行系统之上。

二、RLM：与其说是一种"模型"，不如说是一种 Agent 编程模型

Prime Agent 把 Recursive Language Model，简称 RLM，作为核心概念。这个名字容易让人误以为它提出了一种新的神经网络结构；实际上，从官方当前文档看，它更接近一种模型与运行时的交互编程范式：模型工作在一个持久 Python 控制环境中，把上下文当作可操作变量，把能力当作函数，把子 Agent 当作可以递归派生的执行单元。

（一）RLM 的关键不是"递归"，而是程序化控制上下文

模型上下文负责决策，持久 IPython 负责工作状态，TypeScript Host 持有权威生命周期与持久化状态，子 Agent 作为可寻址执行单元存在。

1、工具从菜单变成语言内部的函数

很多 Agent 运行时会向模型暴露几十个工具：read_file、write_file、run_shell、search、call_agent......模型每次在一个固定 schema 集合中选择工具。Prime Agent 的思路更激进：内建模型工具主要是一个持久 IPython 入口，文件、shell、数据处理、Skills、子 Agent 都通过 Python 代码组合。

这种设计的优势是组合性。模型不是只能"调用工具 A，然后工具 B"，而是可以在代码中写循环、缓存中间结果、定义函数、处理异常、聚合多个子任务。对于数据评估、仓库分析、实验执行这一类程序性很强的任务，它比纯工具调用更接近工程师真实的工作方式。

2、Python 状态承担"工作记忆"

RLM 的另一个关键点是，Python 内核中的变量、导入、函数、解析结果、子 Agent handle 可以跨工具调用和上下文压缩继续存在。这意味着模型上下文不必重复携带所有原始材料，而可以只保存对"状态在哪里、如何读取"的认知。

这是一种很重要的上下文工程思想：把 token 上下文从数据仓库变成控制平面。 大文本、实验结果、索引、结构化对象可以留在可寻址的程序状态或文件中，模型只需要在需要时重新读取。

1.1 控制面与数据面的分离

从系统设计角度看，模型上下文适合保存目标、约束、近期决策和下一步计划；文件、Python 对象和数据库适合保存体量更大、结构更稳定的工作数据。RLM 的工程价值，正是强迫设计者把这两类状态分开。

1.2 上下文压缩不再意味着"失忆"

如果重要中间结果只存在于聊天历史中，compaction 必然伴随信息损失；如果关键状态已被结构化保存，compaction 只需要压缩叙事层历史。对长程任务而言，这是从"努力保留更多 Prompt"到"设计更好的状态边界"的范式变化。

3、子 Agent 是运行时对象，不是一次性 API 返回值

Prime Agent 的 rlm(...) 调用并不是简单地"调用另一个模型并等待答案"。官方文档强调，调用会返回一个 child handle，子 Agent 有独立 Session 目录和上下文，结果通过显式消息或文件返回；父 Agent 后续还能继续向已经保留的子 Agent 发消息。更重要的是，父级子 Agent 注册表可以跨 compaction、kernel restart 与父 Session 恢复继续存在。

这使"多 Agent"从一次 prompt 内部的并行技巧，变成一个具有生命周期的执行拓扑。它更像 actor、worker 或轻量 job，而不是函数调用。

（二）RLM 的代价：自由度越高，安全边界越需要明确

1、持久 REPL 不是沙箱

Prime Agent 官方明确提醒：IPython kernel 会以 worker 的操作系统权限执行模型生成的 Python 和项目命令，worker 与 kernel 的进程隔离用于生命周期与故障隔离，不是安全沙箱。这一点对生产试用非常关键。

持久 Python 环境给了 Agent 极高的表达能力，但同时也意味着任意代码执行能力更直接。对包含未知脚本、第三方 Skill、外部下载内容的任务，如果没有额外容器或最小权限隔离，风险会显著高于只暴露少数受控工具的框架。

2、可编程能力会放大"错误的自动化"

函数、循环、子 Agent、调度和持久目标可以显著提高效率，也能把一个错误决策放大成多轮自动执行。长程 Agent 的核心安全目标因此不能只是"模型第一次别做错"，而必须包含预算限制、质量门、权限边界、变更审查、可撤销和异常停止策略。

三、Continual Harness：Prime Agent 最值得关注的第二条主线

早期讨论 Prime Agent 时，常把第二个核心设计称作 Persistence Framework。但在当前公开文档中，Prime Agent 已经更明确地采用 Continual Harness 这一概念。它与 2026 年发布的同名研究工作一致：Agent 不只在任务中行动，还能利用过去轨迹，持续调整自身的补充 Prompt、Memory、Skill 描述和可复用子 Agent 规格。

如果 RLM 解决的是"Agent 如何在程序化环境中工作"，Continual Harness 解决的则是"Agent 如何在不重新训练基础模型的情况下，让运行策略跨时间积累"。

（一）从静态系统 Prompt 到可演化 Harness

1、传统定制的三个层次

第一层是静态 Prompt：团队把规范、经验和注意事项写进 CLAUDE.md、system prompt 或项目 instructions。第二层是人工维护的 Skill：把成熟流程封装成脚本、工具或 Markdown 技能说明。第三层才是 Continual Harness：系统根据真实执行轨迹，提出小范围、可审阅的改进，并把它们保存为后续任务可复用的状态。

这三层的差别不只是自动化程度，而是知识更新机制。静态 Prompt 的知识来自设计者；人工 Skill 的知识来自工程化沉淀；Continual Harness 试图让知识来自 Agent 自己的运行证据。

2、"自我改进"必须是有边界的改进

Prime Agent 当前的 /refine 设计有一个值得肯定的限制：它并不允许 Agent 任意重写不可变的基础 system prompt，而是对 supplemental harness state 做小幅、基于证据的更新，并保留 refinement history 与快照以支持回滚。

这比"让 Agent 自动修改自己的 Prompt"更接近生产可用的做法。真正可用的自我改进需要满足四个条件：改动范围小、原因可解释、效果可验证、失败可回滚。否则所谓"自我进化"只是难以复现的配置漂移。

（二）Continual Harness 的真正价值在"在线适应"

行动产生轨迹，轨迹经过评估形成小范围 harness 更新，再进入下一轮执行；关键是每次修改都可审查、可验证、可回滚。

1、不等待下一次训练或下一次项目复盘

传统团队会在任务失败后开复盘会，再由人把经验写进文档或工具。Continual Harness 希望把这个周期压缩到同一条长期运行轨迹内部：Agent 在持续任务中发现某种策略反复有效，就把它固化为更好的记忆、技能说明或子 Agent 配置。

2、它更像"操作策略学习"，而不是模型学习

这种机制没有直接修改基础模型权重，因此更准确的理解是 harness-level adaptation。它改变的是模型周围的执行环境和策略提示，而不是模型本身。这种方法的优势是成本低、速度快、可审计；缺点是能力上限仍受基础模型约束，而且错误经验也可能被固化。

2.1 最重要的风险：错误经验进入长期记忆

一次偶然成功可能被误判为普遍规律；某个仓库特有的 workaround 可能被错误推广到其他项目；某次模型幻觉可能在后续被当成"已验证经验"。因此自我改进不能只记录"做了什么"，还应记录适用范围、证据来源、成功率、反例和失效条件。

2.2 Skill 版本管理会成为必要基础设施

一旦 Agent 能持续修改 Skills，Skill 就不再只是静态脚本，而会像代码一样需要版本、测试、审批、依赖管理和回滚。未来成熟的长程 Agent 平台，很可能会出现一套类似 CI/CD 的"能力发布流水线"。

四、持久运行架构：Prime Agent 最有工程含量的部分

如果只选一个部分深入研究 Prime Agent，我更建议看它的 daemon、worker、kernel、session storage 和恢复语义，而不是看 Prompt。官方架构把终端表现层、进程协调、Agent 执行、模型可见 Python 环境和持久状态明确拆开，这一拆分决定了"断线后继续跑"不是 UI 技巧，而是运行时能力。

（一）为什么 daemon + worker + kernel 是合理拆分

1、客户端负责交互，不负责执行

TUI、JSON、RPC 客户端都通过 AgentConnection 与 supervisor 交互。客户端断开以后，resident worker 继续拥有 Session、队列、Scheduler、IPython kernel 和 RLM 子 Agent。这让 attach/detach 成为正常生命周期，而不是异常状态。

2、Supervisor 负责寻址与恢复

Supervisor 负责 discovery、routing、attachments、worker health 和跨 Agent 消息投递。它相当于本地 Agent 集群的控制面。这样设计以后，"用户现在连接到哪个终端"不再影响任务本身的所有权。

3、Worker 以 Session 树为故障边界

每个 worker 持有一个 root runtime，以及该 root 下的 scheduler、kernel 和 descendants。与把所有 Agent 塞进一个进程相比，这种边界更利于故障隔离；与每一步都启动临时进程相比，它又能保留长程状态。

1.1 进程隔离的目标是恢复，不是安全

这是 Prime Agent 架构中必须反复强调的一点。worker/kernel 分进程可以防止一个 kernel 崩溃直接拖死 TUI，也有利于重启和重连，但并没有降低它们对本机文件和命令的权限。故障边界与安全边界是两回事。

（二）长跑能力不是一个功能，而是一组一致的生命周期语义

用户、定时器、目标续跑和其他 Agent 都进入同一 Prompt Queue；执行结果持久化后，worker 或 supervisor 重启可以从 Session 状态恢复。

1、Heartbeat 解决"周期性重新进入"

用户 heartbeat、Agent 内部的 rlm heartbeat、通用 schedule 都会把新的 prompt 注入同一个 Session 队列。重要的不是"能定时"，而是定时事件与用户输入、Agent 间消息、持久目标共同走同一条执行和持久化路径。

2、Persistent Goal 解决"目标跨轮保持"

普通聊天中，一次 assistant turn 结束通常意味着任务暂时结束；Persistent Goal 则显式记录一个仍未完成的目标，并持续携带 token 消耗、时间、继续次数和预算。只有 Agent 明确完成，目标才终止。这让"任务是否完成"从语言上的主观判断变成运行时状态。

3、Bounded Autonomous Mode 解决"继续执行但不能无限执行"

真正危险的不是 Agent 自动继续，而是没有预算和停止条件地自动继续。Prime Agent 把 turn、token、time budget 与 quality gates 放进 autonomous mode，至少在机制上承认自治必须有边界。

五、最值得警惕的地方，也正是它最核心的地方

一个项目越把持久运行当核心，越不能轻描淡写地看待持久化 Bug。Prime Agent 近期公开 Issue 很有代表性：维护者正在强化持久 Session 与配置的 crash safety，处理 JSONL 尾部修复、并发 append、原子写入、stale owner 恢复；同时还在完善 daemon worker identity fencing、supervisor ownership、queued/interrupted/archived Session 恢复，以及 Windows 下的内核启动、认证存储和 supervisor 行为。

这不是普通"边角 Bug"。这些问题直接决定长程 Agent 是否值得托付高成本任务。

（一）状态完整性比模型准确率更基础

1、写坏一次状态，后续推理越聪明越危险

如果 transcript 尾部损坏、Session 配置部分写入、并发 writer 互相覆盖，Agent 恢复后可能在错误世界状态上继续运行。此时更强的模型只会更自信地继续错误路径。

2、需要原子写、日志修复和并发序列化

Prime Agent Issue #1380 提出的方向非常典型：不丢并发 append 地修复不完整 JSONL tail、序列化 Session mutation、对 settings/credentials/migrations 做原子且持久的写入。这些完全是数据库与日志系统熟悉的问题。Agent 平台最终必须学习这些成熟工程经验。

（二）进程所有权必须防止"幽灵 Session"

1、PID 不是可靠身份

长时间运行时，进程号可能复用，registry 可能过期，worker 可能异常退出。如果 supervisor 只凭脆弱标识判断某个 worker 是否仍属于某 Session，就可能向错误进程发送信号或误认所有权。

2、Generation fencing 是必要概念

Issue #1381 提到 worker identity 验证和 supervisor ownership 的 generation fence。这与分布式系统中的 lease/fencing token 思想一致：仅知道"曾经拥有"不够，必须证明"当前这一代仍拥有"。这种语义对于可靠恢复比"重启脚本"重要得多。

（三）恢复必须处理"中间态"，而不是只有成功和失败

1、Queued、Interrupted、Archived 都是不同状态

长程任务会在"prompt 已排队但未执行""子进程已启动但父进程被杀""Session 已归档但收到新消息"等中间状态发生崩溃。Issue #1382 说明项目正在专门补齐这些恢复路径。

2、调度还涉及幂等与重复执行

官方长程文档提到 scheduled tick 在投递前会先 claim，崩溃时不重放不确定 prompt，missed tick 会合并而不是无限堆积。这说明团队已经意识到定时触发不是简单 cron，而是需要定义 crash semantics。对任何无人值守 Agent，这类语义都应成为设计审查重点。

六、同类项目对比：2026 年不应再以"有没有记忆"划界

Agent 生态变化非常快。两年前成立的对比结论，到今天可能已经失真。Prime Agent 与其他项目的差异应该从"执行模型和边界"来看，而不是只比较功能勾选框。

（一）Prime Agent 与 OpenHands：开放运行时，但关注点不同

1、OpenHands 更像完整的软件开发 Agent 平台

OpenHands 当前强调事件驱动的 Agent SDK、Context/Skills、Condenser、Security Analyzer 和沙箱 Runtime。它的 Docker Runtime 把任意代码执行放在容器环境中，这是一个很实际的安全优势。对于端到端软件工程、Web/IDE 体验、多环境部署和受控执行，OpenHands 的产品面更完整。

2、Prime Agent 更强调"持久可编程控制环境"

Prime Agent 的差异不是简单"比 OpenHands 多一个 RLM"。更准确地说，它把 IPython 作为模型面对的主编程面，把子 Agent、Skills、上下文和 host request 都纳入这个程序化环境，并围绕 resident session 做长期运行。它更像一个偏底层、偏黑客型的 Agent runtime。

2.1 安全取舍不同

OpenHands 默认 Docker Runtime 强调沙箱；Prime Agent 明确说其 worker/kernel 不是安全沙箱。这意味着前者更适合默认面对不完全可信代码，后者则更适合在受信环境中追求可编程性与持久控制，但生产部署需要额外隔离。

（二）Prime Agent 与 Aider：常驻自治与高质量人机协作

1、Aider 的核心仍是 Git 驱动的 pair programming

Aider 的强项是终端内的代码修改体验、Repo Map、Git 自动提交、diff/undo，以及几乎对所有主流模型的兼容。它的哲学更接近"人持续在回路中，由 Agent 高效完成局部代码变更"。

2、Prime Agent 面向更长的任务半径

Prime Agent 的 scheduler、persistent goal、后台 daemon、RLM children 和 Continual Harness 都是在为无人值守或低干预运行服务。两者不是同一优化目标：Aider 更像高性能电动工具，Prime Agent 更像尝试建立一个常驻执行进程。

（三）Prime Agent 与 Claude Code：分野转向开放性与运行时控制

1、Claude Code 已经覆盖大量长程能力

到 2026 年，Claude Code 官方已经提供自动记忆、Skills、Hooks、MCP、Agent Teams、后台 Agents、Web 长任务、跨设备 Session、Routines 和 Agent SDK。因此，不能再说 Prime Agent 的优势是"别人没有跨会话记忆或后台任务"。

2、Prime Agent 的优势是可检查、可改造的开源运行时

Claude Code 的产品完成度、模型集成和多端体验更强；Prime Agent 的价值则在于开发者可以直接阅读并修改 daemon、worker、Session、RLM、Skill 和持久化实现。对于要研究 Agent runtime、做深度自定义或把 Agent 嵌入实验平台的团队，这种开放性很重要。

3、Prime Agent 的劣势同样来自开放运行时

闭环产品可以把大量复杂性藏在托管基础设施后面；开源本地常驻 Agent 必须自己面对跨平台、进程恢复、文件一致性、安装环境和权限问题。Prime Agent 最近的 Windows 与生命周期 Issue 就是这种成本的具体体现。

（四）Prime Agent 与 SWE-agent：研究目标已经明显分叉

1、SWE-agent 更强调可评测的软件工程代理接口

SWE-agent 的核心贡献长期在 Agent-Computer Interface、SWE-bench 评测和研究可复现性。当前项目甚至明确建议多数新用户优先使用更简单的 mini-SWE-agent。这说明其方向是把研究接口做得更小、更清楚。

2、Prime Agent 更关注运行时常驻与在线适应

Prime Agent 的复杂度明显更高，因为它试图同时解决 Session 树、后台运行、调度、持久目标、自我改进等问题。它不应以"谁在 SWE-bench 分数更高"来衡量，而应以恢复、长期稳定性、可观测性和策略复用效率来衡量。

维度	Prime Agent	OpenHands	Aider	Claude Code	SWE-agent / mini-SWE-agent
核心定位	长程、可编程、可持续演化的 Agent runtime	完整软件开发 Agent 平台与 SDK	Git 驱动的终端结对编程	产品化全栈编码 Agent	软件工程 Agent 研究与评测
长时间后台运行	强，daemon/worker 为核心	支持，依赖 runtime/deployment	非主要目标	强，Web/后台/Routines	非主要目标
跨会话策略积累	Continual Harness	Skills/Context 等	conventions/config 为主	auto memory/skills	研究配置为主
子 Agent	RLM children，持久可寻址	多 Agent/SDK 能力	非核心	Agent Teams/后台 Agents	视配置而定
默认执行隔离	进程隔离，非安全沙箱	Docker 等 sandbox runtime	本地用户权限	产品权限体系	通常容器化评测环境
可改造运行时	很高	很高	高	Agent SDK 可扩展，但核心产品闭源	很高
最适合	长程研究、评估、深度定制	端到端软件工程与平台集成	日常代码修改	日常开发与组织级自动化	SWE 研究、benchmark

七、Prime Agent 最适合的，不是所有自动化任务

一个框架有鲜明架构以后，适用场景反而应该更明确。Prime Agent 最有价值的场景通常同时满足三个条件：任务时长较长、过程需要探索、执行策略有复用价值。

（一）多步骤数据评估与模型研究 Pipeline

1、适合做"探索型调度层"

例如对几十个数据集做清洗、抽样、模型评估、错误聚类、复测和报告生成。过程中可能需要根据中间结果动态决定下一轮实验，难以提前写成完全确定的 DAG。此时持久 Python、子 Agent 和目标续跑有明显优势。

2、不建议让 Agent 直接替代数据基础设施

数据读取、任务队列、产物存储、指标数据库仍应交给成熟系统。Agent 更适合负责"下一步做什么""如何解释结果""哪一批需要复测"，而不是自行承担所有 durable execution。

1.1 推荐的组合方式

外层用 Temporal、Airflow、Dagster、Kubernetes Jobs 或现有内部平台保证任务幂等、重试、资源配额和产物追踪；内层把 Prime Agent 作为某个可恢复的研究 worker，负责动态决策、代码生成、分析与报告。这样能同时获得确定性基础设施和 Agent 灵活性。

1.2 不要把 Session 文件夹当数据库

Session artifacts 很适合恢复 Agent 自身，但业务关键数据、实验指标和最终结论应写入有 schema、有版本和访问控制的正式存储。Agent Session 是执行上下文，不应成为企业事实源。

（二）长时间代码库迁移与质量治理

1、适合"发现---修改---验证---再发现"的循环

大型依赖升级、API 迁移、静态检查治理、测试补齐都不是一次编辑能完成的。Agent 需要跨多个模块追踪进度、启动并行审查、等待测试、根据失败继续修复。这正是 persistent goal 与 retained subagent 能发挥作用的地方。

2、必须配套版本控制与质量门

所有修改应发生在 disposable clone、worktree 或临时分支中；每一阶段由测试、lint、类型检查、benchmark 或人工 review 作为质量门。对长程 Agent 来说，"可继续运行"不是成功，"满足外部验证"才是成功。

（三）持续研究与情报汇总

1、Heartbeat/Schedule 很适合周期性检查

例如周期检查实验进展、持续扫描某个数据源、定时查看部署状态，再根据变化唤醒分析流程。这种任务比传统 cron 多了一层语义决策：不是每次都输出，而是先判断"是否有值得处理的变化"。

2、但要控制信息污染

长期研究 Agent 很容易把旧结论、过期网页、临时假设混入长期 memory。需要给每条持久知识增加日期、来源、置信度和失效策略，否则"记得更多"会逐渐变成"积累更多陈旧状态"。

八、生产落地前，团队应该重点验证六件事

把 Prime Agent 用进真实 pipeline，最合理的方法不是先问"它能不能自动做完"，而是先做一次运行时验收。下面六项比单次 demo 成功更重要。

（一）可靠性与恢复

1、故意杀进程，看它如何恢复

在任务中随机 kill TUI、worker、kernel、supervisor，甚至模拟机器重启；检查 queued prompt、子 Agent、schedule、goal、transcript 是否一致。没有 fault injection 的长程 Agent 测试，往往只能证明"正常时能跑"。

2、验证重复执行的后果

任何写数据库、发消息、创建 PR、修改线上资源的操作，都应考虑 prompt 被重复投递或恢复后再次执行的情况。业务动作应尽量有 idempotency key 或可检测的已完成标记。

（二）安全与权限

1、默认放进外部沙箱

由于 Prime Agent 的 kernel 不是安全沙箱，生产环境建议用容器、VM、受限用户、只读挂载、网络白名单和短期凭证建立第二层边界。不要把"进程隔离"误当成"权限隔离"。

2、Skill 和外部指令都应视为代码供应链

Python-backed Skills 具有可执行能力，第三方 Skill 的审查要求应接近依赖包，而不是普通 Prompt。最好固定版本、审查来源、跑静态检查，并对自动创建/更新 Skill 设置审批规则。

（三）可观测性与成本

1、记录的不只是最终回答

需要跟踪每个 Session 的模型调用、token/费用、子 Agent 拓扑、调度触发、工具错误、重试、质量门结果、关键 artifact 与恢复次数。长程 Agent 如果只能看最后一段文字，很难定位成本和失败来源。

2、把"自治效率"定义成指标

可以使用单位成功任务 token、单位有效改动成本、恢复后重复工作比例、人工介入次数、失败后平均恢复时间等指标。只有这样，Continual Harness 的"越用越好"才能被验证，而不是依赖主观感受。

（四）团队选型时不要只做功能对照，要做长程运行实验

1、用同一个真实任务比较"首次完成"和"第二次完成"

如果团队真正关心 Continual Harness 是否有价值，最有效的评估不是问它能保存多少 Memory，而是把同一类任务连续执行多次。第一次记录总 token、总时长、失败点、人工干预次数、创建的 Skill/Memory 和最终质量；第二次在不手工补充额外提示的情况下重新执行，观察是否减少重复探索、是否更快进入正确工具链、是否自动避开上一次已经确认的失败路线。只有第二次、第三次表现稳定改善，才说明"跨会话积累经验"产生了工程收益。

2、把恢复测试当作与能力测试同等重要的验收项

常见 Agent benchmark 主要测任务最终成功率，但长程运行系统需要额外的 durability benchmark。可以设计一组故障注入用例：在写 transcript 时终止 worker、在子 Agent 正运行时重启 supervisor、在 schedule 即将触发时关闭客户端、在 goal 续跑过程中让模型 API 连续失败、在 kernel 中保存关键变量后触发 kernel restart。验收标准不是"系统重新启动"，而是恢复后任务状态仍然单调、没有重复副作用、没有丢失已经确认的产物，并且用户能看懂系统恢复到了哪里。

3、把 Harness 变化纳入软件变更管理

团队如果允许 Agent 自动 refinement，就应该建立类似代码 review 的治理方式。每次 refinement 至少保留变更前后 diff、触发证据、适用范围、预期收益和回滚点；高影响 Skill 的可执行代码变化最好经过测试后再进入共享范围。对于多人团队，还需要区分个人经验、项目经验和组织级经验，避免某个开发者 Session 中形成的局部策略直接污染全局。长期看，这种 Harness Governance 很可能会成为企业 Agent 平台区别于个人工具的重要能力。

4、最终要回答的是"它减少了哪一种人类工作"

技术团队很容易被递归子 Agent、常驻 Session、自我改进等架构概念吸引，但生产价值必须落到具体人力环节：是否减少夜间人工盯任务，是否降低重复分析，是否让长测试失败后无需重新排查上下文，是否减少同类迁移项目的准备时间，是否让研究结果更容易复现。如果这些指标没有改善，那么再先进的持久运行机制也只是更复杂的基础设施。反过来，如果它能显著减少等待、重启、重复探索和手工交接，哪怕单次推理质量与其他 Agent 相当，也已经形成明确价值。

九、一个更大的判断：Agent 框架正在分成三层

从 Prime Agent、OpenHands、Claude Code、Aider 与 SWE-agent 的演进可以看到，Agent 系统正在出现比较清晰的三层结构。

基础模型决定认知上限，Harness 决定组织化能力，Durable Runtime 决定长时间运行是否可信。

（一）第一层：模型与推理策略

这一层解决"下一步做什么"，包括基础模型、规划、反思、上下文压缩、工具选择。随着模型能力提升，这一层会持续进步，但框架之间的差异会越来越难长期维持。

（二）第二层：Harness 与能力系统

这一层包括 Skills、Memory、项目规则、子 Agent 模板、Hooks、工具协议和 Continual Harness。它决定同一个模型在一个组织或一个项目中"会不会按正确方式工作"。未来企业真正可积累的 Agent 资产，很可能主要存在于这一层。

（三）第三层：Durable Agent Runtime

这一层解决 Session ownership、队列、调度、恢复、并发、权限、审计、artifact 和可观测性。Prime Agent 当前最有辨识度的部分就在这里。它暴露了一个事实：当 Agent 工作时间从 5 分钟延长到 5 小时，问题会从 AI 产品问题转化为可靠系统问题。

十、不要把"长时间运行"误解成"无限自治"

长程 Agent 最容易被营销语言带偏的地方，是把运行时间长与自主性强画等号。实际上，一个可信的长程系统应该比短会话系统拥有更多约束，而不是更少。

（一）真正成熟的自治必须可中断、可验证、可重放

1、每个阶段都应有外部完成定义

测试通过、指标达到阈值、产物存在、人工批准、PR review 通过，都比"模型说完成了"更可靠。Agent 应当把这些外部信号作为状态机的完成条件。

2、预算本身也是安全机制

token、时间、最大 continuation 数、并行子 Agent 数量都应有上限。无限上下文、无限子 Agent 和无限时间不会自动产生更好结果，只会扩大错误成本。

（二）可恢复比"从不失败"更现实

任何长期运行系统都会失败。生产设计应假设模型 API 会超时、进程会崩、网络会断、磁盘写会中断、第三方服务会返回意外状态。Prime Agent 当前最重要的工程工作，恰恰是把这些失败从"任务报废"变成"可识别、可修复、可继续"的状态迁移。

十一、结论：Prime Agent 值得关注，但应把它当"实验性 Agent Runtime"而不是万能自动化平台

Prime Agent 最有价值的地方，并不是它发明了更多 Agent 功能，而是它把长程 Agent 的几个关键矛盾放在同一个架构里：模型上下文有限，但任务状态必须长期存在；Agent 需要自由组合工具，但安全边界不能失控；执行策略应该从经验中改进，但改进必须可审计和回滚；终端可以断开，但任务所有权不能消失；进程可以崩溃，但业务状态不能因此变得不确定。

RLM 提供了一个高度程序化的模型工作面，让上下文、代码、工具和子 Agent 可以用 Python 组合；Continual Harness 尝试把过去轨迹转化为可持久复用的操作策略；daemon/worker/kernel/session 架构则把"后台继续运行、重新连接、恢复和调度"做成一等能力。三者组合起来，Prime Agent 确实比一般"Prompt + tools + memory"的 Agent 框架更接近一个长期驻留的执行系统。

但也必须看到，项目目前的风险与它的创新点完全重合。持久化越核心，crash safety 越不能妥协；daemon 越重要，worker identity 和 ownership 越必须严谨；跨会话越重要，状态污染和错误经验固化越危险；执行越自由，安全沙箱越不能缺位；跨平台用户越多，Windows 等兼容性越会成为真实门槛。

因此，对团队而言最合适的态度不是"是否全面迁移到 Prime Agent"，而是选择一个真实、长时间、可量化的任务进行压力验证：在 Linux 或受控容器环境中运行，故意制造断线与崩溃，检查 Session 是否可恢复；给所有业务动作增加幂等保护；把关键结果写入外部正式存储；用测试和质量门定义完成；记录成本和人工介入；最后再评估 Continual Harness 是否真的让第二次执行比第一次更稳定、更省成本。

如果这些指标成立，Prime Agent 代表的方向很值得长期跟踪。因为下一代 Agent 平台的竞争，最终可能不再是谁有更多工具、谁的 Prompt 更长，而是谁能把一个不确定的语言模型，放进一个可持久、可恢复、可审计、可约束、可持续积累能力的运行时里。

参考资料与延伸阅读

Prime Agent GitHub Repository --- 项目主页、当前 README、版本与源码。
Prime Agent --- RLM Programming Model --- RLM、持久 IPython、子 Agent、Skills 与 Trust Model。
Prime Agent --- Architecture Overview --- supervisor、worker、AgentSession、kernel 与持久化边界。
Prime Agent --- Long-Running and Background Agents --- attach/detach、heartbeats、schedule、persistent goal 和 autonomous mode。
Continual Harness: Online Adaptation for Self-Improving Foundation Agents --- Continual Harness 研究论文。
Prime Agent Issue #1380 --- Make persisted session and configuration state crash-safe --- 持久状态崩溃一致性与并发写入。
Prime Agent Issue #1381 --- Fence daemon worker identity and recover supervisor ownership safely --- daemon worker 身份与所有权恢复。
Prime Agent Issue #1382 --- Complete queued, interrupted, and archived session lifecycle recovery --- Session 中间态与恢复语义。
Prime Agent Issue #1194 --- Windows kernel bootstrap --- Windows 虚拟环境解释器路径问题及兼容性讨论。
OpenHands --- Runtime Architecture --- OpenHands 沙箱 Runtime 与执行架构。
OpenHands --- Agent SDK Architecture --- 事件驱动 Agent、Context、Condenser 与 Security Analyzer。
Aider Documentation --- Git 驱动的终端 AI Pair Programming。
Aider --- Git Integration --- 自动 commit、diff、undo 与 Git 工作流。
Claude Code Documentation --- Overview --- Auto Memory、Skills、Hooks、Agent Teams、后台 Agent、Web 和 Routines 等当前能力。
SWE-agent GitHub Repository --- SWE-agent 当前定位、SWE-bench 与 mini-SWE-agent 推荐方向。