Claude Code跑10个会话吃2.3GB，这个10K星的Rust开源项目10个才117MB

开篇

你有没有遇到过这种情况——

用 Claude Code 重构一个 Spring Boot 的订单模块，聊了20分钟，模型开始"失忆"了。它忘了你刚才说过要把 @Transactional 从 Service 层提到 Controller 层，忘了 OrderStatus 枚举已经从5个值变成了8个值，忘了那个你反复强调了三遍的业务规则。

你只能把上下文重新喂一遍。Token 哗哗地烧，钱哗哗地花。

更崩溃的是：你想同时搞两件事——让一个 Agent 改 OrderService.java，另一个 Agent 同步改 OrderController.java 的调用。你开了两个终端，两个 Claude Code。结果呢？A 改完保存，B 完全不知道文件变了，继续基于旧代码生成新代码。等你合并的时候，发现满屏的冲突。

你可能会想：是不是模型不够强？要不要换成 GPT-5.6？

但真相可能让你意外：模型没变，是跑模型的"壳"不够好。

这层壳，在 AI 编程领域有个专业名词叫 Harness——Agent 运行基座。它负责把模型、上下文、记忆、工具、权限、终端界面、多智能体协作串起来。模型决定 Agent 的天花板，但 Harness 决定你的 Agent 能稳定工作多久、一次能处理多复杂的任务。

今天聊的这个项目，就是一个独立开发者用 Rust 从零写的 Harness。10天冲到 1 万星，本周还在涨。它把 Claude Code 的内存占用砍掉了 20 倍，启动速度快了 245 倍，还让多个 AI 在同一个项目里同时改代码而不会互相踩脚。

这个项目叫 jcode。

一、jcode 是什么

一句话：jcode 是 Rust 写的 Coding Agent Harness，专为多会话、多 Agent、持久记忆而设计。

它不是 Claude Code 的替代品——它是 Claude Code 的"底座替代品"。你用 jcode 依然可以选择 Claude 当模型，但跑模型的运行时换了。

作者叫 1jehuang，单人项目。仓库地址 github.com/1jehuang/jcode，MIT 协议开源，6,000+ commits，v0.58.0 版本，支持 macOS / Linux / Windows / Termux。

项目的官网域名也很有野心：jcode.sh。

但比这些数字更值得关注的是它的设计哲学——jcode 不把自己定位为"又一个 AI 编程工具"，而是"Agent 的操作系统"。它管理的不只是你和一个 AI 的对话，而是一群 AI 的状态、记忆、通信和协作。

二、性能：不是快一点，是快两个数量级

先看数据。这是 jcode 自测的结果（PSS 内存测量，Linux 环境）：

单会话内存对比：

工具	内存占用	相对 jcode
jcode（本地嵌入版）	27.8 MB	1x
Codex CLI	140.0 MB	5.0x
Cursor Agent	214.9 MB	7.7x
Claude Code	386.6 MB	13.9x
OpenCode	371.5 MB	13.4x

10个活跃会话内存对比（这才是多任务场景的真实情况）：

工具	内存占用	相对 jcode
jcode（本地嵌入版）	117.0 MB	1x
Codex CLI	334.8 MB	2.9x
Cursor Agent	1,632.4 MB	14.0x
Claude Code	2,300.6 MB	19.7x
OpenCode	3,237.2 MB	27.7x

每增加一个会话的边际内存成本：

工具	每会话增量
jcode（本地嵌入关）	9.9 MB
Codex CLI	21.6 MB
Claude Code	212.7 MB
OpenCode	318.4 MB

什么意思？你用 Claude Code 开 3 个会话，内存就接近 1GB 了。而 jcode 开 10 个会话才 117MB——比 Claude Code 一个会话还小。

启动速度对比（首帧时间）：

工具	启动时间	相对 jcode
jcode	14.0 ms	1x
pi	590.7 ms	42x
Codex CLI	882.8 ms	63x
OpenCode	1,035.9 ms	74x
Cursor Agent	1,949.7 ms	139x
Claude Code	3,436.9 ms	245x

14 毫秒——比你的显示器刷新一帧还快。Claude Code 要 3.4 秒，够 jcode 启动 245 次。

这些数据是怎么做到的？三个词：Rust、零成本抽象、自研渲染层。

jcode 的终端界面叫 Handterm，是作者从零用 Rust 写的，不依赖 Electron、不加载浏览器引擎、不走 Node.js 那套重型渲染管线。Mermaid 图表渲染也是自研的 mermaid-rs-renderer，号称比官方的 mermaid-cli 快 1800 倍——因为根本不需要启动一个无头浏览器来跑 JavaScript。

做 Java 的同学可以类比一下：Claude Code 就像启动一个 Spring Boot 应用，带着 Tomcat、带着 AOP 切面、带着连接池，启动等个 3 秒很正常。jcode 就像你写了一个 public static void main，直接 Run——秒开。

三、记忆系统：不是聊得多就记得多

性能数据很漂亮，但 jcode 真正让我觉得"这东西会改变事情"的，是它的记忆系统。

现有的 AI 编程工具怎么处理"记忆"？基本上是三种方式：

1. CLAUDE.md / CODEBUDDY.md：你在项目根目录写一个 Markdown 文件，告诉 Agent 一些固定规则。这是"静态记忆"。
2. 对话历史：直接把前面的对话拼进 prompt。这是"线性记忆"——越聊越长，越长越贵，越贵越容易在长文里丢失关键信息。
3. 手动 /compact ：你感觉上下文太长了，手动触发压缩。这相当于"手动记忆"——取决于你什么时候想起来该清一清了。

jcode 的做法完全不同。它用了一套语义向量记忆系统：

• 自动嵌入：每一轮对话和代码变更，都被编码成语义向量，存入记忆图谱。
• 被动检索：每轮对话开始时，系统自动用余弦相似度匹配相关记忆，注入到当前上下文里。Agent 不需要主动调用"搜索记忆"这个工具——记忆自己会"浮现"。
• 记忆提取：一个后台的"记忆 Agent"会根据语义漂移、轮数阈值、会话结束等触发条件，自动从对话中提炼新的记忆条目。
• 环境整合：Ambient Mode 下，系统定期重组记忆图谱，检查过期信息和潜在冲突。

这套设计的本质是什么？

它把记忆从"Agent 主动去找"变成了"系统被动地给"。

这跟人类记忆很像。你不需要主动调用"回忆昨天午饭吃了什么"这个函数——当你路过昨天那家店的时候，记忆会自动浮现。jcode 要做的就是让 AI Agent 也拥有这种"被动联想"能力。

结果呢？Agent 在长对话中不再"失忆"。你 3 天前说的那个业务规则，今天继续聊的时候它会自动想起来——不需要你再重复一遍，不烧多余的 Token。

四、Swarm：两个 AI 在同一个项目里互改代码

如果说记忆系统是 jcode 的"大脑"，那 Swarm 就是它的"社会协作系统"。

这是我见过最激进的设计：让多个 AI Agent 在同一份代码仓库里同时工作，实时感知彼此的改动。

具体怎么运作的：

1. 你在一个 Spring Boot 项目里开了两个 Agent——A 负责 OrderService.java，B 负责 OrderController.java。
2. A 改了 OrderService 里的 submitOrder 方法签名，增加了一个 CouponContext 参数。
3. jcode 的服务端检测到：B 之前读过 OrderService.java，现在这个文件被 A 改了。
4. 服务端立即通知 B：“你之前读过的文件被改了，要不要看看 Diff？”
5. B 可以忽略（如果跟自己的任务不相关），也可以拉取最新的 Diff，重新调整自己的代码。

这在传统的 Git Worktree 方案里，几乎不可行——因为你得手动感知"什么时候该 pull、什么时候有冲突"。jcode 把这个过程做成了基础设施层的内置能力。

更激进的是：Agent 可以自己创建子 Agent。

你在 jcode 里跟主 Agent 说：“把这个支付模块拆成三层重构——Service 层、Gateway 层、测试层，三个 Agent 并行干。”

主 Agent 自己用 Swarm 工具 fork 出三个子 Agent，分别分配任务。子 Agent 干完活通知主 Agent，主 Agent 汇总结果。整个过程，你只需要给出顶层指令。

这也是为什么作者在 README 里说"Git 不太适合多智能体工作流"——他甚至计划开发一套新的 Git-like 原语，专门为多 Agent 协作场景设计。

五、Self-Dev：Agent 可以改自己的源代码

还有一个让我头皮发麻的设计：Self-Dev 模式。

在 Self-Dev 模式下，Agent 可以修改 jcode 自身的源代码——编辑、构建、测试、热重载二进制，全部自动完成。

你可能会问：这有什么实际用途？

想象一下这个场景：你让 Agent 帮你重构一个微服务项目。Agent 发现 jcode 自带的 Agent Grep 工具在搜索大型 Maven 项目时不够好用——返回的搜索结果缺少 Maven 模块的层级信息。Agent 直接打开 jcode 的 agent_grep.rs，加了几行代码，编译，重载——然后继续重构你的项目。

它把"我需要工具更好用"和"我改工具让自己更好用"这两个步骤合并成了一个闭环。

当然，这个模式目前推荐使用前沿模型（GPT 5.5+），因为自己改自己这件事对模型的代码理解能力要求极高，改坏了可能把自己改崩。但方向本身非常值得关注——当 AI 能修改运行自己的基础设施时，工具的迭代速度就不再受限于人类的 commit 频率。

六、这些设计拼在一起，意味着什么

把性能、记忆、Swarm、Self-Dev 这四件事放在一起看，你会发现 jcode 不是在做"更好的 Claude Code"。它在做一件不同的事情：

维度	传统 AI 编程工具	jcode
定位	单会话助手	多 Agent 运行基座
记忆	线性上下文 + CLAUDE.md	语义向量图谱 + 被动注入
协作	你和一个 AI	你管理一群 AI，它们互相通信
扩展	插件/配置	Agent 直接改源码
性能	Node.js/Electron 重型	Rust 原生，启动 14ms

最关键的转变是：从"工具"到"平台"。

Claude Code、Codex、Cursor 这些东西，本质上是"AI 编程工具"——你打开它，跟它对话，它帮你写代码，你关闭它。下次打开，一切从零开始。

jcode 是一个"Agent 运行时"——你可以让它作为后台服务一直跑着，管理多个 Agent 的状态、记忆、协作。它不需要你每次关掉重来，因为记忆是持久化的，会话是可恢复的，Agent 之间的协作是基础设施层的内置能力。

这让我想起一个类比：Git 出现之前，大家用 diff + patch 也能管理代码版本。但 Git 把"版本管理"这件事从临时操作变成了基础设施。jcode 想做类似的事——把"多 Agent 协作"从手工编排变成基础设施。

七、这给了我们什么启示

第一，AI 编程的下半场，竞争焦点从"模型"转移到了"上下文管理"。

过去一年，所有人都在追更强的模型。但同一个 GPT-5.6，放进不同的 Harness 里，表现天差地别。原因很简单：模型再强，也是 20 万 Token 的上下文窗口。你怎么管理这 20 万 Token——注入什么记忆、屏蔽什么噪音、在什么时机哪些 Agent 看到了什么文件——这些"上下文工程"才是生产力的真正差距。

jcode 的语义记忆、被动注入、Agent Grep、Lazy Skill Loading，本质上都是在优化"给模型喂什么"这个问题。

第二，Rust 在 AI 基础设施层的竞争力正在爆发。

jcode、colibri（744B 模型跑在 25GB 笔记本上）、ds4（Redis 之父的 C 推理引擎）——这一波项目都在告诉你同一件事：当你需要绝对的控制力和极致的资源效率时，Rust 和 C 是绕不开的选择。

TypeScript 写的工具启动要 1 秒，Rust 的 14 毫秒。这不仅是"快"的问题——当启动足够快，你可以随时开关 Agent，不需要一直维持一个占用 2GB 内存的后台进程。这会彻底改变你对"AI 编程助手"的使用习惯。

第三，"自己改自己"可能重新定义软件迭代的速度。

Self-Dev 模式目前还在实验阶段，但方向是对的。如果 AI Agent 能修改自己的运行环境、优化自己的工具链、修复自己的 Bug——那工具的进化速度将不再受限于人类 commit 的频率。一个活跃的 repo 一天可能有几个 commit，但一个 Self-Dev Agent 一小时就能迭代几十次。

八、Claude Code 还是 jcode：你该怎么选

说了这么多，你可能会问：那我到底要不要换成 jcode？

回答这个问题之前，先搞清楚两件事的定位差异——

Claude Code 是个工具。你打开终端，输入 claude，跟它聊，它帮你写代码，你关闭终端。下次打开，一切从头开始。

jcode 是个运行时。你启动 jcode serve，它作为后台服务一直跑着。你随时从不同终端连接它，所有 Agent 共享同一套记忆、同一套协作机制。你关掉终端再打开，Agent 还记得你昨天说的那句"@Transactional 要提到 Controller 层"。

这两个定位，对应的是完全不同的使用场景：

场景	Claude Code	jcode
偶尔让 AI 改几行代码	✅ 够用	🚫 杀鸡用牛刀
拿一个 IDEA，从头写到尾	✅ 单会话够用	✅ 也能干
同时开三四个 Agent 并行干活	😭 内存爆炸，每开一个 +200MB	✅ 每增一个只 +10MB
多个 Agent 改同一个项目（前后端分离、微服务重构）	😭 手动 git 协调冲突	✅ Swarm 自动碰撞检测
跨天甚至跨周的长项目（重构/迁移）	😭 每天重说一遍需求	✅ 语义记忆持久化
给团队定制一套 Agent 工作流	😭 每人自己配 CLAUDE.md	✅ 服务端统一管理 Skill 和记忆

简单说：如果你打开 Claude Code，一次性聊完，关闭，问题解决——那 jcode 对你没有意义。 你不需要为了"快 245 倍"而去换——3.4 秒和 14 毫秒的区别，在你只开一个会话的时候感知不到。

但如果你经常同时开两三个终端、在同一个项目里并行干活、或者一个需求要跨好几天才能做完——那 jcode 解决的就是你每天都在骂、但以为"就这玩意儿了"的问题。

还有一点值得单独提：jcode 支持跨 harness 会话恢复。你下午在 Claude Code 里写到一半，晚上切到 jcode 可以 resume 继续——记忆连续，对话连续。这意味着你不是"迁移"到 jcode，而是"先把 jcode 装上，哪天 Claude Code 扛不住了，切过去试试"。零锁定风险。

写在最后

当然，jcode 不是完美的。

104 个 Open Issue 说明它还不够成熟，benchmark 是作者自测而非第三方独立验证，MCP 当前只支持 stdio 模式不支持 HTTP/SSE，iOS 客户端还在开发中。整体来看，它更像一个有明确方向的实验品，而不是一个能闭着眼睛上生产的成品。如果你需要一个 Production Ready 的选择，Claude Code 依然是更稳的那条路。

但 jcode 代表了另一个方向——把 Agent 的基础设施从"能用"推到"极致"。

当别人还在争论 GPT-5.6 和 Claude Fable 5 谁更强的时候，jcode 的作者在用 Rust 一行一行地抠性能、抠内存、抠启动速度。他在做一件更底层、更慢、但可能在更长时间内产生更大影响的事情。

模型决定 Agent 的上限，但 Harness 决定你的 Agent 能走多远。

---

参考来源：github.com/1jehuang/jcode, jcode.sh, jcode Memory/Swarm Architecture 文档

---

本文首发于「圈圈的AI工程笔记」