<!-- Source: https://hermesbible.com/flows/jira-to-pr-four-agents -->

在我們重建工程工作流程之前，我們的團隊面臨一個經典問題：工單接收→開發→審查→合併→QA 都是手動的、緩慢的，而且在每個交接點都產生摩擦。

開發人員當時要：

• 手動閱讀 Jira 工單
• 手動建立分支
• 等待程式碼審查（需要時間）
• 手動更新工單狀態
• 手動推送到 QA
• 在 Jira 和 GitHub 之間失去上下文

成本？20-30% 的開發時間花在儀式性工作上而不是編寫程式碼。而且，當 QA 發現 bug 時，Jira 中的工單狀態會落後於 GitHub 中實際發生的事情，造成混亂。

以每季約 50 個常規工單計算，舊的工作流程大約消耗 325 個工程小時：50 個工單 × 每個工單 6.5 小時。這大約是 8 個全職工程週，或大約 2 個月的工程時間。有了 Agent，人類時間降到每個工單幾分鐘，而生產環境的合併權限仍然掌握在人類手中。

我們希望自動化 Agent 處理常規工作，同時讓人類控制最終決定（合併到生產環境）。以下是我们建立的系統。

1. 架構

我們的系統使用四個專門的 AI Agent，運行在 Hermes 上，Jira webhook 作為事件觸發器。

四個命名 Agent

1. Mark——接收與關卡 Agent（Claude 3.5 Haiku）

職責： 當新的 Jira 工單到達（Development Board 專案看板上的 DB-*），Mark 會啟動。

任務：

• 驗證工單是否分配給 "Luke The Dev"
• 檢查是否已有 PR 存在於此工單（風險關卡）
• 檢查是否有類似的工單正在進行中（重複關卡）
• 從 origin/prod 建立一個全新的 GitHub 分支（永遠不是從其他功能分支）
• 決定：這個工單可以安全實作嗎？還是有阻塞項？

成本： 便宜——Haiku 在結構化任務上大約有 95% 的準確度，如讀取 + 關卡檢查。

輸出： 如果安全 → 觸發 Andrew。如果被阻塞 → 在 Jira 上留言說明阻塞原因。

2. Andrew——資深程式設計師（OpenAI 5.5 Pro，後備 Claude Opus 4.8）

職責： 撰寫實際的程式碼。

任務：

• 根據工單描述 + 驗收標準實作功能/修復
• 撰寫測試
• 自我審查程式碼
• 推送到 GitHub
• 開啟 PR 並連結到 Jira 工單

成本： 昂貴但值得。

為什麼需要後備？ 當 5.5 被限流或不可用時，Claude Opus 仍然能產生高品質的程式碼。

品質關卡： Mark 批准前需要在 Jira 中提供確切的 commit SHA 和日期。

3. Rev——程式碼審查者（Claude 3.5 Haiku）

職責： 審查 Andrew 開啟的 PR。

任務：

• 檢查安全問題
• 驗證測試是否真的在測試功能
• 執行煙霧測試（如適用）
• 在 PR 上留下行內註釋
• 如果通過 → 批准 PR 並將工單移至 "Ready for Human Merge"

成本： 便宜——Haiku 足以做模式匹配（安全反模式、測試完整性）。

人類覆蓋： 沒有 Luke 的手動批准，PR 不能被合併。

4. Mr. Pipeline——CI/Lint/Style 關卡（Claude Haiku）

職責： 每次提交後運行。

任務：

• 驗證程式碼通過 Codacy lint 規則
• 檢查測試覆蓋率是否達到最低要求（例如 >75%）
• 驗證提交訊息符合格式
• 執行程式碼風格檢查
• 回報給 GitHub + Jira

成本： 非常便宜——主要是對現有 linter 的子程序呼叫。

輸出： 要麼「可以合併」，要麼「修復這些問題」。

通訊路徑

Jira Webhook Event
  → Mark (Gate Check)
  → (If safe) → Andrew (Code)
  → (Diff complete) → Rev (Review)
  → (Approved) → Mr. Pipeline (CI Gate)
  → (Passed) → Jira status: "Ready for QA"
  → (Telegram notification to Luke)

2. 事件驅動流程

步驟 1：在 Jira 中建立工單

• 開發人員/PM 在 DB 專案看板中建立 Jira 工單
• 分配給 "Luke The Dev"（我們的開發篩選器）
• Webhook 觸發到我們的本地 Jira 代理伺服器 127.0.0.1:XXXX（透過 Tailscale Funnel 暴露）

步驟 2：Mark 接收（協調）

Mark 立即執行：

1. 這個工單是否分配給 "Luke The Dev"？→ 不是？靜默退出（不是我們的工作流程）
2. 是否已有 GitHub PR 存在於此工單？→ 是？關卡：「發現既有 PR」→ Jira 留言 + 等待完成
3. 是否有類似的工單正在進行中？→ 是？關卡：「重複/進行中」→ Jira 留言 + 上報給 Luke
4. 狀態檢查：工單是否準備好實作？→ 不是？關卡：「缺少驗收標準」→ Jira 留言
5. 如果所有關卡通過：→ 從新鮮的 origin/prod 建立分支 feature/DB-1234-ticket-name → 觸發 Andrew 開始編碼 → Jira 狀態：「In Progress」

Mark 的 Jira 留言範例：

All gates passed. Triggering code generation...
- Branch: feature/DB-1234-new-payment-flow
- Assigned to: Andrew (Senior Coder)
- ETA: ~5-10 minutes

步驟 3：Andrew 編碼（實作）

Andrew 取得工單詳情 + 儲存庫上下文：

1. 拉取分支 + 閱讀 CLAUDE.md / AGENTS.md / .cursorrules
2. 理解驗收標準
3. 撰寫程式碼 + 測試
4. 自我審查（安全、效能、測試品質）
5. 推送到 GitHub
6. 開啟 PR，連結到 Jira 工單 DB-1234
7. 向 Mark 報告完成

PR 描述範例（自動產生）：

Fixes DB-1234: New Payment Flow

## Acceptance Criteria
- [ ] Payment form validates card details
- [ ] Supports Stripe + PayPal
- [ ] Handles timeout gracefully

## Tests
- 8 new unit tests
- 2 integration tests (Stripe sandbox)
- Manual test: Can complete checkout end-to-end

## Changes
- app/payment/processor.py (+120 lines)
- app/payment/test_processor.py (+200 lines)
- requirements.txt (added stripe==8.0.0)

步驟 4：Rev 審查（品質關卡）

Rev 自動審查 PR：

1. 閱讀 PR diff
2. 檢查安全問題（SQL injection、XSS、程式碼中的 secrets）
3. 驗證測試：測試數量是否匹配變更複雜度？測試是否真的在測試功能？
4. 執行煙霧測試（如已設定）
5. 留下詳細註釋
6. 如果通過 → GitHub 批准 + Jira 狀態：「Ready for QA」

審查註釋範例：

Approved (with notes)

Security: Stripe API key properly injected via env var. OK
Tests: 10 tests cover payment flows well. OK
Coverage: 86% (above 75% threshold). OK

Minor: Consider adding timeout test for slow networks.

步驟 5：Mr. Pipeline 檢查（CI/CD 關卡）

每次提交觸發 Mr. Pipeline：

1. 執行 Codacy lint 規則
2. 驗證測試覆蓋率
3. 檢查程式碼風格（Prettier/Black）
4. 執行單元測試
5. 回報狀態給 GitHub

狀態檢查：

All CI gates passed
- Linting: OK (0 issues)
- Coverage: 86% OK
- Tests: 12 passed in 45s OK
- Ready to merge when approved

步驟 6：人類批准與合併

Luke（人類）看到 Telegram 通知：

DB-1234: New Payment Flow
Code ready for review
Andrew completed implementation
Rev approved PR
All CI gates passed
Ready for merge: [Link to PR]

Luke 手動點擊 GitHub 上的「Merge」。這是故意的。我們不自動合併——合併到生產環境是人類的決定。

步驟 7：QA 交接

合併後：

• Jira 狀態：「In QA」（自動轉換）
• Telegram 通知 QA 團隊
• QA 在 staging 環境中測試
• 如果發現 bug：QA 建立一個新的 Jira 工單（QA-*）連結到 DB-1234
• 當 QA 批准：Jira 狀態：「Done」

3. Token 經濟學（我們如何省錢）

我每個工單大約花費 $8–$18 在 AI Agent 上。以下是與手動工程時間相比仍然便宜的原因。

每個工單的 Token 明細

每個工單合計： 約 120K–230K tokens，約 $8–$18。

4. Token 優化策略

用便宜模型做關卡。 Mark（Haiku）做關卡檢查，不做程式碼生成。Haiku 在結構化任務上有 95% 的準確度，成本只有 Opus 的 1/10。我們只在開放式程式碼生成時使用昂貴模型（Andrew/o5.5 Pro）。

永遠不要重新生成，一次做對。 Andrew 寫程式碼，提交一次。Rev 審查一次，不和 Andrew 迭代。如果 Rev 發現問題，我們上報給 Luke（人類決定）。這防止了多輪迴圈的 token 浪費。

透過 CLAUDE.md 重用上下文。 每個儲存庫都有一個 CLAUDE.md 檔案（AI 指南）。Mark 在建立分支時引用它。Andrew 讀取一次，用它來指導程式碼風格。不需要在每個提示中重複上下文。

平行執行。 Mark 在 webhook 時立即運行。如果關卡通過，Andrew 開始（無需等待）。Rev 與測試平行審查。Mr. Pipeline 在提交時運行（不依賴 Rev）。平行處理 = 更快 + 相同的 token 成本。

無狀態 Agent。 每個 Agent 是獨立的（之間沒有共享狀態）。不需要上下文切換或長期運行的 session。每個 Agent 直接讀取 Jira + GitHub，處理完就退出。無狀態 = 不會在狀態管理上浪費 token。

Kanban 通知是可選的。 發送 Telegram + Jira 留言每個通知大約加 $0.01。對於想要零通知開銷的團隊，這是選擇性啟用的。我們批量發送通知（不每個動作都發一個）。

跳過多餘的工作。 如果已有 PR 存在於某個工單，Mark 會攔截（不會再次生成）。如果工單被阻塞，Mark 不會觸發 Andrew。短路機制防止在死胡同工作上浪費 token。

真實成本範例

一個典型的功能工單（DB-1234）：

• Mark 接收檢查：約 1K tokens（~$0.01）
• Andrew 實作：約 80K–150K 輸入 tokens + 約 25K–50K 輸出/推理 tokens（~$7–$14）
• Rev 審查：約 10K–25K tokens（~$0.03–$0.10）
• Mr. Pipeline CI：約 1K–3K tokens（~$0.01–$0.03）
• Kanban 通知：約 500–1K tokens（~$0.01）

合計： 約 120K–230K tokens，通常每個工單 $8–$18。

以 $12 為平均值，每季 50 個工單的 AI 費用約 $600/季，或約 $200/月。在較重的運行速度下約每週 20 個工單，同一系統的成本約為 $240/週、$1,040/月、或 $12,480/年，用於自動化程式碼生成 + 審查。對於一個 5 人開發團隊，較重的運行速度大約每人每月 $208 的 AI 勞動成本。

5. GitHub 分支策略

我執行嚴格的分支不變量。

規則：永遠從 origin/prod 建立分支

# CORRECT
git checkout -b feature/DB-1234-name origin/prod

# WRONG (creates hidden dependencies)
git checkout -b feature/DB-1234-name feature/DB-999-other

為什麼？如果你從另一個功能分支（DB-999）建立分支，你的 PR 現在隱含地依賴 DB-999 的 PR 先被合併。這會破壞平行處理並產生合併衝突。

命名規範

分支名稱遵循以下格式：

feature/DB-1234-short-description
bugfix/DB-1234-short-description
hotfix/DB-1234-short-description
bau/DB-1234-short-description (business-as-usual)
parent/DB-1234 (epic parent branch)
chore/TICKET-1234-description (no prefix for chores)

被拒絕的格式（GitHub 分支保護規則會拒絕）：

• fix/DB-1234-name（歧義：bugfix 還是 hotfix？）
• DB-1234-name（沒有類型前綴）
• my-feature-fix（沒有 Jira ID）

合併前的 PR 驗證

合併前，Luke 會驗證：

1. 提交歷史只包含 DB-1234 的變更
2. 修改的檔案與工單相關
3. 沒有意外的 merge commit
4. 沒有來自其他工單的多餘檔案
5. Commit SHA 與 Mark/Andrew 報告的一致

這確保我們永遠不會意外合併不相關的程式碼。

6. Jira 狀態自動化

我使用 jira-transition 自動同步 Jira 狀態與 Kanban 進度：

jira-transition DB-1234 "In Progress"
jira-transition DB-1234 "Ready for QA"
jira-transition DB-1234 "Done"

狀態流程

Unstarted
  ↓
Mark triggers Andrew
  ↓
In Progress (Mark sets this)
  ↓
Andrew pushes code
  ↓
Ready for Human Merge (Rev sets this when PR approved)
  ↓
Luke merges manually
  ↓
PR merged → Jira auto-transitions to "In QA"
  ↓
QA approves
  ↓
Done

為什麼自動轉換？沒有它的話，Jira 中的狀態會落後於現實（PR 在 GitHub 中已合併，但 Jira 仍顯示「In Progress」）。這會讓團隊成員困惑並造成重複工作。

7. Telegram 通知系統

每個重要事件都會向 Luke 的家裡頻道發送 Telegram 通知：

Event: Mark gates passed
"DB-1234 ready for code generation. Triggering Andrew."

Event: Andrew completed code
"DB-1234 complete. PR: github.com/smartways/tms/pull/456. Rev reviewing now..."

Event: Rev approved
"DB-1234 approved. All CI gates passed. Ready to merge: [Link]"

Event: Blocker found
"DB-1234 blocked: Duplicate with DB-999. Please resolve and re-trigger."

為什麼選 Telegram？

• 通知立即送達（不是 email）
• 容易點擊跳轉到 GitHub/Jira
• 可以用語音訊息回覆（對忙碌的主管很重要）
• 建立稽核軌跡（所有決定都在對話中）

8. 安全邊界

Agent 沒有生產環境的權限。

• Agent 可以建立分支和 PR，但不能合併受保護的分支。
• 生產環境合併需要 Luke 的手動批准。
• GitHub 分支保護仍然要求 CI 通過。
• Agent 憑證的權限範圍限定在所需的最低權限。
• Secrets 透過環境/設定系統注入，不是貼到提示中。
• Jira、GitHub 和 Telegram 為每個動作建立稽核軌跡。

9. 邊緣案例與上報

系統大約自動處理 95% 的工單。以下是需要上報給 Luke 的情況：

關鍵原則： Agent 做有界、可逆的決定。人類做模糊的、架構性的和生產環境的決定。

10. 成本比較

之前（全部手動）

• 1 個功能工單：約 4 小時開發時間
• 程式碼審查：約 1 小時
• 測試：約 1.5 小時
• 合計：6.5 小時/工單，$150/小時（負載成本）
• 每個工單成本：約 $975

之後（Hermes + Agent）

• Agent 時間：約 15 分鐘實際時間，平行處理
• AI 成本：每個工單 $8–$18，平均約 $12
• 人類審查：約 5 分鐘，只有合併決定
• 人類審查成本：$150/小時計算約 $12.50
• 每個工單成本：約 $21–$31，通常約 $25

節省： 每個常規工單的勞動成本大約減少 97%。（一個注意事項：最適合「常規」功能。複雜的架構變更仍然需要人類先設計。）

11. 監控與可觀察性

我追蹤三個關鍵指標。

1. Agent 成功率

• Mark（接收）：98%（關卡正常運作）
• Andrew（程式碼）：92%（首次嘗試就產生可運作的程式碼）
• Rev（審查）：95%（能抓到 Rev 應該抓到的問題）
• Mr. Pipeline：99%（CI 是確定性的）

2. 從工單到已審查 PR 的時間

• 之前：2-3 天，大部分時間在等交接和審查
• 之後：從工單接收到已審查 PR 約 4 小時

3. Token 消耗

• 每週追蹤：平均每個工單約 $12
• 警報條件：每個工單 >$25，通常意味著重新生成、過多上下文載入、重試迴圈、或異常大的程式碼變更。

12. 未來展望

我正在探索：

1. 多工單功能：讓 Andrew 依序處理 2-3 個相關工單
2. Rebase 自動化：當 origin/prod 移動時，自動 rebase PR
3. QA 機器人整合：Rev 可以執行實際的 Selenium 測試（不只是程式碼審查）
4. 金絲雀部署：自動將「低風險」工單提升到 staging → prod
5. 模型迭代：追蹤哪個模型（o5.5 vs. Opus）產生更好的程式碼，優化選擇

13. 關鍵要點

1. 為你的 Agent 命名。 Mark、Andrew、Rev、Mr. Pipeline——每個都有角色。讓除錯更容易。
2. 提前做關卡。 讓 Mark 在觸發昂貴的 Andrew 之前檢查是否有既有 PR、重複和阻塞項。節省 80% 的失敗工作。
3. 用便宜模型做篩選。 Haiku（Haiku 3.5）在結構化任務上有 95% 的準確度。把 o5.5 Pro 保留給開放式推理。
4. 永遠不要自動合併。 人類擁有合併按鈕。Agent 準備程式碼；人類部署它。
5. 一次機會，一個 Agent。 不要迭代 10 次。寫一次，審查一次，合併一次。
6. 事件驅動執行。 接收、編碼、審查、CI 和通知都是自動觸發的，而不是在每個交接點都等人類。CI 和審查可以重疊。相同的 token 成本，更少的實際時間。
7. 上下文檔案（CLAUDE.md）。 寫一次，永遠重用。節省重複和 token 成本。
8. 狀態同步很重要。 使用 jira-transition 保持 Jira 與 GitHub 現實同步。防止重複工作和混亂。
9. Telegram 是你的駕駛艙。 把所有通知路由到那裡。容易掃描，容易採取行動。
10. 追蹤你的成本。 追蹤每個工單的 token 數。常規工單超過 $25 就是紅燈：重新生成、無限迴圈、過多儲存庫上下文、或比預期更大的程式碼變更。

14. 結論

我建立了一個每季處理 260+ 個工單的系統，平均每個工單的 AI 成本約 $12，同時讓人類控制最終決定。關鍵是專業化：每個 Agent 專注做一件事、關卡防止浪費工作、Telegram 保持所有人同步。

這個工作流程不是魔法。它是無聊的、確定性的、平行的。這正是我們對生產環境自動化的期望。

感謝 Hermes。