您正在為 Caveman Cloud 標籤此儲存庫的 LLM 工作流程。工作流程 是程式碼執行的一項任務 —「回答支援工單」、「建置夜間摘要」、「執行評估套件」— 而不是一種技術。每個網關請求都可以帶有一個工作流程標籤；未標籤的流量都會落入同一個 unlabeled-workflow 桶中。您的工作是：找到工作流程，為它們命名，連接標籤，並驗證一切正常運作。
這會修改程式碼，因此需要經過使用者的正常審查流程：先提出表格，在使用者同意後再套用。 在已標籤的儲存庫上重新執行時，必須不產生任何變更（冪等性）。
此技能由操作者觸發。一個 unlabeled-traffic Cave Plan 觀察僅供審閱，不會建立建議檔案、提案或 Draft PR。請勿推斷遙測選擇了某個呼叫點或授權了編輯。請獨立清查儲存庫，呈現標籤表格，並等待使用者核准後再修改程式碼。
步驟 1 — 清查工作流程
從專案的進入點而非匯入點開始走訪儲存庫：
- 呼叫 LLM（直接或透過多層）的 HTTP/RPC 處理器
- 排程工作：cron 定義、佇列消費者、worker、呼叫 LLM 程式碼的 GitHub Actions
- CLI 命令與腳本（
scripts/、bin/、package.json 腳本） - 消耗真實 token 的評估 / 測試框架
- 框架內的不同代理或鏈（每個 LangGraph 圖表、每個 crew、每個代理定義通常是自己的工作流程）
一個工作流程 = 一個人類會為其命名的工作。同一個請求處理器中的十個呼叫點是一個工作流程；一個由三個工作共用的 llm.ts 輔助程式則是三個工作流程（在呼叫者處標籤，絕不在共用輔助處）。
步驟 2 — 為它們命名
Slug 語法（網關強制執行）：小寫 [a-z0-9_-]，1–96 個字元。命名工作，而非技術：
- 好：
support-reply、nightly-digest、pr-review、eval-suite、onboarding-email - 壞：
openai-calls（技術）、main（未說明）、SupportReply（無效）、johns-test-3（無法長久）
名稱大致是永久的 — 之後重新命名會分割花費歷史紀錄。當工作的目的從程式碼中不明確時，請從檔名推導 slug 並在表格中標記為 review，而不是自行發想目的。
步驟 3 — 提出，然後套用
呈現此表格並詢問是否繼續：
| workflow | job | where | how it gets labeled |
|---|---|---|---|
| support-reply | answers inbound tickets | src/bot/reply.ts:41 | defaultHeaders on the reply client |
| nightly-digest | 02:00 summary job | jobs/digest.ts:12 | header on the digest client |
| eval-suite (review) | scripts/eval.ts:8 — purpose inferred from filename | scripts/eval.ts:8 | env override at invocation |
然後使用該呼叫點可用的最輕量機制連接每個標籤：
- @caveman-ai/sdk / caveman_cloud SDK：每個追蹤的
workflow選項，或單一工作服務建構的客戶端上的defaultWorkflow。 - 原生供應商 SDK（OpenAI/Anthropic/LangChain/LiteLLM/Vercel）：將
"x-cave-workflow": "<slug>"新增到已包含x-cave-api-key的相同defaultHeaders/default_headers/extra_headers區塊。由數個工作共用的客戶端 → 每次呼叫傳遞標頭（上述所有 SDK 都接受每次請求的標頭覆寫），或為每個工作建立自己的精簡客戶端。 - 包裝的編碼代理（
caveman wrap）：在呼叫點（cron 行、CI 步驟）使用--workflow <slug>旗標或CAVE_WORKFLOW=<slug>環境變數。 - 原始 HTTP：將
x-cave-workflow標頭新增到請求中。
在呼叫者處標籤，保持差異最小化，並符合儲存庫的風格。如果某個呼叫點完全沒有通過 Caveman 網關路由，請不要為其標籤 — 在報告中將其列於「未連接」下（標籤僅透過網關流量傳遞；連接是 caveman-setup 技能的職責）。
步驟 4 — 驗證
執行儲存庫已使用來演練一個標籤路徑的任何項目（測試、開發腳本、一個 curl）。然後確認：請求仍然成功（網關會拒絕無效標籤並出現 400 cave_invalid_request_header — 如有必要請修正 slug）。標籤的花費會顯示在儀表板的 /activity?tab=workflows，作為每個工作流程下次執行時出現；排程工作則會在排程觸發時顯示，這點值得在報告中說明，而不是假裝它們已即時。
步驟 5 — 報告
## Workflows labeled
| workflow | job | where |
|---|---|---|
| support-reply | answers inbound tickets | src/bot/reply.ts:41 |
| nightly-digest | 02:00 summary job | jobs/digest.ts:12 |
Verified: <the labeled path you actually exercised, and what you observed>
Lands at: <DASHBOARD>/activity?tab=workflows — each row appears as that workflow
next runs. Anything still unlabeled shows as `unlabeled-workflow`.
Not wired (no gateway routing, so no label): <list or "none">
Marked review: <slugs whose purpose was inferred from filenames, or "none">
如果您完全找不到任何 LLM 進入點：請確切說明，並指向設定技能（<docs origin>/docs/agent-setup.md），而不是憑空製造表格。