jcode

为什么选择 jcode？

jcode 将 AI 编程视为智能体框架的问题，而不只是模型的问题。它将智能体运行环境与推理解耦，不把开发环境绑定到某个模型系列。因此，即使改变认证方式、提供商或模型，甚至将推理迁移到本地机器，也可以沿用相同的终端工作流。

其架构上更独特的选择，是持久化的服务端/客户端模式。jcode 守护进程负责管理会话，终端客户端连接或断开时，任务仍可继续执行。这不同于每个终端进程各自运行一个独立智能体的方式。长时间任务可以放在工作站或远程服务器上持续运行，其他任务则另开会话，无需等待当前对话结束。

如果你已经不满足于每次只向一个编程助手提一个问题，这种设计就尤其有用。jcode 明确针对多个智能体同时调查、实现、测试或审查不同工作的场景进行了优化。

项目还公布了相当详细的运行数据，包括启动时间以及新增会话时的内存消耗。这些结果有助于理解维护者的优化方向，但应将其视为项目方自行发布的基准测试，而不是独立验证的性能保证。

核心工作流程

最简单的工作流仍与常见编程智能体相似：进入代码库，启动终端界面。

jcode

不需要交互界面的任务，可以使用同一框架的无界面模式执行。

jcode run "inspect the authentication flow and identify possible race conditions"

当智能体进程与显示它的终端分离时，这种架构的优势会更明显。持久守护进程只需启动一次，之后客户端可以随时连接。

jcode serve
jcode connect

在这种模式下，编程智能体更像持续待命的工作进程。开发者可以让一个会话处理测试失败，另一个做重构，再让另一个开展研究，而不必把这三项任务依次塞进同一个对话。

代码库专属规则适合写在 AGENTS.md 中。jcode 也会读取机器级的 ~/AGENTS.md，用于跨代码库通用的个人约定。建议保持这种区分：项目规则放在项目内，个人默认偏好留在全局配置中。

在较长的对话中，/fork、/transfer 和 /rewind 提供了不同的上下文整理方式。需要探索两条不同路线时适合分叉；任务还要继续，但累积对话已经成本过高或噪声过多时，适合转移；最近几轮把智能体带偏时，则可以回退。

适用场景

传统的单智能体编程会话无法充分发挥 jcode 的设计优势。并行任务越多，这套架构就越有价值。

对于中等规模的代码库，一种实用做法是将实现与验证分开。一个会话修改代码，另一个审查改动区域或调查失败的测试。后台命令可以持续运行，当前智能体不必浪费对话轮次反复检查构建进程。

远程开发也是适合的场景。实际会话和工具都由守护进程管理，因此 jcode 可以在存放源代码的桌面电脑、家庭实验室服务器或云虚拟机上运行。简单的 SSH 加 tmux 方案通常比额外暴露网络服务更容易管理：

ssh mybox
tmux new -A -s jcode
jcode

这样，文件操作、shell 命令、Git 操作和模型调度都在远程代码副本附近执行。进阶用户还可以转发 jcode socket，将本地客户端连接到远程守护进程。

对于经常用尽订阅配额，或需要测试多个模型系列的开发者，提供商抽象层也很实用。推理渠道改变时，无需更换智能体框架。项目可以在 OAuth 订阅、API 提供商、OpenAI 兼容服务和本地运行环境之间切换，同时基本保留原有的智能体环境。

通过 TypeScript SDK 和 api-bridge，也能以编程方式构建工作流。因此 jcode 不只是交互式 TUI，还可以作为智能体运行环境嵌入脚本或内部开发工具。

同类工具对比

比较 jcode 与 Claude Code、Codex CLI、Gemini CLI、OpenCode 或 Aider 时，最有意义的问题并不是哪个模型回答得最好。模型通常可以独立于 jcode 更换，因此更值得长期比较的是模型周围的智能体框架。

如果偏好与特定 AI 提供商紧密结合的官方智能体，Claude Code、Codex CLI 和 Gemini CLI 都是自然的选择。如果更看重跨提供商保持一致的工作流，而不是沿用某家厂商的默认设置，jcode 就更有吸引力。

对已经重视开源和模型灵活性的开发者，OpenCode 和 Aider 是更接近的对比对象。选择 jcode 时，重点转向架构：持久守护进程会话、内置记忆机制、并行编排、远程连接、迁移兼容性，以及你希望对框架本身定制到什么程度。

如果经常同时保持许多智能体会话，jcode 公布的资源测量结果也值得关注。项目专门优化了每新增一个会话所需的额外内存。但对于通常只运行一个智能体的人，这项优势的重要性要低得多，不应成为所有选购或迁移决定的主导因素。

配置建议

合理的 jcode 配置通常应当比项目支持的最复杂配置更简单。先选一个可靠的提供商并写好项目说明，再根据实际遇到的问题引入记忆、MCP 服务器和并行智能体。

例如，较保守的配置可以设定默认提供商，同时让编排功能按需启用：

[provider]
default_provider = "openai"

[features]
memory = true
swarm = false

配置 MCP 集成时，如果其他贡献者也需要同样的工具，项目专属服务器更适合放在 .jcode/mcp.json，而不是全局配置中。全局 MCP 配置则留给需要跨项目使用的个人工具。

使用本地推理时，模型选择需要比使用托管前沿模型时更加谨慎。jcode 要求本地端点具备智能体工作流所需的能力，尤其是流式响应和工具/函数调用。擅长对话式编程、却不能可靠调用工具的模型，可能带来明显较差的智能体体验。

Swarm 的并发数也应有意识地逐步增加，而不是直接拉满。并行智能体可以提高吞吐量，但也会增加推理消耗，并提高两个执行者修改代码库重叠区域的概率。因此，最佳配置不仅取决于可用 CPU 或内存，也同样取决于任务独立性和模型成本。

迁移建议

jcode 提供多种兼容方式，让现有编程智能体用户在尝试新工具时尽量少受影响。

Claude Code 用户迁移 MCP 最方便。jcode 可以直接读取 Claude Code 的用户级和代码库级 MCP 配置，不必维护一份长期复制的配置。因此，对兼容的 Claude 配置所做的修改，仍可被 jcode 读取。

Codex CLI 的处理方式不同。如果 jcode 尚无自己的 MCP 配置，可以从 Codex 配置执行一次性导入。导入后，生成的 jcode 文件独立管理，后续 Codex 配置的变化不会自动同步。

已有的技能集合也往往可以复用，无需重建，因为 jcode 既能识别自己的 SKILL.md 目录，也能从 Claude Code 插件目录加载技能。

如果希望评估 jcode，又不想放弃正在进行的工作，会话迁移尤其有用。项目支持恢复 Claude Code、Codex、OpenCode 和 pi 的会话。这样更方便并行比较：开发者可以先在其他框架中开始任务，再将现有会话移入 jcode，测试其运行环境或编排行为。

因此，最稳妥的迁移策略是循序渐进：保留原有编程智能体，让 jcode 在合适时复用兼容的项目说明与集成，先迁移少量真实任务，再改变团队的默认工作流。这样可以在实际代码库中观察编辑行为、工具执行、上下文处理和模型路由的差异，而不只是依赖基准测试。