！ 本篇文章將會介紹 高手玩法：多 Agent 平行寫作，期望大家都能用一支 Agent 軍團，辦出一份有主編拍板的報紙 :D

昨天把全組煞車裝好，結尾承諾「明天開始放心踩油門」。踩油門的方式很多，本系列選的是加掛引擎。還記得 D06 埋的那張支票嗎？「多 agent 平行寫作、互評、主編彙整，第 28 天再來玩真的」——今天兌現。

先老實交代現況：本系列每晚的生成管線（generate.sh）是道地的單人作業，一次 opencode run 從讀規則寫到完稿，穩定但每次只有一種想法。真正的一人編輯部應該長這樣：三個記者各寫各的稿、寫完互相審稿、最後一個主編拍板定稿。今天就是把這間編輯部架起來的過程。

本篇目標

讀完這篇你會學到：

• 編輯部架構的分工：記者（平行生成）、審稿（互評）、主編（彙整），誰該做什麼、誰不該碰什麼
• 平行任務不互踩的檔案介面設計：一人一格草稿路徑，主編只讀結論不讀全文
• 把 generate.sh 既有的品質守衛變成主編的驗收清單——再花哨的玩法，也要過同一套關卡

環境準備

不用裝任何新東西，全是 D06 學過的 subagent 技巧加既有檔案：

$ cd /Users/benben/ai/automations/ironman
$ ls prompts/ templates/            # 編輯部的「校規」與「版型」
$ ls .opencode/agents/ 2>/dev/null  # 自訂 agent 放這裡（D06 的 fact-checker 就住這）
$ mkdir -p state/drafts             # 編輯部工作台：一人一格的草稿架

主要內容

步驟一：三個記者——同一個題目，三路平行開稿

在 TUI 對話裡，把幾個互不依賴的任務寫進同一則訊息，主 agent 就會在同一回合發出多個 Task 呼叫（D06 的平行作戰），三路同時開工，總耗時取決於最慢那一路，而不是三段加總。但平行寫作比平行偵察多一條鐵律：輸出路徑要先分好。

請同時派出三個 general subagent 寫鐵人賽 d28 草稿，全部完成後再回報：
1. 記者 A：角度＝「辦報紙」的組織比喻，草稿寫到 state/drafts/d28-a.md
2. 記者 B：角度＝效能實測的數據控，草稿寫到 state/drafts/d28-b.md
3. 記者 C：角度＝最小可行的 Step by Step，草稿寫到 state/drafts/d28-c.md
三人都必須先讀 prompts/generate.md 與 templates/article-template.md；
寫完只回報「中文字數 + 三句話摘要」，不要把全文貼回來。

「不要把全文貼回來」是 context 經濟學：三篇兩千字草稿全灌回主對話，主編還沒上班，辦公室已經被紙張淹沒。草稿落在檔案系統、回報只帶摘要——這份紀律就是步驟二和步驟三的介面。

步驟二：互相審稿——戴上 D06 的查核員帽子

審稿員就是 D06 那位 fact-checker 的變形，靈魂一樣是兩個欄位：permission 全 deny（只准出嘴，不准動手），description 寫清楚量表來源：

description: 審鐵人賽草稿：逐條比對 prompts/generate.md（字數、標題一致、台灣繁中、機敏）與 outline.md，至少回報三條具體問題
mode: subagent
permission:
  edit: deny
  bash: deny
你是嚴格的審稿編輯。只回報問題與修改建議，禁止動手改檔。
講不出「違反規則第幾條、在草稿哪一段」的意見不算數；
湊不出三條，就再讀一次規則——通常是你不夠認真。

「互評」的互相是設計出來的：A 審 B、B 審 C、C 審 A，棋錯開，避免自家人護短。而評審標準不靠感覺——prompts/generate.md 的十條寫作規則，同時就是評審量表，一份文件兩用，規則改一處、寫稿與審稿同時跟上。

小小小測驗：你知道今天這篇 d28 文章，本身是誰寫的嗎？（答案：老實說，是原本那條單人管線寫的——generate.sh 的一次 opencode run。編輯部架構是今天的加時賽示範，等它哪天真站上 19:00 的夜班，明天 D29 的數據成績單會替它說真話）

步驟三：主編拍板——用舊守衛驗新稿

三份草稿、三份審稿報告回到主編手上。主編（就是你的 primary agent）先讀三份摘要與互評結論，必要時抽讀原文，選出優勝者或指示合稿——注意它從頭到尾不需要把三篇全文都塞進 context。拍板之後，驗收不用新的標準，直接沿用 generate.sh 的既有判準：

# 主編的驗收清單 ＝ generate.sh 既有守衛原封不動（節錄）
C=$(cjk_count "$ARTICLE"); T=$(head_title "$ARTICLE")  # 剝除 code block 後的中文字數、frontmatter 標題
(( C >= 1500 )) || echo "CJK(${C}字)不足"               # 字數門檻
[[ "$T" == "28 高手玩法：多 Agent 平行寫作" ]] || echo "標題不符"
secret_scan "$ARTICLE" && echo "機敏命中，隔離重寫"      # 紅線：命中即進隔離區，沒得商量

過了關，才輪到下游：publish.sh、發文 flag、備稿機制一行都不用改。平行化只發生在「彼此獨立」的寫作與審稿段；規則 → 大綱 → 文章 → 發佈這條依賴鏈，維持單行道——D06 說過有依賴的任務拆平行毫無意義，編輯部也一樣。

那為什麼不直接把夜班換成編輯部？答案還是那句老話：可預測性優先。19:00 到 20:00 只有一小時，單路徑加五次重試的行為最好預測；編輯部多三個會動的零件，除錯面積跟著變三倍。所以我的定位是：夜班照舊單人作業，編輯部留給值得端出大菜的日子，或等明天的數據說話，再決定要不要給它正職。

常見問題 / 踩坑記錄

• Q：三個 subagent 同時開工，草稿會不會互相覆蓋？
  A：會，如果只給一個路徑的話。平行任務的第一戒律是「先分格子再開工」：d28-a / b / c 一人一格，路徑寫死在派遣訊息裡。兩個 agent 同時寫同一個檔案，後寫的安靜蓋掉先寫的，沒有報錯、沒有警告——你的稿子是無聲消失的，等發現通常已經過了一個 commit。

• Q：互評會不會變成互相吹捧，三篇都「寫得很好」？
  A：預設真的會，LLM 天生客氣。兩個解法雙管齊下：一是把「至少回報三條具體問題」寫進審稿員的規則，堵死客氣的退路；二是把評審依據從感覺換成量表——直接引用 prompts/generate.md 的條目，違反第幾條、出事在第幾段，講不出來的意見不算數。量表越具體，審稿越不留情面。

• Q：三路生成，token 成本不就變三倍？
  A：對，帳要認。省法有二：草稿這種體力活派小模型（自訂 agent 的 frontmatter 可以單獨指派 model，D06 講過），主編的判斷力留給大模型——便宜的他多做、昂貴的他少做；二是只在值得的日子開編輯部，平常夜班維持單人。至於整體到底多花了多少，明天 D29 的數據成績單會連 token 成本一起攤開，歡迎來查我的帳本 :D

小結

• 編輯部三人組：記者平行開稿（一人一格路徑、回報只帶摘要）、審稿互評（量表就是 generate.md、edit 全 deny）、主編彙整（讀報告與中選稿，不囤積全文）
• 平行化的鐵律：只拆「彼此獨立」的段落；寫與審可以並進，規則 → 大綱 → 發佈的依賴鏈維持單行道
• 舊守衛驗新玩法：bytes、CJK 字數、標題一致、機敏掃描——架構再花哨，過關標準永遠只有一套

明日預告

下一篇我們要介紹 量化回顧：30 天自動化的數據成績單，敬請期待！生成成功率、耗時、token 成本、人工介入次數，30 天的帳本全部公開——包含今天這間編輯部，到底值不值得升級成夜班正職。

參考資料：

• opencode 官方文件：Agents
• opencode 官方文件：Permissions
• opencode 官方文件

有任何疑問但沒有 iT 邦幫忙帳號，或是想匿名提問？
歡迎到 https://dev.benben.me/q/Z5442T 提問或加油打氣，沒意外的話會在完賽之後一起回答 :D