Claude Code 上的 Agent Orchestration — AI 自動產生高品質 .NET 測試（1） | mrkt的程式學習筆記 - 點部落

2026-05-30

Claude Code 上的 Agent Orchestration — AI 自動產生高品質 .NET 測試（1）

37
0
dotnet-testing-agent-orchestration-claude
2026-05-31

為 .NET 專案自動產生高品質測試 — dotnet-testing-agent-orchestration-claude

在 Claude Code 上用 Agent Orchestration 為 .NET 專案自動產生測試：1 個 Orchestrator 加 4 個 Subagent，把分析、撰寫、執行、審查串成一條流程。這篇先說明整體架構、四個 Orchestrator 的分工，以及底層那 29 個測試知識 Skill 的來源。

前言

寫測試大家都知道重要，但實際動手時常常卡在一些瑣碎的地方：這個類別有外部依賴，Mock 要怎麼設定？這個模型有循環參考，AutoFixture 要怎麼配置才不會出問題？這個服務依賴系統時間，要怎麼凍結時間來測？整合測試要起容器，Testcontainers 跟 Respawn 怎麼搭？每一個單獨看都不難，但加起來就成了一道一道的門檻。

這個系列要介紹的，是我整理的一套跑在 Claude Code 上的方案：用 Agent Orchestration（多個 AI 代理分工協作）為 .NET 專案產生測試。你下一句「為 OrderService 撰寫單元測試」，它就會自動分析類別、決定要用哪些測試技術、撰寫測試、執行驗證，最後再審查一次品質。

補充一點背景：這個 Claude Code 版本，是從我先前做的 GitHub Copilot 版本 dotnet-testing-agent-orchestration 移植過來的。核心的 orchestration 構想一樣 — 一個指揮者統籌、底下四個角色分工 — 只是換成 Claude Code 的 Skill 與 Subagent 機制重新實作。

dotnet-testing-agent-orchestration (copilot 版)

dotnet-testing Agent Orchestration for Claude Code

提供完整的 Claude Code Subagents .NET 測試工作流程，透過 Agent Orchestration 自動化完成四種測試類型的完整流程（Analyzer → Writer → Executor → Reviewer）。

這套方案是什麼

核心是 Agent Orchestration — 不是單一個 AI 一股腦把測試寫出來，而是讓多個專職的 AI 代理分工協作。

具體來說是 1 + 4 的架構：一個 Orchestrator（指揮者）統籌全局，底下有四個 Subagent（執行者）各司其職：

Analyzer：分析被測類別 — 它有哪些依賴？是服務、驗證器還是遺留程式碼？需要哪些測試技術？
Writer：根據分析結果撰寫測試 — 按需載入對應的測試技術知識，產出符合最佳實踐的測試程式碼
Executor：建置並執行測試 — 跑 dotnet build 與 dotnet test，遇到錯誤自動修正
Reviewer：審查測試品質 — 命名規範、斷言品質、覆蓋完整性，產出評分與改善建議

這四個代理依序跑完，就是一次完整的「分析 → 撰寫 → 執行 → 審查」流程。整個過程你只需要下一句指令，剩下的全自動。

為什麼要這樣分工，而不是讓一個 AI 全包？因為測試這件事牽涉的知識面很廣 — 從 Mock 框架、測試資料產生、時間抽象，到整合測試的容器管理。如果全塞給一個 AI，它的 context 會被各種知識和中間結果塞爆，品質反而下降。分工之後，每個 Subagent 只專注自己那塊，context 保持精簡，產出品質更穩定。

整體架構

整體來看，這套方案分成三層：

4 個 Orchestrator Skill（.claude/skills/）
   ├── dotnet-testing-orchestrator-unit
   ├── dotnet-testing-orchestrator-integration
   ├── dotnet-testing-orchestrator-aspire
   └── dotnet-testing-orchestrator-tunit
        │ 委派
        ↓
16 個 Subagent（.claude/agents/，4 組 × 4 個）
   每組：Analyzer / Writer / Executor / Reviewer
        │ 按需載入
        ↓
29 個 Agent Skills（.claude/skills/，由 dotnet-testing-agent-skills 提供）＋ dotnet-test
   autofixture / nsubstitute / awesomeassertions / testcontainers ...
   dotnet-test（repo 內建，Executor 用來建置與執行測試）

最上層是四個 Orchestrator Skill，對應四種測試領域（單元、整合、Aspire、TUnit）。中間是 16 個 Subagent，四個領域各有自己的一組 Analyzer / Writer / Executor / Reviewer。最下層是 Subagent 會用到的 Skill：29 個封裝 .NET 測試技術知識的 Agent Skills（由 dotnet-testing-agent-skills 提供），加上 Executor 用來建置與執行測試的 dotnet-test。連同最上層的 4 個 Orchestrator Skill，整套方案在 .claude/skills/ 下一共有 34 個 Skill。

實際運作起來是這樣：

你下一句斜線指令，Orchestrator 就接手後面所有事 — 依序委派四個 Subagent，Analyzer、Writer、Reviewer 各自按需去載入需要的測試技術知識，Executor 負責實際跑建置與測試。至於這套架構為什麼長這樣（例如 Orchestrator 為什麼是 Skill 而不是 Agent），下一篇會專門深入。

它能做什麼

前面架構圖最上層的四個 Orchestrator，涵蓋了 .NET 開發中最常見的測試場景：

Unit Test Orchestrator — 單元測試。處理純函式、有 Mock 依賴的服務、FluentValidation 驗證器、含時間或檔案系統抽象的類別。技術棧涵蓋 xUnit、NSubstitute、AutoFixture、Bogus、FakeTimeProvider、MockFileSystem、AwesomeAssertions。這是最常用、也最適合入門的一個。

Integration Test Orchestrator — 整合測試。為 ASP.NET Core WebAPI 產生端對端的整合測試，用 WebApplicationFactory + Testcontainers + Respawn，支援 InMemory、PostgreSQL、SQL Server、MongoDB、Redis 五種資料層。

Aspire Testing Orchestrator — .NET Aspire 分散式應用的整合測試。用 DistributedApplicationTestingBuilder 啟動整個分散式環境，由 Aspire 自動編排所有容器。

TUnit Testing Orchestrator — TUnit 框架的測試。TUnit 是基於 Source Generator 的新世代測試框架，跟 xUnit 有根本差異。這個 Orchestrator 既能新建 TUnit 測試，也能把現有的 xUnit 測試遷移過來。

四個 Orchestrator 看起來各自獨立，但骨架完全一樣：同樣的 1 + 4 架構、同樣的四階段流程，差別只在各自處理的測試領域。換句話說，架構是共用的模板，真正不同的是填進去的領域知識。

它的知識從哪裡來

架構圖最下層那 29 個 Agent Skills，是這套方案很重要的一個基礎 — 它們來自 dotnet-testing-agent-skills，一份開源的 .NET 測試知識庫。

每一個 Skill 封裝了一項測試技術的實務做法：NSubstitute 怎麼搭配 Returns 與 Received、AutoFixture 的 Customization 怎麼寫、整合測試的 DbContext 衝突怎麼處理、TUnit 跟 xUnit 的語法對照……這些知識原本散在文件、部落格和開發經驗裡，我把它們整理成 AI 可以直接讀取、套用的形式。

當 Writer 要撰寫測試時，它不是憑空生成，而是先讓 Analyzer 判斷需要哪些技術，再按需載入對應的 Skills，照著裡面的規範來寫。所以產出的測試不只是「能跑」，而是符合這套知識庫定義的品質標準 — 中文三段式命名、AwesomeAssertions 斷言、AAA Pattern、對稱的驗證覆蓋。

也因為知識封裝在平台無關的 Skills 裡，前面提到的 GitHub Copilot 版本與這個 Claude Code 版本，底層共用的是同一份知識庫。本系列專注在 Claude Code 版本，不依賴對其他平台的了解 — 你完全可以把這裡當作起點。

dotnet-testing-agent-skills
dotnet-test

這個系列會怎麼走

整個系列規劃五篇，由淺入深：

這一篇（總覽）帶你看懂整套方案 — 它是什麼、整體架構長什麼樣、能做什麼、知識從哪來。

第二篇（架構解析）深入設計細節 — 為什麼 Orchestrator 在 Claude Code 上必須是 Skill 而非 Agent、bypassPermissions 與計時 Hook 的設計、Writer 分割策略、JSON 交接機制，以及四組 Orchestrator 的對比。

第三篇（安裝 + Unit Test）進入實作 — 從環境需求、安裝步驟，到 Unit Test Orchestrator 的七種使用情境與練習專案。讀完這篇你就能跑出第一個工作流程。

第四篇（三個進階 Orchestrator）介紹 Integration、Aspire、TUnit — 它們各自是哪一種測試：WebAPI 的端對端整合測試、Aspire 分散式應用的整合測試、TUnit 框架版的工作流程，以及各自最該留意的地方。

第五篇（**幕後：量化優化**）回到這些 Orchestrator 背後的 agent 定義 — 它們本質上是一大包 prompt。這一篇講怎麼用 autoresearch 把「改 prompt 的好壞」變成一個可量測的數字，跑「改一處 → 量分數 → 進步就留、退步就退回」的迴圈，一步步把定義調到位。

小結

這套方案把 .NET 測試的領域知識封裝成 29 個 Agent Skills，再用 1 + 4 的 Agent Orchestration 架構去調度，下一句指令就能跑完「分析 → 撰寫 → 執行 → 審查」一整輪。

這一篇我們看了整套方案的全貌 — 三層架構、四個 Orchestrator、底層的知識庫。但還沒回答一個關鍵問題：這套架構在 Claude Code 上為什麼要這樣設計？下一篇就從最根本的一個設計決策講起 — 為什麼 Orchestrator 必須是 Skill，而不是 Agent。

參考資源

dotnet-testing-agent-orchestration（Claude Code 版）：https://github.com/kevintsengtw/dotnet-testing-agent-orchestration-claude
dotnet-testing-agent-orchestration（GitHub Copilot 版，本方案的前身）：https://github.com/kevintsengtw/dotnet-testing-agent-orchestration
dotnet-testing-agent-skills：https://github.com/kevintsengtw/dotnet-testing-agent-skills
Claude Code 官方文件：https://docs.claude.com/en/docs/claude-code/overview

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

回首頁

mrkt的程式學習筆記

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