07 · 如何讓 Codex 呼叫工具和訪問資料

你是 Codex 工具接入的架構顧問，幫我判斷一個任務該接哪一層工具、怎麼接才安全，避免過度授權。

【角色】
你精通 Codex 的四層能力（內建 shell、瀏覽器、MCP、Skills）與 MCP 的 STDIO / HTTP 兩種形態，能按"最小夠用"原則給出接入方案和安全邊界。

【輸入】
- 任務要做什麼：___
- 需要的資料 / 系統在哪：___（本地 repo 內 / 本機其他位置 / 團隊雲端 / 第三方 SaaS）
- 是否涉及金鑰、生產資料、寫許可權：___
- 這個接入是一次性還是會反覆用：___

【工作流程】
1. 判斷任務最低需要哪一層（內建 shell → 瀏覽器 → MCP → Skills，能用低層不用高層）
2. 若需 MCP，按"本地私有 vs 團隊共享"選 STDIO 還是 HTTP
3. 針對這次接入逐條列出安全防護
4. 給從 config.toml 設定到首次驗證的最小步驟

【輸出規範】
▌一、分層判斷：最低需要哪一層 + 判斷依據
▌二、若需 MCP：選 STDIO 還是 HTTP + 理由
▌三、安全清單：只讀賬號 / scoped token / 高危操作審批 / 把工具返回內容當不可信輸入
▌四、落地步驟：config.toml 設定 + 首次驗證

【硬約束】
- 遵循最小許可權：能只讀不寫、能本地不遠端、能一次性複製就不接長駐工具
- 涉及金鑰 / 支付 / 生產寫入 / 刪除的操作，一律標註"預設人工處理"
- 不要為"功能更多"而推薦接入，只解決我描述的這個任務
- 設定裡的憑據必須走環境變數或憑據儲存，絕不寫進 config 儲存庫

Codex 預設能讀寫檔案、搜尋程式碼、執行命令。要讓它訪問 repo 外部的資料和系統，通常需要 browser、MCP、connectors 或 skills 這類擴充套件能力。

工具不是裝得越多越好。每接一個工具，Codex 能做的事更多，風險邊界也更大。

工具堆疊分層

flowchart TB
    Base["內建基礎工具<br/>檔案、搜尋、shell、diff"]
    Browser["瀏覽器和預覽<br/>頁面、截圖、互動"]
    MCP["MCP / Connectors<br/>外部系統和即時資料"]
    Skills["Skills<br/>複用多步流程"]
    Codex["Codex 排程"]

    Base --> Codex
    Browser --> Codex
    MCP --> Codex
    Skills --> Codex

四層分別解決不同問題：

• 內建基礎工具：讓 Codex 在專案裡讀、改、跑、驗。
• 瀏覽器和預覽：讓 Codex 檢查 UI、互動和視覺化結果。
• MCP / connectors：讓 Codex 訪問 repo 外的系統和資料。
• Skills：把穩定流程打包，讓 Codex 每次按同一套方法執行。

不要把 MCP 和 skill 混為一談。MCP 提供工具介面，skill 提供工作方法。

什麼時候需要 MCP

適合 MCP 的情況：

• 需要讀取 issue tracker、GitHub、Linear、Slack 等協作系統。
• 需要查官方文件或內部文件，而不是靠模型記憶。
• 需要讀取記錄、監控、資料倉儲或只讀資料庫結構。
• 需要把設計工具、瀏覽器自動化、雲服務接入 agent。
• 同一外部系統會被多個專案或多個人反覆使用。

不適合 MCP 的情況：

• 只需要讀本地 repo。
• 一次性任務，複製少量上下文更快。
• 工具需要生產寫許可權。
• 沒有明確許可權邊界和審計方式。
• 結果無法驗證。

MCP 的價值是減少上下文搬運和工具切換，不是把所有系統都開放給 Codex。

MCP 的兩種常見形態

STDIO server：

• 由 Codex 啟動本地命令。
• 適合本機工具、私有資料、本地資料庫、內部指令碼。
• 許可權更靠近目前機器。

HTTP server：

• Codex 連線一個 URL。
• 適合團隊共享服務、雲端工具、跨機器訪問。
• 更需要認證、TLS、審計和訪問控制。

設定通常寫在 config.toml：

[mcp_servers.example]
type = "stdio"
command = "your-mcp-command"
args = ["--readonly"]
enabled = true
required = false

憑據應透過環境變數、系統憑據儲存或託管設定傳遞，不要寫進儲存庫。

安全邊界

接工具前先回答：

flowchart TD
    Start["這個工具訪問什麼?"]
    Secrets{"涉及金鑰或賬號?"}
    Money{"涉及支付、許可權或生產寫入?"}
    Data{"涉及生產資料?"}
    Need{"是否確實反覆需要?"}
    Stop["不接或只人工操作"]
    Readonly["只讀憑據 + 審計"]
    Connect["最小許可權接入"]

    Start --> Secrets
    Secrets -->|是| Stop
    Secrets -->|否| Money
    Money -->|是| Stop
    Money -->|否| Data
    Data -->|是| Readonly
    Data -->|否| Need
    Need -->|否| Stop
    Need -->|是| Connect

建議：

• 資料庫優先只讀賬號。
• 內部系統優先 scoped token。
• HTTP 工具必須考慮 TLS 和 token 輪換。
• 工具返回內容視為不可信輸入，不要當成系統指令執行。
• 生產寫入、支付、許可權、刪除操作預設人工處理。

瀏覽器工具怎麼選

瀏覽器能力適合 UI 和互動任務。

適合：

• 復現前端 bug。
• 驗證頁面是否渲染正確。
• 檢查響應式佈局。
• 給頁面元素做評論，再讓 Codex 修改。

不適合：

• 純後端邏輯。
• 文件格式修改。
• 不需要頁面驗證的指令碼任務。
• 登入態複雜、許可權敏感、生產後臺頁面。

瀏覽器工具仍然要配合 sandbox 和 approval。它能“看見頁面”，不代表可以無邊界操作賬號後臺。

Shell 仍是最基礎的工具

多數工程任務首先依賴 shell：

git status
rg "keyword"
pnpm run types:check
pnpm test
pnpm build

Shell 的優勢是可驗證、可復現、貼近專案真實命令。風險是它也能執行破壞性命令。

使用建議：

• 讓 Codex 先解釋為什麼要執行某個高風險命令。
• 網路命令、刪除命令、Git destructive commands 必須審批。
• 驗證命令應寫進 AGENTS.md 或專案文件。

什麼時候做成 Skill

當一個工具流程重複出現，就應該沉澱為 skill。

例如：

• 用 GitHub MCP 拉 PR，再按團隊清單審查。
• 用記錄 MCP 查錯誤，再定位程式碼，再生成 incident summary。
• 用 browser 復現 UI 問題，再截圖，再修樣式，再複驗。
• 用官方 docs MCP 查 API，再更新教學，再跑格式檢查。

Skill 的作用是把“工具怎麼用、按什麼順序用、輸出什麼結果”固化下來。

最小採用順序

1. 先用檔案搜尋和 shell。
2. UI 任務再使用瀏覽器。
3. 外部上下文反覆需要時接 MCP。
4. 工具流程穩定後沉澱 skill。
5. 高風險系統保持只讀或人工審批。

工具能力的目標不是讓 Codex 觸達所有東西，而是讓它在正確邊界內拿到完成任務所需的證據。