VS Code AI 工作流實戰：Agent mode、Context、MCP 設定

這篇會帶你把 VS Code 內建 AI 能力拆成可落地流程，從日常寫前端到 MCP 串接都能直接上手。

前言

前端團隊評估 VS Code AI 工作流時，最需要先回答三件事：

今天打開 VS Code 能用到哪些能力？
這些能力各自解哪一段 workflow？
哪些功能還在 preview 或需要額外信任設定？

這篇文章以 2026-04-01 可查核的官方文件為基準，聚焦 VS Code 內的實際工作流。

前端工程師現在在 VS Code 內可用的 AI 能力

先把最重要的事釐清：VS Code 裡的 AI 不只是一個聊天框，而是幾個可組合能力。

1. Agent sessions：同一個 Chat 視圖管理不同執行型態

官方把 agent 使用情境分成 Local、Copilot CLI、Cloud 等型態，你可以在同一個 Chat 介面切換或接手 session。對前端最直接的價值是：

小改動：用 Local agent 直接在目前 workspace 做
長任務：交給背景或雲端 agent 跑，自己先繼續開發
要協作：把結果轉成 PR 流程

重點不是「AI 會取代編輯器」，而是同一個工作台能承接不同粒度任務。

2. Context 管理：不是只丟 prompt，而是精準餵上下文

VS Code 官方把 context 視為獨立能力，包含檔案、符號、終端、@-mentions（例如 @vscode、@terminal）與圖片等來源。這對前端除錯很有用，因為你可以把「程式碼 + 終端錯誤 + UI 截圖」放在同一輪對話。

3. Tools：內建工具 + Extension 工具 + MCP 工具

Agent 在 VS Code 裡可以呼叫多種工具來源，其中 MCP 是把外部能力接進來的關鍵。官方也提醒：工具可能改檔、跑命令、碰外部服務，審核參數與權限仍是工程責任。

Agent mode、聊天整合體驗、Context、MCP 分別解什麼問題

這四個名詞常被混在一起，實務上要分層看。

Agent mode：解「多步驟任務自動化」

當你要做的是「跨多檔案改動 + 執行命令 + 修回歸」，Agent mode 的回報比單純 chat 高很多。典型任務像：

把 React 元件從 CSR 改成 server/client 邊界清楚的結構
針對 lint/type error 批次修復後再跑一次測試
生成 migration PR 所需的機械式改動

聊天整合體驗（sessions list）：解「任務可追蹤」

VS Code 官方強調在同一個 Chat 視圖管理 sessions，讓團隊能追蹤「哪一輪 prompt 造成哪些改檔」。

Context：解「回答有沒有貼近你的 repo」

AI 回答品質常常不是模型問題，而是 context 問題。前端專案特別容易踩這點，因為 monorepo、設計 token、SSR 邊界都很吃脈絡。

MCP：解「讓 agent 操作 repo 以外的能力」

當你希望 agent 查文件、打 API、連資料來源或串第三方工具時，MCP 才是關鍵。它把接入流程標準化，避免每個整合都土法煉鋼。

可執行 MCP 設定範例：從 0 到可用

以下範例使用 VS Code 官方 mcp.json 結構，包含 inputs、env、sandboxEnabled。

Step 1：建立 workspace 設定檔

mkdir -p .vscode
touch .vscode/mcp.json

Step 2：貼上設定（可直接用）

{
  "inputs": [
    {
      "type": "promptString",
      "id": "perplexity-key",
      "description": "Perplexity API Key",
      "password": true
    }
  ],
  "servers": {
    "context7": {
      "type": "http",
      "url": "https://mcp.context7.com/mcp"
    },
    "perplexity": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "server-perplexity-ask"],
      "env": {
        "PERPLEXITY_API_KEY": "${input:perplexity-key}"
      },
      "sandboxEnabled": true,
      "sandbox": {
        "filesystem": {
          "allowWrite": ["${workspaceFolder}"],
          "denyRead": ["${userHome}/.ssh"]
        },
        "network": {
          "allowedDomains": ["api.perplexity.ai"]
        }
      }
    }
  }
}

Step 3：在 VS Code 啟動與檢查

# 從 Command Palette 可用：
# 1) MCP: List Servers
# 2) 針對 server 執行 Start / Show Output
# 3) 確認工具有出現在 chat tools 清單

Step 4：團隊協作時的最小規範

.vscode/mcp.json 可以進版控，但不要把 secrets 寫死
API key 一律走 ${input:...} 或 envFile
第一次啟動 server 時一定 review trust prompt
對本機 stdio server 先開 sandbox，再談 auto-approve

MCP 讓你「可擴充」，也把安全責任拉回團隊流程。不要把它當成裝好就全自動的黑盒。

AI Toolkit 放在 VS Code 工作流中的正確位置

這次重寫我刻意不把 AI Toolkit 寫成「萬能中台」，而是照官方能力拆成可用場景。

根據 AI Toolkit 官方文件，目前可核對的主軸包含：

Model Catalog：集中檢視不同來源模型
Playground：互動測試 prompt 與參數
Agent Builder：建立 agent workflow 與 MCP 整合
Agent Inspector：在 VS Code 內做 agent 偵錯與可視化
Copilot tools：如 Agent Code Gen、AI Model Guide 等工具

如果你是前端團隊，建議把 AI Toolkit 放在「原型驗證與 agent 開發」階段，而不是取代日常 IDE。較穩的切法是：

需求探索與 prompt 試驗：Playground
Agent 行為定義：Agent Builder
工具與流程問題定位：Agent Inspector
回到主專案落地：VS Code 一般開發流程（typecheck、test、CI）

這樣可以避免把「模型實驗」和「產品交付」混在同一條流水線。

常見問題 / 注意事項

Q1：要不要開啟全域 auto-approve？

不建議在日常開發預設打開。官方文件已明確標示會降低安全保護，尤其工具可執行命令與改檔時風險更高。

Q2：MCP 設定該放 workspace 還是 user profile？

團隊共享：放 .vscode/mcp.json
個人私有工具：放 user profile 的 mcp.json
連到 remote 開發環境時，注意 server 實際運行位置（本機或遠端）

Q3：Thunder Client MCP 可以直接寫進最佳實踐嗎？

若沒有可核對的一手官方文件，不建議當成既定能力寫死在教學文。比起追求「新」，更重要的是讀者能重現。

總結

對前端工程師來說，VS Code 的 AI 工作流已經很實用，但要用得穩，關鍵不是追新名詞，而是把邊界切清楚：

Agent mode 處理多步驟自動化
Context 提升回答貼合度
MCP 擴充外部工具能力

下一步建議是在中型專案做 1 週試點：固定一條任務跑完整流程，量化比較 lead time 與 review 退件率，再決定是否擴張。