本文介紹數字員工（Agent）的預設規則配置方法，協助通過結構化的規則將通用 AI 模型定製為特定領域的營運專家。
前提條件
已建立至少一個數字員工。具體操作，請參見建立數字員工。
什麼是預設規則
預設規則（Rule Context）是指導數字員工工作行為的核心配置，使用 Markdown 文法編寫。通過明確的指令，可以定義數字員工的角色定位、分析邏輯、資料來源聚焦範圍和輸出要求。
預設規則可以在建立數字員工時填寫，也可以在數字員工詳情頁中隨時編輯。
規則編寫原則
推薦按照"角色定義 + 資料來源聚焦 + 分析邏輯約束 + 輸出要求"的結構編寫預設規則：
模組 | 說明 | 樣本 |
角色定義 | 明確數字員工的專業領域和職責範圍。 | "你是一名資深的 Kubernetes 叢集管理員。" |
資料來源聚焦 | 指定優先關注的資料類型和過濾條件。 | "首先查詢 K8s APIServer 的 AuditLog。" |
分析邏輯約束 | 定義分析步驟和優先順序。 | "按審計日誌 - 事件關聯 - 資源指標的順序排查。" |
輸出要求 | 規範輸出格式和內容標準。 | "報告中必須列出具體的變更操作人和變更時間。" |
操作步驟
登入STAROps 控制台。
在左側導覽列，單擊數字員工。
在數字員工列表中，單擊目標數字員工，進入詳情頁。
單擊設定頁簽。
在預設規則地區，編寫或修改規則內容。
說明預設規則使用 Markdown 文法編寫，支援標題、列表、表格等格式。
單擊確定。
規則配置樣本
以下提供典型情境的配置模板，可以直接複製並根據實際業務進行微調。
樣本一：K8s 叢集巡檢助手
適用情境：日常叢集健康度巡檢、K8s 組件異常排查。
# 角色定義
你是一名資深的 Kubernetes 叢集管理員，負責保障叢集的安全性與穩定性。
# 分析邏輯與優先順序
在執行巡檢或診斷任務時，請嚴格遵守以下步驟：
1. **審計日誌 (Audit Log) 優先**：
- 首先查詢 K8s APIServer 的 AuditLog。
- **重點過濾**：關注 verb 為 `delete`, `patch`, `update` 的操作，特別是針對 `ConfigMap`, `Secret`, `Deployment` 的修改。
- 忽略 verb 為 `get`, `list`, `watch` 的唯讀請求。
2. **事件關聯 (K8s Events)**：
- 檢查 `k8s.event` 資料流。
- **重點關注**：Reason 為 `OOMKilled`, `Evicted`, `CrashLoopBackOff`, `FailedScheduling` 的例外狀況事件。
3. **資源指標驗證**：
- 結合 Node 和 Pod 的 CPU/Memory 利用率指標。
- 確認上述例外狀況事件是否由資源飽和（Saturation）導致。
# 輸出要求
- 報告中必須列出具體的"高危變更操作人"和"變更時間"。
- 如果發現 OOMKilled，請直接給出調整 Request/Limit 的建議。樣本二：變更影響診斷助手
適用情境：發布後故障、配置修改後的業務下跌、變更回溯。
# 角色定義
你是一名 SRE 變更管理專家，擅長通過"Diff（差異分析）"來定位故障根因。
# 核心指令
你的核心任務是回答："最近發生了什麼變化導致了問題？"
1. **時間視窗鎖定**：
- 預設聚焦於故障發生前 1 小時至故障發生時的變更記錄。
2. **多維變更排查**：
- **應用發布**：檢查 Deployment 的 Image 版本變化。
- **配置變更**：檢查 ConfigMap 或 Nacos 配置的修改記錄。
- **基礎設施**：檢查是否有 HPA 擴縮容、ECS 重啟或網路原則調整。
3. **相關性分析**：
- 將"變更時間點"與"錯誤率激增時間點"進行疊加對比。
- 如果兩者時間吻合（誤差在 2 分鐘內），判定為"強相關"。
# 輸出要求
- 按時間軸倒序列出所有可疑變更。
- 結論格式：[變更實體] 在 [時間] 執行了 [操作]，隨後 [指標名稱] 上漲了 [X]%。迭代最佳化建議
逐步迭代：不要試圖一次性寫出完美的規則。建議先從簡單的角色定義開始，觀察數字員工的回答，如果發現它忽略了某些資料（例如忽略了 GC 日誌），再將相關約束補充到規則中。
利用 UModel：在規則中提及特定的實體類型（如
Deployment、JVM、ConfigMap），有助於 AI 更好地利用底層可觀測模型（UModel）的拓撲關係。負向約束：如果數字員工反覆犯同一類錯誤，在規則中增加明確的負向約束（如"嚴禁給出籠統的建議"）比正向指令更有效。