你对 Cline 的认知，大概率停在两年前
提起 Cline，多数人的印象还是"VS Code 里那个要你逐个批准操作的开源插件"。这个印象不算错，但严重过时了——2026 年的 Cline 是 一个 agent core、五个产品表面：CLI、Kanban 看板、VS Code 扩展、JetBrains 插件、还有给开发者自己造 Agent 用的 @cline/sdk。
看几个数据就明白它现在的体量：65,689 Star、7,050 Fork，Apache-2.0，TypeScript 写的，2024 年 7 月 6 日创建（早期叫 Claude Dev）。npm 上 cline 包过去 30 天被下载 60.5 万次，而 @cline/sdk 也有 57.6 万次——SDK 的下载量几乎追平本体，这是"大家拿它当引擎再造 Agent"的最硬证据。就在昨天（8 月 5 日），主仓库刚发 v4.1.4，CLI 侧也更新到 v3.0.50。
所以今天这篇不聊"怎么在 IDE 里点批准"，聊它真正值得抄的三个设计：单核心多表面的架构、SDK 怎么把 Agent 变成库、CLI 为无人值守场景做了哪些取舍。
它到底是什么
- 65,689 Star / 7,050 Fork，Apache-2.0，TypeScript 单仓（monorepo）
- 一个共享 agent core，五个产品：CLI、Kanban、VS Code 扩展、JetBrains 插件、SDK。plan/act 模式、MCP、checkpoints、rules、skills、provider 配置在所有表面上行为一致
- 模型不锁死：Anthropic、OpenAI、Gemini、OpenRouter（200+ 模型）、Vercel AI Gateway、AWS Bedrock、Azure/GCP Vertex、Cerebras/Groq、Ollama/LM Studio、任何 OpenAI 兼容端点
- CLI 是平台二进制：macOS/Linux/Windows × arm64/x64 都有预编译产物，通过 optional dependencies 分发，装的时候不需要 Node/Bun/Zig 运行时
- JetBrains 插件官方存在但不开源——README 里写得很直白，这是五个表面里唯一的闭源件
一个核心五个壳：这不是产品矩阵，是架构决策
绝大多数编码 Agent 项目只做一条产品线：要么 IDE 插件，要么 CLI，要么框架。Cline 的选择是全部都要，但共享同一个 core。结构是这样的：
| 产品 | 形态 | 安装 | 定位 |
|---|---|---|---|
| CLI | 终端 TUI + headless | npm i -g cline | 交互式结对、CI/CD 无人值守、脚本管道 |
| Kanban | Web 任务看板 | npm i -g kanban | 并行跑多个 agent，每张卡片独立 worktree + 自动 commit + 依赖链 |
| VS Code 扩展 | IDE 集成 | VS Marketplace | 编辑器内 human-in-the-loop 审批 |
| JetBrains 插件 | IDE 集成 | JetBrains Marketplace | IDEA/PyCharm/WebStorm/GoLand 全家桶（闭源） |
| SDK | TypeScript 库 | npm i @cline/sdk | 用同一引擎构建你自己的 Agent/自动化 |
这个架构的好处是一次调优，处处生效：core 里修一个工具调用的 bug，五个产品同时拿到。坏处是 monorepo 复杂度爆炸——它的版本号已经出现分裂：主仓库 v4.1.4、CLI 独立版本 v3.0.50、SDK 独立版本 v0.0.70，三个 changelog 各记各的，追更新要多看三个地方。
对我们这些使用者，真正值得注意的信号是：CLI 和 SDK 的优先级已经明显高于 VS Code 插件（插件部分 README 标注"WIP migrating"）。Cline 的战略重心正在从"编辑器助手"移到"可编程的 Agent 运行时"。
SDK：30 行代码造一个 Agent，月下载 57 万
SDK 是 Cline 最有技术含量的一块。它把 agent core 暴露成 TypeScript API，最简用法是 10 行：
import { Agent } from "@cline/sdk"
const agent = new Agent({
providerId: "cline",
modelId: "openai/gpt-5.5",
systemPrompt: "You are a helpful coding assistant.",
tools: [],
})
const result = await agent.run("Create a REST API with Express and TypeScript")
console.log(result.text)自定义工具用 createTool，schema 驱动，agent 根据 description 决定何时调用：
const deploy = createTool({
name: "deploy",
description: "Deploy the app to staging or production.",
inputSchema: {
type: "object",
properties: { environment: { type: "string", enum: ["staging", "production"] } },
required: ["environment"],
},
execute: async (input) => {
const result = await runDeployment(input.environment)
return { url: result.url, status: "success" }
},
})
const agent = new Agent({
providerId: "moonshot",
modelId: "kimi-k2.5",
systemPrompt: "You are a deployment assistant.",
tools: [deploy],
})执行过程中的每个事件都能实时订阅——content_update、content_start、usage，做流式输出和 token 计费都很直接。再往上还有插件系统（AgentPlugin，manifest 声明 capabilities，setup 里注册工具，hooks 里挂 beforeRun/beforeTool/afterRun 做审计、策略、埋点）和ClineCore——完整运行时，带 SQLite 会话持久化、内置工具（bash/editor/read_files/apply_patch/search/fetch_web）、从 .cline/ 目录发现配置，还能接 RPC sidecar 做跨进程的定时任务。
SDK 甚至配套了一个 skill（npx skills add cline/sdk-skill），作用是给你的 Claude Code / Codex 提供 SDK 的 API 上下文，让别的 Agent 帮你写 Cline Agent——自己造自己，套娃套得很完整。
CLI：为无人值守做了全套设计
安装后一条命令进交互 TUI（基于 OpenTUI，markdown 渲染 + 语法高亮 diff + 鼠标支持），但真正体现工程水平的是 headless 形态：
# 一条命令跑完并退出
cline "Audit this package and propose fixes"
# 管道输入：把 diff 喂给它 review
git diff origin/main | cline "Review these changes for issues"
# NDJSON 流式输出，接 jq 做下游处理
cline --json "List all TODO comments" | jq -r 'select(.type == "agent_event" and .event.text) | .event.text'
# yolo：跳过所有审批，适合 CI
cline --yolo --retries 5 "Refactor this package"
# zen：派给后台 hub daemon，CLI 立刻退出，跑完通知
cline --zen "Refactor the authentication module and add unit tests"几个值得展开的设计：
--zen：任务提交给本地 hub daemon 后 CLI 立即退出，无人在场也全自动审批（语义等同 yolo），menubar 应用在时会弹系统通知。相当于"fire and forget"模式，适合长任务。- 多 Agent 团队：
cline --team-name auth-sprint "Plan and implement user authentication with tests"——协调者拆子任务、分派给带各自工具和上下文的专家 agent，团队状态跨会话持久化，第二天能接着干。 - 定时任务：
cline schedule create "PR summary" --cron "0 9 * * MON-FRI" --prompt "List all open PRs and their review status"——cron 表达式直接进 CLI，结果还能路由回 Telegram/Slack。 - 聊天连接器：
cline connect telegram -k $BOT_TOKEN，Telegram/Slack/Discord/WhatsApp/Linear 的每个会话线程映射到一个完整上下文的 agent session。 - MCP 管理：
cline mcp install fs -- npx -y @modelcontextprotocol/server-filesystem /tmp，stdlib 和 HTTP/SSE 远程 server 都能装。 - 证书信任：CLI 启动时自动收割 OS 信任锚写入
~/.cline/cli-node-extra-ca-certs.pem并指向NODE_EXTRA_CA_CERTS——企业 TLS 拦截代理、自签名内网端点开箱即用，不用手动配证书。这个细节很多 CLI 都不做。
和同类项目比，差异在哪
这个赛道我们写过多篇了，放一起看 Cline 的位置：
| 维度 | Cline | opencode | Qwen Code | oh-my-pi |
|---|---|---|---|---|
| Star | 65.7K | ~13K | 26.6K | 21K |
| 核心形态 | 五栖（IDE+CLI+SDK+Kanban） | CLI + SDK | CLI | CLI + IDE |
| 引擎复用 | 一个 core 五个表面 | SDK 驱动 | 单 CLI | 单 CLI |
| SDK 生态 | @cline/sdk 月下载 57 万 | 有 | 无 | 无 |
| 无人值守 | yolo / zen / schedule / connect | yolo 等价 | 有限 | 有限 |
| IDE 支持 | VS Code + JetBrains | 无 | VS Code 扩展 | VS Code 类 |
| 协议 | Apache-2.0 | MIT | Apache-2.0 | MIT |
最大差异还是那条：Cline 是这批项目里唯一把"IDE 插件"和"可编程 Agent 引擎"两条路线同时走完的。opencode 的 SDK 也很强，但 Cline 有两年多的 IDE 用户积累和 65K Star 的社区底盘；Qwen Code、oh-my-pi 更偏"把单机 CLI 做好"。如果你要的是"一个引擎，既能进 IDE 人机协作，又能被代码调用、能上 CI、能挂 IM"，目前只有 Cline 全家桶覆盖得最全。
实际体验的几个坑
- 版本号三轨制，追更新心累——主仓库 v4.1.4、CLI v3.0.50、SDK v0.0.70，三个 changelog 分开记。装 CLI 前先
cline --version看实际装到哪版，别被主仓库的 tag 误导。 - OAuth 不会自动弹浏览器——
cline auth（不带 provider）才是交互式登录；非交互运行时如果选了 OAuth 但没有已存凭证，会直接 fail fast 而不是偷偷拉起浏览器。自动化脚本里第一次用要先手动跑一次cline auth <provider>存好凭证。 - CLI 默认是 auto-approve——跟 VS Code 扩展"每个操作都要批准"的体验正好相反，CLI 默认自动批准所有工具调用（
--auto-approve false才关）。在本地跑无所谓，接 CI 或共享 runner 前一定想清楚。而且非 TTY 下需要审批的调用会被直接拒绝，不是挂起等待。 - yolo 模式默认禁用 spawn/team 工具——防的是无人值守时 Agent 再派生子 Agent 失控。想并行要显式开，安全逻辑是对的，但第一次用
--yolo跑多文件重构发现它不派生子任务时别懵。 --zen有兼容性限制——跟--data-dir（隐式沙箱需要随 CLI 退出的本地后端）和--tui互斥。而且如果 menubar 应用没在跑，zen 任务跑完没有任何 UI 通知，只能事后cline history翻结果。- JetBrains 插件闭源——README 明说 not open-sourcing。团队如果强制全开源合规，JetBrains 这条线得单独评估。
- 默认模型是收费的——
anthropic/claude-sonnet-4.6是默认，不配 key 或想省钱得显式换 provider（Ollama/LM Studio 本地模型都支持）。SDK 里 providerId/modelId 可以按 agent 分别指定，别全局一把梭。 - 桌面审批模式要手动接线——
CLINE_TOOL_APPROVAL_MODE=desktop+CLINE_TOOL_APPROVAL_DIR两个环境变量配对才生效，CLI 写 request JSON 文件、等 decision JSON 文件。配错了不会报错，只是审批永远超时。
适合谁用
- 想把 Agent 嵌进自己产品/流程的开发者——SDK 是最大卖点：Slack bot、PR review 流水线、定时自动化、IDE 集成，一个引擎全包
- IDE 和终端都要用的重度用户——VS Code 里人机协作、终端里 headless 跑 CI，同一套 rules/skills/provider 配置两边一致
- 要并行跑多个 Agent 的团队——Kanban 每张卡片独立 worktree + 自动 commit，比手动开一堆终端窗口强一个量级
- 被企业代理/自签名证书卡过的 CLI 用户——自动信任 OS 证书存储这点，是很多同类工具懒得做的
- 不想被单一模型绑架的人——从 Anthropic 到 Ollama 本地模型全覆盖，OpenAI 兼容端点随便接
总结
Cline 做的事情一句话：把编码 Agent 从"IDE 功能"重构成"可编程运行时"，再以五个产品表面分发出去。技术上它没有特别玄的东西——TypeScript、SQLite、RPC sidecar 都是常规武器——但它赢在架构决策：单 core 多表面带来的行为一致性、SDK 优先的战略倾斜、CLI 对无人值守场景的完整覆盖（zen/schedule/connect/证书信任）。
65.7K Star 和 SDK 57 万的月下载量说明市场已经买账：Cline 正在从"编辑器里的助手"变成"你自家 Agent 的引擎"。如果你已经在用别的 CLI Agent，SDK 那条线依然值得单独看一眼——它是这个项目里最有复利的部分。
项目地址：github.com/cline/cline · 文档：docs.cline.bot · CLI README：apps/cli