Prime-agent 火了，DeepSeek Harness 也来了

引导语

prime-agent 的热度、pi 的积累和 DeepSeek Harness 的出现，凑在同一个时间点，刚好把 coding agent 的问题摊开了：模型差距还在，但工作台开始影响每天的使用体验。

前几天，我看到 prime-agent 这个名字。

一开始我以为，这又是一个典型的 GitHub 热门项目。一个开源 coding agent，带着「自我改进」「长期自主任务」「RLM」这些关键词，很容易让人产生一种感觉，新的答案是不是又来了。

资料翻下来，我关心的变成了另一件事：同样接一个强模型，为什么有的 agent 只能聊几轮，有的能在项目里持续干活，有的会记住前面的坑，有的却越跑越让人不放心？

差别很大一部分出在 harness。

截至北京时间 8 月 16 日，prime-agent 在 GitHub 上约有 16.4k Star，pi 约有 91k Star，DeepSeek Harness 约有 120k Star。涨星速度太快了，数字会变，我不把它们当成谁强谁弱的证据。但这几个项目在同一段时间被大量讨论，已经足够说明，开发者开始把注意力从「模型能不能回答」挪到「模型能不能完成任务」。

今天这篇就想把这件事查清楚。

我会先讲明白 harness 是什么，再看 prime-agent 为什么突然让人关注，pi 和它到底是什么关系，DeepSeek Harness 又在补哪一层。最后聊聊，我们现在到底该怎么选、怎么试，才不会刚看到一个新项目就把主力仓库交出去。

这篇只谈终端、项目目录、工具调用和长任务这一类 coding-agent harness。IDE 补全插件、普通聊天产品、纯模型跑分和企业协作平台也有价值，只是这次先不混在一起说。

Harness 到底是什么

harness 听起来像技术黑话。用人话说，它就是模型干活时的工作台。

模型很像一个脑子不错的人。它能理解需求、给方案、写代码，也能解释为什么这么做。

进了项目以后，模型还得知道从哪个目录开始看，哪些文件不能碰，能不能执行 shell，测试失败该翻哪段日志，任务中断怎样接上，写坏了又从哪里回退。这些不是模型参数天然附送的，得靠 harness 补齐。

所以，同一个模型接到不同工具里，体验差别会很大。有的更像一个聊天窗口，你问一句它答一句。有的会建立任务计划、读文件、调用工具、跑测试、保留会话状态。有的功能很多，但一旦任务拉长，命令输出和聊天记录越积越多，模型自己也开始找不到重点。

现在从三个角度看一套 harness。

第一，任务现场是否清楚。模型能看见什么，能用什么工具，哪些文件和目录被允许接触。

第二，过程是否留得住。它查过什么、试过什么、失败在哪里、任务断了以后能不能接上。

第三，边界是否收得回来。它能不能改文件、跑命令、读取敏感信息，出了问题我有没有清晰的暂停、审阅和回滚入口。

模型决定它能不能想明白；harness 决定它能不能在项目里把事做完，还不把现场弄乱。这是我的使用判断，不是官方定义。

prime-agent 把经验当成可维护的工作状态

prime-agent 的定位很明确，它是面向 coding workflow 和长期自主任务的开源 agent。它把两个概念放在了最前面，RLM 和 Continual Harness。

「自我改进」很容易让人上头，看到这种说法我们不妨先多问一句：它到底改了什么？

过去一年，这个词被用得太泛了。很多产品所谓的记忆，不过是把聊天记录多存了一份。下次它能叫出你的名字，知道你偏好中文回复，但一遇到真实项目里的规则、坑和协作边界，还是会重新踩一遍。

prime-agent 的做法要更具体一些。

官方说明里，它不会改模型参数。它会把补充提示、记忆、技能描述和可复用子 agent 规格，当成可以维护的长期状态。任务结束以后，/refine 可以根据当次轨迹做小幅更新。基础系统提示词保持不可变，更新有记录，也可以回滚。

它不训练模型参数，更像是项目做完后留下一页能翻出来的复盘。

这次为什么失败，哪条命令先跑，哪个目录有风险，什么做法被验证过。下一次再接近类似问题时，不用从零开始猜。

我在意的是，经验能不能从聊天记录里拿出来，变成一份可以审阅的东西。

平时用 coding agent，最浪费人的地方常常不是它第一次犯错。第一次不熟项目，读错文件，甚至改错一处，我都能理解。

最消耗人的是，你已经纠正过一次，隔几天重新开一个会话，它又像刚入职一样，重新问、重新试、重新踩同一个坑。

如果经验真的能留住，长期使用的感觉会完全不一样。

但这事不能只看宣传页。

经验积累也会出问题。一条偶然成功的规则，可能被误写成长期习惯。一段临时绕过方案，可能在后面变成隐患。什么都记，最后也会变成另一种混乱。

所以我不们不应该把 /refine 理解成「让 AI 自己学，自己越来越强」。我更愿意把它理解成，一本能够查看、能够对比、能够撤销的工作日志。

如果我后面真的要用它，先看四件事。

我要确认什么	为什么重要
经验具体写到哪里	不能把长期规则藏在我看不到的状态里
每条经验来自哪次任务	需要知道它有没有足够证据
修改记录是否可审阅	规则和代码一样，都可能需要 code review
不合适时怎样回滚	能删除，才敢长期积累

这些检查不花哨，却决定经验会越积越有用，还是慢慢变成没人敢碰的旧规则。

RLM：别让长任务把上下文堆满

prime-agent 的另一条路线叫 RLM，Recursive Language Model。

官方描述是，把上下文作为变量，把递归子 agent 当成函数调用，运行在持久的 Python REPL 里。

这句话听着抽象，换成一个任务就容易理解。

假设你要让 agent 读一堆配置、筛出过期项、改完以后跑测试，再把失败原因归类。普通对话式 agent 很容易把文件片段、命令输出、测试日志、失败堆栈一路塞进聊天上下文。

短任务没有问题。

任务一长，麻烦就来了。上下文里堆满中间过程，模型需要在一大堆自己刚刚制造出来的信息里找重点。读者如果用过很长的 coding agent 会话，应该都见过那个时刻，前面明明已经查到了，后面它又像没见过一样重新翻一遍。

RLM 的思路是把中间结果放到程序环境里。

# 这里只是帮助理解思路，不是 prime-agent 的完整 API。
config = open("config.json", encoding="utf-8").read()
expired = [line for line in config.splitlines() if "deprecated" in line]
print(expired)

需要筛选时就筛选，需要统计时就汇总，需要拆任务时再调用子 agent。最后带回给模型的，是处理后的结果，而不是每一段原始材料。

它更适合三类任务。

场景	RLM 可能带来的帮助
输入很长、目标明确	从日志、配置、文档里筛选和提取信息
需要多轮检查	先扫描、再验证、再汇总，不必反复重塞上下文
可以拆成子任务	按模块并行调查，最后统一复核和测试

需求没讲清楚，或者每一步都要人做业务判断，拆得再细也消不掉误解。RLM 处理的是过程复杂度，不替人定义问题。

还有一条必须放在这里。

Prime Agent 官方明确提醒，它会以当前用户权限执行模型生成的 Python 和项目命令，它不是安全沙箱。官方建议使用可丢弃的副本、干净工作树，或者外部限制环境。

先记住这一条：一个 agent 越能自主执行，越不该直接放进主力仓库。

prime-agent 从 pi 上长出来，却走向了另一头

prime-agent 的 README 中写得很坦白，它的 agent 和 TUI 建在 pi 之上。

拿父子关系来讲故事容易，拿它做判断就不够了。

pi 现在是一个更轻量的 agent harness。它包含终端 coding agent、agent runtime 和统一多模型 API，但把大量选择交给了用户。模型怎么接，规则怎么写，扩展怎么装，怎么隔离环境，都可以自己决定。

这条路线并不省心。

pi 也明确说明，默认没有内置的文件、进程、网络或凭据权限隔离。想要更强边界，需要自己使用 Docker、micro-VM 或其他沙箱方案。

但轻量的好处也在这里。你知道哪一层是自己接的，哪一层是自己配的，哪一条规则是自己写的。遇到问题时，至少还有机会把它拆开。

prime-agent 则把更多东西先装好。持久 Python、后台会话、子 agent、任务目标、心跳和经验沉淀，都更接近一台已经组装好的长任务机器。

两者不该用“谁更先进”来排队，问题是你愿意把复杂度放在哪一边。

你更在意什么	更接近的选择
自己掌控模型、规则、扩展和运行方式	pi 这类轻量 harness
希望长任务、后台恢复、子 agent 与经验沉淀更完整	prime-agent 这类厚 harness
只想稳定处理日常任务	先把熟悉的 coding agent 用顺，再看是否真有长任务瓶颈

薄 harness 的成本在前面。你需要自己配置、自己判断、自己把边界搭起来。

厚 harness 的成本在后面。系统替你做了更多预设，你也需要花时间理解它保存了什么、替你启动了什么、什么时候会越过你的预期。

DeepSeek Harness 把问题换到了组件层

官方 README 里最醒目的一句是 Everything is a Plugin。它基于 Cordis，强调模型、工具、界面和工作流都应该放进一个可替换、可组合的插件架构里。

prime-agent 关心的是 agent 怎样跑得久、留下经验、保住长任务状态。

DeepSeek Harness 更在意，一套 agent 环境怎样不被焊死。今天只在终端跑，明天又想接 Web 界面、换一组工具、补一段工作流；每多一个变化，是否都要把整套东西推倒重来？

对喜欢搭工作流的人来说，这个问题很真实。

DeepSeek Harness 的方向就是，希望把这些零件拆开。模型是一块，工具是一块，界面是一块，流程也是一块。需要什么就接什么，换一部分也不必把整间工作室拆掉。

这里容易看错的是：它不是单纯在做一个「插件更多」的 coding agent。它想把插件当成 agent 的组成方式。底层的 Cordis 负责组件的装载、卸载与依赖关系；上层才是你看得到的模型、工具、界面和工作流。它背后的取舍也因此很鲜明：pi 把底座压薄，把搭配权交给用户；prime-agent 把长期任务、持久状态和经验沉淀装进系统；DeepSeek Harness 则更关心这些能力能不能在同一个运行环境里被拆开、替换和重新组合。

对普通使用者，这不是让你一上来就去「造插件」。更实际的理解是：它目前更像一个可研究、可试验的 agent 工作台。你可以先用它跑一个隔离目录里的小任务，观察工具、会话和界面怎样拼起来；等你真的遇到固定模型、固定权限、内部搜索或专属流程这类需求，再考虑是否有必要把它做成可复用的组件。

但这里也要冷静一点。DeepSeek Harness 官方仍把它标为 developer preview，并明确提示会有不兼容变更。

所以应该把它看作一个非常值得观察和试验的架构方向，而不是因为热度就立刻承担主力生产任务的成品工具。

把 pi、prime-agent、DeepSeek Harness 放在一起看，差异会更清楚。

项目	当前更突出的重点	我会先检查什么
pi	轻量底座、多模型与用户自主组合	规则、扩展、容器化和权限边界
prime-agent	长任务、持久状态、RLM、经验沉淀	/refine 记录、后台任务和回滚方式
DeepSeek Harness	以 Cordis 为核心的插件化运行环境，强调组件可替换、可组合	插件边界、升级策略和兼容风险

它们同样都叫 harness。

但并没有在回答同一道题。

四派格局，这条战线到底是谁在打

我自己分成四种格局派系：看谁在做 harness，把它做得多厚，又准备交给谁用。

第一派，是大厂派。Claude Code、Codex CLI、DeepSeek Harness、Qwen Code、Kimi Code 都在这一边。它们的共同点，是模型公司不再只卖模型，而是亲自来做终端、会话、权限、工具调用和工作流这一层。Claude Code 适合深度接入 Anthropic 生态；Codex CLI 把审批模式和受限目录的沙箱自动化做成明确选项；Qwen Code 与 Kimi Code 则把国内模型、会话、Skills 和 Agent 能力装进自己的产品路径。DeepSeek Harness 也是大厂派，只是它选择先把模型、工具、界面和流程拆成插件化组件，产品形态更像在铺一层基础设施。

第二派，是社区派。这派不绑定某一家模型，工具长得也最不一样。OpenCode 是实用主流：多模型、多 provider、终端、桌面、IDE、Web、MCP 和项目级配置都能接，核心思路是把一套开源工作台做全。prime-agent 是更激进的社区实验：它把持久 Python、长任务、子 agent、任务恢复和 /refine 放到中心，试图让 agent 积累经验。Hermes Agent 走得更宽，它不只盯 coding，而是把跨会话记忆、Skills、定时任务、子 agent 和多平台入口做成一套个人 agent 系统。三者都属于社区路线，但解决的不是同一个问题。

第三派，是极简派。目前最有代表性的仍是 pi。它有终端 agent、运行时和多模型 API，但模型、规则、扩展、隔离方式大多交给用户决定。这样做的好处是可控、可替换，也能看清每层发生了什么；代价是很多默认值不会替你准备好，权限隔离也要自己补上。prime-agent 建在 pi 之上，却往另一端走，把长期自主能力越装越多。这对“父子”分叉得很彻底。

第四派，是平台派。OpenClaw 更接近这一类：它把多聊天入口、会话路由、插件、Skills 市场和 agent runtime 包进一个可自托管的平台，面对的任务和用户也比终端 coding agent 更广。平台派有开箱能力和生态，接入渠道、技能来源和运行边界也要审得更严。

把所有工具放回这张地图里，会更清楚。

派别	代表工具	核心回答	适合谁	主要取舍
大厂派	Claude Code、Codex CLI、DeepSeek Harness、Qwen Code、Kimi Code	模型公司是否把工具层一起做进去	已有模型订阅或企业生态，想少配环境的人	接受产品默认路径与生态绑定
社区派	OpenCode、prime-agent、Hermes Agent	社区能把 agent 做成怎样的工具或长期系统	想多模型、自定义，或愿意试验新工作流的人	质量差异大，配置与安全验证要自己做
极简派	pi	harness 能不能尽量薄，把选择权交回用户	重视可控、可替换、愿意自己搭规则的人	不省心，隔离、扩展和默认策略都要自己负责
平台派	OpenClaw	能不能把 agent 包进多入口、技能和服务生态	希望把 agent 用到聊天、自动化和日常事务的人	连接面更广，权限与技能来源要审得更严

没有哪一派天然会赢。

你想自己控制，就要承担配置的复杂度。

你想省事，就要接受产品默认值。

你想让 agent 跑得更久，就要接受更多状态、更多权限和更多审阅工作。

这不是某个项目的问题，是 agent 从聊天工具走向工作工具以后一定会遇到的交换。

我的选择：先看任务，再选工具

日常写代码和项目排错，我会优先从大厂派里选。

如果你已经有 Claude、ChatGPT、Qwen 或 Kimi 的订阅与使用习惯，Claude Code、Codex CLI、Qwen Code、Kimi Code 这类工具通常是成本最低的起点。改一个 bug、补一个功能、看一个陌生项目，最重要的是打开就能用、改动看得清、测试能跑起来。此时为了一个小任务从头搭环境，通常不划算。

Claude Code 更适合已经在 Anthropic 生态或企业平台里工作、需要在终端持续处理项目的人。Codex CLI 的审批模式和目录范围内的沙箱化全自动模式，适合希望逐步放权、但仍要保留清晰操作边界的人。

模型会频繁切换，或者想接本地路由时，我会先看社区派，再判断自己是否需要极简派。

OpenCode 是我会先看的那个。它能接多 provider、支持项目级配置、插件、MCP 和可细分的权限规则，终端、桌面、IDE、Web 也能走同一套工作流。你想让同一套工作方式接 Claude、GPT、国产模型或本地模型，OpenCode 比绑定单一生态的工具更自然。

pi 则更适合已经知道自己要什么的人。你清楚规则放哪里、扩展怎么选、模型怎么接、容器怎么隔离，它会给你更薄的底座。代价也很直接，很多默认值不会替你准备好。

想把 agent 变成长期助手时，我会在社区派里看 prime-agent 和 Hermes Agent，但先把权限收紧。

用 prime-agent 时，我会盯着两件事：多次任务后，它有没有少让我重复解释；留下来的经验，会不会把规则带偏。Hermes Agent 更像一套个人 agent 系统，它有跨会话记忆、Skills、计划任务、多平台入口和子 agent，适合把代码、研究和个人自动化放进同一套长期工作流里。

可这一派的共同风险也最明显。它们不只是帮你答一轮问题，而是会留下状态、持久运行，甚至连接更多工具和渠道。我的建议很保守，先给干净 clone 或独立目录，只跑可验收的小任务，确认记录、权限、恢复和停止方式都看得懂，再逐步扩大范围。

想研究 agent 架构时，我会把大厂派里的 DeepSeek Harness 放进单独试验台。

它的插件化思路很有价值，特别适合想弄清模型、工具、界面和流程怎么拆开的人。但 developer preview 和不兼容变更已经写在官方 README 里，这个阶段更适合跑样例、看插件边界、验证自己的组件接法，不适合因为热度就承担稳定生产任务。

如果把建议压成一句话，就是这样。

日常任务先从大厂派里选最顺手的工具；多模型与本地路由先看社区派的 OpenCode，想把底座压薄再试 pi；长期自主任务再碰 prime-agent 或 Hermes；DeepSeek Harness 适合单独研究架构，OpenClaw 适合要扩展到多入口和日常自动化的人。无论选谁，第一次都先放进隔离目录。

我现在怎么用：终端和桌面，故意不只留一个工具

说到这里，我也把自己现在的组合交代清楚。

我的终端主力是 Claude Code 和 pi。桌面端则更多用 ChatGPT 和 WorkBuddy。

我没有把它们都留下来凑工具箱。它们在我手里分工不同。

场景	我更常用的工具	我把它放在这里的理由
进入真实项目、读代码、改文件、跑命令和测试	Claude Code	终端里的连续工作感更强。一个任务要反复读项目、改动、验证、再回头修时，我更需要的是上下文不断、操作过程能看见，而不是一次漂亮回答。
想自己决定模型、路由、规则和扩展	pi	它不替我把所有默认值先定好。对需要反复换模型、接本地或中转通道、试规则的任务，这种薄底座更方便把问题拆出来，也方便知道究竟是哪一层出了问题。
先把问题聊透、理顺思路、拆任务和核对信息	ChatGPT 桌面端	这类工作开始得很早，往往还没有一个需要立刻修改的项目目录。桌面端适合把零散想法、资料和判断先摊开，等问题真正收敛后再带进终端执行。
从一个具体需求快速推进，边看边改边确认结果	WorkBuddy	我更常把它当成桌面上的协作入口：把一句不完整的需求先变成可讨论的界面、流程或下一步，再决定哪些部分值得进入正式工程。它先帮我跨过「不知道从哪里开始」这一步。

这样用以后，我不再纠结谁才是“唯一最强”的 agent。

现实里，写代码、想清楚需求、查资料、看结果、在项目里执行，本来就是不同状态。终端工具适合把事情做实，桌面工具适合把问题摊开。把它们混成同一场比赛，反而容易选错。

我更在意它能不能在自己负责的那一步少添麻烦。需要进仓库、跑命令、看 diff，就回到终端；还在梳理想法、比较方案、确认需求，就先留在桌面。最后仍由人决定，这件事要不要进入正式项目，agent 能做到什么程度。

大家怎么选，别先看派别，先看手上的任务

很多人看到这些新工具，会有一种焦虑。一个新模型还没摸明白，又来了 RLM、harness、插件架构、后台 agent。好像不全装一遍，就已经落后了。

我觉得没必要。

如果你只是偶尔改 Bug、写个小功能、问一下代码，先把当前最熟的工具用顺。它能读懂项目，改完能给你 diff，测试能跑起来，已经比追一个热词更重要。

经常做多文件改造、长时间排错、资料整理，再去看长会话、任务恢复和上下文管理。省下来的时间，常常在任务中断之后：不用把背景从头再说一遍。

如果你想试自我改进、长任务或插件化架构，我建议第一次按照下面的顺序来。

1. 用 git clone 建一个可随时丢弃的副本，不在主力目录直接试。
2. 先给一个只读的小任务，例如找出过期配置，但不要修改文件。
3. 再允许它改文件，同时要求它跑指定测试，并把 diff 留下来。
4. 如果它会写记忆、规则或经验，只允许它先写一条，手动检查来源和必要性。
5. 连续跑三到五个真实任务，再判断它到底是在帮你省时间，还是在制造新的审阅工作。

这套方法有点笨，但比看完一段演示视频就把项目交出去可靠得多。

我最后更在意的是：它能不能放心用

这部分是我的判断，不是厂商的结论。

模型还会继续变强，跑分也会继续更新。真要把 coding agent 放进日常工作，我会盯住几件更具体的事：它留下了什么状态，我能不能看见；它跑过哪些命令，我能不能制止；任务中断后还能不能接上；改错时有没有清楚的回退办法。

一次回答漂亮，不足以让我把重要项目交出去。要连续做过几次真实任务，失败时解释得明白，改动也能审，才谈得上信任。

重看 prime-agent、pi 和 DeepSeek Harness 后，我的感受很简单：模型只是进场的人，harness 决定现场怎么运转。工具能不能收住权限，记录有没有留下来，出了问题能不能停下，都比演示视频里的那一下惊艳更接近日常使用。

想试新 agent 没问题。第一次请用一个能随时丢掉的副本，先看它怎么读文件、怎么下命令、怎么留下改动。跑过几次再决定要不要扩大权限。

---

如果你觉得这篇内容有价值，欢迎点个赞、点个在看，也欢迎转发给更多朋友。

我是 AI杨侦探，持续记录 AI、技术、产品和产业变化里那些真正值得看、值得想的事。

谢谢你读到这里，我们下次见。