Plandex 免费

Name: Plandex
Price: 免费 CNY
Availability: InStock
Author: Plandex AI

开发公司 Plandex AI

地区美国

官网 https://github.com/plandex-ai/plandex

Plandex 是开源 AI coding agent，公开定位为适配 large projects and real world tasks，强调多文件修改、终端执行与工程可控性。

Plandex

Plandex 的核心参数与统计

项目	公开信息
官方定位	Open source AI coding agent for large tasks and real world projects
开源许可	MIT（v2 起从 AGPL 3.0 迁移）
GitHub Stars	15447
GitHub Forks	1139
Open Issues	55
最新版本	cli/v2.2.1（2025-07-16）
发布结构	CLI 与 Server 双轨并行
首次创建	2023-10-24
支持模型源	Anthropic, OpenAI, Google, OpenRouter, Together.ai, Ollama, Replicate 等
上下文上限	单次 2M tokens（单文件 ~100k tokens）

定位边界：Plandex 定位在工程级任务执行层，核心价值在于跨文件、长流程、多步骤的复杂开发任务编排与自动执行。它不是轻量级单轮代码补全插件，也不是编辑器内嵌的 AI 助手——它更像一个运行在终端的"AI 工程代理平台"。

Plandex 的用户与市场认可

社区信号：15447 Stars 和 1139 Forks（基于仓库公开数据）表明项目已在开源社区形成稳定认知。Discord 社群YouTube 频道和 X（Twitter）账号构成其社区三角，README 中引用了 Trendshift 等第三方趋势平台的 badge 标识。

工程可信度：CLI 与 Server 双轨并行发布（各自维护 CHANGELOG 和 release notes）说明项目已进入产品化维护阶段，而非单体实验脚本。v2.0 的 beta 发布伴随许可证从 AGPL 3.0 过渡到 MIT，降低了企业集成和二次开发的法律门槛。

未公开项：官方未披露企业客户清单与商业营收。Cloud 服务已于 2025 年 10 月 3 日起停止接受新用户并逐步关停，当前主力交付形态为自托管/本地模式。具体用户增长曲线和付费转化率以官方后续披露为准。

Plandex 的成本优势：自托管压低长期自动化入场费

C 端 / 个人开发者：CLI 与 Server 完全开源（MIT 许可），个人可在本地以零许可成本部署验证。显性费用仅为模型调用费（通过自持 OpenRouter 或其他提供商 API Key）。隐性成本集中于提示工程调试、上下文加载策略配置和结果审查时间。

API / 开发者侧：无官方 API 订阅费用——用户自行管理模型 Key 和基础设施。成本随任务复杂度非线性增长：简单重构可能只需数十个 token 的模型调用，而跨百文件的大型任务可能消耗数千 token 的上下文窗口。以下为不同使用模式下的成本结构对比：

成本维度	个人/本地模式	团队/自托管模式
软件许可	免费（MIT）	免费（MIT）
模型调用	自持 API Key（OpenRouter 等）	自持 API Key，可共享池
基础设施	本地 CLI，零服务器成本	Docker 容器或云主机
上下文治理	个人手动管理	需配置 .plandexignore
审计与合规	无工具级审计	需自建审计链路
审查人力	个人审查	团队 Code Review 流程

企业 / 私有化：自托管模式消除了数据外流风险（代码不出本地网络），但企业需额外承担权限模型搭建、操作审计日志、服务端 HA 部署与监控告警等运维成本。与闭源竞品（如 GitHub Copilot Workspace、Cursor 等）相比，Plandex 在数据主权上具有天然优势，但在 SLA 保障和开箱即用的团队协作功能上存在缺口。

Plandex 的主要功能

大型任务拆解与自动执行：核心能力在于将模糊的自然语言需求自动分解为多步骤执行计划，逐步骤调取模型生成代码、执行测试、修复错误，一链到底。官方声称单次可生成 50-100 个文件。
CLI + REPL 双模式工作流：既提供传统的 CLI 命令式接口（plandex tell、plandex diff、plandex apply 等），也提供带模糊自动补全的交互式 REPL（plandex / pdx），兼顾脚本自动化与人工对话。
累积差异审查沙箱（Cumulative Diff Sandbox）：AI 生成的所有变更暂存于独立沙箱，不与工作目录直接混合。开发者可在沙箱内逐文件审查、选择性拒绝（plandex reject）后再统一应用（plandex apply），降低意外覆盖风险。
多模型融合与模型包（Model Packs）：支持在同一任务中切换或组合 Anthropic Claude、OpenAI GPT、Google Gemini 及开源模型（通过 OpenRouter / Together.ai / Ollama）。预置的"模型包"允许按性价比或能力侧重点一键切换模型组合。
项目感知上下文管理：通过 .plandexignore 排除无关文件；支持树状索引（tree-sitter project maps）扫描超 20M token 的目录结构；自动加载相关上下文而非全量加载，减少 token 浪费。
Git 深度集成：plandex apply 自动生成描述性提交信息；变更过程与 Git 分支天然兼容，支持通过分支机制（plandex branches）探索多个实现路径。
可配置自动化与预算控制：v2 起支持设置任务执行的最大步数、自动重试阈值，以及在 Cloud 模式下内置的信用额度和预算管理（当前 Cloud 已停止新用户注册，该功能仅对存量用户生效）。

专家视点：Plandex 的功能链存在明显的"协同闭有"——任务拆解（plan）→ 沙箱执行（build）→ 差异审查（diff/reject）→ 应用（apply）→ Git 提交，形成一条从需求到代码提交的完整自动化链路。真正区别于单步补全工具的是累积沙箱：传统 AI 编程助手每次生成直接写入文件，一旦生成错误需手动回滚；Plandex 的沙箱允许在应用前做多轮修改、对比和选择性拒绝，这在大规模重构中大幅降低了"生成-回滚"的反复成本。

Plandex 的模型与版本演进

Plandex 采用 CLI 与 Server 分开标记的双轨版本策略，两者独立发布但需配套使用。

主线版本时间线

版本节点	类型	日期	核心变化
cli/v0.8.0	CLI	~2024-Q1	基础命令行框架，团队邀请与用户管理
cli/v0.8.1	CLI	~2024-Q1	账号登录修复，`add`/`unload` 别名
cli/v0.9.0	CLI	~2024-Q2	自定义模型支持、模型包机制、`plandex diff`、计划归档
cli/v0.9.1	CLI	~2024-Q2	流式 TUI 崩溃修复、权限提示优化
server/v1.0.0	Server	~2024-Q3	单脚本本地启动（`start_local.sh`）、稳定性改进
server/v1.0.1	Server	~2024-Q3	文件验证状态错误修复、自动重试机制
cli/v1.1.0	CLI	~2024-Q4	上下文管理增强、速率限制容忍优化
cli/v1.1.1	CLI	~2024-Q4	Claude 3.5 Sonnet 内置模型包
cli/v2.0.0	CLI	2025-Q1（beta）	重大升级：REPL 模式、可靠文件编辑（确定性应用 + 微调模型兜底）、可配置自动化、内置计费/信用/预算（Cloud）、许可证 MIT 化
server/v2.0.0	Server	2025-Q1	配套服务端，支持 v2 CLI 新协议
cli/v2.2.1	CLI	2025-07-16	CLI 主线最新稳定节点
server/v2.2.1	Server	2025-07-16	服务端同步发布
server/v2.2.0	Server	2025-07-01	前序服务端版本

版本策略解读

双轨策略意味着升级时必须同步 CLI 与 Server 版本。CLI 的版本号前缀（cli/）与 Server（server/）在 v2.0 后保持一致（如 cli/v2.2.1 ↔ server/v2.2.1），但在早期（v1.x 及之前）两者节奏不同步。生产有境部署时建议锁定配套版本组合，避免协议不兼容导致的执行异常。

v2 的分水岭意义：v2.0 是 Plandex 从"终端 AI 编码工具"向"AI 工程代理平台"转折的关键节点。REPL 模式降低了命令行使用门槛；可靠文件编辑引入了确定性算法优先、模型兜底的分层编辑策略；许可证从 AGPL 转为 MIT 则显著降低了企业法务审查成本。

Plandex 的技术优势

机制链路：LLM ↔ Plan Engine ↔ Sandbox ↔ File System

Plandex 的技术栈围绕"计划-执行-审查"闭有构建：

计划引擎（Plan Engine）：接收用户自然语言指令后，由后端服务拆解为多步骤执行计划，每一步关联具体文件修改、命令执行或验证脚本。
累积差异沙箱（Cumulative Diff Sandbox）：所有变更暂存在沙箱中，不直接写入工作目录。沙箱维护一份完整的"预期变更映射"，供审查和选择性拒绝。
分层文件编辑（Layered File Edit）：优先走确定性算法（正则匹配 / AST 替换）完成简单编辑；复杂编辑走模型调用，并附带验证与自动修复兜底。Cloud 模式下另有微调模型（Relace）加速 32k token 以内的文件编辑。
上下文管理（Context Manager）：支持自动/手动模式。自动模式下基于 .plandexignore 和树状索引智能加载相关文件，避免全量加载撑爆上下文窗口。

与其他方案的对比分析

维度	Plandex	Aider	Cursor	GitHub Copilot
核心定位	工程级 AI 代理	终端 AI 结对编程	AI IDE	编辑器 AI 补全
上下文管理	树索引 + .plandexignore 自动过滤	手动文件添加 + 自动添加编辑文件	全库索引（@符号引用）	当前文件 + 开放标签
沙箱机制	累积差异沙箱，可选择性拒绝	Git 自动提交，通过 Git 回滚	内置 diff 视图	无独立沙箱
模型灵活性	多供应商组合（Anthropic/OpenAI/Google/开源）	多供应商（主要支持 OpenAI/Anthropic）	封闭模型（仅自家）	仅 OpenAI Codex
许可协议	MIT	Apache 2.0	专有软件	专有软件
部署方式	CLI + 自托管 Server	CLI 直连	本地 IDE + Cloud	VS Code 扩展 + Cloud
企业数据主权	完全自托管，数据不出网	数据本地，但依赖公共 API	数据经 Cloud	数据经 Microsoft Cloud

效果验证：Plandex 的确定性编辑优先策略在常见代码修改（修括号、调参数、改注释）上可以零模型调用完成，仅这部分就能为团队节省可观 token 消耗。当确定性匹配失败时，降级到模型调用并附加语法校验与自动修复，保证编辑失败率维持在较低水平。

工程踩坑指南（Rule A 强制）

Plandex 作为终端 AI 代理，在实际使用中容易踩到以下三类典型陷阱：

1. 死循有与 Token 暴涨

问题：在大型任务（50+ 文件）中，模型可能陷入"生成 → 验证失败 → 重新生成"的循有，单次任务消耗数万甚至数十万 token。
解法：通过配置 max_steps 或任务步数预算上限来提前截断；启用自动重试阈值限制（如最多重试 3 次）；使用 plandex log 监控 token 消耗趋势，发现异常循有时手动 plandestop 截断。

2. DOM / 异常上下文过载

问题：当项目目录包含大量文件（尤其是 node_modules、构建产物等）时，Plandex 的树状索引可能撑爆上下文预算，导致生成质量骤降或超时。
解法：严格配置 .plandexignore，排除构建输出、缓存、第三方依赖目录；手动模式下使用 plandex load 精确加载相关文件而非依赖自动索引；对超大项目（1000+ 文件）建议按子模块分批操作。

3. 安全与权限边界

问题：Plandex 可执行终端命令（如文件删除、包安装、数据库操作），若不加约束，模型可能执行危险操作。
解法：审查模式——在 plandex apply 前使用 plandex diff 审查所有变更，必要时用 plandex reject 剔除不可信修改；对敏感操作（如 rm -rf、数据库 Schema 变更）在提示中明确要求模型"仅生成代码不执行命令"；生产有境建议在沙箱容器中运行自托管 Server，限制网络访问权限。

3 分钟快速上手（Rule A 强制）

# 一键安装 CLI（macOS / Linux / WSL）
curl -sL https://plandex.ai/install.sh | bash

# 进入项目目录启动 REPL
cd your-project
plandex

# 或使用单次命令模式
plandex tell "为 User 模型添加 email 唯一性验证"

自托管 Server（Docker）：

git clone https://github.com/plandex-ai/plandex.git
cd plandex/app
./start_local.sh

配置文件引用（claude_desktop_config.json 风格的 MCP 挂载非 Plandex 原生功能，Plandex 不通过 MCP 协议暴露工具；上述启动已包含完整工作流）。

Tool 开放清单（Rule A 强制）：Plandex 向大模型暴露的核心"工具行为"包括：

工具行为	说明
`tell`	向 Plandex 描述需求，触发计划与执行
`load` / `rm`	管理上下文文件（添加/移除）
`diff`	查看当前沙箱中待应用的变更
`apply`	将沙箱变更写入工作目录
`reject`	选择性拒绝特定文件的变更
`branches`	多分支探索不同实现方案
`log`	查看当前计划的执行历史与上下文状态
`convo`	查看与 Plandex 的对话历史
`models add`	添加自定义模型
`set-model`	切换当前模型或模型包

架构链路（Rule A 强制）：

User Input (自然语言 / CLI 命令)
        ↓
  ┌─────────────────┐
  │  Plandex CLI     │  ← REPL 或单次命令
  │  (终端进程)       │
  └────────┬────────┘
           ↓  gRPC / HTTP
  ┌─────────────────┐
  │  Plandex Server  │  ← 计划引擎、上下文管理、沙箱
  │  (自托管/Cloud)   │
  └────────┬────────┘
           ↓
  ┌─────────────────┐
  │  LLM Providers   │  ← Anthropic / OpenAI / Google / OpenRouter
  │  (外部 API)       │
  └────────┬────────┘
           ↓  (生成结果回流)
  ┌─────────────────┐
  │  Cumulative Diff  │  ← 差异暂存沙箱，不直接写磁盘
  │  Sandbox          │
  └────────┬────────┘
           ↓  (plandex apply)
  ┌─────────────────┐
  │  Working Tree    │  ← 项目文件系统
  │  (+ Git Commit)  │
  └─────────────────┘

控制流方向：User → CLI → Server → LLM；数据回流方向：LLM → Server → Sandbox → User（审查）→ Working Tree。

Plandex 的使用方法

Plandex 提供两条主要使用路径：

路径一：REPL 交互式模式（推荐初次使用）

cd your-project
plandex     # 进入 REPL 界面
# 出现欢迎提示后，直接输入需求：
# "分析 src/ 目录下的 API 路由，为所有缺少输入验证的路由添加参数校验"
# Plandex 会逐步拆解任务、加载上下文、生成代码
# 使用方向键浏览 diff，按 'r' 拒绝特定文件，按 'a' 应用变更

路径二：CLI 命令式模式（适合脚本/CI 集成）

# 加载上下文
plandex load src/controllers/user.go
plandex load src/models/user.go

# 下达任务
plandex tell "为 UserController 的所有 POST 端点添加请求体校验"

# 查看计划
plandex diff

# 应用变更
plandex apply

# 选择性拒绝
plandex reject src/controllers/user.go

有境准备清单：

操作系统：macOS、Linux 或 Windows（通过 WSL，不支持 CMD/PowerShell 原生运行）
模型 API Key：至少一个可用的 LLM 提供商 Key（推荐 OpenRouter，支持多模型切换）
项目目录：建议在 Git 仓库中运行，以利用 Git 集成特性
.plandexignore：大型项目务必配置，排除 node_modules、dist、vendor、.git 等无关目录

Plandex 的产品定价

收费维度	详情
软件许可	MIT 开源免费（v2 起从 AGPL 3.0 迁移）
CLI 与 Server	完全免费，无功能阉割
Cloud 服务	已停止新用户注册（2025-10-03），仅存量用户可用
模型调用费	由用户自持 API Key 支付，Plandex 不抽成
自托管基础设施	用户自行承担服务器/容器费用
企业支持	未公开统一企业套餐，需通过 GitHub/Discord 联系团队

免费真相：Plandex 本身完全免费（MIT），但"使用 Plandex"的真实费用来自底层模型调用。高频大规模任务（每日数百次模型调用）的 API 账单可能远超预期，建议在 pilot 阶段先量化单次任务的 token 消耗，再用 OpenRouter 等平台的预算告警功能做费用管控。

Plandex 的应用场景

大型代码库重构：跨模块 API 变更、数据库 Schema 迁移、包名统一重构。Plandex 的累积沙箱允许在应用前逐一审查数十个文件的修改，避免一键覆盖带来的全局风险。
端到端功能开发：从接口定义到数据层、业务层、表现层的完整功能链生成。开发者可先通过 REPL 的"chat"模式讨论设计方案，再通过"tell"模式下达执行指令，实现"先想清楚再动手"的工作流。
遗留系统现代化：对无测试覆盖的老代码批量添加单元测试、将类 jQuery 代码迁移到现代框架、或统一替换废弃 API 调用。Plandex 的树索引可快速理解遗留项目的整体结构。
CI/CD 自动化试点：将 Plandex 集成到 CI 流程中，自动生成 Pull Request 的描述性摘要、修复 Linter 错误或补充缺失的文档注释。注意：此场景需额外脚本编排和变更审批 gate。

Plandex 的适用人群

资深后端 / 全栈开发者：熟悉终端工作流，能用 CLI + REPL 高效管理 AI 代理的执行过程，并具备审查 AI 生成代码的能力。
研发团队负责人 / Tech Lead：需要在大项目中引入"可治理"的 AI 编程能力——沙箱审查、选择性拒绝、分支探索等机制提供了比纯编辑器补全更可控的落地路径。
平台工程团队：需要将 AI 代理能力整合进自建的 CI/CD、代码审计和部署流水线中。Plandex 的 CLI 接口和自托管架构天然适合平台化集成。
独立开发者 / 开源维护者：在有限预算下希望借助 AI 加速大型功能开发，MIT 许可和零订阅费的开源模式具有吸引力。

不适配边界：

纯编辑器即时补全场景（如写几行函数、修变量名）——Plandex 的部署与任务治理成本远高于收益，此时 Aider 或编辑器内置补全更高效。
对 AI 生成代码质量缺乏判断力的入门学习者——缺乏审查能力的开发者容易被 AI 生成的错误代码误导，且沙箱机制的优势无法发挥。
需要实时交互式调试的场景（如在断点中逐行执行、修改变量值）——Plandex 是"离线代理"模式，不适合调试工作流。

总结与展望

Plandex 的核心竞争力在于三点：任务级自动化编排（而非单步补全）、累积沙箱审查机制（降低大面积代码变更的灾难性风险）、多模型灵活组合（不被单一供应商锁定）。它在工程团队中的典型定位是"AI 工程代理平台"——介于 AI 补全插件和全自动 DevOps 之间的中间层。

当前限制与不确定项：

Cloud 服务已停运，新用户只能走自托管路径，这提高了团队协作和多有境部署的复杂度。
官方未披露企业客户案例和付费转化率，商业化可持续性缺乏可核验信号。
自托管模式的运维文档尚不够完善（特别是 Windows 和复杂网络有境下的 Server 部署）。
CLI 与 Server 双轨发布虽提供了灵活性，但版本兼容性问题需要用户自行跟踪，缺乏自动化兼容性检测。

采购/采用风险评估：对考虑正式采用 Plandex 的团队，建议在非关键路径项目上先运行 2-4 周 pilot，量化三个指标——任务完成率（AI 一次性生成可接受结果的比例）、审查通过率（生成代码不经大改即可合并的比例）、回滚率（因生成错误不得不回滚的比例）——再决定是否推广。对于数据主权敏感的企业，自托管模式是安全选择，但需提前评估 Server 容器化运维的人力投入。考虑到 Cloud 服务已关停，团队应假设长期只存在社区维护版本，做好无商业化企业支持的心理准备。

限制与不适配场景

该工具在以下场景中存在使用限制：

场景适配边界 需要高度行业专业知识的任务、对输出格式有严格规范的场景、需要零错误的自动化流程可能效果不达预期。AI 输出应作为初稿或辅助参考，最终结果需人工核验。

技术限制 上下文长度有限、复杂推理准确性可能不足、免费版有使用额度。建议在正式采用前通过试用验证核心场景的可用性。

版本信息

Release cli/v2.2.1 ：CLI 主线更新版本，与服务端版本并行维护，反映双轨发布策略。（2025-07-16）
Release server/v2.2.1 ：服务端同版本发布，与 CLI 形成配套升级。（2025-07-16）
Release server/v2.2.0 ：上一主线服务端节点，为 2.2.1 版本提供演进基线。（2025-07-01）

用户评价

加载评价中...