Cline + Roo Code — VS Code 智能体配置

这个 pack 包含什么

你已经在用 VS Code。你不想换 Cursor、Windsurf 或纯 CLI。你只想让 agentic 编码循环 — 读仓库、改文件、跑命令、查文档 — 在 VS Code 里发生，并且每步都过你眼。

2026 年只有两个扩展真正能做到这点：Cline（鼻祖，60K+ stars）和 Roo Code（Cline 的 fork，加了按模式独立的专家 agent 和 boomerang 编排，22K+ stars）。其他的要么是 inline 补全（Copilot、Continue 的 chat），要么是外部 CLI 套了个扩展皮。

这个 pack 涵盖：怎么在两者间选、用哪些规则文件来驯化它们、以及四个 MCP 服务器 — 这些 MCP 两边都通用。同一套 MCP 接线两边都吃，所以你可以切换甚至并行跑，不用重新接管线。

目标读者：想要真正的 agentic 编码（多步、用工具、能创建文件），但不愿意离开 VS Code — 也不想把 marketplace 上每个 AI 扩展都试一遍。

推荐安装顺序

1. Cline — VS Code 自主编码 Agent — 先装这个，作为默认。在 VS Code marketplace 搜 "Cline"、Install、粘 Anthropic 或 OpenAI 的 API key。60K+ stars，用户基数最大，最稳。每个动作都要你 approve — Cline 永远不会在你点「Approve」之前自己改文件或跑命令。
2. Cline — VS Code Autonomous AI Coding Extension — 同一个扩展的 MCP-config 视角条目。把它当作把 MCP 服务器接入 Cline 设置 JSON 的参考（语法和 Roo 略有差异，下面会讲）。
3. .clinerules — Cline 项目行为文件 — 干活前先在仓库根目录放一个 .clinerules。这是项目记忆的 Cline 版（类似 CLAUDE.md）：技术栈、规范、硬性禁忌。Cline 每次任务都会读。关键的是，Roo Code 也读同一个文件 — 之后你试 Roo 时，规则自动带过去，不用重写。
4. Roo Code — VS Code AI 编码团队 — 装上 Roo 作为第二个扩展（是的，两个可以同时在 VS Code 里 — 不冲突）。Roo 是 Cline 的 fork，核心能力相同，外加按模式独立的专家和 boomerang 任务编排。早晚你会想试它，先装好可以 A/B 对照。
5. Roo Code — 带自定义模式的 AI 编码 Agent — 同一个扩展的另一个参考条目，详细讲自定义模式的 UX。模式是 Roo 的招牌：你定义专家 agent，每个有自己的 system prompt 和工具白名单。
6. Roo Code Modes — Architect / Code / Ask / Debug 四个 agent — Roo 开箱即用的四个内置模式。Architect 规划，Code 写，Ask 读，Debug 排错。用这个条目学 boomerang 模式（Architect 启动一个多步任务，把子任务交给 Code，再拿回结果继续）。Cline 没有对应能力 — 这是 Roo 的主要差异化。
7. 2026 AI 编码 Agent 完整对比指南 — 决策文档。覆盖 Claude Code / Cursor / Codex / Gemini CLI / Cline / Roo Code / Windsurf / Aider，带 feature 矩阵。第 1 步装完读一遍，确认 Cline 是对的起点；第 6 步之后再读一遍，决定 Roo 是否值得占第二个槽位。
8. MCP Reference Servers — 官方实现集合 — Anthropic 官方维护的基线：filesystem、git、memory、fetch、sequential thinking。先接到 Cline；这些经过实战、零配置。等它们能跑了，你就信任 MCP 这根管子，再加更激进的就有底气。
9. Playwright MCP — 浏览器自动化服务器 — 两个扩展都受益最大的单个 MCP。让 agent 能截浏览器快照、点链接、填表单 — 这样它能 debug 你的前端、爬文档、QA 一个已部署页面，不用你来回截屏分享。在官方参考服务器证明管子通了之后再加。
10. Git MCP — AI Agent 版本控制服务器 — Cline / Roo 已经能通过终端跑 git，但 Git MCP 给的是结构化访问 — 分支列表、diff 摘要、log 查询都是带类型的响应，不用 shell 输出 parse。对任何非平凡仓库都值。
11. awesome-mcp-servers — MCP 目录索引 — 你每月翻一次的目标。当你接好 3-4 个 MCP 都能跑时，这个精选索引是你发现下一个的地方。第一天别从这里装；等你感受到上面四个的极限再回来。

它们怎么协同

         VS Code（你的编辑器，没变）
              │
   ┌──────────┴──────────┐
   │                     │
Cline (#1, #2)       Roo Code (#4, #5)
   默认                 备选
   │                     │
   │   读同一个文件:     │
   └──── .clinerules (#3) ────┘
                │
         （项目记忆）
                │
   ┌────────────┴────────────┐
   │       仅 Roo 有:        │
   │ Modes (#6) — Architect  │
   │ / Code / Ask / Debug    │
   │ + boomerang 路由        │
   └─────────────────────────┘
                │
         MCP 协议层
      （两个扩展共用同一根线）
                │
   ┌────────┬───┴────┬──────────┐
   │        │        │          │
Reference  Playwright Git MCP  awesome-mcp
Servers    MCP (#9)  (#10)    目录 (#11)
(#8)
filesystem 浏览器     结构化   每月
git/memory 截图/点击  git 操作 浏览
fetch/seq  填表       diff/log
thinking

   ↑                                ↑
   从这开始                         每月回来翻一次
   （官方零配置）                   （感受到极限之后）

   2026 AI 编码 Agent 对比指南 (#7)
      └── 决策文档，读两次：
            • 第 1 步后确认 Cline
            • 第 6 步后决定要不要 Roo

非显然的赢点：.clinerules 两个扩展都读，所以你切换 Cline 和 Roo 不用重写规范。MCP 同理 — 在系统层接一次，两个扩展看到的是同一组服务器。

你会遇到的取舍（Cline vs Roo Code）

这个 pack 存在的核心理由就是这一节。挑选之前先读。

• 稳定 vs 灵活 — Cline 是上游，更保守，用户基数大，扩展更新少出意外。Roo 上新功能快（自定义模式、boomerang、cloud agent），但也更容易出问题。**如果你周二早上承担不起「我的 agent 突然不工作」这种事故，默认上 Cline。**喜欢折腾就默认 Roo。
• 一个模式 vs 多个模式 — Cline 一个 agent 人格、一个 system prompt。Roo 有 Architect / Code / Ask / Debug（还能定义无限自定义模式），每个有自己的 prompt 和工具白名单。**80% 的活一个人格就够了。**自定义模式只有在你有真实的多步工作流时才赚回它的复杂度 — 比如「Architect 规划迁移、Code 执行每步、Debug 在每次失败后跑」。别预防性加模式，最后你只是维护更多 YAML。
• boomerang vs 线性 — Roo 的 boomerang 编排让一个模式里启动的任务可以委托给另一个模式跑完，拿回结果再继续。Cline 一个任务跑在一个 context 里。boomerang 对 >30 分钟的任务确实有用（context 不被污染、子 agent 失败不会把父任务也拖坏）。5 分钟的小改它就是 overhead。
• 每次任务成本 — 模型 token 烧得一样。Roo 的模式可以让成本变高（多模式任务做更多 LLM 调用），也可以变低（Ask/Debug 模式用便宜模型，只给 Architect 上大模型）。早点配模式级模型，否则你会流血。
• 生态成熟度 — Cline 的第三方 MCP 教程更多、YouTube 教程更多、Reddit 帖子更多。Roo 文档更精炼但社区更小。习惯 Google 出路的选 Cline；偏好读源码的选 Roo。
• MCP 兼容性 — 完全一致。两个都说 MCP 协议。这个 pack 里每个 MCP 两边都能用。系统层把 server 接一次，两个扩展都看得到。这就是为什么并行跑两个扩展很便宜 — 没有重复管线。
• 审批疲劳 — 默认两个都对每个动作要审批。Cline 的审批 UI 更快（点击少）。Roo 的更细（可以按模式预批准 pattern）。一周后你会想给 git status / ls / cat 这种预批准 — 谨慎做，只对只读命令开。
• 诚实总结 — Cline 是 iPhone（稳、主流、推荐给老板用）。Roo 是 Android（更可定制、更新更快、推荐给爱写 config 的工程师）。Cline 当默认，副业项目上装 Roo 试两周模式，能 justify 就两个都留、不能就砍一个。

常见踩坑

• 没试 Cline 直接上 Roo — 你会失去「正常」的基线感觉。模式 / boomerang 确实是真东西，但你只有先吃过 Cline 的限制才能判断是不是真需要。两周 Cline，再评估。
• MCP 只接到一个扩展、忘了另一个 — Cline 的设置在它扩展配置里；Roo 的在它的。每个 MCP 要写两次（或者用 ~/.config/mcp/ 这种系统级配置，如果你 OS 支持）。如果一个 server 在 Cline 能用、Roo 不能 — 那就是你忘了在 Roo 侧加。
• .clinerules 写太工程化 — 和 CLAUDE.md 同样的坑：有人把架构文档 paste 进去，每次任务 burn 4K token。控制在 100 行以下：技术栈、命令、规范、硬性禁忌。两个扩展每轮都读。
• 全部 Auto-approve 一路点 — 两个扩展都有「Auto-approve」开关。第一天别全局打开。白名单只读命令（git status / ls / pwd），写操作 / 删除 / 网络调用保持手动，直到你信任模型在你这个代码库的行为。
• 跳过对比指南 (#7) — 它是无聊的文档，但它阻止「我怎么装了这 4 个」的瞬间。读一次，决定哪些扩展占永久槽位，其他卸了。
• 把 Playwright MCP 当可选 — 它是让 agent 在前端工作上真正有用的 MCP。没它，Cline / Roo 能改你的 React 组件但不能告诉你页面渲染是否正常。有它，闭环才闭合。