单会话 27.8 MB，比 Claude Code 省 13 倍内存——我试了 Rust 写的 jcode

我日常工作会同时开好几个 AI 编程会话：一个改后端，一个调前端，一个写脚本。但机器内存只有 16GB，开三个 Claude Code 会话就开始风扇狂转，开五个基本就卡得没法用了。

然后我发现了 jcode。Rust 写的 coding agent harness，单 session 占用 27.8 MB，冷启动 14ms，10 个 session 并行也才 117 MB。GitHub 周增 3550 Star。

我把它装在一台老 MacBook Air 上试了一周。今天聊聊这个工具到底怎么把内存压下来的，以及它适合谁。

一、先上硬数据

我根据公开 benchmark 整理了一张对比表：

Harness	单 session 内存	10 sessions 内存	冷启动时间
jcode（关 embedding）	27.8 MB	117 MB	14 ms
jcode（开 embedding）	167.1 MB	260.8 MB	约 50 ms
Codex CLI	140.0 MB	334.8 MB	882 ms
Cursor Agent	214.9 MB	约 1.9 GB	1,949 ms
Claude Code	386.6 MB	约 2.3 GB	3,436 ms
OpenCode	371.5 MB	3,237 MB	1,035 ms

最直观的感受：jcode 关 embedding 时，一个 session 的内存连 Claude Code 的零头都不到。 这意味着在 8GB 的 MacBook Air 上同时跑 5-10 个 session 完全不慌。

二、jcode 是什么

简单说，jcode 是一个原生的 AI 编程 Agent 执行框架（harness）。它提供：

启动 session 加载 LLM provider（Claude / GPT / Gemini / OpenRouter） 运行 agent 循环 执行工具调用（文件读写、shell、搜索等） 管理上下文和记忆

和 Claude Code、Codex CLI 属于同一类产品，但 jcode 是从 Rust 原生构建的，不走 Node.js / Electron 路线。

核心分成四个模块：

Harness Runtime：启动 session、加载 provider、调度 agent 循环 Memory Subsystem：跨 session 的语义记忆 Provider / MCP 适配层：接入 LLM 和外部 MCP 工具 TUI：终端交互界面

三、内存是怎么压到 27.8 MB 的

jcode 能做到这个内存占用，主要靠三点。

1. Rust 原生，无 Electron / Node.js

Claude Code、OpenCode 这类工具基于 Node.js 和 V8。V8 本身的 baseline 内存就不低，再加上 transitive dependencies，单进程几百 MB 是常态。jcode 是 Rust 编译的原生二进制，没有 JIT 运行时，PSS 接近普通系统进程。

2. 本地 embedding 是可选开关

这是最关键的一项。jcode 的记忆系统用本地 ONNX embedding 做语义检索，但这个模块可以关掉：

开 embedding：单 session 167.1 MB 关 embedding：单 session 27.8 MB

关掉后，记忆子系统退化成"文件 文本索引"，但 session 间持久化、命令历史、调用栈记录这些功能都还在。对于资源敏感的机器，这个开关非常实用。

3. 多 session 内存增长接近常数

jcode 的设计目标不是单 session 功能最丰富，而是让多个 session 并行时内存不爆炸。实测 10 个 active session：

jcode（关 embedding）：117 MB Claude Code：约 2.3 GB OpenCode：3.2 GB

这个差距在真实工作流里是决定性的。

四、安装和上手

安装方式很直接：

curl -fsSL https://jcode.sh/install | bash

装完之后直接运行：

jcode

就会进入 TUI 对话界面。交互习惯和 Claude Code 接近，迁移成本不高。

常用命令

jcode serve# 启动服务端jcode connect# 连接远程/本地会话jcode run "任务描述"# 非交互式运行jcode memory # 体验跨 session 记忆jcode memory-demo# 跑记忆 demo

配置文件在 ~/.jcode/config.toml，可以调：

compaction 模式 memory 设置 safety 安全配置 MCP server 列表 生命周期钩子

五、Swarm：多 Agent 协作是差异化能力

jcode 不只是省内存，它还支持 Swarm 模式：多个 Agent 在同一个仓库里并行协作。

典型场景：

Agent A: 改 React 前端Agent B: 改 Rust 后端Agent C: 写测试

它们之间会：

感知彼此改了哪些文件 避免代码冲突 必要时互发消息协调 自主派生子 Agent 处理子任务

省内存的意义在这里体现得很清楚：如果跑 3 个 Claude Code 就要 1GB ， Swarm 根本没法常态化。但 jcode 三个 session 加起来不到 100 MB，多 Agent 协作才变得实际可行。

六、语义记忆系统

jcode 的记忆系统分几层：

事实（facts）：用户偏好、项目约定 实体（entities）：代码库里的关键模块、函数 偏好（preferences）：输出风格、常用命令

记忆通过本地 ONNX embedding 做语义检索（也可以关掉换文本索引）。跨 session 持久化，下次打开同一个项目，Agent 还记得你上次说的"我们用 4 空格缩进"。

有个 jcode memory-demo 可以体验：保存一条记忆后，再问相关问题，Agent 能直接命中。

七、实际使用体验

我主要试了三个场景。

场景 1：多项目并行

同时开了三个 session：

一个看 Python 数据处理脚本 一个改 Go CLI 工具 一个写 TypeScript 前端组件

三个 jcode session 加起来内存不到 100 MB，MacBook Air 的风扇根本没转。换成 Claude Code，开第三个就开始明显发热。

场景 2：冷启动随手用

14ms 的冷启动意味着"想问就问"。Claude Code 启动要 3 秒多，有时候因为启动成本会犹豫要不要开。jcode 没有这个问题，打开 terminal 敲 jcode 几乎立即能用。

场景 3：Swarm 分工

让两个 Agent 同时处理一个全栈任务：一个写 API，一个写前端调用。它们能感知到彼此改的文件，没有撞车。当然，复杂场景下还是需要人最后把关，但基础协调确实省了不少来回沟通。

八、适合谁 / 不适合谁

适合：

内存紧张的机器（8-16 GB） 需要同时跑多个 Agent session 的开发者 想把 Agent 嵌入脚本或 CI 环境的人 不喜欢被单一 LLM vendor 绑定的用户

不适合：

只要开箱即用、不想写配置的人 重度依赖 VS Code / JetBrains 插件的人 单 session 工作流为主、不在乎内存的人

结语

jcode 的核心取舍非常明确：

它不是要替代 Claude Code 的所有功能，而是给那些"内存不够用、启动等不起、想同时跑多个 Agent"的人一个新选择。

如果你的主要痛点是资源效率，jcode 值得一试。