一句话总览（先给全景图）

AI Agent + VS Code + LLM 集成 =
1️⃣ VS Code 扩展（人机交互）
2️⃣ Agent Runtime（决策与工具调用）
3️⃣ LLM API（推理大脑）
4️⃣ Tools（文件系统 / Git / Shell / Test / CI）

要做的不是“接 LLM”，而是 让 LLM 能在 VS Code 里「行动」。

一、三种主流集成路线（该选哪条）

✅ 路线 A：VS Code Extension + 自己的 Agent（推荐，最强）

适合这种：想做真正 Agent / E2E 自动化 / DevOps 智能体

1
2
3
4
5
6
7

VS Code Extension (TypeScript)
        ↓
Agent Orchestrator (Node / Python)
        ↓
LLM (OpenAI / Azure / Claude / DeepSeek)
        ↓
Tools (FS / Git / Shell / Test / Browser)

👉 Cursor / Continue / Copilot Chat 本质就是这条路

⚡ 路线 B：VS Code 扩展 + MCP（Model Context Protocol）

适合：多工具、多 Agent、低耦合

1
2
3
4
5

VS Code
   ↓ MCP Client
MCP Server (Tool Registry)
   ↓
LLM

代表：

• Cursor MCP
• Continue + MCP
• Claude Desktop + MCP

👉 未来主流，Agent 标准化方向

🧪 路线 C：外部 Agent（CLI / Server）+ VS Code 控制

适合：CI / 自动生成代码 / 批量任务

1

VS Code → Command → Agent CLI → LLM

二、推荐用的「现实可跑」技术栈（2026）

三、最小可跑 Demo（核心思想）

1️⃣ VS Code Extension（入口）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// extension.ts
import * as vscode from 'vscode';

export function activate(context: vscode.ExtensionContext) {
  context.subscriptions.push(
    vscode.commands.registerCommand(
      'ai-agent.run',
      async () => {
        const editor = vscode.window.activeTextEditor;
        const code = editor?.document.getText();

        await runAgent(code);
      }
    )
  );
}

2️⃣ Agent Orchestrator（决策层）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

async function runAgent(code: string) {
  const plan = await llm(`
是一个代码智能体。
目标：改进下面代码并补充测试。

代码：
${code}

请输出执行计划（PLAN）
  `);

  if (plan.includes("修改代码")) {
    await applyPatch(code);
  }

  if (plan.includes("运行测试")) {
    await runShell("npm test");
  }
}

👉 这一步就是 Agent 的核心：

• 拆目标
• 决策
• 调用工具

3️⃣ LLM 接入（以 OpenAI 为例）

1
2
3
4
5
6
7
8
9
10

import OpenAI from "openai";
const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

async function llm(prompt: string) {
  const res = await client.chat.completions.create({
    model: "gpt-4.1",
    messages: [{ role: "user", content: prompt }]
  });
  return res.choices[0].message.content;
}

4️⃣ Tools：让 Agent 真正“能干活”

文件系统工具

1
2
3
4
5

import fs from "fs";

function writeFile(path: string, content: string) {
  fs.writeFileSync(path, content);
}

Shell 工具

1
2
3
4
5
6
7

import { exec } from "child_process";

function runShell(cmd: string) {
  return new Promise((res, rej) =>
    exec(cmd, (e, stdout) => e ? rej(e) : res(stdout))
  );
}

四、Agent 才是重点，不是 Chat

❌ 错误：

VS Code + Chat = Copilot

✅ 正确：

VS Code + 计划 + 工具 + 状态 = Agent

要的 Agent 至少有：

五、进阶：用 LangGraph / MCP（推荐下一步）

LangGraph（多步可控）

1
2
3
4
5
6

const graph = new StateGraph()
  .addNode("plan", planNode)
  .addNode("code", codeNode)
  .addNode("test", testNode)
  .addEdge("plan", "code")
  .addConditionalEdges("code", decideNext);

MCP（工具标准化）

1
2
3
4
5
6
7
8
9
10

{
  "name": "run_tests",
  "description": "Run project tests",
  "inputSchema": {
    "type": "object",
    "properties": {
      "command": { "type": "string" }
    }
  }
}

VS Code / Cursor / Claude 都能直接调用。

六、现在最适合做的 3 个 Agent 场景（结合之前聊的内容）

1️⃣ E2E 自动生成 Agent

• 读需求
• 写 Playwright
• 跑测试
• 修失败用例

2️⃣ DevOps 质量守护 Agent

• Sonar 扫描
• 分析失败原因
• 自动修复 + 提 MR

3️⃣ 代码审计 / 安全 Agent

• SAST
• 依赖漏洞
• 修复建议

结论先给：

对这个目标而言，最简单、且后期不推翻重来的方案只有一个：
👉「Continue（VS Code 扩展） + MCP + 单 Agent」

不是“最炫”，而是认知成本最低 + 演进成本最低。

一、直接给结论排序（按「简单 → 强大」）

所以：现在选 Continue + MCP，后期不会后悔。

二、为什么 Continue + MCP 是「最简单且正确」

未来要做的事情：

• ✅ E2E 自动生成（Playwright / Cypress）
• ✅ UT 自动生成
• ✅ 测试数据分析（失败分布、flake、趋势）
• ✅ DevOps 接入（Sonar / Jenkins）

Continue + MCP 天然支持这一切。

Continue 本质是什么？

一个已经帮写好的 VS Code AI Agent 外壳

不用写：

• VS Code 扩展
• Chat UI
• 编辑器上下文注入
• 多模型切换

只做一件事：
👉 写 MCP Server = 写 Agent 的「工具能力」

三、最小可跑架构（10 分钟能跑）

1
2
3
4
5

VS Code
  ↓ Continue（现成）
LLM（GPT / Azure / Claude）
  ↓ MCP
写的 Agent Tools

四、最小 Demo：写的第一个 Agent（E2E 雏形）

1️⃣ 安装 Continue（不用写代码）

VS Code 插件市场：

1

Continue

2️⃣ Continue 配置（~/.continue/config.json）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

{
  "models": [
    {
      "title": "GPT-4",
      "provider": "openai",
      "model": "gpt-4.1"
    }
  ],
  "mcpServers": [
    {
      "name": "qa-agent",
      "command": "node",
      "args": ["mcp-server.js"]
    }
  ]
}

3️⃣ MCP Server（核心，极简）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

// mcp-server.js
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

const server = new Server(
  { name: "qa-agent", version: "0.1" },
  { capabilities: { tools: {} } }
);

server.tool(
  "generate_e2e",
  "Generate Playwright E2E tests",
  {
    type: "object",
    properties: {
      feature: { type: "string" }
    }
  },
  async ({ feature }) => {
    return {
      content: [
        {
          type: "text",
          text: `
import { test, expect } from '@playwright/test';

test('${feature}', async ({ page }) => {
  // TODO
});
`
        }
      ]
    };
  }
);

const transport = new StdioServerTransport();
server.connect(transport);

4️⃣ 在 VS Code 里直接用（这一步很关键）

Continue Chat 里输入：

“为登录功能生成 Playwright E2E 测试”

LLM 会自动：

• 理解需求
• 选择 generate_e2e
• 把代码写进的项目

⚠️ 没写 Agent 决策逻辑，Continue + LLM 帮做了

五、为什么这条路对“后期不崩”

后面要加的只是 工具，不是 框架。

🔹 UT 生成（加一个 tool）

1

server.tool("generate_ut", ...);

🔹 E2E 执行 + 失败分析

1
2

server.tool("run_playwright", ...);
server.tool("analyze_report", ...);

🔹 数据分析（很关心这个）

1
2
3
4
5
6
7
8
9
10
11
12

server.tool(
  "analyze_test_metrics",
  {
    type: "object",
    properties: {
      reportPath: { type: "string" }
    }
  },
  async () => {
    // flake rate / failure trend
  }
);

👉 LLM = 分析师
MCP = 数据通道
= 规则制定者

六、什么时候才需要「自写 VS Code 扩展」

只有这三种情况：

1️⃣ 要自定义 UI（仪表盘 / 图表）
2️⃣ 要深度控制编辑器行为
3️⃣ Continue 不够用了（极少）

在那之前，用 Continue 永远是“最省脑力”的选择。

七、给一句“架构箴言”（这种级别会懂）

不要一开始就写 Agent，大部分 Agent 都死在“壳子”上。
Continue 把壳子干掉了。

非常好，这四步是唯一一条可控、可审计、可规模化的路线。
下面我把它 工程化拆解成一份「可执行实施蓝图」，每一步都有：

• 目标
• 架构边界
• 可交付物
• 验收标准
• 常见坑

可以直接拿去做实施计划 / 架构评审。

总体路线图（四阶段）

1
2

Phase 1  →  Phase 2  →  Phase 3  →  Phase 4
MCP工具    规则Agent   LLM Agent   策略放权

Phase 1️⃣ 完成 MCP 工具（无 LLM）

🎯 目标

建立稳定、只读、可复现的上下文感知层。

🧱 架构边界

• ❌ 不允许任何推理
• ❌ 不调用 LLM
• ❌ 不产生决策
• ✅ 只返回结构化数据

🧰 必做 MCP 工具（最小集）

📦 可交付物

• MCP Host
• 工具 JSON Schema
• 本地 CLI 调用示例
• Jenkins 可调用

✅ 验收标准（硬）

• 同样输入 → 同样输出
• 无副作用
• 无模型依赖
• 可被单元测试

⚠️ 常见坑

• 工具“顺手”加判断逻辑
• 返回自然语言而不是 JSON

Phase 2️⃣ 完成 Agent（无 LLM，先规则）

🎯 目标

把“质量判断逻辑”从 Jenkins 中拿出来，变成可测试的规则系统。

🧱 架构边界

• ❌ 不调用 LLM
• ❌ 不学习
• ❌ 不自适应
• ✅ 显式规则 + 状态机

🧠 Agent 核心模块

1
2
3
4
5
6

Agent
├─ Event Router
├─ Rule Engine
├─ State Store
├─ MCP Orchestrator
└─ Decision Formatter

📜 规则示例（YAML）

1
2
3
4
5
6
7
8

rules:
  - id: NO_TEST_CHANGE
    when:
      code.changed: true
      test.changed: false
    then:
      decision: WARN
      reason: "代码变更但无测试"

📦 可交付物

• Rule Engine
• 决策 JSON Schema
• Agent API
• 审计日志

✅ 验收标准

• 不同事件 → 可预测输出
• 决策完全可解释
• 规则可回放

⚠️ 常见坑

• 把规则写死在代码里
• Jenkins 中留判断逻辑

Phase 3️⃣ 给 Agent 接入 LLM

🎯 目标

让 Agent 从「规则判断」升级为「语义判断」，但不失控。

🧱 架构边界

• ✅ LLM 只能参与 reasoning
• ❌ 不允许 LLM 直接下结论
• ❌ 不允许 LLM 直接操作 Jenkins

🧠 正确调用方式

1
2
3
4
5

llm.evaluate({
  policyContext,
  mcpContext,
  ruleResult
})

🛡️ 控制点（必须有）

📦 可交付物

• Prompt 模板
• JSON Schema 校验
• LLM 失败降级策略

✅ 验收标准

• 同规则下，LLM 输出一致性可接受
• 可随时关闭 LLM
• 无 LLM ≠ 系统不可用

⚠️ 常见坑

• 让 LLM“自由发挥”
• 用自然语言控制 Jenkins

Phase 4️⃣ 放开策略权限（成熟度驱动）

🎯 目标

让系统随着 DevOps 成熟度逐步“更严格”。

🧱 架构边界

• 权限由策略控制
• 人工可 Override
• 可回滚

🗺️ 策略矩阵示例

📦 可交付物

• 成熟度模型
• 策略配置
• 质量趋势看板

✅ 验收标准

• 无“一刀切”
• 策略可灰度
• 可随时降级

一句话总总结（非常重要）

不是在“接 AI”，
而是在“逐步赋权一个质量治理系统”。