jcode：用共享守护进程把 20 个并行编码代理压进 91 MB 内存

概览：把「内存占用」当作第一性指标的编码代理外壳

jcode（1jehuang/jcode）是一个用 Rust 编写的终端编码代理「harness」（外壳），MIT 许可，支持 Linux、macOS 和 Windows。项目自我定位只有两句话：最省内存，也最聪明。它和 Claude Code、Codex CLI、OpenCode、GitHub Copilot CLI、Cursor Agent、pi、Antigravity CLI 属于同一赛道，但取舍很不一样：别人把力气花在模型提示词和工具链上，jcode 先把运行时本身做到极致轻量，再在其上叠加记忆图谱、多代理协作（swarm）和高速终端渲染。

安装只需一行：macOS 与 Linux 用 `curl -fsSL https://jcode.sh/install | bash`，Windows 11 用 PowerShell 的 `irm https://jcode.sh/install.ps1 | iex`。在 TUI 中运行 `/update`，或在终端运行 `jcode update`，即可后台下载最新稳定版并保留会话重载。README 还写明了防降级策略：版本更旧或相同则跳过；开发版会把本地二进制的 Git 提交与发布标签比较；无法验证祖先关系时宁可停止更新，也不冒降级风险。默认通道是 `features.update_channel = "stable"`，显式设为 `"main"` 才跟随源码分支。

核心架构：一个共享守护进程，多个轻客户端

jcode 最关键的设计在于「会话共享同一个守护进程（daemon）」。README 对无头（headless）会话的测量说得很直白：jcode 的多个会话共享一个 daemon，而 Claude Code 为每个会话启动一个 `claude -p --input-format stream-json` 进程。进程模型的差别，直接决定了内存曲线的斜率。

作者给出的无头会话基准（每个会话完成 5 轮真实模型调用，包括列目录、读文件、仓库搜索、总结、回复，然后统计所有相关进程的 PSS 总和；两者都使用 claude-sonnet-4-6）数据如下：1 个会话时 jcode 为 32.6 MB，Claude Code 为 261.0 MB，约 8.0 倍；5 个会话时 51.0 MB 对 908.6 MB，17.8 倍；10 个会话时 66.7 MB 对 1749.7 MB，26.2 倍；20 个会话时 90.6 MB 对 3376.8 MB，37.3 倍。每新增一个会话，jcode 约增加 3.1 MB，Claude Code 约增加 164 MB，相差约 54 倍。测试日期为 2026-09-29，版本为 jcode v0.89.19-dev（默认构建，未编译本地嵌入）与 Claude Code 2.1.267，可用 `python3 scripts/bench_headless_memory.py` 复现。

这组数字的意义在于斜率，而不是绝对值。当你把代理当作「可批量启动的工人」使用，比如同时跑 20 个并行任务，Claude Code 路线需要约 3.4 GB，jcode 路线约 91 MB。内存不再是并行度的瓶颈，瓶颈转移到模型配额和调用成本上。

交互式性能：首帧 14 毫秒

除内存外，README 还测了启动延迟，方法是 10 次交互式 PTY 启动。首帧时间：jcode 14.0 ms（范围 10.1 到 19.3 ms），Antigravity CLI 383.5 ms，pi 590.7 ms，Codex CLI 882.8 ms，OpenCode 1035.9 ms，GitHub Copilot CLI 1518.6 ms，Cursor Agent 1949.7 ms，Claude Code 3436.9 ms（范围 2032.7 到 8927.2 ms），后者约为 jcode 的 245.5 倍。首次可输入时间：jcode 48.7 ms，Claude Code 3512.8 ms，约 72.2 倍。

交互式内存对比里数字更复杂，也更诚实。单会话时，关闭本地嵌入的 jcode 为 27.8 MB，开启本地嵌入的 jcode 为 167.1 MB，pi 为 144.4 MB，Codex CLI 为 140.0 MB，Claude Code 为 386.6 MB。也就是说，开启本地语义嵌入后，jcode 的单会话占用并不比 pi 和 Codex 低。优势出现在扩展时：10 个会话时，jcode 为 260.8 MB（关闭嵌入为 117.0 MB），Codex CLI 为 334.8 MB，pi 为 833.0 MB，Claude Code 为 2300.6 MB，OpenCode 为 3237.2 MB。每增加一个会话的额外 PSS：jcode 约 10.4 MB，Codex CLI 约 21.6 MB，pi 约 76.5 MB，Claude Code 约 212.7 MB，OpenCode 约 318.4 MB。

记忆系统：向量嵌入加记忆图谱

jcode 的「聪明」主要来自 agent memory。按 README 的描述，每一轮对话与回复都会被嵌入为语义向量；每轮都会在记忆图谱里做余弦相似度查询，找出相关记忆条目，注入对话，或者交给一个「记忆侧代理」（memory sideagent）先核验相关性再注入。

写入侧同样是异步的：当出现语义漂移、距上次提取已过 K 轮、会话结束等条件时，侧代理会提取记忆并写入图谱。此外还有显式的记忆工具，让主代理可以主动检索或存储，不必完全依赖被动后台流程；并提供会话搜索，对历史会话做传统 RAG。最后，环境（ambient）模式会定期整理记忆：重组、检查过期与冲突。这套设计把「被动召回、主动读写、后台整理」三条通路分开，思路接近人类的联想记忆加复盘。

多代理 Swarm：服务器感知的协作

在同一仓库里启动两个以上代理，服务器会自动管理，实现原生协作。关键机制是冲突感知：当代理 A 编辑了代理 B 读过的文件（代码在 B 脚下发生了变化），服务器会通知 B。B 可以判断无关而忽略，也可以重新读取。代理还能自主调用 swarm 工具生成队友，此时主代理变成协调者，被生成的代理成为工人。

配置层面，swarm 模式把根代理的推理强度和工人强度分开：`~/.jcode/config.toml` 中 `[agents]` 下的 `swarm_root_effort`（对应 `/effort swarm`）和 `swarm_deep_root_effort`（对应 `/effort swarm-deep`），默认均为 `max`，可选 `none`、`minimal`、`low`、`medium`、`high`、`xhigh`、`max`，并映射到各提供商支持的范围；环境变量为 `JCODE_SWARM_ROOT_EFFORT` 与 `JCODE_SWARM_DEEP_ROOT_EFFORT`。这些设置不改变工人的 `swarm_effort`。「根代理少想、工人多做」或「根代理深想」可按任务成本切换。

提供商与生态：订阅登录加 OpenAI 兼容

jcode 支持订阅型 OAuth 登录，让你沿用已付费的模型额度，必要时回退到直连 API。内置登录包括 Claude、OpenAI/ChatGPT/Codex、Google Gemini、GitHub Copilot、Azure OpenAI、Alibaba Cloud Coding Plan、Fireworks、Novita AI、MiniMax、Meta Model API、LM Studio、Ollama，以及自定义 OpenAI 兼容端点。内置的 OpenAI 兼容档案还包括 openrouter、deepseek、zai、kimi、moonshotai、opencode 等。原生 OpenAI 提供商使用 Responses WebSocket v2，带机会性的后台预热，并可回退到 HTTPS。

面向脚本和代理的 `jcode provider add` 命令可以一步写入档案，支持 `--api-key-stdin`（密钥不进 shell 历史）、`--api-key-env`、`--context-window`、`--no-api-key`（本地 vLLM、Ollama 等无需认证的服务）。`extra_body` 与环境变量 `JCODE_OPENAI_EXTRA_BODY` 允许向请求体注入非标准字段，例如 NVIDIA NIM 上 DeepSeek-V4 需要的 `chat_template_kwargs` 才会启用思考。还有 Anthropic Messages 兼容网关档案（`type = "anthropic-compatible"`），支持 Bearer、自定义头或无认证。流式空闲超时默认 180 秒，高推理强度会自动放大（high 为 2 倍，xhigh 为 3 倍，max 为 4 倍）。

MCP 方面，jcode 读取 `~/.jcode/mcp.json` 与项目内 `.jcode/mcp.json`，并兼容 Claude Code 的 `~/.claude.json`、仓库根的 `.mcp.json`，且是每次实时读取，不复制快照。目前只支持 stdio 服务器，HTTP/SSE 类型会被识别并跳过；每个请求默认 30 秒超时，可用 `timeout_secs` 调整。从 Codex CLI 迁移时会一次性导入 `~/.codex/config.toml`，导入的环境变量可能含密钥，需要留意。

界面工程：为速度而生的自研组件

作者自己写了一个不依赖浏览器和 TypeScript 的 mermaid 渲染库（mermaid-rs-renderer），声称图表渲染快 1800 倍，使侧边栏与聊天区可以内联渲染流程图。`panel` 工具可用 Markdown 或 PDF 打开桌面面板。

「信息小部件」只占用屏幕的空白区域，空间不足时自动让位。jcode 声称渲染可超过每秒一千帧，以避免闪烁。自定义滚动回看带来更多能力，但终端层面无法做到平滑的半行滚动，所以作者又做了自己的终端 Handterm。

影响、局限与观察

对开发者而言，jcode 的价值在于把「并行代理」的边际成本压到接近零：笔记本上同时跑几十个会话不再是内存问题。对企业而言，OAuth 订阅复用、Anthropic 与 OpenAI 兼容网关、自定义请求头和自托管 vLLM 的支持，使它可以接入内部网关。

需要保持审慎的几点。第一，所有基准都由项目作者在自己的 Linux 机器上完成，尚无独立复现；各表使用的版本也不完全相同（无头测试用 v0.89.19-dev 与 Claude Code 2.1.267，交互式表格则列出 jcode v0.9.1888-dev 与 Claude Code 2.1.86），横向比较时应看清口径。第二，PSS 反映的是内存而非任务质量，「最聪明」是自我宣称，README 的数据并没有证明代理的解题能力优于对手。第三，开启本地嵌入的单会话内存并不占优，优势依赖共享守护进程和关闭嵌入的配置。第四，MCP 暂不支持 HTTP/SSE，Windows 与 macOS 的表现 README 未给出数据。第五，共享守护进程意味着故障域更集中，一个 daemon 的崩溃会影响所有会话，这类取舍文档中没有展开。

总体看，jcode 提供了一个值得关注的方向：先把代理外壳做成真正的轻量基础设施，再讨论记忆与协作。如果你在做大规模并行代码代理、CI 里的批量评审，或者在低配开发机上工作，它值得亲自跑一遍 `scripts/bench_headless_memory.py` 来核实数据。