mrkt的程式學習筆記

ASP.NET MVC, ASP.NET Web Api, .NET Core (C#), Test

2026-05-28

計費衝擊下的架構回應 — dotnet-testing-agent-orchestration v2.0.0 與後續方向

系列：從鐵人賽到 Agent Orchestration — AI 自動建立 .NET 測試的完整方案（6）

前言

GitHub Copilot 在 2026/04/27 公告，2026/06/01 起計費方式將從「按請求次數」改成「按 token 消耗」。這個改變對 Agent Orchestration 這類運算密集的工作流程衝擊極大 — 在新制下，繼續投入 GitHub Copilot 版本的 dotnet-testing-agent-orchestration 已經不符合經濟效益。

因此這篇插進來的文章要趕緊把 Copilot 版告一段落，帶各位看一下這個轉換點的完整脈絡。首先有三件事：

  1. dotnet-testing-agent-orchestration 在 2026/05/05 發佈了 v2.0.0。這是針對 v1.0.0 在 GitHub Copilot 執行環境下三類結構性問題所做的架構重構：skill 載入延遲、subagent handoff 的 context 成本、workflow 缺乏階段耗時可觀測性。它解掉了 v1 在 Copilot 上跑起來不夠俐落的核心問題。
  2. 但在 v2.0.0 發佈後不久，遇上 GitHub Copilot 計費改制。這是一個獨立於本專案、發生在 v2.0.0 開發後期的外部事件，但它改變了 Copilot 版本的成本盤算。
  3. 前面兩件事加起來，讓我做了一個決定 — GitHub Copilot 版本的 dotnet-testing-agent-orchestration，後續不再有調整與維護的計畫；這個系列文章後續會轉向已經完備的 Claude Code 版本，以及正在開發中的 Codex 版本。

特別說明：v2.x 的調整是為了解決 v1.x 在 Copilot 環境下的執行效率問題而做的，跟新計費制度無關。事實上 v2.0.0 的規劃與開發，遠早於 Copilot 公告計費改制。只是新計費剛好在 v2.0.0 發佈後不久上路，讓「在 Copilot 環境繼續投入」變得不符合經濟效益。

延伸閱讀：GitHub Copilot 6/1 計費改制：Agent Mode 重度使用者該如何重組 AI 工具訂閱?

dotnet-testing-agent-orchestration v2.0.0 / v2.0.1

在進入細節說明之前，先提供這兩個版本的 Release Notes，可以直接對照原始資料：

v2.0.0 是本篇的主軸，針對 v1.0.0 三類結構性問題做了架構層面的調整。
v2.0.1 是在 v2.0.0 之後的補強，主要是 mcp-local-rag 的離線索引腳本與說明文件的完善。

一、v2.0.0 做了什麼

用過 v1.0.0 一段時間後，幾個問題會逐漸浮現 —— skill 載入拖慢了整體流程、subagent 之間的交接資訊越來越膨脹、跑完一次也看不出時間花在哪。v2.0.0 就是針對這三個問題做的調整。

v1.0.0 留下的三類結構性問題

v1.0.0 跑得起來，產出品質也不錯，但在 GitHub Copilot 環境下用久了，會清楚感受到三個結構性問題：

問題 1：skill 載入延遲

v1.0.0 的 Writer 在開始寫測試前，會根據 Analyzer 的分析結果，用 read tool 把需要的 SKILL.md 一個一個讀進來。在 GitHub Copilot 中，每次讀檔都是「一次 tool call + 一次檔案 round-trip」。Unit Test 最大場景下要讀 19 個 SKILL.md，光是 skill 載入這一段就會佔掉相當可觀的等待時間。

問題 2：subagent handoff 的 context 成本

v1.0.0 的 Analyzer 把分析結果寫在回傳的 prompt 裡，Orchestrator 再把這段 prompt 串到 Writer 的指令中。隨著流程推進到 Writer → Executor → Reviewer，這段 handoff 文字會被反覆攜帶。到了 Reviewer 階段，context 已經膨脹到讓 prompt 變得難以維護，也排擠了實際給 Reviewer 推理用的空間。

問題 3：workflow 缺乏階段耗時可觀測性

v1.0.0 跑完一次 Orchestration，使用者看到的就是「一連串的 tool call + 最終結果」。如果某次跑了 6 分鐘，沒辦法知道這 6 分鐘是怎麼分布的 — 是 Analyzer 分析得久？Writer 載 skill 載得久？還是 Executor 修正迴圈多跑了兩輪？沒有分階段的耗時資料，問題診斷與優化都缺一個基礎。

這三類問題的共通點：它們是 GitHub Copilot 執行環境特有的問題。在 Copilot 上，它們會疊加成「跑一次 Orchestration 體感很拖、prompt 很臃腫、不知道時間花到哪去」這個結果。

v2.0.0 就是針對這三類問題逐一回應。

v2.0.0 的四項主要改進

1. mcp-local-rag：把 skill 載入從「逐一讀取」改成「語意查詢」

mcp-local-rag 的基本資訊：

  • Github Repo：https://github.com/shinpr/mcp-local-rag
  • 作者：Shinsuke Kagawa（shinpr）
  • 定位：本地端語意搜尋 MCP server，完全在本機運行、不需外部 API、無需 Docker
  • 提供 7 個 MCP tools：ingest_file、ingest_data、query_documents、read_chunk_neighbors、list_files、delete_file、status
  • 底層技術：Transformers.js（預設 all-MiniLM-L6-v2） + LanceDB（file-based vector DB）
  • 支援格式：PDF、DOCX、TXT、Markdown
  • 安裝：一個 npx 指令，zero setup
  • 適用平台：Cursor、Claude Code、Codex、GitHub Copilot

v2.0.0 引入 mcp-local-rag 與 dotnet-testing-skills MCP server，把 dotnet-testing-agent-skills 全部建成本地語意索引。Subagent 不再用 read tool 逐個讀 SKILL.md，而是用語意查詢取得相關片段：


 

實作上有三層 fallback：

  • MCP protocol tool（mcp:dotnet-testing-skills/query_documents） — Writer 優先使用
  • CLI fallback（mcp-local-rag --db-path .mcp/dotnet-testing-skills query） — Reviewer 在 subagent 模式下優先使用（MCP tool 在 subagent context 中不保證可用）
  • 直接讀取 SKILL.md — MCP 與 CLI 都不可用時的最終 fallback

MCP 設定透過 repo 內的 .vscode/mcp.json 管理，索引建立腳本（PowerShell + Python）與安裝說明集中於 docs/mcp_local_rag/。

.vscode/mcp.json

{
  "servers": {
    "dotnet-testing-skills": {
      "command": "npx",
      "args": ["-y", "mcp-local-rag"],
      "env": {
        "BASE_DIR": "${workspaceFolder}/.github/skills",
        "DB_PATH": "${workspaceFolder}/.mcp/dotnet-testing-skills",
        "CACHE_DIR": "${workspaceFolder}/.mcp/cache",
        "RAG_HYBRID_WEIGHT": "0.7",
        "RAG_GROUPING": "similar"
      }
    }
  }
}

這項調整需要使用者在環境設定階段做幾件事：

  1. clone dotnet-testing-agent-skills 到本機
  2. 全域安裝 mcp-local-rag
  3. 建立 Skills 索引
  4. 在專案的 .vscode/mcp.json 中註冊 dotnet-testing-skills MCP server

從工程觀點看，這把「多次 tool call 載入 SKILL 全文」改成了「一次查詢回相關片段」，是 v1 → v2 中影響最直接的一項。

2. 結構化 JSON Handoff：把階段交接從 prompt 內嵌改成檔案讀取

v2.0.0 把 Analyzer、Writer、Executor 的中間結果改寫到本地檔案：

.orchestrator/{TargetName}/
├── analyzer-result.json   # Analyzer 的結構化分析報告
├── writer-result.json     # Writer 的測試檔案路徑與技術選擇
└── executor-result.json   # Executor 的執行結果（固定 schema）

Orchestrator 在委派下一階段時，只在 prompt 裡告訴 Subagent 對應 JSON 的路徑，Subagent 自己去讀檔。這樣每個階段的 prompt 都保持精簡，handoff 內容不會堆疊。

executor-result.json 的 schema 在 v2.0.0 還做了「固定欄位」的嚴格規範 — 例如 totalTests、passedTests、failedTests 不准用 tests / passed / failed 之類的別名 — 這讓 Reviewer 對結果的解析變得穩定，不會因為 Executor 的小幅輸出漂移而失敗。

3. Phase Timing：把可觀測性內建進 workflow

v2.0.0 在四個 Orchestrator 裡都加上 phase timing 的輸出，會輸出對應的 timing log 檔：

OrchestratorTiming Log 檔名
單元測試orchestrator-timing.log
整合測試integration-orchestrator-timing.log
Aspire 整合測試aspire-orchestrator-timing.log
TUnit 測試tunit-orchestrator-timing.log

每次流程結束後，會在訊息中直接顯示分階段耗時，類似這樣：

Phase 1 (Analyzer)：  43 秒
Phase 2 (Writer)：    1 分 28 秒
Phase 3 (Executor)：  56 秒
Phase 4 (Reviewer)：  39 秒
─────────────────────
Total：               3 分 46 秒

這對問題診斷的價值很直接：當你發現某次流程比平常慢，可以立刻看出是哪個階段在膨脹。

4. Executor Fast-Path：成功路徑直接快返

v2.0.0 在 Executor 內加上 happy-path 快返規則：

只要「首輪 build 成功」且「首輪 filtered tests 全數通過」，立即回傳固定 schema 的精簡 JSON、不再進入最多 3 輪的修正迴圈、不再輸出冗長敘述。

對「測試一次就過」的情境，這個調整直接縮短了 Executor 階段的執行時間。對需要修正的情境也沒有影響 — fast-path 不觸發時，原本的修正迴圈照樣執行。

配套：模型統一與目錄結構整理

除了上述四項主要改進，v2.0.0 也做了一些配套整理：

  • 模型統一：所有 Agent 定義檔的主要模型統一為 GPT-5.3-Codex (copilot)，備用模型 GPT-5.4 (copilot)。
  • .github/prompts/ 移除：v1.0.0 為了給沒用 Orchestrator 的使用者一個出口，提供了 16 個 Custom Prompts。v2.0.0 把這部分移除，把使用入口統一到 Agent。
  • .github/skills/ 精簡：dotnet-testing-agent-skills 的 SKILL 內容從 repo 中拿掉，.github/skills/ 只保留 dotnet-test，這是 Executor Subagent 會用到的測試執行流程規範。

dotnet-testing-orchestrator - Unit Test 執行狀態

以下是有開啟 dotnet-testing-skills MCP (mcp-local-rag) 的執行結果

二、GitHub Copilot 6/1 計費改制

改制重點：從 PRU 到 AIC

GitHub 在 2026 年 4 月 27 日宣布，2026/06/01 起 Copilot 的計費單位從 Premium Request Unit（PRU，按請求次數） 換成 AI Credits（AIC，按 token 消耗）。1 AIC = 0.01 美元，每次互動的 input / output / cached tokens 都會精算。

對一般 Code Completion 或 Chat 對話，這個改變的衝擊有限。但對 Agent Mode、Agent Orchestration 這類運算密集的工作流程，新制等於把過去被訂閱費攤平的成本全部攤在陽光下。

我用自己 4 月份的 Billing Preview 數據實際算過 — 同樣的使用模式，舊制月費 39 美元、新制換算下來月費約 1,727 美元。這個數字的拆解、計費結構的完整對照、訂閱組合的調整建議，我寫在另一篇文章裡，篇幅比較完整，這裡就不重複：

延伸閱讀：GitHub Copilot 6/1 計費改制：Agent Mode 重度使用者該如何重組 AI 工具訂閱?

對這個專案的具體衝擊

dotnet-testing-agent-orchestration 是一個典型的 1 + 4 Subagent 架構工作流程：一次完整的 Orchestration 會啟動 Orchestrator + 4 個 Subagent，每個 Subagent 各自讀取被測類別與既有測試、進行多輪推理。在 AIC 制下，這整個流程的每一步都要精算。

即便 v2.0.0 已經解掉了執行效率上的結構性問題，但對 AIC 制下的帳單數字，這類工作流程的成本本質就不是個人使用者日常負擔得起的。

三、兩件事加在一起的決定

v2.0.0 處理了 v1.0.0 在 Copilot 環境下的核心問題，原本還有 v2.x 的後續調整在計畫中。新計費改制是 v2.0.0 完成同期發生的外部事件 — 跟 v2.0.0 沒有因果關係，但深刻改變了「繼續投入 Copilot 版本」的成本盤算。

兩件事加在一起，讓我做了這個決定：

dotnet-testing-agent-orchestration 的 GitHub Copilot 版本，後續不再有調整與維護的計畫。

具體來說：

  • 既有 repo 會留下來作為公開資源（可以 clone、可以參考、可以拿來改）
  • 我不會再投入時間在這個版本上做新功能、新測試類型或進一步優化
  • 不管是維護或是日常使用，都已經不符合經濟效益

那這段時間做的事情都白做了嗎？

不會。從鐵人賽到把文章提煉出 dotnet-testing-agent-skills，再到製作 dotnet-testing-agent-orchestration v1.0.0 一路到 v2.0.0，這個過程累積出來的是對「怎麼設計一個可運作的測試 Agent Orchestration 工作流程」的第一手知識——包括四階段設計的必要性、Subagent 分工的邊界在哪裡、銜接與交接如何保持穩定、測試執行流程要怎麼處理回傳變數。

不過要說清楚的是：dotnet-testing-agent-orchestration 的 agent 設計跟 GitHub Copilot 有強耦合。無論是 .agent.md 的平台語法、MCP 橋接方式，還是 Subagent 的委派機制，都是 Copilot 特定的實作方式。要在其他平台上實現同樣的流程，需要針對各平台的機制重新實作，不是直接搬過去就能用的。

已經實作出來的流程與架構雖然無法直接移植到其他平台，但核心同樣都是使用 dotnet-testing-agent-skills，而且 Claude 與 Codex 也都有提供 multi-agents 的機制。因此可以將同樣的架構與流程在這些平台上重新實作出來——雖然底層機制與實際運作會有所差異，但同樣的內容與流程是可以落實的。

小結

  1. v2.0.0 是針對 v1.0.0 三類結構性問題的架構重構 — 處理掉了 skill 載入延遲、handoff context 成本、缺乏可觀測性等核心痛點。但 v2.x 本身仍有可以再優化的空間，原本應該還會有後續調整。
  2. 6/1 計費改制是一個獨立發生的外部事件 — 跟 v2.0.0 沒有因果關係，但讓「在 Copilot 環境繼續投入這套工作流程」不再符合經濟效益。
  3. 基於這兩件事，GitHub Copilot 版本的調整與維護到此告一段落。系列文章後續會轉向其他平台的版本，屆時再作介紹。

dotnet-testing-agent-orchestration v2.x 雖然已經告一段落，但目前系列文章只介紹到了 Unit Test Orchestrator。Integration Test、Aspire、TUnit 這三種 Orchestrator 還是會繼續介紹完畢，下一篇就從 Integration Test Orchestrator 開始。

參考資源

純粹是在寫興趣的，用寫程式、寫文章來抒解工作壓力

關連網站

mrkt 的程式學習筆記(Blogger)

twMVC

本頁段落

標籤雲

系列文章

最新留言