企業需要能在其自身環境中良好運作的代理程式。這些代理程式所執行的工作，會受到企業所使用的系統、遵循的規則以及資料狀態的影響。一個模型即使能力廣泛，仍可能在特定環境中遇到困難，例如處理不佳的工作流程、誤用工具組合，或未能遵守某項限制。這些都是企業需要改進的弱點。

困難之處在於如何將這些弱點轉化為訓練資料。單一的失敗案例能提供一些資訊，但訓練模型需要大量新的任務，以在不同情境下鍛鍊相同的能力。這些任務還必須能在實際環境中完成、類似於使用者會提出的真實請求，並且具備可靠的方式來驗證代理程式是否成功。

在 ServiceNow CoreAI，我們開發了 AutoSynthData 系統，旨在將這些能力差距轉化為訓練資料。它利用目標模型的失敗案例和更強大「教師模型」的成功經驗，來決定模型接下來應該學習什麼，然後生成並驗證鍛鍊這些能力的新任務。

隨著模型的改進，訓練課程會轉向模型仍然覺得困難的部分。我們將透過 EnterpriseOps Gym (Malay et al., 2026) 和其發布的資料集來闡述這個流程。首先，我們將描述代理程式運作的環境，以及哪些因素能讓任務對訓練有益。

代理程式環境定義了代理程式運作的世界：它能觀察和修改的狀態、能調用的工具和 API，以及其行動所產生的狀態轉換。

任務是在這個環境中實例化的。我們使用以下抽象概念：任務 = (系統規範, 使用者提示詞, 驗證器)。

系統規範定義了代理程式運作的限制，包括系統指令、環境政策，以及在適用情況下，任務特定的初始化，例如預設的資料庫狀態或一系列知識文章。

此規範必須與環境的工具、狀態和支援的行動相容。其指令應清晰明確，並避免僅為製造難度而引入任意限制。

使用者提示詞指定了使用者希望代理程式完成的目標，以及任何使用者層級的限制。生成的任務應滿足三個特性。

可行性：在當前環境中，應至少存在一條能滿足使用者提示詞並同時遵守系統規範的軌跡。這排除了依賴不可用工具、無法存取的知識、不可能的狀態轉換或政策禁止的行動的任務。

真實性：使用者提示詞應類似於使用者在目標環境中可能提出的合理請求。可執行行為的空間通常遠大於真實工作流程的空間。

難度：對於訓練而言，任務應揭示當前代理程式的弱點。已經能可靠解決的任務提供的訓練訊號很少。因此，有用的區域是那些可行且真實，但尚未能持續解決的任務。

驗證器判斷最終的軌跡是否成功完成了任務。它應滿足三個特性。

一致性：它應與使用者提示詞、系統規範和任務特定的環境狀態保持一致。

健全性：它應拒絕未能滿足任務或違反相關限制的軌跡。

完整性：它應接受有效的解決方案，而不是僅編碼特定的參考軌跡。

這些特性在訓練期間直接影響結果。一個寬鬆的驗證器可能會獎勵不正確的行為，而一個過於嚴格的驗證器則可能懲罰有效的解決方案。

在給定環境和目標模型的情況下，AutoSynthData 會生成包含系統規範、使用者提示詞和驗證器的訓練任務。這些生成的任務以環境為基礎，並經過選擇，旨在為當前模型提供有用的訓練訊號。

AutoSynthData 首先使用診斷任務在環境中評估目標模型，並識別其難以完成的任務模式。一個更強大的「教師模型」有助於判斷哪些任務是可解決的，以及成功的行為模式為何。AutoSynthData 將由此產生的能力差距轉化為新的可執行任務，在環境中檢查每個任務，並使用通過驗證的樣本進行後續訓練。評估更新後的模型會揭示哪些差距仍然存在，並能指導下一輪的生成。

AutoSynthData 利用目標環境中的評估運行，來識別模型接下來需要學習什麼。在我們的 EnterpriseOps Gym 實驗中，我們讓目標模型和一個更強大的教師模型都執行評估任務。我們檢查這些運行結果，以識別：正在測試的能力；涉及的工具和工作流程結構；目標模型失敗的地方以及教師模型成功的方式；正確最終狀態必須滿足的屬性；以及在保持測試能力不變的情況下可以變化的維度。

我們將這些發現提煉成經過淨化的「能力規範卡」。評估任務指導模型應該學習什麼，但生成器不會接收其原始提示詞、實體、軌跡或驗證器細節。它會接收這些卡片，並使用它們來創建具有不同提示詞、狀態和解決路徑的新任務。

識別能力差距告訴我們應該教什麼，但訓練需要許多多樣化的任務來鍛鍊這些能力。AutoSynthData 使用規範卡來生成這些任務。

假設目標模型在需要特定工作流程的任務上遇到困難：生成器會創建鍛鍊此工作流程的新任務，並改變實體、初始環境狀態、工作流程組成、工具組合、措辭和難度。然後，更強大的教師模型會為每個任務展示一條成功的軌跡。對於監督式微調 (SFT) 而言，這些示範會教導目標模型如何在新的情境中應用該能力。

AutoSynthData 分兩個階段建立資料集：首先生成並驗證核心樣本，然後將其擴展為新穎的變體。

「目標階段」從能力規範中創建核心訓練樣本集。工作者並行生成獨立任務，完成後會領取一個新目標。每個候選樣本在被接受之前，都會經過驗證、執行、求解器評估和修復。結果是一批經過審查的範例，圍繞著目標模型需要學習的內容而建立。

「倍增階段」透過創建已接受目標樣本的新穎變體來擴展資料集。每個變體都有自己的使用者請求、環境狀態、實體配置、參考軌跡和驗證器，並且必須通過相同的驗證和執行檢查。一個倍增樣本不能再作為另一個倍增樣本的種子。這將擴展錨定在經過審查的目標集上，並限制了跨代之間的漂移。

為了支援這兩個階段，AutoSynthData 將生成控制與環境特定的執行分開。一個共享控制器協調生成、品質控制、覆蓋率和資料集建構，而一個轉接器則處理環境執行、任務和狀態管理、參考重放、確定性驗證、求解器執行和任務分析。

總體而言，並行目標生成和倍增為訓練規模的資料集提供了途徑。它們的實用性取決於對每個候選樣本施加的檢查：任務必須可執行、解決方案必須有效，並且驗證器必須能區分成功與失敗。

僅僅生成一個看似合理的請求並不足以產生有用的訓練資料。任務可能在目標環境中無法執行，其參考解決方案在執行時可能會失敗，或者其驗證器可能會獎勵錯誤的最終狀態。AutoSynthData 在接受任務進行訓練之前，會檢查這些屬性。

AutoSynthData 從兩個層面審查品質：個別候選樣本必須通過驗證，而批次必須提供有用的覆蓋率和多樣性。

每個候選樣本在進入訓練資料集之前，都必須通過品質控制循環。我們首先進行求解器評估以衡量難度。在此處使用的配置中，我們偏好目標模型在三次嘗試中最多解決一次，而更強大的求解器在三次嘗試中至少解決兩次的任務。候選樣本還會經過正向和負向驗證以及有限的修復過程。

正向驗證會問：預期的解決方案是否解決了生成的任務？該流程會在目標環境中執行參考軌跡，並根據候選樣本的驗證器檢查結果狀態。這揭示了提示詞、初始狀態、解決方案和成功標準之間的不匹配。

負向驗證會問：相關的不正確結果是否會失敗？例如，它可以修改預期結果的部分內容，並確認這些狀態不再通過驗證。這可以捕捉到那些在未要求預期行為的情況下就給予成功的弱驗證器。

失敗的候選樣本在被丟棄之前會交由「評論者」審查。評論者會檢查樣本及其失敗原因，尋找不一致的狀態、不可能的工作流程、不正確的任務建構、不良的參考軌跡、薄弱的驗證器邏輯，或與預期能力不符之處。評論者的發現會指導修復，並設有固定的重試次數限制：候選樣本 ↓ 失敗 ↓ 評論/診斷 ↓ 有針對性的修復 ↓ 再次運行驗證關卡 ↓ 接受或重試。

修復後的任務必須再次通過相關檢查。診斷結果會指導對現有候選樣本的修復，而不是要求重新開始生成。

通過這些檢查使樣本符合訓練資格，但個別有效的樣本仍可能形成重複或不平衡的資料集。因此，AutoSynthData 也會在批次層面審查生成結果。

一個批次可能會過度代表少數幾個簡單的任務家族、遺漏某項能力，或者反映出過多的生成精力花費在低產出的模式上。元審查會檢查每個批次中已接受的樣本、被拒絕的樣本以及生成行為。它會詢問：哪些任務家族被過度代表，哪些能力維度缺失？是否重複出現相同類型的範例？是否有特定目標持續生成失敗？評論中是否出現系統性問題？下一批次應該改變哪些指導方針？

控制器會追蹤已接受資料集中的覆蓋率，減少在過度代表區域的生成，並將更多工作導向差距所在。當某個區域重複產生不良候選樣本時，評論和元審查會指導生成策略的改變。這些調整在可用的生成預算和資料集大小要求內，平衡了有用的學習訊號、任務品質、覆蓋率、多樣性和低冗餘。

總之，這些回饋循環同時改進了個別任務及其形成的資料集：樣本層級的檢查指導候選樣本的修復，而批次層級的審查則指導未來的生成。

隨著模型的改進，有用的訓練分佈也會隨之改變。AutoSynthData 將合成資料生成視為在目標模型能力邊界附近尋找任務的過程：這些任務既要足夠困難以揭示弱點，又要足夠可解決，以便教師模型能提供可靠的示範。在後續訓練之後，我們會在相同的環境中評估更新後的模型。模型現在能可靠解決的任務，對於未來的訓練而言，其用處會降低。