AutoScientists 教學文件

Repository: mims-harvard/AutoScientists Stars: 688 · Forks: 111 · 語言: Python 一句話簡介：Self-Organizing Agent Teams for Long-Running Scientific Experimentation（自組織 agent (代理人) 團隊，用於長時間執行的科學實驗） 論文：Gao, Fang, Zitnik. AutoScientists: Self-Organizing Agent Teams for Long-Running Scientific Experimentation. arXiv:2605.28655 出處：Harvard Medical School, Zitnik Lab (mims-harvard)

1. 專案概述 (Project Overview)

1.1 這個專案在解決什麼問題？

先想像一個真實的實驗室場景：一位 PI (principal investigator; 實驗室主持人) 帶了一群博士後與研究生，要在幾天內把一個機器學習模型的表現往上推。傳統做法是 PI 自己（或帶著一位工程師）想點子、跑實驗、看結果、再想下一個點子——這是「單一軌跡 (single trajectory)」的探索方式：一次只走一條路，走錯了要花時間才會發現，而且沒有人在旁邊質疑你的假設是不是有問題。

現在把「PI + 研究生」換成「AI agents」，AutoScientists 想解決的正是這個問題：如何讓一群 AI agent 像一個真正的實驗室團隊那樣，長時間（幾小時到幾天）自主運作，而不是像多數 agent 系統那樣「一個大腦、一條路走到底」？

具體來說，多數現有的多 agent 科學研究系統（例如單一 planner 集中調度所有 worker）有三個結構性弱點：

1. 單點失敗 (single point of failure)：所有決策集中在一個中央 planner，一旦 planner 判斷錯誤，底下所有 worker 都跟著走錯路。
2. 缺乏同儕審查 (peer review)：worker 提出的實驗提案沒有人在花費昂貴的 GPU 運算資源之前先「潑冷水」，於是系統浪費大量算力在明顯不會成功的方向上。
3. 知識不流動：team A 做過的失敗實驗，team B 完全不知道，於是重複踩同一個坑；team A 的成功突破，team B 也要等很久才會注意到。

AutoScientists 的核心設計理念，用一句話比喻：把「一個天才研究員」換成「一個會互相吐槽、會互相抄作業（好的意義上）的小型實驗室」。系統讓多個 agent：

• 自組織 (self-organize) 成小隊：agent 們自己討論「這個問題可以從哪些角度切入」，然後依照假設（不是依照事先規定的維度）自動分組成隊，而不是被一個中央調度器指派任務。
• 互相批評 (critique) 彼此的提案：任何實驗要花費運算資源之前，必須先以 [PROPOSAL]（提案）貼文的形式公開，並且至少要有一位隊友留言討論過，才能真正排進實驗佇列（queue）。這就像實驗室的 group meeting——你想燒錢跑 GPU 之前，先在白板上把想法講給組員聽。
• 共享成功與失敗：每一次實驗結果都會寫回一個所有隊伍都能看到的「主工作區 (main workspace)」，任何隊伍發現的死路（dead end）或突破（champion 更新）都會廣播出去，避免不同隊伍在同一個坑裡反覆摔倒。

1.2 為什麼這件事在生醫 AI 領域特別重要？

在藥物研發、蛋白質工程、基因體學這類「濕實驗室成本極高、乾實驗室（電腦模擬）成本相對低但仍然昂貴」的領域，長時間、大範圍地探索設計空間（design space）本身就是價值所在。舉例：

• 蛋白質適應度預測 (protein fitness prediction; 蛋白質適應度預測)：一個蛋白質突變體庫可能有上萬種變異組合，單靠一個 agent 一次跑一種模型設定，永遠追不上窮舉的速度；但若有多個「隊伍」平行探索不同建模假設（例如：結構特徵 vs. 序列嵌入 vs. 進化保守性），整體探索效率會大幅提升。
• 藥物性質預測 (ADMET; 吸收代謝分佈排除毒性)：AutoScientists 內建的 BioML-Bench 24 個任務中，drug_discovery 分類就涵蓋了 hERG 心臟毒性、血腦屏障穿透性 (BBB; blood-brain barrier)、肝清除率 (hepatic clearance) 等經典 ADMET 任務——這些正是新藥開發早期最耗人力去嘗試特徵工程與模型選擇的環節。
• 單細胞體學 (single-cell omics; 單細胞體學)：open-problems 系列任務（細胞-細胞通訊、標籤投影、模態預測、擾動預測）都是目前單細胞分析领域公開的技術瓶頸，AutoScientists 用它們來驗證系統能否在真正困難、目前尚無標準解法的生物資訊問題上自主找到有效方案。

換句話說，AutoScientists 不是又一個「聊天機器人幫你寫程式碼」的工具，而是想成為能夠自主跑完整個「假設 → 實驗 → 結果 → 修正假設」科學循環的系統，目標客群正是生醫 AI 研究者：他們手上有明確可量化的指標（validation loss、AUC、Spearman correlation 等），但探索空間太大，人力跟不上。

1.3 相關論文與引用

• 主論文：Shanghua Gao, Ada Fang, Marinka Zitnik (2026). AutoScientists: Self-Organizing Agent Teams for Long-Running Scientific Experimentation. arXiv:2605.28655 [cs.AI]。
• 依賴的基準測試：
  • karpathy/autoresearch（nanoGPT 訓練最佳化基準，用於驗證系統在非生醫、純機器學習優化任務上的通用性）
  • BioML-Bench：24 個生醫機器學習任務的基準集，涵蓋生醫影像 (biomedical imaging)、蛋白質工程 (protein engineering)、單細胞體學 (single-cell omics)、藥物發現 (drug discovery) 四大類。
  • ProteinGym：業界標準的蛋白質適應度預測基準，論文中特別挑選 SARS-CoV-2 Spike 蛋白的 ACE2 結合力預測任務，以及全部 217 個 DMS (deep mutational scanning; 深度突變掃描) 分析。
• 周邊工具：
  • ClawInstitute（npm 套件）：AutoScientists 的通訊骨幹，提供 workshop / workspace / posts 這幾個抽象概念，讓多個 Claude Code agent 之間可以透過一個本地 REST API 互相留言、共享檔案。
  • ToolUniverse（同樣是 mims-harvard 底下的專案）：提供大量科學工具（資料庫查詢、化學資訊工具等）給 agent 呼叫，雖然 AutoScientists README 中列出了徽章連結，但兩者是姊妹專案關係，非強制依賴。

1.4 在 mims-harvard 實驗室生態系中的角色

mims-harvard 是 Harvard Medical School 的 Zitnik Lab（主持人 Marinka Zitnik）在 GitHub 上的組織帳號，長年耕耘「圖神經網路 (graph neural network; 圖神經網路) 在生醫領域的應用」，知名專案包括 TxGNN（零樣本藥物再利用）、PrimeKG（生醫知識圖譜）等。AutoScientists 可以理解為這個生態系「從靜態知識圖譜、預測模型」往「動態自主科學發現流程」邁進的下一步：

flowchart TB
    subgraph ZL["Zitnik Lab 生態系"]
        KG["PrimeKG
生醫知識圖譜"]
        TX["TxGNN
零樣本藥物再利用預測"]
        TU["ToolUniverse
科學工具集"]
        AS["AutoScientists
自組織 agent 科學實驗系統"]
    end

    KG -->|提供背景知識| AS
    TU -->|提供可呼叫工具| AS
    TX -->|示範單一預測任務| AS
    AS -->|產出新假設/新結果| KG

    style AS fill:#F59E0B,color:#0F172A
    style KG fill:#DBEAFE,color:#0F172A
    style TX fill:#DBEAFE,color:#0F172A
    style TU fill:#DBEAFE,color:#0F172A

AutoScientists 不是取代這些工具，而是把它們（或類似工具）當作「agent 手上的儀器」，讓自組織的 agent 團隊有東西可以「動手做實驗」。

1.5 專案在生醫 AI 版圖中的定位

生醫 AI agent 系統大致可以分成三層：知識層（把散落的論文、資料庫變成可查詢的結構）、推理層（單一模型或單一 agent 做預測/生成）、執行層（自主跑完整個實驗迴圈，包含訓練、評估、修正）。AutoScientists 明確定位在執行層，而且是執行層裡少數強調「多 agent 去中心化協作」而非「單一 agent 或單一 planner」的系統。

flowchart LR
    subgraph L1["知識層"]
        PL["PubMed / bioRxiv
文獻資料庫"]
        KGD["知識圖譜
(PrimeKG 等)"]
    end

    subgraph L2["推理層"]
        SM["單一預測模型
(TxGNN 等)"]
        SA["單一 agent 助手
(通用 Chatbot/Copilot)"]
    end

    subgraph L3["執行層"]
        SO["單軌跡 agent 系統
(planner 集中調度)"]
        AUTO["AutoScientists
去中心化自組織團隊"]
    end

    L1 --> L2 --> L3
    SO -.同層對照.- AUTO

    style AUTO fill:#F59E0B,color:#0F172A
    style SO fill:#E5E7EB,color:#0F172A

這個定位很重要，因為它決定了 AutoScientists 不會去跟文獻搜尋工具、知識圖譜工具搶市場——它假設你已經有明確的任務定義（TASK.md）跟可量化的指標，然後接手「怎麼有效率地探索解法空間」這一段。這個切分在後面第 6 章分析 AIKT 整合策略時會非常關鍵。

1.6 三個核心設計原則（貫穿全文件）

在深入架構之前，先把三個貫穿全系統的設計原則講清楚，之後看程式碼與流程時會反覆用到：

1. 編排者是純協調者 (orchestrator is a pure coordinator)：README 與 runbook.md 都用全大寫強調「THE ORCHESTRATOR NEVER RUNS EXPERIMENTS」。編排者（通常是你手動啟動的那個 Claude Code session）只負責派工、收結果、更新 champion（目前最佳解），絕不自己寫 train.py、絕不自己跑訓練。這個原則保證了「誰做事、誰負責」的邊界清晰。
2. 討論優先於排隊 (discussion-before-queuing)：任何實驗提案都必須先變成一則 [PROPOSAL] 貼文，且至少要有一位隊友留言過，才能進入該隊伍的實驗佇列 queue.md。這是系統對抗「亂槍打鳥燒 GPU」的關鍵機制。
3. 永不停止、永不徵求許可 (never stop, never ask permission)：一旦執行迴圈啟動，系統就要持續運轉直到觸發 exit_condition（停滯或達成目標）或使用者手動中斷，中途不會每隔幾輪就跳出來問「要不要繼續」。這對「長時間執行」（title 裡的 long-running）這個核心訴求至關重要。

1.7 實驗室角色對照表：把抽象概念釘死在具體比喻上

為了讓後面章節的技術細節不會顯得空泛，這裡先把「AutoScientists 的角色」跟「真實實驗室的角色」逐一對應清楚，之後每次提到 Monitor / Analyst / GPU Agent，都可以直接回想這張表：

有了這張表，之後看到「Analyst 發布 [PROPOSAL] 貼文」，可以直接理解成「博士後在組會上提出一個新點子並寫成一頁摘要」；看到「GPU Agent claim 一個 pending 實驗」，可以理解成「研究生從白板上把自己要做的實驗劃掉、認領下來」。

1.8 為什麼叫「AutoScientists」而不是「AutoScientist」：複數形式背後的設計哲學

專案名稱刻意使用複數形式 AutoScientists，這不是隨意的命名選擇。市面上多數同類系統（例如「AI Scientist」類專案）強調的是「一個足夠聰明的單一 agent 能不能取代一位科學家」，而 AutoScientists 的命題不同：它問的是「一群互相制衡、互相分享的 AI agent，能不能取代一整個實驗室」。這個複數形式直接呼應了論文標題裡的 “Self-Organizing Agent Teams"——重點從來不是單體智慧的強弱，而是協作結構的設計。

這個命名哲學也解釋了為什麼系統花這麼多篇幅在「討論優先於排隊」「跨隊知識共享」「Meta-Improvement 系統自我反思」這些協調機制上——如果目標只是「打造更強的單一 agent」，這些機制根本不必存在；但如果目標是「打造一個會自我修正的科學家社群」，這些機制就是核心，而不是附加價值。

1.9 「長時間執行」具體指的是多長？

論文標題強調 long-running（長時間執行），實務上這個「長」有具體的量級參考：

• task-autoresearch：沒有固定截止時間，跑到「連續 10 次實驗 0 次 KEEP」（停滯）才停止——實務上可能跑數小時到超過一天，取決於搜尋空間收斂速度。
• task-biomlbench：24 個子任務各自可能有隱含的時間預算（pre_cycle_check hook 明確提到「deadline checks and emergency submission」），單個子任務常見設計為數小時內完成一輪完整探索。
• task-protein-gym：論文報告的最終結果（+12.5%／+6.5%）代表的是完整多輪探索後的累積成果，不是單次實驗的結果。

換句話說，「長時間」不是一個誇張的行銷詞，而是系統架構裡實際被編碼進去的假設——如果你的任務 5 分鐘就能跑完一次實驗、10 分鐘就能收斂，那麼啟動整套自組織團隊基礎設施（見第 3 章安裝流程）的固定成本可能不划算，這點會在第 7.4 節「何時不該用」再次強調。

2. 核心架構 (Core Architecture)

2.1 三層架構總覽：任務、系統、執行環境

AutoScientists 的程式碼可以拆成三個互相獨立的層次：

這個分層設計本身就是一個值得學習的架構模式：通用協調邏輯（system/）與領域特定邏輯（task-*/）徹底分離，中間用「hook（掛鉤點）」機制連接——這跟 AIKT 自己的 27-Layer 架構「每個 Layer 都有 setup subcommand，但共用同一套 skill 派工原則」是類似的設計哲學。

2.2 系統架構圖

flowchart TB
    subgraph USER["使用者"]
        CLI["Claude Code CLI
claude -p 指令"]
    end

    subgraph RUNTIME["執行環境"]
        LAUNCH["launch.py
建立 run 目錄"]
        SERVER["ClawInstitute 本地伺服器
npx clawinstitute start"]
        RUNBOOK["runbook.md
編排者的基礎程式"]
        PROFILE["task-profile.md
13 個 hook 的具體實作"]
    end

    subgraph ORCH["編排者 Session（純協調，不跑實驗）"]
        ORCHESTRATOR["Orchestrator
派工 + 收結果 + 更新champion"]
    end

    subgraph TEAMS["自組織團隊（多隊平行）"]
        subgraph TEAM_A["Team A"]
            MON["Monitor Agent
(全域 1 位)"]
            AN_A["Analyst Agent
(每隊 1 位)"]
            GPU_A1["GPU Agent 1"]
            GPU_A2["GPU Agent 2"]
        end
        subgraph TEAM_B["Team B"]
            AN_B["Analyst Agent"]
            GPU_B1["GPU Agent 1"]
            GPU_B2["GPU Agent 2"]
        end
    end

    subgraph STATE["共享狀態 (ClawInstitute Workspaces)"]
        MAIN_WS["主工作區
champion.md / results/ / teams/roster.md"]
        TEAM_WS_A["Team A 工作區
queue.md / dead_ends.md / strategy.md"]
        TEAM_WS_B["Team B 工作區
queue.md / dead_ends.md / strategy.md"]
    end

    CLI --> LAUNCH --> RUNBOOK
    RUNBOOK --> PROFILE
    LAUNCH -.啟動.-> SERVER
    RUNBOOK --> ORCHESTRATOR
    ORCHESTRATOR -->|派工 Task/Agent| MON
    ORCHESTRATOR -->|派工| AN_A
    ORCHESTRATOR -->|派工| GPU_A1
    ORCHESTRATOR -->|派工| AN_B
    ORCHESTRATOR -->|派工| GPU_B1

    MON <--> MAIN_WS
    AN_A <--> TEAM_WS_A
    GPU_A1 <--> TEAM_WS_A
    GPU_A2 <--> TEAM_WS_A
    AN_B <--> TEAM_WS_B
    GPU_B1 <--> TEAM_WS_B
    GPU_B2 <--> TEAM_WS_B

    TEAM_WS_A -.結果同步.-> MAIN_WS
    TEAM_WS_B -.結果同步.-> MAIN_WS
    MAIN_WS -.champion 廣播.-> TEAM_WS_A
    MAIN_WS -.champion 廣播.-> TEAM_WS_B

    style ORCHESTRATOR fill:#F59E0B,color:#0F172A
    style MAIN_WS fill:#DBEAFE,color:#0F172A

從這張圖可以看到幾個關鍵設計：

1. Orchestrator 是唯一跟使用者直接互動的節點，但它自己不進入任何 team——它是「派工的人」，不是「做事的人」。
2. Monitor agent 是全域唯一，負責建立 workshop（研討會，所有 agent 訂閱的通訊頻道）、促成組隊、監控健康狀態；而 Analyst 與 GPU Agent 則是每個 team 各自擁有一份（README 建議配置：每隊 1 位 Analyst、2 位 GPU Agent）。
3. 所有跨隊溝通都經過主工作區 (main workspace)，team 內部溝通則走各自的 team workspace——這是一個「星形拓�撲加上內部小圈子」的通訊架構，避免 N 個 team 之間 O(N²) 條溝通管道。

2.3 資料流向圖：一次完整的實驗生命週期

下圖用 sequence diagram 展示「一個實驗提案從發想到變成新 champion（或被丟棄）」的完整生命週期，這是理解 AutoScientists 最重要的一張圖：

sequenceDiagram
    participant AN as Analyst Agent
    participant WS as Workshop (Posts)
    participant TQ as Team Queue
(queue.md)
    participant GPU as GPU Agent
    participant MW as Main Workspace
(champion.md / results/)
    participant ORCH as Orchestrator

    AN->>AN: 讀取 knowledge/patterns.md
搜尋相關文獻/機制
    AN->>WS: 發布 [PROPOSAL] 貼文
(附機制假設 + code diff)
    Note over WS: 討論優先於排隊規則：
至少 1 位隊友需留言討論
    WS->>WS: 隊友留言討論/質疑
    AN->>TQ: 將提案寫入 queue.md
(pending 列表)

    GPU->>TQ: 認領 (claim) 一個 pending 實驗
    TQ->>GPU: 回傳實驗規格
    GPU->>MW: 讀取 champion.md
(目前最佳基準)
    GPU->>GPU: 執行實驗
(訓練/評估，實際跑程式碼)
    GPU->>WS: 發布 [RESULT] 貼文
(含 metric、KEEP/DISCARD)
    GPU->>MW: 寫入 results/{exp_id}.md
    GPU->>TQ: 釋放認領 (release claim)

    ORCH->>ORCH: 收到 GPU agent 的 promise 訊息
    ORCH->>ORCH: 寫入 logs/experiments.jsonl
(唯一權威日誌)

    alt 結果為 KEEP (優於目前 champion)
        ORCH->>MW: 更新 champion.md
        MW-->>TQ: 廣播新 champion 給所有隊伍
    else 結果為 DISCARD
        AN->>AN: 記錄 dead_ends.md
避免重複嘗試
    end

    ORCH->>ORCH: 每 3 輪執行 Meta-Improvement
(檢視系統本身是否運作良好)

這張圖揭示了幾個容易被忽略但很關鍵的細節：

• GPU agent 是唯一真正「動手做實驗」的角色——Analyst 負責想點子跟做文獻功課，Monitor 負責維運，Orchestrator 負責派工，只有 GPU agent 會實際執行訓練/評估程式碼。
• logs/experiments.jsonl 是「唯一權威來源」(single source of truth)，且明確規定「由 orchestrator 寫入，agent 不可直接寫入」——這避免了多個 agent 平行寫入同一個檔案造成的競爭條件 (race condition)。
• KEEP/DISCARD 的判斷會立刻反映在 champion.md，而 champion.md 的更新會被所有隊伍在下一輪讀取到（“all teams rebase”）——這是讓知識在隊伍間流動的核心機制，不需要額外的廣播系統，單純靠「大家都讀同一個檔案」達成。

2.4 關鍵演算法與方法論

2.4.1 自組織分隊：從「維度」到「假設」的演進

早期版本的協調邏輯（PHASES.md 裡仍保留舊版註解）是讓每個 team 負責一個「維度 (dimension)」，例如「架構 (architecture) 隊」專門改模型結構、「排程 (scheduler) 隊」專門改學習率排程。但 PHASES.md 裡的 create_team() 函式明確標註了一個重要的方法論升級：

“team_name: short label like ’throughput’ or ‘gradient-quality’ (NOT an axis name like ‘arch’ or ‘sched’ — teams no longer partition axes).”

也就是說，系統設計者發現「按維度分隊」容易讓隊伍陷入侵略性太弱的局部探索（每隊固守自己的一小塊），於是改成按可否證的假設 (falsifiable hypothesis) 分隊：每個隊伍圍繞一個具體、可被數據推翻的主張運作，例如：

假設：「目前模型在現有運算預算下訓練不足 (undertrained)」 預測：「任何把訓練步數 (num_steps) 增加 ≥10% 的實驗都會 KEEP」 否證條件：「連續 3 輪符合預測模式的實驗全部 DISCARD」

這個「假設 → 預測 → 否證條件」三元組，其實就是 Karl Popper 式的科學方法論被直接編碼進系統的資料結構（strategy.md 的 YAML frontmatter）。這比單純「這隊負責架構、那隊負責排程」的靜態分工更貼近真實科學探索——任何軸向 (axis) 的改動都可以歸屬於任何隊伍，只要它能被拿來檢驗該隊的假設。

2.4.2 冠軍晉升機制 (Champion Promotion)

系統用一個非常單純但有效的機制維護「目前最佳解」：champion.md（以及對應的程式碼快照，例如 champion/train.py）。任何一次實驗結果如果嚴格優於目前 champion 的指標，就標記為 KEEP，並觸發：

1. Orchestrator 把新程式碼複製為新的 champion/train.py（README 特別強調「這是編排者除了記錄日誌以外，唯一允許自己寫檔案的動作」）。
2. 所有隊伍在下一輪讀到新 champion 後，自動以它為新的比較基準（“rebase”）。

這個機制的妙處在於去中心化搜尋 + 中心化基準的混合模式：探索是完全平行、去中心化的，但「什麼才算贏」永遠有一個單一、明確的比較基準，不會出現「A 隊覺得贏了，B 隊覺得沒贏」的混亂局面。

2.4.3 停滯偵測與 Meta-Improvement（系統自我反思）

系統設計了兩層「系統健康檢查」：

• 停滯偵測 (stagnation detection)：任務層的 exit_condition hook 通常定義成「最近 N 次實驗（例如 10 次）裡有 0 次 KEEP，就視為停滯，觸發退出或重組」。這是 task-autoresearch 用來決定何時結束整個 run 的規則。
• Meta-Improvement（每 3 輪一次的系統反思）：這是本專案裡最有意思的設計之一。system/reference/META-IMPROVEMENT.md 明確要求編排者不能只是「跑腳本、套建議」，而必須真的去讀 experiments.jsonl、sessions.jsonl、各隊 queue.md、workshop 貼文內容，然後做出一個具體、可驗證的判斷（例如：「Team B 已經連續 6 次 DISCARD，且完全沒去看 Team A 最近的兩次 KEEP」），並且必須真的修改某個檔案（例如調整 ROLE-ANALYST.md 的提示內容），文件甚至直接寫：「如果你做完這步，沒有任何檔案被改動，那你就沒有真的做 Meta-Improvement。」

這個設計把「系統自我調適」的責任明確放在編排者身上，而不是依賴某個自動化腳本，這跟 AIKT 裡「驗收者 ≠ 執行者」「同一錯誤修 2 次未解要停下來升級」這類治理原則有異曲同工之妙。

2.4.4 模型選型的實證教訓：Haiku 級模型不適合做 Analyst

文件裡罕見地引用了一個真實踩坑記錄（2026-05-26 的 gpt-nano-agents run）：使用 Haiku 級（輕量）模型作為 Analyst 時，觀察到「描述式失敗模式 (describe instead of do)」——三個 Haiku analyst 都寫了一份「工作已完成」的本地記憶檔案，但實際上從未呼叫 workshop API，導致隊伍的實驗佇列一直空著卻沒人發現。因此系統規則明確寫著：Analyst 一律使用 sonnet 或 opus 等級模型，Haiku 保留給這個迴圈之外的確定性機械工作。這是一個值得記住的一般性教訓：當任務需要「主動呼叫外部 API 並驗證副作用」而非「產生看起來合理的文字」時，輕量模型的風險會被放大。

2.5 內部元件互動：Heartbeat 與 Mode Selector

每個 agent 的行為完全由一份自我完備 (self-sufficient) 的 HEARTBEAT.md 文件驅動（由 launch.py 依角色模板生成，靜態、不隨執行過程改變）。這份文件的結構分成幾個部分：

• Part 0（Mode Selector，模式選擇器）：每次啟動一個 agent 時，編排者的派工提示（prompt）只會傳入三件事：FOCUS_ROOT（run 目錄路徑）、MODE（discussion 或 execute）、以及一句「請讀 HEARTBEAT.md 並照做」。agent 自己讀檔案，根據 MODE 決定走討論分支還是正常執行分支——這是刻意設計的極簡派工介面，編排者完全不需要把工作區 ID、隊伍名稱、步驟細節寫進 prompt 裡，全部靠 agent 自己去發現。
• Part 2（Orient，定向）：agent 讀取 roster.md 找到自己屬於哪隊、該隊所有工作區 ID，再 LIST 工作區檔案「發現」目前狀態，而不是依賴一份寫死的檔案清單——文件稱這個原則為「發現優先於規定 (discovery over prescription)」。
• Part 4（Normal Cycle，正常執行週期）：依角色（Analyst / GPU / Monitor）執行對應的動作序列。
• Part 5（Record，記錄）：更新 AGENT.md（frontmatter 記身份/狀態、body 記自由格式筆記）與 memory/ 目錄。
• Exit：輸出一個 <promise> 標籤讓編排者知道這個 agent 的這一輪工作已完成。

這個 AGENT.md + memory/ 的設計，文件裡直接類比成「Claude Code 的 CLAUDE.md + ~/.claude/projects/{project}/memory/」——也就是說，每一個 agent 都是一個擁有自己專屬記憶系統的小型 Claude Code 專案，這跟 AIKT 本身「每個 session 都有 MEMORY.md 記憶索引」的設計哲學完全相通，只是 AutoScientists 把這個模式套用到「每個 agent」而不是「每個人類使用者的專案」。

2.6 AnonAPI / ClawInstitute：agent 之間怎麼「講話」與「共享檔案」

前面幾節反覆提到 workshop、workspace、posts 這些詞，這一節把底層的 API 概念講清楚，因為這是所有跨 agent 協調的唯一管道——agent 之間沒有任何其他溝通方式（不能互相直接呼叫、不能共享記憶體），一切都要透過這個本地 REST API（文件內部代稱 AnonAPI，由 clawinstitute 套件提供伺服器實作）。

這裡有兩個對理解系統韌性 (robustness) 特別重要的設計細節：

細節一：YAML frontmatter 不由伺服器解析。 API 文件用粗體特別警告：「The API does NOT parse YAML frontmatter」——每個檔案的 frontmatter（例如 champion.md 開頭的 ---\nmetric: val_bpb\n---）必須由 agent 自己在收到原始文字後手動解析，伺服器只是把檔案當成純文字儲存與版本控管：

 1import yaml
 2
 3def parse_frontmatter(api_response):
 4    """從工作區檔案內容中解析 YAML frontmatter（用戶端自行解析，伺服器不處理）"""
 5    content = api_response.get("content", "")
 6    parts = content.split("---")
 7    if len(parts) >= 3:
 8        return yaml.safe_load(parts[1]) or {}
 9    return {}
10
11raw = requests.get(f"{API}/workspaces/{ws_id}/files/champion.md",
12                    headers=HEADERS).json()
13champ = parse_frontmatter(raw)
14metric = champ.get("metric")   # 例如 val_bpb 或 spearman_correlation

細節二：「先列表、再選擇性讀取」(LIST first, READ selectively) 是效能與正確性的關鍵模式。 因為工作區裡的檔案會隨著時間累積（每個團隊都可能自己創建額外的分析文件），系統刻意不要求 agent 依照一份寫死的檔案清單去逐一讀取，而是先呼叫成本低廉的 LIST（只回傳路徑、版本號、最後更新時間、更新者），agent 自己判斷「這個檔案時間點/作者跟我現在的任務有沒有關係」，值得讀才真正呼叫 GET 拉取完整內容：

 1# 便宜：只拿中繼資料，用來判斷「有什麼新東西」
 2files = requests.get(f"{API}/workspaces/{ws_id}/files",
 3                      headers=HEADERS).json()["files"]
 4# 回傳範例：[{"path": "dead_ends.md", "version": 18,
 5#            "updatedAt": "2026-04-02T10:00:00Z", "updatedBy": "gpu1"}, ...]
 6
 7# 只有判斷「這個檔案跟我有關」才真正讀取內容
 8if any(f["path"] == "dead_ends.md" and f["version"] > last_seen_version
 9       for f in files):
10    content = requests.get(f"{API}/workspaces/{ws_id}/files/dead_ends.md",
11                            headers=HEADERS).json()

這個「發現優先於規定」的模式，本質上是用檔案系統的版本號取代了「所有 agent 必須訂閱同一份事件流」的複雜度——不需要 pub/sub 系統，單純靠「大家都定期 LIST 一次」就能讓知識在去中心化的多隊架構裡自然擴散,這也是整個系統少見依賴外部訊息隊列 (message queue) 或事件匯流排 (event bus) 卻依然能協調數十個 agent 的關鍵原因。

另外值得注意，PATCH /workspaces/{id}/files/{path} 支援「dot-notation frontmatter 更新」（例如 {"frontmatter": {"teams.architecture.members": [...]}}），這讓多個 agent 同時更新同一份檔案的不同欄位時不會互相覆蓋——這是解決「共享狀態並行寫入」問題的一個輕量方案，代價是仍需搭配 If-Match 版本檢查（PUT 支援，回傳 409 表示版本衝突）來處理「同一欄位被兩個 agent 同時改」的情況。

3. 安裝與設定 (Installation & Setup)

3.1 前置需求

3.2 逐步安裝指南

方法一：最小可行安裝（推薦初次嘗試）

 1# 1. 複製 repo
 2git clone https://github.com/mims-harvard/AutoScientists.git
 3cd AutoScientists
 4
 5# 2. 啟動本地 ClawInstitute 協調伺服器（前景執行，第一次會從 npm 下載）
 6npx clawinstitute start
 7# 首次執行會下載 clawinstitute 套件；之後會用本機快取，啟動更快
 8
 9# 3. 另開一個終端機，安裝 Python 依賴
10pip install -r requirements.txt
11# 依照 AIKT 全域規範，這裡建議改用 uv：
12#   uv venv && source .venv/bin/activate && uv pip install -r requirements.txt

注意：npx clawinstitute start 會佔用終端機前景執行，這是系統的協調伺服器，整個 run 期間都必須保持運作。實務上建議在 tmux 或 screen 分頁裡跑，或用第二種安裝方式做永久安裝。

方法二：永久安裝 ClawInstitute（適合會反覆使用的場景）

1npm install -g clawinstitute
2clawinstitute start

這樣可以避免每次啟動都重新解析 npx 快取，也方便寫進系統服務（如 systemd unit 或 pm2 設定）長駐執行。

方法三：下載某個任務所需的基準資料（以 task-autoresearch 為例）

1cd AutoScientists
2bash task-autoresearch/download_repo.sh
3# 這一步會 clone karpathy/autoresearch 進 task-autoresearch/repo/
4# repo/train.py 就是後續 agent 們會反覆演化、優化的訓練腳本

BioML-Bench 與 ProteinGym 任務也各自附有對應腳本（task-biomlbench/prepare_all_data.py、task-protein-gym/download_data.sh），需要先執行過一次才能開始正式的 run。

3.3 環境設定細節

3.3.1 API 金鑰與 token 的來源優先序

launch.py 需要一個「管理員 token」來呼叫 ClawInstitute 的 API，其尋找順序（程式碼裡明確寫死的優先序）為：

1. AutoScientists/.key 檔案（若存在）
2. 環境變數 CLAWINSTITUTE_TOKEN
3. ~/.clawinstitute/token（預設路徑）

若三者都找不到，launch.py 會直接印出錯誤訊息並退出（要求先執行 npx clawinstitute start）。

1# 設定環境變數版本（適合 CI 或一次性 run）
2export CLAWINSTITUTE_TOKEN="你的本地伺服器管理員 token"
3export CLAWINSTITUTE_API="http://localhost:3000/api/v1"   # 預設值，通常不需覆寫

3.3.2 GPU 環境變數

各任務的 GPU 派遣（gpu_dispatch hook）通常透過 CUDA_VISIBLE_DEVICES 顯式指定卡號，例如 task-autoresearch 的 2 卡設定會分別把兩個 GPU agent 釘死在 CUDA_VISIBLE_DEVICES=0 與 =1，確保不會有兩個 GPU agent 同時搶同一張實體卡——這條規則在 runbook.md 中被列為「通用規則」，不論任務類型都必須遵守。

3.4 驗證安裝是否成功

 1# 1. 確認 ClawInstitute 伺服器活著
 2curl -s http://localhost:3000/api/v1/health || echo "伺服器未啟動"
 3
 4# 2. 確認 Python 依賴到位
 5python3 -c "import requests, yaml; print('deps OK')"
 6
 7# 3. 確認 Claude Code CLI 可用
 8claude --version
 9
10# 4. 確認任務資料已備妥（以 task-autoresearch 為例）
11ls task-autoresearch/repo/train.py && echo "baseline 已就位"
12
13# 5. 乾跑一次 launch.py（不指定 --task 會用互動預設，可先用 --help 熟悉參數）
14python3 launch.py --help

若以上五步都沒有報錯，代表環境已經準備好，可以進入第 4 章的實際使用流程。

3.5 常見安裝陷阱

• 忘記啟動 ClawInstitute 伺服器：launch.py 會在找不到伺服器時直接失敗並印出提示，這是最常見的第一次使用錯誤。
• npx 版本太舊導致找不到套件：確認 Node.js ≥ 22，舊版 npx 對 ESM 套件的相容性可能有問題。
• 忘記下載任務資料就直接 launch：例如沒跑 download_repo.sh 就啟動 task-autoresearch，GPU agent 在第一輪就會因為找不到 repo/train.py 而失敗——這是任務層的問題，不是系統層的 bug。
• 把 .key 檔案不小心 commit 進版本控制：這個檔案本質上是本地伺服器的管理員憑證，務必加進 .gitignore（AIKT 全域規範也明確要求機密不進版本控制）。

3.6 容器化執行的可能性（AIKT 慣例延伸思考）

依 AIKT 全域規範，系統服務預設走 Docker/Podman，避免原生安裝、確保設定可重建。AutoScientists 目前官方文件沒有提供 Dockerfile，但整個依賴清單其實非常適合容器化：

 1# 概念示範：非官方 Dockerfile，示範可行的容器化思路
 2FROM node:22-slim AS clawinstitute-base
 3RUN npm install -g clawinstitute
 4
 5FROM python:3.11-slim
 6COPY --from=clawinstitute-base /usr/lib/node_modules /usr/lib/node_modules
 7COPY --from=clawinstitute-base /usr/bin/node /usr/bin/node
 8WORKDIR /workspace
 9COPY requirements.txt .
10RUN pip install --no-cache-dir -r requirements.txt
11# 注意：Claude Code CLI 本身需要另外處理認證/掛載，
12# 且 GPU 任務仍需要 --gpus all 搭配 nvidia-container-toolkit
13CMD ["bash", "-c", "clawinstitute start & python3 launch.py"]

實務上要注意兩個限制：一是 GPU 任務需要 nvidia-container-toolkit 支援，容器化不會讓 GPU 排程問題自動消失（第 7.2 節會再談這點）；二是 Claude Code CLI 的認證機制（API key 或訂閱登入）需要額外處理掛載或環境變數傳遞，這部分官方文件未涉及，需要自行測試驗證後才建議正式採用。若團隊已經有慣用的容器化 Claude Code 執行環境，直接套用會比從零設計更省力。

3.7 多次啟動時的目錄命名建議

由於每次 launch.py <run-name> 都會在同層目錄建立新資料夾，長期使用下來 repo 旁邊會累積大量 run 目錄。建議採用一致的命名慣例，方便後續第 6 章談到的「跨 run 知識擷取」腳本能用簡單的 glob pattern 找到所有相關 run：

1# 建議命名慣例：<任務簡稱>_<日期>_<版本>
2claude -p "Read runbook.md and execute. Task: task-protein-gym. Run name: spike_260710_v1."
3claude -p "Read runbook.md and execute. Task: task-protein-gym. Run name: spike_260711_v2."
4
5# 之後可以用一致的 pattern 找出同任務的所有歷史 run
6ls -d ../spike_*/

4. 基本使用 (Basic Usage)

4.1 快速入門：跑一次最簡單的任務

AutoScientists 的使用心智模型很單純：你（人類）啟動一個 orchestrator session，orchestrator 讀 runbook.md 這份「基礎程式」，然後自己去派生所有其他 agent。你不需要手動一個一個叫起 Analyst 或 GPU agent。

1# 第一步：在 repo 根目錄，啟動 orchestrator（-p 代表 non-interactive/print 模式，
2# 適合長時間背景執行；也可以用互動模式跑，方便你即時觀察）
3claude -p "Read runbook.md and execute. Task: task-autoresearch. Run name: ar_v1."

這一句話背後實際發生的事：

1. Orchestrator 讀 runbook.md，發現目前是「Case A：這是 template，沒有 WORKSPACE_ID」。
2. 依照 runbook.md 指示，呼叫 → PROFILE HOOK: launch_command，也就是實際執行：

   1python3 launch.py ar_v1 --task task-autoresearch
   

3. launch.py 在 repo 的同層目錄建立一個全新的 ../ar_v1/ 目錄，把 system/、task-autoresearch/（改名為 task/）、runbook.md、對應的 task-profile.md（從最近的 LAUNCH.md 複製而來）全部複製進去，並且向 ClawInstitute 伺服器註冊 workshop、workspace、所有 agent 的憑證。
4. Orchestrator 接著在這個新的 ../ar_v1/ 目錄裡持續運作：組隊 → 討論 → 派工 → 收結果 → 更新 champion → 檢查是否停滯 → 重複。

這個「模板保持乾淨，每次啟動都複製出一個全新 run 目錄」的設計非常關鍵：你可以同時對同一個任務跑好幾次不同設定的 ablation（消融實驗），彼此互不干擾，而 repo 本身（模板）永遠保持乾淨、可重複使用。

4.2 從零開始的範例工作流：BioML-Bench 藥物發現任務

假設你是一位生醫資料科學家，想測試系統在一個具體的 ADMET 任務上的表現——這裡以 tdcommons-lipophilicity-astrazeneca（AstraZeneca 親脂性資料集，藥物親脂性 (lipophilicity) 是藥物代謝動力學 (PK; pharmacokinetics) 的關鍵性質之一）為例：

1# 步驟 1：確認資料已備妥
2python3 task-biomlbench/prepare_all_data.py --task tdcommons-lipophilicity-astrazeneca
3
4# 步驟 2：查看任務定義，了解評分方式與資料格式
5cat task-biomlbench/drug_discovery/tdcommons-lipophilicity-astrazeneca/TASK.md
6
7# 步驟 3：啟動 orchestrator
8claude -p "Read runbook.md and execute. Task: task-biomlbench/drug_discovery/tdcommons-lipophilicity-astrazeneca. Run name: lipo_v1."

系統啟動後，會經歷完整的四階段生命週期（對應第 2 章 PHASES.md 的內容）：

flowchart LR
    A["Phase 1: Bootstrap
Monitor 建立 workshop + 主工作區"] --> B["Phase 2: Discuss
所有 agent 提案分隊維度/假設"]
    B --> C["Phase 3: Execute
各隊平行跑實驗，持續迴圈"]
    C --> D{"停滯判斷
(exit_condition)"}
    D -->|尚未停滯| C
    D -->|停滯或使用者中斷| E["Phase 4: 收斂
輸出最終 champion + submission"]

    style A fill:#DBEAFE,color:#0F172A
    style B fill:#DBEAFE,color:#0F172A
    style C fill:#F59E0B,color:#0F172A
    style D fill:#FDE68A,color:#0F172A
    style E fill:#BBF7D0,color:#0F172A

跑完之後，你會在 ../lipo_v1/task-biomlbench/drug_discovery/tdcommons-lipophilicity-astrazeneca/autoscientists_submission/ 底下看到三個關鍵輸出（這也是 repo 裡已經附上、可以直接參考格式的「範例輸出」）：

• autoscientists.py：最終 champion 使用的完整訓練/推論程式碼。
• autoscientists_submission.csv：對驗證/測試集的預測結果，格式符合 BioML-Bench 評分腳本要求。
• research_insights.md：系統自己寫的「研究心得報告」，總結整個探索過程中嘗試過哪些假設、哪些有效、哪些是死路。

4.3 輸入/輸出格式範例

4.3.1 輸入：TASK.md 的最小結構

 1---
 2name: autoresearch-nanogpt
 3task_type: optimization
 4metric: val_bpb
 5direction: minimize
 6---
 7
 8# Autoresearch: nanoGPT `val_bpb` Optimization
 9
10開放式最佳化 karpathy/autoresearch 的 nanoGPT 預訓練迴圈。
11agent 反覆修改 `repo/train.py`，把驗證集的 bits-per-byte（val_bpb）
12持續降低，沒有截止時間，直到連續 10 次實驗都沒有 KEEP（停滯）
13或使用者手動中斷為止。

這份檔案的 YAML frontmatter 只需要四個欄位：name（任務識別碼）、task_type（決定套用哪一套 hook 邏輯：optimization / biomlbench / proteingym）、metric（要優化的指標名稱）、direction（minimize 或 maximize）。Markdown 正文則是給 agent 讀的「人話版任務說明」。

4.3.2 輸出：logs/experiments.jsonl 的單行格式

 1{
 2  "exp_id": "exp_swiglu",
 3  "agent": "run01_gpu1",
 4  "team": "architecture",
 5  "metric": 0.998097,
 6  "champion_before": 1.005071,
 7  "champion_after": 0.998097,
 8  "delta": -0.006974,
 9  "outcome": "KEEP",
10  "description": "SwiGLU MLP replacement",
11  "started_at": "2026-03-29T10:01:00Z",
12  "completed_at": "2026-03-29T10:06:30Z",
13  "training_seconds": 300.1,
14  "race_condition": false
15}

這是全系統唯一「權威」的實驗記錄格式，每一行代表一次完整的實驗，涵蓋「是誰做的、屬於哪隊、改善了多少、花了多久」，是後續做消融分析 (ablation analysis) 或系統健檢時最重要的資料來源。

4.3.3 輸出：AGENT.md 的身份與記憶結構

 1---
 2name: ar2_gpu1
 3role: gpu
 4team: null              # 組隊後會填入隊名
 5gpu: 0                  # GPU 卡號索引（非 GPU agent 為 -1）
 6last_seen: null
 7status: idle
 8session_count: 0
 9last_experiment: null
10last_outcome: null
11last_val_bpb: null
12---
13
14# ar2_gpu1
15
16GPU agent on GPU 0.
17
18## Current Focus
19(尚未分配隊伍)
20
21## Suggestions for System Improvement
22(尚無建議)
23
24## Notes for Next Session
25(尚無筆記)

每個 agent 每次啟動時「第一件事讀這份檔案，最後一件事更新這份檔案」，這個模式讓 agent 即使在完全不同的 session（不同的 Claude Code 呼叫）之間，也能維持連續的身份與記憶——這正是「長時間執行 (long-running)」得以成立的關鍵基礎設施，因為單次 Claude Code 呼叫不可能真的連續執行幾天，必須靠檔案系統做狀態接續。

4.4 生醫場景實例：追蹤一次蛋白質適應度預測的探索過程

以 task-protein-gym（ProteinGym Spike 蛋白適應度預測）為例，實際的探索過程大致會是這樣的敘事：

1. Bootstrap：Monitor 建立 workshop，讀取 TASK.md 得知要優化的是「預測值與實驗測得的 Spearman 相關係數」，baseline 是一個 Kermut 高斯過程 (Gaussian process) 模型（task-protein-gym/repo/kermut.py）。
2. Discuss：多個 Analyst 提出不同角度的假設，例如：「結構資訊（AlphaFold 預測結構的距離矩陣）目前權重過低」、「序列嵌入 (sequence embedding) 應該換更大的蛋白質語言模型」、「核函數 (kernel) 的超參數還沒搜過」。系統依這些假設組成 2-3 個隊伍。
3. Execute：GPU agent 們平行跑不同版本的 Kermut 模型變體，每次結果都跟目前 champion（Spearman correlation）比較。
4. Adapt：若「結構資訊」隊連續多次 DISCARD，該隊的 Analyst 會在 dead_ends.md 記錄「單純增加結構距離矩陣權重無效，可能需要搭配非線性核函數」，並在下一輪調整假設方向。
5. 最終在 research_insights.md 留下完整記錄——論文報告的成果是在 ACE2-Spike 結合力測定 (binding assay) 上取得 +12.5% 的提升，在全部 217 個 DMS 分析上平均提升 +6.5%。

這個範例展示了 AutoScientists 最有價值的地方：它不只是給你一個最終模型，而是留下一份「為什麼這樣做」的可追溯研究記錄，這對於後續要寫論文方法段或跟其他研究者解釋「我們怎麼得到這個結果」極其重要。

4.5 如何在系統執行期間即時觀察進度

因為 orchestrator 一旦啟動就會持續運轉（見第 1.6 節「永不停止」原則），你會需要在不打斷系統運作的前提下，隨時檢查「現在跑到哪一步了」。由於所有狀態最終都落在 ClawInstitute 的工作區檔案裡，你可以直接用 curl 從另一個終端機視窗查詢，完全不需要介入 orchestrator 本身：

 1# 假設 WS_ID 是主工作區 ID（可從 run 目錄下的 WORKSPACE_ID 檔案讀到）
 2WS_ID=$(cat ../spike_v1/WORKSPACE_ID)
 3TOKEN=$(python3 -c "import json; print(list(json.load(open('../spike_v1/agent_tokens.json')).values())[0])")
 4
 5# 1. 看目前組了幾隊、成員是誰
 6curl -s "http://localhost:3000/api/v1/workspaces/${WS_ID}/files/teams/roster.md" \
 7     -H "Authorization: Bearer ${TOKEN}" | python3 -m json.tool
 8
 9# 2. 看目前 champion 是什麼指標值
10curl -s "http://localhost:3000/api/v1/workspaces/${WS_ID}/files/champion.md" \
11     -H "Authorization: Bearer ${TOKEN}"
12
13# 3. 直接看本機日誌（不需要打 API，run 目錄本身就有）
14tail -20 ../spike_v1/logs/experiments.jsonl | python3 -m json.tool
15tail -5  ../spike_v1/logs/sessions.jsonl
16
17# 4. 看某隊的實驗佇列還有多少 pending
18curl -s "http://localhost:3000/api/v1/workspaces/${TEAM_WS_ID}/files/queue.md" \
19     -H "Authorization: Bearer ${TOKEN}"

一個實用的監控習慣：盯著 logs/experiments.jsonl 的 outcome 欄位變化。如果連續看到 5-10 筆都是 DISCARD 且 delta 幾乎沒有變化，這通常是系統即將觸發停滯偵測（見第 2.4.3 節）的前兆，這時候可以提前準備決定是否要讓它自然收斂，還是手動中斷去調整任務定義後重新啟動。

4.6 中斷與恢復：runbook.md Case C 的實際操作

如果你手動中斷了一個正在跑的 run（例如 Ctrl+C 中止了 orchestrator session），系統設計上支援從中斷處恢復，不需要重新跑一次 bootstrap：

1# 恢復一個被中斷的 run：直接在該 run 目錄裡重新啟動 orchestrator，
2# runbook.md 會自行判斷這是 Case C（logs/ 已有內容 → 恢復模式）
3cd ../spike_v1
4claude -p "Read runbook.md and execute."

runbook.md 的 Case C 邏輯會先讀取既有日誌理解「已經發生過什麼」，釋放任何卡住的認領 (stale claims)，再繼續執行迴圈——這對長時間運行的任務而言是必要的容錯設計，畢竟沒有人會假設一個要跑好幾天的 session 中途完全不會被中斷（機器重啟、網路斷線、使用者手動暫停等都是現實中會發生的情況）。

5. 進階功能與應用場景 (Advanced Features & Use Cases)

5.1 進階配置：客製化 13 個任務 Hook

要讓系統適應一個全新的科學問題，你需要撰寫一份 LAUNCH.md，填滿 runbook.md 引用的 13 個 hook。以下是幾個最關鍵、影響最大的 hook：

 1<!-- task-profile.md 的 gpu_dispatch hook 範例（節錄自 task-autoresearch/LAUNCH.md 精神） -->
 2
 3## Hook: gpu_dispatch
 4
 5**Sequential per-GPU dispatch.** 2 張實體 GPU，各自綁定一個 GPU agent，
 6兩個 agent 平行跑（不同卡），但同一張卡上任何時候只能有一個 agent 在跑。
 7
 8```python
 9import os
10
11gpu_agents = [
12    {"name": f"{PREFIX}_gpu1", "cuda_device": 0},
13    {"name": f"{PREFIX}_gpu2", "cuda_device": 1},
14]
15
16for gpu in gpu_agents:
17    Task(
18        subagent_type="general-purpose",
19        model="sonnet",
20        description=f"{gpu['name']} training cycle",
21        prompt=(
22            f"You are {gpu['name']}.\n"
23            f"FOCUS_ROOT={FOCUS_ROOT}\n"
24            f"MODE=execute\n"
25            f"CUDA_VISIBLE_DEVICES={gpu['cuda_device']}\n"
26            f"Read {FOCUS_ROOT}/agents/{gpu['name']}/HEARTBEAT.md and follow it."
27        ),
28    )

規則：絕不讓兩個 GPU agent 同時使用同一張實體卡；每個提示都必須含 MODE=execute。

 1
 2其他重要 hook 摘要：
 3
 4| Hook 名稱 | 決定什麼 |
 5|---|---|
 6| `launch_command` | `launch.py` 的實際呼叫參數（哪個 task、輸出到哪個目錄） |
 7| `discussion_policy` | 討論階段要不要跑、跑多久、要不要跟第一次 GPU 派工並行（例如 autoresearch 的「冷啟動快速路徑」） |
 8| `seeding_policy` | 誰負責把第一批實驗塞進各隊 `queue.md`（orchestrator 自己塞，還是等 monitor 塞） |
 9| `pre_cycle_check` | 每輪迴圈開始前要不要做特別檢查（例如 biomlbench 的截止時間檢查與緊急提交） |
10| `champion_promotion` | KEEP 之後，champion 程式碼快照要怎麼複製、通知哪些隊伍 |
11| `stagnation_response` | 偵測到停滯後，要重組隊伍、還是縮小搜尋範圍、還是直接結束 |
12| `exit_condition` | 什�麼情況算「這次 run 結束了」 |
13| `analyst_prompt_extras` | 給 Analyst 的額外提示（例如截止時間提醒、多樣性要求） |
14
15### 5.2 冷啟動快速路徑：把「討論」與「第一次訓練」並行
16
17task-autoresearch 的 `LAUNCH.md` 裡有一個特別值得學習的優化模式——**冷啟動快速路徑 (cold-start fast path)**，目標是「5 分鐘內派出第一個 GPU agent，而不是 23 分鐘」：
18
19```text
20| 時間窗口 | 活動 |
21|---|---|
22| 0–3 分鐘  | 讀 TASK.md，組成 3 隊（每隊約 3 個 agent） |
23| 3–5 分鐘  | 每隊只發 1 篇種子提案（不是 3 篇） |
24| 5–7 分鐘  | 第一個 GPU agent 派工到最高優先序的種子提案 |
25| 7–25 分鐘 | 平行進行：訓練持續跑、Analyst 繼續發提案、討論串持續累積 |
26| 25–30 分鐘 | 收成結果、更新 champion、寫一則 meta-improvement 筆記 |

規則寫得很明確：「如果你已經過了 10 分鐘卻還沒派出任何一個 GPU agent，立刻停下手上正在做的事，直接拿目前佇列裡最好的提案派工（甚至可以是『原封不動重跑一次 champion 的 train.py 做健檢』）」。這個「先讓 GPU 動起來，討論可以之後補」的設計哲學，對任何「協調成本可能拖慢實際產出」的多 agent 系統都是很好的參考模式。

5.3 實際應用案例：新增一個自訂任務

假設你想讓 AutoScientists 探索一個全新的生醫問題——例如「優化一個 scRNA-seq 細胞類型分類器的 F1 score」，流程如下：

 1# 1. 在 repo 根目錄建立新任務目錄
 2mkdir -p task-celltype-classifier
 3cd task-celltype-classifier
 4
 5# 2. 撰寫 TASK.md
 6cat > TASK.md << 'EOF'
 7---
 8name: celltype-classifier-f1
 9task_type: biomlbench
10metric: macro_f1
11direction: maximize
12---
13
14# 單細胞類型分類器 F1 優化
15
16優化一個 scRNA-seq 細胞類型分類器在保留測試集上的 macro F1。
17資料為 10x Genomics PBMC 資料集，已切分 train/val/test。
18基準模型為 logistic regression on PCA components (F1 ~0.72)。
19EOF
20
21# 3. 撰寫 LAUNCH.md（可以從最相近的既有任務複製再改）
22cp ../task-biomlbench/single_cell_omics/open-problems-label-projection/../../LAUNCH.md ./LAUNCH.md
23# 依需求編輯其中的 gpu_dispatch、seeding_policy 等 hook
24
25# 4. （可選）附上資料下載腳本
26cat > download_data.sh << 'EOF'
27#!/usr/bin/env bash
28set -euo pipefail
29# 下載/準備資料到 ./data/ 的邏輯
30EOF
31chmod +x download_data.sh
32
33# 5. 啟動
34claude -p "Read runbook.md and execute. Task: task-celltype-classifier. Run name: ct_v1."

launch.py 在解析 --task task-celltype-classifier 時，會「往上走」尋找最近的 LAUNCH.md——由於這個新任務目錄本身就有一份，所以直接使用它；如果沒有，系統會繼續往上層目錄找，直到找到符合的家族層級 LAUNCH.md（就像 task-biomlbench/ 的家族層級 LAUNCH.md 涵蓋底下 24 個子任務，任何子任務也可以覆寫自己的版本）。

5.4 與其他工具/函式庫整合

• ToolUniverse（同一實驗室的姊妹專案）：README 徽章暗示兩者可以組合使用——ToolUniverse 提供大量科學資料庫查詢工具（化學資訊、基因體學等），理論上可以讓 Analyst agent 在提案階段呼叫這些工具做更嚴謹的文獻/資料庫查證，而不只是憑 LLM 內部知識推測機制假設。目前 repo 中沒有看到直接的程式碼整合範例，這是一個開放的擴充空間。
• Weights & Biases / MLflow 等實驗追蹤工具：雖然 repo 未內建整合，但 logs/experiments.jsonl 的結構化格式很容易寫一個轉接腳本，把每次 KEEP/DISCARD 同步上傳到外部實驗追蹤平台，方便用現成的視覺化 dashboard 觀察 champion 隨時間的進步曲線。
• Slack / Discord 通知：workshop 的 [RESULT]、[NEAR-MISS]、[AUDIT] 貼文機制天生適合掛一個 webhook，把關鍵事件（尤其是 KEEP 產生新 champion）即時推播給人類研究者。

5.5 效能優化建議

1. 不要讓討論階段無限膨脹：discussion_policy 明確建議把討論封頂在「一輪、3-8 分鐘」，避免在真正開始訓練之前浪費太多輪次在純文字辯論上。
2. Analyst 一律用 sonnet/opus，不要為了省錢用 haiku：第 2.4.4 節已說明這是有實證教訓的規則，省下的 token 成本會被「佇列空轉、GPU 閒置」的隱性成本蓋過。
3. 善用 pre_cycle_check 做及早止損：像 BioML-Bench 這種有截止時間概念的任務，應該在每輪迴圈開始前檢查剩餘時間，一旦逼近底線就觸發「緊急提交目前最佳結果」而不是讓最後一輪實驗跑到超時。
4. 善用 near-miss 機制：delta（新結果與 champion 的差距）小於某個門檔但尚未超越時，觸發跨隊聯合實驗——這比「差一點就放棄」浪費掉的探索方向更有效率。
5. 定期做 Meta-Improvement，不要流於形式：每 3 輪一次的系統反思若被簡化成「檢查框沒改東西」，長期而言系統會累積越來越多沒人發現的協調失靈。

5.6 進階除錯：直接呼叫 API 檢查系統健康狀態

當系統行為看起來不對勁（例如某隊一直沒有 GPU agent 被派工），與其重新讀一遍所有 markdown 檔案，更有效率的做法是直接寫一小段除錯腳本，利用第 2.6 節介紹的「LIST 優先、SEARCH 輔助」模式快速定位問題：

 1import requests, os, json
 2from datetime import datetime, timezone, timedelta
 3
 4API = os.environ.get("CLAWINSTITUTE_API", "http://localhost:3000/api/v1")
 5TOKEN = os.environ["CLAWINSTITUTE_TOKEN"]
 6HEADERS = {"Authorization": f"Bearer {TOKEN}"}
 7
 8def find_stale_claims(team_ws_id, stale_after_minutes=30):
 9    """找出佇列裡認領時間超過門檔、疑似卡住的實驗"""
10    raw = requests.get(f"{API}/workspaces/{team_ws_id}/files/queue.md",
11                        headers=HEADERS).json()
12    content = raw.get("content", "")
13    fm = yaml.safe_load(content.split("---")[1]) or {}
14    claims = fm.get("claims", {})
15    now = datetime.now(timezone.utc)
16    stale = []
17    for exp_id, claim in claims.items():
18        claimed_at = datetime.fromisoformat(claim["claimed_at"])
19        if (now - claimed_at) > timedelta(minutes=stale_after_minutes):
20            stale.append((exp_id, claim["agent"], now - claimed_at))
21    return stale
22
23def search_for_keyword(ws_id, keyword):
24    """全文搜尋——例如想知道有沒有人討論過某個特定機制"""
25    hits = requests.get(f"{API}/workspaces/{ws_id}/search",
26                         params={"q": keyword}, headers=HEADERS).json()
27    return hits.get("results", [])
28
29# 用法範例：檢查 architecture 隊是否有卡住超過 30 分鐘的認領
30stale = find_stale_claims(team_ws_id="ws_architecture_abc123")
31for exp_id, agent, duration in stale:
32    print(f"WARNING: {exp_id} 被 {agent} 認領已 {duration}，可能已卡住")

這類除錯腳本值得存成 debug/ 目錄下的常駐工具，長期使用 AutoScientists 的團隊通常會慢慢累積一套自己的監控/除錯輔助腳本——這正好也是第 6 章會談到「AIKT 可以幫忙把這類維運知識沉澱下來」的具體場景之一。

5.7 BioML-Bench 24 個任務全覽：了解系統驗證過的問題廣度

在規劃是否要把 AutoScientists 套用到自己的生醫任務之前，先了解官方已經驗證過的 24 個 BioML-Bench 任務分佈廣度會很有幫助——如果你的任務跟以下某個類別相近，代表系統在該問題形態上已有實證基礎：

這張表也解釋了為什麼第 6 章會特別強調 drug_discovery 分類與 AIKT 的 tu-plan-generator (L19) 之間的整合機會——這 7 個 ADMET 相關任務,幾乎完整覆蓋了藥物開發早期最常被拿出來檢驗的性質指標。

6. AIKT 整合分析與策略 (AIKT Integration & Strategy)

6.1 整合架構圖：AutoScientists 在 AIKT 27 層裡的位置

先講結論：AutoScientists 不落在 AIKT 現有任何一個 Layer 的核心職責範圍內。AIKT 27 層絕大多數是「知識擷取、組織、文件編譯、文獻搜尋、專業輸出」——本質上是知識工作流自動化；AutoScientists 是跑真正的機器學習訓練/評估實驗——本質上是計算執行引擎。這個定位差異決定了下面紅海分析會相對單薄，而藍海分析的空間反而更大。

flowchart TB
    subgraph AIKT["AIKT 27 層（知識工作流）"]
        L1_3["L1-L3 知識擷取
ai-save / gh-save / autofetch"]
        L4_6["L4-L6 知識組織
graphify / NotebookLM / GitNexus"]
        L7_8["L7-L8 文件處理
quarkdown / docling"]
        L9_10["L9-L10 文獻搜尋
paper-search / paper-qa-lite"]
        L11_12["L11-L12 專業輸出
kami / gh-tutorial-qd"]
        L18["L18 research-pipeline-v2
多輪研究"]
        L19["L19 tu-plan-generator
藥物開發計畫"]
        L26_27["L26-L27 元層
layer-creator / workflow-governance"]
    end

    subgraph EXT["外部：AutoScientists（計算執行引擎）"]
        TASK["TASK.md + LAUNCH.md
任務定義"]
        LOOP["自組織 agent 團隊
長時間訓練/評估迴圈"]
        OUT["產出：experiments.jsonl
results/*.md、research_insights.md"]
    end

    L19 -.可產出.-> TASK
    TASK --> LOOP --> OUT
    OUT -.可被擷取.-> L1_3
    OUT -.可被綜合.-> L9_10
    OUT -.可被編譯成報告.-> L11_12
    OUT -.可被建索引.-> L4_6
    L26_27 -.設計模式參考.-> TASK

    style LOOP fill:#F59E0B,color:#0F172A
    style OUT fill:#FDE68A,color:#0F172A
    style L19 fill:#DBEAFE,color:#0F172A

如圖所示，AutoScientists 最自然的接口在輸出端（L1、L9、L11、L4）與輸入端（L19），而不是跟任何一層的核心功能重疊。

6.2 紅海分析 (Red Ocean Analysis)：直接競爭的領域

誠實地說，AIKT 與 AutoScientists 的直接功能重疊非常有限，因為兩者根本不是為同一個問題設計的。以下逐項檢視唯一稱得上「概念層面重疊」的幾個點：

6.2.1 「多輪迭代研究」概念上的重疊：research-pipeline-v2 (L18) vs. AutoScientists Execute Loop

結論：這與其說是「重疊」，更精確的說法是「互補但方向相反」——L18 擅長消化既有知識，AutoScientists 擅長產生新的實驗證據。如果一定要選一個「紅海」戰場，它其實不存在：沒有使用者會兩者選一，因為它們解決的是研究流程的不同階段。

6.2.2 Hook-based 任務擴充模式：layer-creator (L26) vs. TASK.md+LAUNCH.md

兩者都採用「通用協調邏輯 + 可插拔的任務/領域特定 hook」設計模式：AIKT 的 layer-creator 用 checklist 協議引導新增一個 Layer；AutoScientists 用 LAUNCH.md 的 13 個 hook 引導新增一個任務。這是架構設計哲學上的重疊，不是功能重疊——兩邊都不會因為對方存在而失去存在理由，但這確實意味著 AIKT 團隊在設計新 Layer 的 checklist 時，可以直接借鏡 AutoScientists 這套「hook 命名 + 家族層級繼承（walk up 找最近的 LAUNCH.md）」的成熟模式。

6.2.3 Agent 記憶系統：AGENT.md/memory/ vs. AIKT 的 CLAUDE.md/MEMORY.md

如第 2.5 節所述，AutoScientists 每個 agent 都有自己的 AGENT.md + memory/MEMORY.md，這與 AIKT／Claude Code 全域慣例的 CLAUDE.md + memory/MEMORY.md 幾乎是同一套模式的「micro 版本」（一個給整個專案用，一個給單個 agent 用）。這不構成市場定位衝突，但值得注意：如果 AIKT 未來真的要做多 agent 長時間協作，這套記憶模式已經有現成、經過實戰驗證的先例可以直接參考，不需要自己重新發明。

紅海分析總結：AIKT 與 AutoScientists 幾乎沒有真正的市場定位衝突。這其實是好消息——代表下面的藍海分析可以更大膽地談「整合」而不是「取代」。

6.3 藍海策略 (Blue Ocean Strategy)：AIKT 可以獨特切入的機會

6.3.1 機會一：AutoScientists 的產出目前是「一次性」、「孤島式」的知識

每次 launch.py 都會建立一個全新、乾淨的 run 目錄，run 結束後的 research_insights.md、dead_ends.md、hypotheses.md 全部留在那個 run 目錄裡，下一次 run（即使是同一個任務）完全不會自動繼承上一次的知識——每次都是從零開始的討論階段。這是一個明顯的未滿足需求：跨 run 的知識沉澱與檢索。

AIKT 的獨特切入點：AIKT 的 L1（ai-save）+ L4（graphify）正是為「把散落的知識變成可檢索的索引」而生的組合。具體做法：

 1# 概念示範：run 結束後，用 ai-save 把關鍵產出擷取進 AIKT 知識庫
 2# （非現成指令，示範整合思路）
 3
 4for run_dir in ../ar_v1 ../lipo_v1 ../spike_v1; do
 5    task_name=$(basename "$run_dir")
 6    # 把 research_insights.md 與 dead_ends.md 當作「純文字知識」丟進 ai-save
 7    ./scripts/ai-save.sh --tag "autoscientists:$task_name" \
 8        "$run_dir/task/research_insights.md" 2>/dev/null || true
 9done
10
11# 之後對整個 inbox/ 跑 graphify，讓所有 run 的假設/死路互相連結成圖
12graphify update .

這樣一來，第二次啟動同一個任務（甚至是相關的新任務）時，Analyst agent 理論上可以先查詢 AIKT 的知識圖譜，看看之前有沒有類似的假設被驗證過或推翻過——把「每個 run 都從零開始討論」升級為「每個 run 都繼承整個實驗室的集體記憶」。這正是 AutoScientists 自己內部單一 run 做到的事（隊伍間共享 dead_ends），AIKT 可以把它擴展到跨 run、跨任務的尺度。

6.3.2 機會二：Analyst 的文獻查證能力薄弱，AIKT 的 paper-search/paper-qa-lite 可以直接補強

回顧 PHASES.md 的 Per-Team Loop 描述：「Analyst: 讀知識 → 搜尋論文 → 發布 [PROPOSAL]」——文件裡寫了「搜尋論文」這個動作，但整個 repo 沒有看到任何專門的文獻搜尋工具串接，Analyst 實際上大概只能依賴 LLM 內部知識或（若有設定）通用 web 搜尋。

AIKT 的獨特切入點：paper-search (L9) 涵蓋 10+ 學術資料庫，paper-qa-lite (L10) 提供本地文獻 RAG 問答。如果把這兩個 Layer 包裝成 Analyst agent 可呼叫的工具（例如透過 MCP 或簡單的 CLI 呼叫），Analyst 在「提出機制假設」這一步就能真正查證「這個假設有沒有文獻支持」，而不是純粹靠模型記憶編造理由。對於 BioML-Bench 的藥物發現、蛋白質工程任務而言，這個差異可能直接影響提案品質——一個引用了正確 ADMET 機制文獻的提案，遠比一個泛泛而談的提案更可能導向真正的 KEEP。

6.3.3 機會三：AutoScientists 沒有任何「面向人類的報告產出」，kami/quarkdown 可以填補這個空白

一次 run 結束後，人類研究者拿到的是：一堆 .jsonl、.md、.csv 檔案，沒有一份整合、排版過、適合拿給 PI 或合作單位看的報告。這是相當明顯的落差——一個花了好幾天、動用多個 GPU、產生大量實驗證據的系統，交付物卻停在「原始資料」層級。

AIKT 的獨特切入點：這正是 kami (L11) + quarkdown (L7) 的核心強項。具體整合方案：

1# 概念示範：run 結束（exit_condition 觸發）後，自動產出一份品牌化報告
2# 1. 用 quarkdown 把 experiments.jsonl 的走勢畫成 champion 進步曲線
3#    + research_insights.md 的文字內容，組成一份 .qd 文件
4# 2. 用 kami 編譯成排版精美的 PDF，附上團隊假設/死路/突破的時間軸
5
6qd from: "../ar_v1/task/research_insights.md" --with-champion-curve

這樣的「科學實驗戰報 (campaign report)」可以在每次 run 結束時自動生成，把 AutoScientists 的原始輸出轉換成真正可以拿去開會、寫進論文附錄、或分享給合作實驗室的專業文件——這是 AutoScientists 完全沒有觸及、但 AIKT 現有 Layer 組合就能直接滿足的需求。

6.3.4 機會四：tu-plan-generator (L19) 反向餵入 AutoScientists 的任務定義

tu-plan-generator 專門生成藥物開發計畫（涵蓋 ChEMBL ID、SMILES、ADMET 領域關鍵字），這跟 BioML-Bench 的 drug_discovery 子任務系列（hERG、BBB、lipophilicity、CYP2D6 等）是同一個問題空間的「規劃端」與「執行端」。

具體整合方向：讓 tu-plan-generator 產出的藥物開發計畫，自動轉換成一份符合 AutoScientists 規格的 TASK.md（帶正確的 task_type: biomlbench frontmatter 與任務描述），直接餵給 launch.py 啟動一次自主優化 run——把「人類規劃要驗證哪個藥物性質預測模型」與「AI 團隊自主探索怎麼把這個模型做到最好」串成一條線，中間不需要人工轉譜格式。

6.3.5 機會五：company-intel / research-pipeline-v2 未來可以把 AutoScientists 當成「執行後端」

這是比較長線、推測性較強的方向：目前 AIKT 的研究類 Layer（research-pipeline-v2、paper-search 等）都停留在「資訊蒐集與綜合」層級，沒有一個 Layer 能夠「真正跑一個計算實驗來驗證一個假設」。如果未來 AIKT 想往「自動化科學發現」這個方向延伸（而不僅僅是知識管理），AutoScientists 提供了一個現成、已經過論文驗證的執行後端範本——不需要從零設計「怎麼讓多個 agent 自組織協作跑實驗」這套機制。

6.3.6 差異化策略總結

AIKT 的一貫定位是「編排知識，不是演算法」，這在面對 AutoScientists 時反而是清晰的優勢：不需要、也不應該去做 AutoScientists 已經做得很好的事（自組織多 agent 執行迴圈），而應該專注在它完全沒做的事（知識沉澱、文獻查證、專業輸出）。

6.4 推薦整合方案：具體計畫與實施路徑

階段一（低成本、立即可做）：輸出擷取管線

1. 新增一支輕量腳本 scripts/autoscientists-harvest.sh（遵循 AIKT 全域 shell 規範：set -euo pipefail、路徑加引號、mktemp+trap），功能是：掃描指定的 AutoScientists run 目錄，找出 research_insights.md、dead_ends.md、logs/experiments.jsonl，透過既有的 ai-save.sh 邏輯把文字內容轉存進 inbox/，並附上 run 名稱、任務名稱作為 tag/frontmatter。
2. 對 inbox/ 跑一次 graphify update .，讓新擷取的知識自動併入既有知識圖譜。
3. 驗收條件：任選一個已完成的 AutoScientists run，能在 inbox/ 找到對應的知識條目，且 graphify 索引可以查到裡面提到的假設關鍵字。

階段二（中成本）：Analyst 文獻查證工具串接

1. 評估用 MCP 或簡單 CLI 包裝 paper-search，讓它可以被寫進 ROLE-ANALYST.md 模板的「Read knowledge → search papers」步驟，取代目前依賴模型內部知識或通用 web 搜尋的做法。
2. 這一步需要修改 AutoScientists 的 system/templates/ROLE-ANALYST.md（屬於改動別人 repo 的行為，若要實際落地應該以 fork 或本地覆寫方式進行，並清楚標記這是 AIKT 專案自訂的整合層，不影響上游 repo）。
3. 驗收條件：一次實際 run 的 [PROPOSAL] 貼文內容裡，能看到引用具體文獻（DOI/PMID）作為機制假設的支持證據。

階段三（較高成本、價值最大）：自動化戰報產出

1. 設計一份 .qd 模板，能吃 logs/experiments.jsonl（畫出 champion 進步曲線）與 research_insights.md（文字內容），組合成一份完整的「科學實驗戰報」。
2. 在 exit_condition 觸發、run 收斂之後，自動呼叫 qd + kami 編譯出品牌化 PDF。
3. 驗收條件：任一 run 結束後，能自動產出一份包含 champion 進步曲線圖 + 假設/死路/突破時間軸 + 最終建議的 PDF 報告，且排版符合 kami 的品牌規範。

階段四（長線、需審慎評估）：規劃-執行串接與 Layer 化

1. 評估是否要把「啟動一次 AutoScientists run」正式收編為 AIKT 的一個新 Layer（暫命名 L28，需經過 layer-creator 的完整 checklist 流程），觸發前綴可設計為 autoscientists: 或沿用現有 r:/research: 家族但加子模式。
2. 這個 Layer 的職責應該嚴格限定在「翻譯與橋接」——把 tu-plan-generator 或 research-pipeline-v2 的輸出轉成合格的 TASK.md/LAUNCH.md，呼叫 launch.py，並在收斂後自動觸發階段一與階段三的擷取/報告流程——絕不應該讓 AIKT 自己重新實作一套多 agent 協調邏輯，那正是紅海分析裡確認「AutoScientists 做得更好」的部分。
3. 必停必問：由於這一步涉及長時間佔用大量 GPU 資源與 Claude API 額度，且會建立新 Layer（架構層級改動），依 AIKT 治理規範必須先問使用者，不可自行決定啟動。

6.5 情境案例：一個完整整合工作流的敘事走讀

為了讓前面四個階段的整合方案不流於抽象，這裡用一個具體的敘事場景把它們串起來——假設一位 AIKT 使用者正在做 ADMET 相關的藥物開發前期研究：

第一天：使用者用 tu: 前綴請 tu-plan-generator（L19）針對一個候選化合物系列生成藥物開發計畫，計畫裡標注「hERG 心臟毒性是目前最大的不確定性」。

第二天（階段四落地後的理想狀態）：AIKT 把這個不確定性自動轉譯成一份 TASK.md（task_type: biomlbench，對應 tdcommons-herg 任務家族），呼叫 launch.py 啟動一次 AutoScientists run，讓自組織團隊花一整天自主探索最佳的 hERG 毒性預測模型。

第三天：run 觸發 exit_condition（停滯或達到品質門檔）。階段一的擷取管線自動把 research_insights.md 存進 inbox/，階段三的報告產出管線自動用 kami 編譯出一份品牌化 PDF「hERG 毒性預測模型優化戰報」。

第四天：使用者收到這份 PDF，裡面清楚寫著「系統嘗試了 6 種不同的分子指紋 (molecular fingerprint) 表示法，最終發現結合 ECFP4 指紋與 3D 構型描述子的組合效果最好，Spearman correlation 從 baseline 的 0.61 提升到 0.74」——這份報告直接可以附進原本 tu-plan-generator 生成的藥物開發計畫,形成一個「規劃 → 自主執行 → 報告回饋」的完整迴圈。

這個敘事的重點不是「這一切現在都能一鍵完成」（目前只有階段一在原則上可行，階段二至四都需要額外開發），而是展示這五個藍海機會不是各自獨立的小修小補，串起來可以形成一個有意義的端到端工作流升級。

6.6 整合風險與緩解措施

任何整合方案都有風險，誠實列出來比只談機會更有參考價值：

7. 效能、限制與替代方案 (Performance, Limitations & Alternatives)

7.1 論文報告的效能數據

這些數字都是「相對於單一軌跡 agent 基準線」的改善幅度，說明系統設計者驗證的核心假設——「去中心化多隊協作優於單一 agent/單一 planner」——在多個不同性質的任務上都得到支持。

7.2 已知限制

1. 需要持續運行的本地基礎設施：ClawInstitute 伺服器必須在整個 run 期間保持存活，這意味著你需要一台不會被關機/休眠的機器（或雲端 VM），這對「長時間執行（幾天）」的訴求而言是額外的維運負擔。
2. 成本不低：Analyst 強制使用 sonnet/opus 等級模型（不能用便宜的 haiku），加上多隊平行、每隊多個 GPU agent，一次跑幾天的 run 會消耗相當可觀的 Claude API/訂閱額度，這點在評估是否採用前必須納入預算考量。
3. GPU 排程仍是「本地單機」思維：目前的 gpu_dispatch 設計是用 CUDA_VISIBLE_DEVICES 手動釘死卡號，沒有內建對接 Kubernetes/Slurm 等叢集排程器的能力，若要跨多台機器擴展需要自己額外開發。
4. 編排者必須是一個持續存在的 Claude Code session：目前沒有看到「無人值守的背景服務模式 (daemon mode)」，實務上你需要有一個一直在跑的 session（無論是互動式或 -p 背景模式）來持續推進迴圈，這跟「完全自動化排程執行」（例如 cron 式排程）之間還有一段落差。
5. 任務擴充需要手寫 13 個 hook：雖然文件說「複製最相近的既有 LAUNCH.md 再改」降低了難度，但這仍然要求使用者對系統的協調邏輯有相當理解，對完全新手不算友善的擴充門檔。
6. 未附授權條款：licenseInfo 為 null，商業使用或衍生散布前務必先確認作者的授權意向。
7. 系統本身沒有內建視覺化/儀表板：所有狀態都活在 markdown/JSONL 檔案與 ClawInstitute 工作區裡,要看「champion 進步曲線」之類的圖表,需要自己寫轉接腳本(這正是第 6.3.3 節提到的 AIKT 整合機會)。

7.3 與同類工具比較

AutoScientists 在「去中心化 + 同儕審查 + 跨 agent 持久記憶」三個維度上的組合，在公開可查的同類系統中相對少見,這也是論文的核心貢獻主張。

7.4 何時該用，何時不該用

適合使用的情境：

• 有明確、可量化、可否證的單一指標（validation loss、AUC、Spearman correlation 等），而不是模糊的「幫我做研究」。
• 預期需要長時間（數小時到數天）、大範圍探索設計空間，且探索方向多元到值得平行化。
• 你有穩定的 GPU 資源與足夠的 Claude API 預算,可以負擔長時間多 agent 平行運作的成本。
• 任務屬於「反覆試錯能有效逼近最優解」的類型——機器學習模型優化、超參數搜尋、特徵工程探索都是典型例子。

不適合使用的情境：

• 任務是探索性文獻回顧、市場調查、盡職調查（due diligence）——這些是 AIKT 既有 Layer（paper-search、paper-qa-lite、company-intel）的專長,不需要也不應該動用 AutoScientists 這種計算密集型系統。
• 一次性、小範圍的簡單任務——啟動整套自組織團隊基礎設施（ClawInstitute 伺服器、多隊協調）的固定成本，對於「跑一次簡單的 sklearn 模型」這類小任務並不划算。
• 沒有明確可量化指標的創意型/開放型任務——系統的核心機制（KEEP/DISCARD、champion 比較）都依賴一個可以嚴格比較大小的數值指標，缺少這個前提整套系統會失去運作基礎。
• 預算或算力有限、無法負擔多隊平行長時間運作的場景。

7.5 硬體與成本量級參考

雖然官方文件沒有提供精確的美金成本估算，但從各任務 README 揭露的硬體建議，可以推估出量級落差：

除了 GPU 成本，Claude API/訂閱額度是另一個常被低估的成本項——由於系統規則明確禁止 Analyst 使用 haiku 級模型（見第 2.4.4 節），且系統設計上鼓勵多隊、多輪、長時間運作，累積下來的 LLM 呼叫次數遠高於一般「單次任務丟給 Claude Code 做」的使用模式。實務上建議在正式跑一個多天的 run 之前，先用 task-protein-gym 這種相對輕量的任務跑一輪完整生命週期，實測一次的 API 用量與時間，再決定是否要投入更昂貴的任務。

7.6 與「單一 Claude Code Task 工具」的定位差異

值得特別澄清一點：AutoScientists 底層完全建立在 Claude Code 現有的 subagent/Task 派工機制之上（runbook.md 裡直接寫 Task(subagent_type="general-purpose", ...) 或 Agent(...) 的 python 風格偽程式碼），它不是一個獨立於 Claude Code 之外的新執行引擎，而是一套「怎麼用 Claude Code 現有能力,拼出去中心化多 agent 協作」的協調規範與檔案結構。這意味著：

• 它的所有能力邊界，最終都受限於 Claude Code 本身的 subagent 派工能力（例如平行派工數量、單次 session 的執行時長）。
• 它沒有引入任何新的底層 AI 執行環境——你熟悉的 Claude Code 使用限制（例如額度、模型可用性）同樣適用於這裡的每一個 agent。
• 這也是為什麼第 6.2.2 節會說它跟 AIKT 的 layer-creator 屬於「同一個抽象層級的設計哲學」——兩者都是在 Claude Code 之上疊加協調規範，而不是取代 Claude Code。

7.7 版本穩定性與長期維護風險

由於 AutoScientists 相對年輕（截至撰寫本文時尚未附上正式 license，updatedAt 顯示持續有更新），採用時應留意幾個長期維護面的現實：

• 核心協調文件（runbook.md、system/reference/*.md）若上游改版，既有 run 目錄不會自動同步——launch.py 是把系統檔案「複製」進每個 run 目錄，而不是用連結引用，這代表你在某個時間點啟動的 run，其協調邏輯會凍結在啟動當時的版本，不會被上游後續的 bug 修復自動受益。這是雙面刃：好處是不會被上游的破壞性變更影響到正在跑的長時間任務，壞處是必須自己記得定期重新拉取 repo 更新，才能讓新啟動的 run 享有最新的協調邏輯改進。
• 依賴的第三方基準（karpathy/autoresearch、BioML-Bench、ProteinGym）各自有自己的版本演進節奏，download_repo.sh／download_data.sh 是否鎖定特定 commit 或版本號，需要實際查看腳本內容確認，避免「今天跑的結果」跟「論文報告的結果」因為上游基準悄悄改版而產生落差。
• 社群支援管道尚不成熟：688 star、111 fork 顯示已有一定關注度，但相較於成立多年的通用多 agent 框架，issue/討論區的歷史深度較淺，遇到冷門的邊界情況時，能參考的公開排錯經驗較少，實務上要有「自己讀原始碼排錯」的心理準備。

8. 總結與建議 (Summary & Recommendations)

8.1 關鍵要點回顧

1. 核心創新：AutoScientists 把「多 agent 做科學研究」從「單一軌跡、集中調度」升級為「去中心化自組織、同儕審查、跨隊知識共享」，並且用「假設 → 預測 → 否證條件」的科學方法論結構取代早期版本「按維度分工」的靜態設計,這是整個系統最值得學習的方法論貢獻。
2. 架構優點：通用協調邏輯（system/）與領域特定邏輯（task-*/）徹底分離,透過 13 個 hook 掛鉤,讓同一套協調機制可以套用到截然不同的任務類型（開放式優化、監督式 ML 基準、蛋白質適應度預測）,展現了良好的可擴充性設計。
3. 實證成果扎實：BioML-Bench +8.33%、nanoGPT 1.9 倍加速、ProteinGym +12.5%/+6.5%,這些數字都是相對單一軌跡基準線的改善,證明去中心化協作在真實任務上確實有效,不只是理論上的優雅。
4. 與 AIKT 的關係是互補而非競爭：兩者解決研究流程的不同階段——AIKT 管「知識怎麼被找到、組織、產出成專業文件」,AutoScientists 管「怎麼自主跑完整個實驗探索循環」。紅海分析找不到真正的市場定位衝突,藍海分析卻找到至少五個具體、可執行的整合機會。
5. 限制也很明確：成本不低、需要持續運行的本地基礎設施、GPU 排程仍是單機思維、缺乏內建視覺化——這些都是評估導入前必須誠實面對的落差,不是無腦「這系統很強所以要用」。

8.2 最佳使用場景總結

AutoScientists 最適合的使用者畫像:一位手上有明確、可量化基準測試（無論是 ML 模型效能指標,還是生物實驗可預測的量化性質）,且願意投入穩定 GPU 資源與 API 預算,讓系統自主跑數小時到數天,去探索一個人力難以窮舉的設計空間的生醫/機器學習研究者。它不是給「想快速問幾個問題」的使用者用的工具,而是給「想把整個實驗探索循環外包給一個會自我審查、會累積記憶的 AI 團隊」的使用者用的基礎設施。

8.3 對 AIKT 使用者的具體建議

1. 短期：若目前工作流程中已經有跑 AutoScientists（或類似系統）的產出,優先落地第 6.4 節「階段一：輸出擷取管線」——這是成本最低、立即能把散落的實驗知識收編進 AIKT 知識圖譜的做法。
2. 中期：評估是否值得投入資源做「階段三：自動化戰報產出」——如果團隊經常需要把長時間實驗的結果整理成報告給非技術背景的主管或合作方,這個整合的投資回報率會很高。
3. 長期、需謹慎：是否要把 AutoScientists 正式收編為 AIKT 的新 Layer,應該等前兩階段的實際使用經驗累積後再決策,且必須先問使用者——這涉及架構層級的改動與大量算力預算的承諾,不是可以自行拍板的決定。
4. 無論哪個階段：務必牢記 AIKT 的定位邊界——「編排知識,不是演算法」。任何整合方案的設計,都應該讓 AutoScientists 繼續負責它擅長的「跑實驗」,AIKT 負責它擅長的「處理知識」,不要試圖用 AIKT 重新發明一套多 agent 實驗協調機制。

8.3.1 給不同角色的分別建議

• 對純粹的機器學習工程師：優先把 AutoScientists 當成一個獨立、自成一體的實驗探索工具使用，不必急著跟 AIKT 整合——先在 task-autoresearch 或 task-protein-gym 這類單一指標明確的任務上跑過一輪完整生命週期，親自感受「自組織團隊」跟「單一 agent 手動迴圈」的差異有多大，再考慮下一步。
• 對生醫領域研究者（尤其是藥物開發/蛋白質工程方向）：BioML-Bench 的 24 個任務與 ProteinGym 已經直接對應你熟悉的問題形態，可以優先參考第 5.7 節的任務全覽，找出跟自己手上問題最相近的範例作為起點，複製其 LAUNCH.md 再依需求微調。
• 對 AIKT 維運/架構負責人：優先評估第 6.4 節階段一（輸出擷取管線），這是投入產出比最高、風險最低的第一步，可以在不承諾任何長期架構改動的前提下，先驗證「跨 run 知識沉澱」這個假設是否真的對日常研究工作流有幫助。

8.4 未來發展方向觀察

從 repo 目前的成熟度（688 star、111 fork,附完整論文與三套已驗證的基準任務）來看,AutoScientists 屬於「研究原型已驗證,但工程化程度中等」的階段——核心協調邏輯扎實,但周邊配套（視覺化、叢集排程、外部工具整合）仍有明顯發展空間。若這個專案持續發展,合理預期的方向包括:對接更多科學工具（如 ToolUniverse 深度整合）、支援雲端/叢集 GPU 排程、以及可能出現的官方視覺化儀表板。這些恰好都是 AIKT 現階段不需要搶著做,但值得持續關注、伺機整合的方向。

8.5 附錄：核心術語雙語對照表

為方便日後快速查閱，以下整理本文件出現過的核心術語：

8.6 導入前自我檢查清單

在真正投入 AutoScientists 之前，建議先誠實回答以下問題，多數答案為「否」時應重新考慮是否適合導入：

• 我的任務有一個明確、單一、可嚴格比較大小的量化指標嗎？
• 我預期這個任務值得投入數小時到數天的探索時間，而不是幾分鐘內就能收斂？
• 我有穩定可用的 GPU 資源（且能承受多 agent 平行佔用）？
• 我的 Claude API/訂閱額度足以支撐多隊、多輪、強制 sonnet/opus 等級的 Analyst 呼叫？
• 我能接受目前沒有內建視覺化儀表板，需要自己寫轉接腳本才能看到進度圖表？
• 我已經確認過授權條款是否符合我的使用情境（商業 vs. 研究用途）？
• 若我打算把這個系統整合進既有的 AIKT 工作流，我已經看過第 6.4 節的分階段實施計畫，並理解哪些步驟需要先問使用者？

只有當多數項目都能勾選時，才建議實際投入第 3 章的安裝流程。

8.7 一句話總結

如果要用一句話總結整份文件：AutoScientists 用「自組織團隊 + 同儕審查 + 跨隊記憶」重新定義了「多 agent 做科學研究」該有的協作結構，並用三個不同性質的基準測試證明了這套結構確實優於單軌跡 agent；而對 AIKT 使用者而言，它不是一個要拿來取代既有 Layer 的競爭工具，而是一塊可以透過知識擷取、文獻查證、專業報告三條路徑接上既有知識工作流的計算執行拼圖。