Coding Agent harness 这个赛道，2026 年已经挤满了选手。Claude Code 是 TypeScript 写的，Codex CLI 是 TypeScript 写的，OpenCode 也是 TypeScript 写的，Pi 还是 TypeScript 写的。大家都在用同一个运行时，面对同一类问题：启动慢、内存吃得多、多开会卡。
jcode 换了条路——整个 harness 用 Rust 从头写。不是 wrapper，不是 binding，是实打实的 Rust 原生实现。结果是什么？启动时间 14ms（Claude Code 要 3.4 秒），单 session 内存 28MB（Claude Code 要 387MB），10 个 session 并行只多吃 100MB（Claude Code 吃 2.1GB）。
9.4K Star，MIT 协议，一个人写的。
性能差距到底有多大
先看数据。jcode 作者做了一组 benchmark，在同一台 Linux 机器上测了 10 次 PTY 启动取中位数：
| 指标 | jcode | Pi | Codex CLI | OpenCode | Claude Code |
|---|---|---|---|---|---|
| 启动到首帧 | 14ms | 591ms | 883ms | 1036ms | 3437ms |
| 启动到首输入 | 49ms | 596ms | 906ms | 1048ms | 3513ms |
| 1 session 内存 (PSS) | 28MB | 144MB | 140MB | 372MB | 387MB |
| 10 session 内存 (PSS) | 261MB | 833MB | 335MB | 3237MB | 2301MB |
| 每增 1 session 边际 | ~10MB | ~77MB | ~22MB | ~318MB | ~213MB |
启动速度差两个数量级，内存差一个数量级。这不是微优化，是架构层面的不同。
为什么会这样？TypeScript 写的 harness 每次启动都要经过 Node/Bun 的模块加载、JIT 编译、运行时初始化。jcode 是 Rust 编译成原生二进制，启动就是加载 ELF/PE，没有解释器开销。内存方面，Rust 没有 GC，没有 V8 heap，数据结构布局紧凑，多 session 之间还能共享只读数据。
对于"同时跑 10 个 Agent"这种场景，这个差距是决定性的。Claude Code 开 10 个要吃 2.3GB，jcode 只要 261MB。省出来的内存够你再开 80 个 session。
语义记忆：不用工具调用就能记住事情
大多数 Agent 的记忆系统是"工具驱动"的——Agent 需要主动调用 retain/recall 工具来存取记忆。问题是 Agent 经常忘记调用，或者在不该调用的时候调用，浪费 token。
jcode 的做法不一样：每一轮对话自动做语义向量化，然后用 cosine similarity 在记忆图谱里检索相关条目，命中的话直接注入到对话上下文里。Agent 不需要做任何事，记忆是"被动回忆"的。
记忆的提取也是自动的：语义漂移时、每隔 K 轮时、session 结束时，都会触发一个 memory side agent 来提取和存储记忆。记忆还会定期自动合并——检查过期、解决冲突、重新组织。
这个设计参考了人类记忆的工作方式：你不需要"调用工具"来回忆一件事，相关的事情会自动浮现在脑海里。jcode 把这个机制做到了 harness 层。
当然，Agent 也可以主动搜索或存储记忆（通过 memory tools），但默认的被动模式已经足够覆盖大多数场景。
Swarm：同一仓库里的多 Agent 协作
Swarm 是 jcode 最有意思的功能之一。当你在同一个仓库里 spawn 两个以上的 Agent，它们会被 server 自动管理，实现原生协作：
- 文件冲突检测——Agent A 编辑了 Agent B 已经读过的文件，server 会通知 Agent B。B 可以检查 diff 确认是否冲突
- Agent 间通信——每个 Agent 可以 DM 单个 Agent、广播给所有 Agent、或者只跟同仓库的 Agent 通信
- 自主 spawn——Agent 可以用 swarm 工具自主创建团队成员来并行完成任务。主 Agent 变成 coordinator，spawn 出来的变成 worker
跟 Claude Squad / Agent Orchestrator 用 git worktree 做物理隔离不同，jcode 的 swarm 是在同一套代码上做逻辑隔离。好处是不需要频繁 merge worktree，坏处是需要更精细的冲突检测。jcode 选择了后者，用 server 端的实时通知来解决。
其他亮点
自改源码（Self-Dev Mode）——告诉 Agent 进入 self-dev 模式，它会开始修改 jcode 自己的源码。有完整的基础设施支持：编辑、构建、测试、热重载二进制，全自动。作者建议用 GPT 5.5 或最新前沿模型来做这件事，因为 jcode 的代码库不简单。
Agent Grep——不是普通的 ripgrep 包装。jcode 的 grep 工具会在返回结果里附带文件结构信息（函数列表、位移量等），让 Agent 不用读文件就能推断上下文。还会根据 Agent 已经看过的内容自适应截断返回值，省 token。
Session 恢复——可以从 Claude Code、Codex、OpenCode、Pi 的 session 断点续传。Claude Code 崩了？用 jcode 恢复 session 继续干。
自建终端——为了实现丝滑滚动，作者写了一个原生终端 Handterm，实现了 native scroll API。还写了一个 Rust mermaid 渲染器，比浏览器方案快 1800 倍。
40+ 模型提供商——Claude、OpenAI、Gemini、Copilot、DeepSeek、OpenRouter、Ollama、LM Studio 等等，支持 OAuth 登录、多账号切换、自定义 OpenAI-compatible endpoint。
MCP 兼容——读 Claude Code 和 Codex 的 MCP 配置文件，支持 stdio 类型的 MCP server。
跟同类工具比
| jcode | Pi / omp | Claude Code | OpenCode | |
|---|---|---|---|---|
| 语言 | Rust | TypeScript + Rust | TypeScript | TypeScript |
| 单 session 内存 | 28MB | 144MB | 387MB | 372MB |
| 启动时间 | 14ms | 591ms | 3.4s | 1.0s |
| 记忆系统 | 语义向量自动注入 | Hindsight 手动 | CLAUDE.md | MEMORY.md |
| 多 Agent | Swarm 自动协作 | task 子 Agent | 无 | 无 |
| 自改源码 | ✅ | ❌ | ❌ | ❌ |
| LSP/DAP | ❌ | ✅ (14 LSP ops + 28 DAP ops) | ❌ | ✅ |
| 平台 | 全平台 | macOS/Linux/Win | macOS/Linux/Win | 全平台 |
| 协议 | MIT | MIT | 闭源 | MIT |
jcode 的优势在于性能和内存——这是 Rust 带来的结构性优势。Pi/omp 的优势在于工具丰富度——LSP、DAP、浏览器、子 Agent 一应俱全。Claude Code 的优势在于生态——Anthropic 直接优化的体验。OpenCode 的优势在于插件系统和社区。
选哪个取决于你的场景：如果你需要同时跑很多 Agent 且内存敏感，jcode 是目前最好的选择。如果你需要 IDE 级别的代码智能（重构、调试），Pi/omp 更成熟。如果你已经在 Claude 生态里，Claude Code 没有替代品。
上手
# macOS & Linux
curl -fsSL https://jcode.sh/install | bash
# macOS Homebrew
brew tap 1jehuang/jcode
brew install jcode
# Windows PowerShell
irm https://jcode.sh/install.ps1 | iex
# 启动 TUI
jcode
# 单次运行
jcode run "say hello"
# 恢复 session
jcode --resume fox
# 后台 server 模式
jcode serve
jcode connect登录模型提供商：
jcode login --provider claude
jcode login --provider openai
jcode login --provider copilot
jcode login --provider gemini踩坑提醒
记忆系统需要本地 embedding——默认开启本地 embedding 模型，单 session 内存从 28MB 涨到 167MB。如果内存敏感可以关掉（jcode --no-local-embedding），但记忆检索质量会下降。
LSP/DAP 缺失——jcode 目前没有内置 LSP 和 DAP 支持。这意味着它不能做符号级重命名、不能驱动调试器。对于需要这类能力的场景，Pi/omp 更合适。
Swarm 的冲突检测是逻辑层面的——不像 git worktree 那样物理隔离，两个 Agent 编辑同一个文件的不同位置时，依赖 server 的通知机制。如果通知延迟或者 Agent 忽略了通知，理论上还是可能出问题。
自改源码有风险——作者明确说弱模型做 self-dev 可能引入 subtle bug。建议只用最强的前沿模型，并且在自改之前备份。
项目还年轻——v0.9.x 版本，API 和配置格式可能还会变。文档有但不如 Claude Code/OpenCode 完善。社区主要在 Discord。
为什么 Rust harness 重要
jcode 的存在证明了一件事：Coding Agent 的 harness 层不需要用 TypeScript 写。当你的 Agent 需要同时管理 10+ 个 session、每个 session 处理几万行代码、还要跑语义检索和记忆注入的时候，性能不是锦上添花，是核心需求。
TypeScript 的 harness 生态已经很成熟了——Claude Code、OpenCode、Codex CLI、Pi 都是。但它们面临同一个问题：多开时内存爆炸。这不是代码写得不好的问题，是运行时的结构性限制。V8 的 heap、GC 的暂停、Node 的模块加载开销，在单 session 时可以忽略，在 10+ session 时就是致命的。
jcode 用 Rust 绕过了这些问题。14ms 启动意味着你可以把 Agent 当命令行工具用——jcode run "fix the bug" 比等 3 秒 Claude Code 启动再输入要自然得多。28MB 内存意味着你可以在一台 8GB 的笔记本上同时跑 20 个 Agent 而不卡。
项目状态：活跃开发中，MIT 协议，9.4K Star，一个人维护。作者同时还在做 iOS 版本和自建终端 Handterm。有 Discord 社区。