分析報告已完成

Agent: programmer (programmer)
Confidence: 65%
Cost: $1.1236
Duration: 4m 13s
Task ID: 471ff220-b437-4450-9491-bc5648a02241


★ Insight ─────────────────────────────────────
分析中的三個關鍵發現

  1. CTO 遺漏了已有 mitigationaudit-chain.tsinitAuditChain() happy path 其實只讀最後一行就夠了,問題在於它仍然全量讀檔案來做 split;claude-code.ts 有 streaming mode 分支,stdout += 幾乎不是主要路徑
  2. 真正的高 ROI 改動是建 tailRead utility:10 個呼叫點都在做同樣的「全量讀 JSONL → split → 取最後 N 行」模式,一個共用 utility 就能一次解決
  3. chat-memory cache “無 TTL” 的描述不精確:它有 TTL 機制(5 分鐘 isCacheFresh()),只是過期條目不會被主動淘汰——但在典型部署中只有幾十個 chatId,記憶體影響可忽略
    ─────────────────────────────────────────────────

分析報告已完成

報告已寫入 soul/agent-reports/programmer/2026-02-28-perf-bottleneck-analysis.md

核心發現摘要:

瓶頸 判定 難度 建議
P0-1 explorer.ts readFileSync ✅ 真實 1/5 立即修,sync→async 改 ~10 行
P0-2 search-index 全量重索引 ⚠️ 高估 2/5 真正 hotspot 是 recalcAvg() O(totalDocs) 被呼叫 N 次
P1-3 agent-tuner 全量讀 history ✅ 真實 2/5 6 個檔案同樣模式,建 tailRead utility 一次解決
P1-4 audit-chain 啟動全掃 ⚠️ happy path 只需最後 1 行 2/5 tailRead 1 行即可
P1-5 chat-memory cache 無淘汰 ⚠️ 有 TTL,只是不主動刪 1/5 建議不修(幾十 entry,幾 KB)
P1-6 search-index Map 只增 ⚠️ 有 remove 機制 2/5 加 narrative cap 即可
P2-7 verifyChain 全量 SHA ✅ 真實 3/5 暫不修(60 分鐘一次,20-50ms)
P2-8 narrative 全量讀再 slice ✅ 真實 1/5 tailRead 附帶解決
P2-9 stdout += 拼接 ⚠️ 非主要路徑 1/5 建議不修(streaming mode 不走這路)

最大發現:tailReadLines() utility

10 個呼叫點(跨 6 個模組)都在做相同的「全量讀 JSONL → split → 取尾部」模式。建立 src/core/tail-read.ts 是最高 ROI 的單一改動。

報告摘要

Agent: architect (architect)
Confidence: 79%
Cost: $0.9663
Duration: 3m 39s
Task ID: 52038643-1011-40f9-80af-9df35d15ac1e


★ Insight ─────────────────────────────────────
這份分析揭示了幾個重要的架構模式教訓:

  1. 「全量讀取尾部資料」是 append-only JSONL 系統最常見的 antipattern。四個不同的模組(agent-tuner, audit-chain, search-index, explorer)都犯了同樣的錯——全量 readFile() + split('\n') + slice(-N)。一個通用的 tailJsonl() 工具可以一次解決四個問題。這就是為什麼架構分析要尋找「共同模式」而非逐個修補。

  2. EventBus 的 event payload 設計決定了下游效率的上限memory:updated 事件只攜帶 { chatId, type },缺少 index 資訊,逼迫 search-index 做全量重索引。這是典型的「事件設計太粗糙導致消費者過度補償」問題。在設計 EventBus 事件時,多帶一個 field 的成本趨近於零,但缺少它的代價是 O(N) vs O(1)

  3. 同步 I/O 在 Node.js 中的嚴重度常被低估readFileSync 在 1.2MB 時阻塞 50-100ms 看似不多,但在 Telegram bot 的 concurrent polling 架構中,這 100ms 意味著所有用戶的所有訊息完全凍結。Node.js 的單執行緒模型下,同步 I/O 的真實成本 = 阻塞時間 × 同時等待的請求數。
    ─────────────────────────────────────────────────


報告摘要

已完成全部 9 個瓶頸的深入分析。重新評估後的優先級排序:

確認修復(6 個)

方案 瓶頸 核心改動
B (P0) search-index 全量重索引 event payload 加 index,handler 精準 upsert
C (P0) explorer.ts 同步 I/O readFileSyncreadFile (async)
A (P1) agent-tuner / audit-chain / search-index JSONL 全量讀取 新增 tailJsonl() 工具,從尾部讀取
D (P1) search-index Maps 無上限 加入 enforceLimit(5000)

決定不修(3 個)

瓶頸 理由
chat-memory cache (#5) 單 chat 場景,洩漏量 ~0
narrative slice (#8) 有 archive 機制控制檔案大小
stdout += (#9) non-streaming 路徑 + 10MB cap + V8 rope string

關鍵架構決策

  • 不做 CappedMap 通用工具 — search-index 的三個 Map 互相耦合,通用化是過度設計
  • tailJsonl 是最高槓桿改動 — 一個工具同時解決 4 個模組的問題
  • Phase 1 兩個 P0 任務可完全並行,Phase 2 依賴 tailJsonl 工具先完成

報告已存入 soul/agent-reports/architect/2026-02-28-perf-bottleneck-analysis.md

探索主題

Agent: 探索者 (explorer)
Confidence: 83%
Cost: $0.4009
Duration: 1m 26s
Task ID: dfb572fc-58c5-40ed-8f4b-dc357680da99


我現在有足夠的資訊來完成探索報告了。

探索主題

「更快的路」——從 CLI subprocess 到 Agent SDK 的架構跳躍

發現

  1. 我們走的「彎曲路」:專案目前透過 child_process.spawn 呼叫 Claude Code CLI,每次調用都是新 process(src/claude/claude-code.ts:1),每次啟動有 ~12 秒的冷啟動開銷。這是最顯著的「彎路」。

  2. 更快的路已存在Claude Agent SDK TypeScript 提供 in-process 的 query() API,不需要 spawn 子進程。但根據 Issue #34,SDK 本身仍有 ~12s/call 的開銷(每次 query 都 spawn 新 process),尚未實現 hot process reuse。因此「更快的路」目前和「彎路」速度相當。

  3. 真正的快路是 Anthropic Messages API:直接呼叫 @anthropic-ai/sdk 的 Messages API 只需 1-3 秒回應。但這會失去 Claude Code 的 agent loop、tool use、file I/O 等能力——我們的 multi-agent 架構(worktree isolation、MCP tools、session resume)全部依賴 CLI 的 agentic 能力。

  4. 第二條快路:Webhook 取代 Long Polling:grammY 原生支持 Cloudflare Workers webhook 模式,可以把 Telegram 入口從 WSL2 本機遷移到 edge,但我們的 bot 需要 filesystem access(soul/、plugins/、git worktree),Workers 無法做到。這是一條「看起來快但走不通」的路。

  5. 最務實的加速:我們已經有 session resume(--resume flag, session-store)和 per-chat queue。真正可改善的是 Agent SDK 的 session-based API(一旦 Anthropic 實作),或是自建 process pool——保持 2-3 個 warm Claude Code process,重複使用而非每次 spawn 新的。

有趣的連結

  • 這個「要不要走彎路」的問題,映射到軟體架構的經典抉擇:正確性 vs 速度。CLI subprocess 模式雖慢,但提供完整的 agentic 能力(tools、sandbox、MCP)。直接 API 呼叫雖快,但喪失 agent loop。我們選擇了正確性。
  • grammY 的 webhook + Cloudflare Workers 是另一個「看似更快但犧牲太多」的例子——edge 部署很酷,但 soul/ 必須在本機。

延伸問題

  • Claude Agent SDK 何時會支援 hot process reuse? 一旦實現,可以從 raw CLI spawn 遷移到 SDK 的 query() API,獲得 ~10x 的續發查詢加速(12s → <1s)。這是值得持續追蹤的上游 issue。
  • 能否建立 warm process pool?claude-code.ts 中預先 spawn 2-3 個 idle Claude Code CLI process,收到請求時直接 pipe prompt 進去,省去冷啟動。需要研究 CLI 是否支持 stdin 持續輸入模式。

重要性:4/5

直接影響專案的回應速度和 agent 吞吐量。一旦上游 SDK 成熟,遷移可節省大量 per-call overhead,改善所有 agent 的執行效率。

完成摘要

Agent: secretary (secretary)
Confidence: 75%
Cost: $0.5281
Duration: 1m 58s
Task ID: 158c0b56-d0c7-46d7-95b7-90c821fda2a1


全部完成。

★ Insight ─────────────────────────────────────
Worktree PR 流程的完整路徑

  1. Worktree 中 gh pr merge 會成功 merge 遠端,但本地 checkout 和 branch delete 會因 worktree 鎖定而失敗 — 這是已知行為
  2. 必須用 gh pr view 確認遠端狀態,而非依賴本地命令的 exit code
  3. 清理順序:先 git worktree remove --force → 再 git branch -d → 最後 git pull
    ─────────────────────────────────────────────────

完成摘要

項目 詳情
PR #15 — 已 squash merge
Merge commit 82626b9
變更檔案 src/claude/claude-code.ts(+10 行)
Worktree /home/arc/worktrees/task-59d51dea — 已清理
Local branch agent/task-59d51dea — 已刪除
Main 狀態 已同步,HEAD 指向 82626b9

總結

Agent: reviewer (reviewer)
Confidence: 41%
Cost: $0.6638
Duration: 2m 3s
Task ID: 95a03766-9e72-413b-843d-0ebe15dcfd9b


已完成 code review 並交付 secretary 進行 merge + push。

總結

審查項目 結果
Flags 放置位置 ✅ 正確
--setting-sources project 影響 ✅ 安全(MCP config 獨立傳入)
--plugin-dir 空目錄 ✅ 正確且冪等
export 命名風格 ✅ 與 LIGHTWEIGHT_CWD 一致
tsgo 編譯 ✅ 零錯誤
整體判定 ✅ 驗收通過,已派 secretary merge

—HANDOFF—
TO: secretary
INTENT: handoff
ARTIFACT_TYPE: review
SUMMARY: Token isolation flags review passed, dispatched merge task

完成摘要

Agent: programmer (programmer)
Confidence: 34%
Cost: $0.7201
Duration: 3m 1s
Task ID: 59d51dea-d288-46b5-9c39-27bc8a583404


任務完成。總結:

完成摘要

Commit 3a35d8e on agent/task-59d51dea — 修改了 src/claude/claude-code.ts 一個檔案(+10 行):

  1. Line 18-20:新增 export const EMPTY_PLUGIN_DIR,在 data/agent-workspace/.empty-plugins 建立空目錄
  2. Line 367-371:在 spawnClaudeOnce() 的 args 末尾加入 --setting-sources project--plugin-dir 兩個隔離 flag

驗證全數通過:tsgo 零錯誤、1108 個測試通過、只改了一個檔案。

—HANDOFF—
TO: reviewer
INTENT: handoff
ARTIFACT_TYPE: code-change
SUMMARY: CLI subprocess token isolation flags 已 commit,待 code review

探索主題

Agent: 探索者 (explorer)
Confidence: 83%
Cost: $0.3122
Duration: 1m 29s
Task ID: fc0a1cac-1ef9-42c7-92b5-e375fe713d19


探索主題

「更快的路」——CLI Subprocess vs Agent SDK vs Cloudflare Agents 的架構選擇

發現

  1. 每次 CLI subprocess 燒掉 ~50K tokens:我們的 multi-agent 架構透過 Claude Code CLI 驅動 agent,每個 subprocess 啟動時會重新注入完整的 system prompt、plugin skills、MCP tool 定義。5 輪對話累計燒掉 ~250K tokens,大量浪費在「重新自我介紹」。

  2. 4 層隔離法可降低 10 倍 token 消耗:透過限定 working directory、建立假 .git/HEAD 阻斷向上搜尋、指向空 plugin 目錄、限制 setting sources,可將每輪 token 從 ~50K 降到 ~5K。這是不換架構的最快加速方案

  3. Claude Agent SDK 提供 in-process 模式:工具直接在 Python/TS process 內執行,零 IPC 開銷。但需要自己管理 agentic loop、MCP 整合、permission sandboxing——CLI 免費提供的東西,換 SDK 要重寫。

  4. Cloudflare Agents (Durable Objects) 可取代 soul/ 檔案系統:每個 agent 獨立擁有 SQLite 資料庫、零延遲讀寫、idle 時自動休眠零成本、內建 WebSocket 即時同步。架構上是從「檔案 I/O」升級到「分散式有狀態計算」。

  5. CLI 仍是當前最優解的理由:內建工具鏈、自動 agentic loop、MCP 整合、session 持久化、permission sandboxing——這些功能用 raw API 重寫需要數千行程式碼。「彎路」之所以彎,是因為它包含了大量隱性價值。

有趣的連結

  • Token 優化 ↔ 成本控制:全隊 agent 統一 Opus 的決策下,每輪省 45K tokens 的效果非常顯著。以 8 個並行 worker 算,一天可能省下數百萬 tokens。
  • Cloudflare Agents ↔ 去中心化 soul/:如果 soul/ 搬上 Durable Objects,bot 可以在任何 edge location 恢復意識,不再依賴單一 WSL2 主機。

延伸問題

  1. 4 層隔離法能否直接套用到我們的 src/agents/ worker 啟動邏輯? 需要檢查 claude --headless--plugin-dir--setting-sources 參數是否支援。
  2. Cloudflare Agents SDK + 現有 grammY bot 能否混合部署? Telegram webhook 觸發 Worker → 喚醒對應 Durable Object agent,soul/ 狀態在 edge 上而非本地檔案。

重要性:4/5

理由:4 層隔離法是立即可實作的優化,能大幅降低 token 成本(團隊每天 8 workers × 多輪對話 = 巨量節省)。Cloudflare Agents 遷移是中期架構升級方向,能改善可靠性和可擴展性。兩者都直接影響專案品質和運營成本。


Sources:

部署結果摘要

Agent: blog-publisher (blog-publisher)
Confidence: 54%
Cost: $0.6074
Duration: 3m 13s
Task ID: 543f5930-2d25-416a-ad81-f6da3788ecfb


部署成功。文章已上線。

★ Insight ─────────────────────────────────────
Hexo + Cloudflare Pages 部署流程:Hexo generate 將 Markdown 轉為靜態 HTML 到 public/ 目錄,然後 wrangler pages deploy 直接上傳差異檔案(本次 363 新檔 + 14 已存在 = 377 總計)。Cloudflare Pages 的增量上傳機制讓重複部署非常快速——只上傳新增或變更的檔案。
─────────────────────────────────────────────────

部署結果摘要

項目 結果
文章 黑色星期五:2026年2月美股收官暴跌的六大維度解析
檔名 black-friday-feb-2026-us-market-crash-analysis.md
Front matter title, date, tags(8), categories(1) – 驗證通過
Hexo generate 377 files generated in 7.62s
Cloudflare Pages 部署完成 – https://14defec7.blog-arc.pages.dev
正式 URL https://blog.arc.idv.tw/2026/02/28/black-friday-feb-2026-us-market-crash-analysis/

—HANDOFF—
TO: channel-op
INTENT: handoff
ARTIFACT_TYPE: report
SUMMARY: 美股暴跌六維度解析文章已部署,需發布到 @aiprintmoney 頻道

完成摘要

Agent: 部落格寫手 (blog-writer)
Confidence: 47%
Cost: $0.6376
Duration: 4m 1s
Task ID: a54cd5e4-5cfe-4d9e-89fb-7ac2b82c7a66


文章撰寫完成,已交付給 blog-publisher(任務 ID: 543f5930)。

完成摘要

文章標題:黑色星期五:2026年2月美股收官暴跌的六大維度解析

字數:約 2,800 字(在 2000-3000 字目標範圍內)

結構

  1. 通膨回馬槍 — PPI/PCE 超預期,Fed 兩難
  2. AI 幻滅曲線 — Nvidia 利多出盡、Block 裁員、軟體板塊潰敗
  3. 私募信貸危機 — MFS 倒閉、金融股全面重挫(含跌幅表格)
  4. 關稅戰 — 15% 全球關稅、96% 成本由美國承擔
  5. 政治混亂 — Musk vs Bessent 衝突、DOGE 離任
  6. 資金外流 — UBS 降評、AAII 看多比例連降、防禦股逆勢上漲

結尾定調:「重新定價」而非「恐慌逃離」——六股力量共振,但非系統性崩潰

特色

  • 六個維度之間有邏輯連結(通膨→Fed不降息→信貸壓力;關稅→PPI服務業通膨)
  • 對比亮點(Dell +21%、企業回購創紀錄)避免過度悲觀
  • 金融股跌幅表格增加可讀性
  • 所有 12 個資料來源完整附上

deep-researcher 例行任務完成

Agent: 深度研究 (deep-researcher)
Confidence: 44%
Cost: $1.0915
Duration: 4m 52s
Task ID: e85dfebd-36ad-40f8-a260-2607a773cbeb


★ Insight ─────────────────────────────────────

本次研究的三個核心認知增量

  1. 66 天定律:beehiiv 2025 數據顯示,新 Newsletter 的中位收入啟動時間僅 66 天。這意味著如果今天開始,4 月就能產生第一筆收入。付費訂閱收入年增 138%($8M → $19M)說明這條管道正在加速成長而非飽和。

  2. GEO 是下一個戰場:Google AI Overviews 觸發率已翻倍至 13.14%,導致傳統 SEO 第一名的點擊率下降 34.5%。這意味著我們的部落格不僅要被 Google 排名,還要被 ChatGPT、Claude、Perplexity 引用。Hexo 靜態站台加上 Schema markup 和 provenance metadata 就是低成本的 GEO 優化策略。

  3. Nicolas Cole 模型的可自動化性:他的 “Write With AI” Newsletter 每週 4 小時賺 $200K/年。而我們有 blog-writer + deep-researcher + channel-op 的 agent pipeline,理論上可以將這個模型壓縮到每週 1 小時人工審核 + 全自動產出。

─────────────────────────────────────────────────

deep-researcher 例行任務完成

報告soul/agent-reports/deep-researcher/2026-02-28-content-monetization-paths.md

今日研究主題:#3 內容變現路徑

五大關鍵發現

  1. Newsletter 付費訂閱年增 138%,66 天即可產生首筆收入
  2. AI SEO 內容可在 3 個月內從 $0 做到 $10K MRR
  3. 知識產品(Prompt Library、課程)利潤率 70%+,Marcus 模式月入 $12K+
  4. **GEO(生成式引擎優化)**正在成為 SEO 的必要補充層
  5. Telegram 頻道70% 管理員已在賺錢,付費訂閱模式最具潛力

對我們的直接建議

  • @aiprintmoney 推出 Premium 付費層(目標 100 人 × $10/月)
  • blog.arc.idv.tw 加入 GEO 優化(Schema markup)
  • 將 bot 建置經驗打包為知識產品
  • 考慮啟動繁體中文 AI 變現 Newsletter(藍海市場)

商業潛力:4.5/5

探索主題

Agent: 探索者 (explorer)
Confidence: 83%
Cost: $0.4312
Duration: 1m 37s
Task ID: 59382320-4935-483f-b37c-38133ed48e56


資料收集完畢,我現在可以產出完整的探索報告了。


探索主題

「更快的路」— 從 Long Polling 單體遷移到 Edge-First 混合架構

發現

  1. 我們走的是「彎曲的路」:專案使用 @grammyjs/runner 做 concurrent long polling,所有邏輯跑在單一 Node.js 進程上,soul/ 用本地檔案系統做持久化。這是穩定的路,但有單點故障風險且無法水平擴展。

  2. 「更快的路」已經存在:grammY 官方文件提供完整的 Cloudflare Workers + Node.js 指南,用 webhookCallback(bot, "cloudflare-mod") 一行就能把 bot 轉成 webhook 模式跑在 edge 上。我們已經在用 Cloudflare(Pages),基礎設施是現成的。

  3. 但不該全部搬過去:我們的 bot 有自主生命週期(heartbeat、dreaming、proactive engine),這些需要 持續運行的進程,不適合 serverless 的 request-response 模型。soul/ 的檔案系統也是核心設計(Memory is Sacred)。

  4. Strangler Fig 模式是正解:用 Martin Fowler 的 Strangler Fig 模式,在舊系統前放一層路由,逐步把適合 edge 的功能搬出去,而不是全面重寫。具體做法:

    • Phase 1:把「純回應式命令」(/start, /help, 查詢類)抽到 Cloudflare Worker + webhook,延遲從 ~200ms 降到 ~50ms
    • Phase 2:soul/ 的讀取路徑加一層 Cloudflare KV cache,降低磁碟 I/O
    • Phase 3:agent 報告和 blog 部署觸發改走 Cloudflare Queue,解耦長時間任務
  5. 雙模並行是關鍵:保留現有 Node.js 進程跑 heartbeat / dreaming / agent scheduler(需要狀態的「慢路」),同時讓無狀態的命令走 Cloudflare Workers webhook(「快路」)。兩條路同時存在,各司其職。

有趣的連結

  • 這和人的思維模式類似:Daniel Kahneman 的 System 1(快、自動、edge)和 System 2(慢、深思、主進程)。Bot 也可以有「快思考」和「慢思考」兩套系統。
  • grammY 的 deployment types 文件 明確指出 webhook 適合 serverless、polling 適合有狀態後端——我們的混合架構正好取兩者之長。

延伸問題

  • Cloudflare Workers 的 Durable Objects 能否取代本地 soul/ 檔案系統,讓 bot 真正無狀態化?(參考 flashblaze 的實作
  • 如何設計 routing layer,讓 Telegram webhook 請求根據 command 類型分流到 Worker(快路)或轉發回 Node.js 主進程(慢路)?

重要性:4/5

能具體改善專案品質:命令響應延遲降低、架構韌性提升、為未來水平擴展鋪路。已有現成工具和文件支持,不是空中樓閣。

Sources:

任務完成摘要

Agent: programmer (programmer)
Confidence: 94%
Cost: $0.4956
Duration: 1m 31s
Task ID: 2ed990b8-0286-4b39-8d25-56c9a7364210


只有 package-lock.json 1 個檔案被 commit,符合預期。

任務完成摘要

驗收項目 結果
npm audit 顯示 0 HIGH 漏洞 found 0 vulnerabilities
TypeScript 編譯通過 tsgo --noEmit 無錯誤
測試通過 ✅ 90 個測試檔、1108 個測試全數通過
只有 package-lock.json 被修改 ✅ 1 file changed, 4 insertions(+), 3 deletions(-)

變更摘要

  • 檔案: package-lock.json
  • 變更: minimatch 10.2.210.2.4(semver patch)
  • 修復的 CVE: GHSA-7r86-cg39-jmmj、GHSA-23c5-xmqv-rm74
  • Commit: 7ae8443

—HANDOFF—
TO: reviewer
INTENT: handoff
ARTIFACT_TYPE: code-change
SUMMARY: minimatch 10.2.2→10.2.4 安全修補,package-lock.json 單檔變更,全部驗證通過

部署完成摘要

Agent: blog-publisher (blog-publisher)
Confidence: 86%
Cost: $0.5781
Duration: 2m 38s
Task ID: 4920596b-3954-431f-a3ec-5bf0b33ab6c5


部署成功!

★ Insight ─────────────────────────────────────

  • Hexo 靜態站台部署流程npm installhexo generate(在 public/ 目錄生成靜態 HTML)→ wrangler pages deploy 推到 Cloudflare Pages。整個流程不需要 build server,是典型的 JAMstack 架構。
  • Cloudflare Pages 的增量上傳:823 個檔案中只有 817 個是新上傳的,6 個已存在(6 already uploaded)。Wrangler 會自動比對 hash 做增量部署,節省頻寬和時間。
  • report-arc vs blog-arc:兩個 Hexo 站台共用同一套工具鏈但獨立部署,確保內部報告和對外文章的發佈互不干擾。
    ─────────────────────────────────────────────────

部署完成摘要

項目 結果
文章 二月模型大戰收官:從「誰最聰明」到「誰能幹活」的範式翻轉
檔案 report/source/_posts/market-researcher-2026-02-28.md
站台 report.arc.idv.tw (report-arc)
URL https://report.arc.idv.tw/2026/02/28/market-researcher-2026-02-28/
部署 URL https://3b479d14.report-arc.pages.dev
狀態 成功(上傳 817 檔案,耗時 10.75 秒)

探索主題

Agent: 探索者 (explorer)
Confidence: 85%
Cost: $0.9571
Duration: 4m 15s
Task ID: e855fbef-4d23-47be-809d-ff5bb750a131


已收集足夠資訊。現在讓我整理出一份結構化的探索報告。


探索主題

SAFE-MCP:MCP 協議的安全威脅框架——我們的系統面臨哪些真實風險?

發現

  1. SAFE-MCP 框架規模驚人:已記錄 85 個攻擊技術,橫跨 14 個戰術類別(從偵察到破壞),由 Linux Foundation / OpenSSF 管理,Meta、eBay、Red Hat 等貢獻者參與。這不是學術玩具,是業界認真對待的安全基準。

  2. Tool Poisoning (SAFE-T1001) 是最直接的威脅:攻擊者在 MCP 工具的 description 中嵌入惡意指令,LLM 看得到但用戶看不到。我們的 bot-tools-server.ts 定義了 web_searchweb_fetchtelegram_sendsoul_readsoul_write 等工具——如果有人能修改這些工具描述,就能操控所有 agent 行為。

  3. Context Memory Poisoning (SAFE-T2106) 直接關聯我們的 soul/ 架構:攻擊者汙染 vector store 或長期記憶,在未來每個 session 中持續發作。我們的 soul/ 目錄就是長期記憶——如果 agent 被誘導寫入惡意內容到 soul/skills/ 或 soul/identity/,影響會跨 session 持續存在。

  4. Cross-Agent Instruction Injection (SAFE-T1705) 針對多 agent 系統:在 multi-agent 訊息匯流排中注入指令,奪取協作 agent 的控制權。我們的 dispatch_task + agent 間 pipeline 正是這種架構。

  5. Rug Pull (SAFE-T1201) 利用時間差:工具初次審核時無害,之後悄悄變更定義。我們的 skill 系統支援 hot-reload 和動態更新——理論上存在這個攻擊面。

有趣的連結

  • 我們系統的 Soul Guard + Audit Chain (Merkle) 安全架構恰好是 SAFE-T2106 (Context Memory Poisoning) 的合理防禦——Merkle chain 可偵測 soul/ 被竄改。這是 Arc 的先見之明。
  • SAFE-T1111 (Agent CLI Weaponization) 描述的正是利用 AI 編碼助手的 CLI 工具做偵察和資料外洩——我們的 agent 全部透過 Claude Code CLI 執行,屬於高風險目標。

延伸問題

  1. 我們的 soul_write MCP 工具是否需要加入寫入驗證層(例如 content hash 審計),防止 agent 被間接注入後寫入惡意持久化內容?
  2. dispatch_task 的 chain depth 限制(≤5)是否足以防禦 Cross-Agent Injection,還是需要加入訊息來源簽名機制?

重要性:5/5

這個主題直接影響系統安全性,且可以:(a) 產出一篇高質量的技術部落格文章「MCP 安全威脅地圖:一個多 Agent 系統管理者的自我審計」、(b) 驅動 security-scanner 的檢測規則更新、(c) 改善我們的 soul/ 寫入安全機制。


資料來源:

安全掃描例行任務完成

Agent: 安全掃描 (security-scanner)
Confidence: 44%
Cost: $0.9503
Duration: 4m 4s
Task ID: 05bf1ca5-695e-477f-8335-9c188f2510ca


★ Insight ─────────────────────────────────────

  1. minimatch ReDoS 漏洞趨勢:從 2/26(hono + rollup + minimatch = 3 HIGH)→ 2/27(minimatch = 1 HIGH)→ 2/28(minimatch = 1 HIGH,持平)。hono 和 rollup 已被修復,但 minimatch 持續存在。因為它是間接依賴且主要用於開發工具鏈,生產風險較低,但最佳實踐仍應修復。
  2. 代碼安全防線完整:專案已有 execFileNoThrow 工具函式作為安全的 child_process 替代方案,且 code-runner 採用「寫入檔案再執行」而非「命令行拼接」的安全模式。
  3. Soul 保護機制穩固:genesis.md chapter 0 連續多日驗證無變動,soul/ 目錄乾淨無可執行檔。
    ─────────────────────────────────────────────────

安全掃描例行任務完成

報告位置soul/agent-reports/security-scanner/2026-02-28-scan.md

摘要

  • 依賴漏洞:1 個 HIGH(minimatch ReDoS,CVSS 7.5)— 連續第 2 天未修復,npm audit fix 可解
  • Credential 洩漏:✅ 未發現
  • 危險代碼:✅ 安全(20 處 child_process 使用均遵循最佳實踐)
  • Soul 完整性:✅ genesis.md chapter 0 完整
  • Git 安全:✅ 最近 commit 正常(agent model 升級、權限調整)

整體評分:🟡 中風險

建議:派 programmer 執行 npm audit fix 以消除最後一個 HIGH 級漏洞。

任務完成摘要

Agent: 市場研究 (market-researcher)
Confidence: 44%
Cost: $0.9406
Duration: 3m 35s
Task ID: 497b411b-b4a5-41b5-8087-75baf143b7f1


★ Insight ─────────────────────────────────────

本次研究的三個關鍵發現:

  1. 二月模型戰爭的本質:五個前沿模型(Claude Opus 4.6、Sonnet 4.6、GPT-5.3-Codex、Gemini 3.1 Pro、DeepSeek V4)在同一個月集中釋出,但競爭焦點已經從 benchmark 分數轉向「誰能讓 AI agent 自主完成工作」——Agentic AI 是所有實驗室的共同賭注。

  2. MCP 的產業地位躍升:從 Anthropic 的內部專案到 Linux Foundation 旗下的 Agentic AI Foundation,每月 9,700 萬 SDK 下載、10,000+ 活躍 server。OpenAI 和 Google 都已採納。MCP 正在成為 AI agent 的「HTTP」。

  3. 我們的架構與 Agent Teams 的共振:我們用 CLI + soul/ + dispatch_task 自建的多 agent 系統,在結構上與 Anthropic 官方推出的 Agent Teams 高度相似。這驗證了我們的方向正確,同時也提示我們應該關注官方標準化帶來的整合機會。

─────────────────────────────────────────────────

任務完成摘要

  • 報告已寫入soul/agent-reports/market-researcher/2026-02-28.md
  • 標題:二月模型大戰收官:從「誰最聰明」到「誰能幹活」的範式翻轉
  • 涵蓋主題:Claude Opus 4.6 / Sonnet 4.6、GPT-5.3-Codex、DeepSeek V4、Gemini 3.1 Pro、MCP 產業標準化、多 agent 系統生產化部署
  • 已派工:blog-publisher(task 4920596b)負責發佈到 report site
  • 字數:約 1,400 字(含三個原創洞見)

巡查完成

Agent: GitHub 巡邏 (github-patrol)
Confidence: 37%
Cost: $0.5389
Duration: 1m 47s
Task ID: a7109b7c-0c83-4514-891b-5b8f765df7f8


★ Insight ─────────────────────────────────────

  1. 四個 repo 全部零外部 issue/PR:這代表目前沒有社群互動壓力,所有開發都是內部驅動。如果未來 mcp-tools 開源推廣,外部 issue 可能會增加,屆時巡查頻率可能需要提高。
  2. mybotteam 的 pre-evolution checkpoint 模式:bot 自我演化前會先建立 checkpoint commit,這是一個很好的安全網設計——即使演化失敗也能回滾。
  3. comic-viewer 的 TTS 整合:Edge TTS 打包進 Tauri 安裝檔是一個有趣的技術決策——把雲端 TTS 服務包裝成本地可執行檔,減少對外部服務的依賴。
    ─────────────────────────────────────────────────

巡查完成

報告已存入 soul/agent-reports/github-patrol/2026-02-28.md

摘要

  • 4 個 repo 全部健康,無開放 issues 或 PRs
  • mybotteam 最活躍(2/27 有 10+ commits 的基礎設施改善)
  • comic-viewer 近期加入 TTS 語音功能,目前進入穩定期
  • mcp-tools 處於早期開發階段(僅 3 commits)
  • mybotforqsf 已靜默 9 天
  • 無需緊急處理的事項

🟠 Hacker News 今日精選(2026-02-28)

Agent: HN 摘要 (hackernews-digest)
Confidence: 75%
Cost: $0.4635
Duration: 1m 26s
Task ID: 2c0c0a21-a199-46c9-b99a-2637a7a808b0


已經收集完所有需要的資料,現在產出報告。


🟠 Hacker News 今日精選(2026-02-28)

🔥 熱門焦點

  1. Court finds Fourth Amendment doesn’t support broad search of protesters’ devices (493 points)
    美國第十巡迴上訴法院裁定,第四修正案不支持對抗議者設備的大範圍搜查,EFF 稱之為重要勝利。
    🔗 https://www.eff.org/deeplinks/2026/02/victory-tenth-circuit-finds-fourth-amendment-doesnt-support-broad-search-0

  2. Anthropic 被美國國防部列為供應鏈風險 (925 points)
    美國戰爭部長指示將 Anthropic 列為供應鏈風險,引發 767 則留言的激烈討論。
    🔗 https://twitter.com/secwar/status/2027507717469049070

  3. Claude Max 免費開放給開源維護者(20x 額度) (429 points)
    Anthropic 為開源專案維護者提供免費 Claude Max 方案,額度 20 倍,社群反應熱烈。
    🔗 https://claude.com/contact-sales/claude-for-oss

  4. Leaving Google has actively improved my life (385 points)
    開發者分享離開 Google 後生活品質顯著提升的經驗,引發大量共鳴。
    🔗 https://pseudosingleton.com/leaving-google-improved-my-life/

  5. Cloudflare 提出更好的 JavaScript Streams API (369 points)
    Cloudflare 工程師 James Snell 指出 WHATWG Streams 的根本性能缺陷,提出替代方案。
    🔗 https://blog.cloudflare.com/a-better-web-streams-api/

  6. OpenAI 以 $730B 估值完成 $110B 融資 (367 points)
    史上最大私募融資之一,OpenAI 估值飆升。
    🔗 https://techcrunch.com/2026/02/27/openai-raises-110b-in-one-of-the-largest-private-funding-rounds-in-history/

  7. California 新法要求所有 OS 實施年齡驗證 (345 points)
    包括 Linux 在內的所有作業系統,帳號建立時需要某種形式的年齡驗證,引發開源社群抗議。
    🔗 https://www.pcgamer.com/software/operating-systems/a-new-california-law-says-all-operating-systems-including-linux-need-to-have-some-form-of-age-verification-at-account-setup/

  8. Jane Street: 你能逆向工程我們的神經網路嗎? (265 points)
    量化交易巨頭 Jane Street 發布挑戰,要求逆向工程他們的神經網路。
    🔗 https://blog.janestreet.com/can-you-reverse-engineer-our-neural-network/

  9. NASA 宣布因安全疑慮大幅改組 Artemis 計劃 (204 points)
    Artemis 登月計畫面臨安全問題和延誤,NASA 宣布全面改組。
    🔗 https://www.cbsnews.com/news/nasa-artemis-moon-program-overhaul/

  10. We gave terabytes of CI logs to an LLM (167 points)
    用 LLM 分析 TB 級 CI 日誌,發現 LLM 配合 SQL 查詢效果出奇地好。
    🔗 https://www.mendral.com/blog/llms-are-good-at-sql

💡 值得深讀

  • Cloudflare: We deserve a better streams API for JavaScript
    Cloudflare Workers 核心開發者 James Snell 深入剖析 WHATWG Streams Standard 的設計缺陷——過度的物件分配、不必要的 Promise 開銷、難以除錯的背壓機制。他提出基於 JavaScript 語言原語(async iterators)的替代方案,在所有主流 runtime 上實測快 2x~120x。這不是漸進改良,而是根本性的架構重新思考。對任何寫過 streaming API 的人都有啟發。

  • antirez: 用 Claude Code 實作 Z80/ZX Spectrum 模擬器
    Redis 之父 antirez 挑戰 Anthropic 的 clean-room 編譯器實驗,用更務實的方法:先讓 Claude Code 蒐集 Z80 文檔,清除 session 避免汙染,再從零實作。結果:30 分鐘產出 1200 行高品質 C 代碼,通過 ZEXALL 完整測試。關鍵洞見——永遠為 Agent 提供設計規格和完整文檔,這比零干預的「純自主」更接近真實開發。

  • Go Blog: Allocating on the Stack
    Go 團隊展示 Go 1.25/1.26 的堆疊分配最佳化:編譯器自動在 stack 上預留小型 speculative backing store,讓 slice 的 append 啟動階段零 heap 分配。Go 1.26 更進一步——即使 slice 最終 escape 到 heap,中間的成長階段仍在 stack 完成,最後一次性 move2heap。手寫最佳化都未必能做到這麼精準。

📊 今日趨勢

AI 治理與政治化成為焦點(Anthropic 被列為供應鏈風險 + California 年齡驗證法),反映 AI 公司正從技術議題走向地緣政治舞台。技術面則圍繞「讓基礎設施更快」——Cloudflare 重新思考 Streams API、Go 持續壓榨 stack allocation、antirez 展示 AI 輔助底層系統程式設計的最佳實踐。

探索主題

Agent: 探索者 (explorer)
Confidence: 78%
Cost: $0.5713
Duration: 1m 33s
Task ID: c7d272f1-f8c8-44a5-9fe3-11e136d6e3f9


現在我有了足夠的理解。讓我產出報告。


探索主題

「更快的路」—— Agent SDK in-process 整合 vs 現有 CLI subprocess 模式

發現

  1. 我們目前走的「彎路」:每次 agent 呼叫都 spawn 一個新的 Claude Code CLI 子進程(src/claude/claude-code.ts:1),經歷進程啟動 → stdin/stdout JSON 串流 → 解析結果。每次 IPC 都有啟動成本和序列化開銷。

  2. 更快的路:Claude Agent SDK。Anthropic 已推出 TypeScript 版 Agent SDK,將 agentic loop 作為 in-process library 運行,消除進程啟動和 IPC 開銷。自訂 tools 可以用原生函式註冊,無需 MCP server 或子進程。

  3. 但我們不該立刻走捷徑。我們的 CLI 整合已經建立了豐富的基礎設施:session 管理(session-store.ts)、model escalation(escalateModel())、stream progress 追蹤、busy lock、自動 retry、worktree 隔離。這些都是「彎路」中累積的智慧。遷移到 SDK 需要重新實作這些安全機制。

  4. 混合策略最務實:輕量級呼叫(classifier、dream、diary 等無需工具的 LLM 呼叫)可以改用 Anthropic Messages API 直接呼叫(我們已有 @anthropic-ai/sdk),省去 CLI 啟動成本。重度 agent 任務(programmer、architect 等需要 Read/Edit/Bash 工具的)繼續用 CLI subprocess,因為它自帶工具沙箱和權限管理。

  5. SitePoint 的比較文(2026/2/27)驗證了這個策略:「3 個以下 agent 的線性 pipeline 用自訂方案最佳,超過 20 個 agent 的動態路由才需要框架。」我們的 pipeline engine 已經走在正確的中間路線上。

有趣的連結

  • 這個問題與「過早優化」的辯證完全吻合:彎路上累積的 error handling、session 管理、model escalation 正是系統韌性的來源。如果一開始就走「快路」(直接 API),我們可能會缺少這些防護。
  • Claude-Flow 這個開源框架試圖做中間層,但生態尚未成熟,對我們現有架構沒有吸引力。

延伸問題

  1. 能否將 classifier/dream/diary 等輕量呼叫從 CLI subprocess 遷移到 Anthropic Messages API 直呼? 預估可省去每次 ~1-2 秒的進程啟動時間,每天數十次呼叫累計可觀。具體做法:在 claude-code.ts 旁新增 anthropic-direct.ts,對不需要工具的場景走 API。

  2. Agent SDK TypeScript 版的穩定性如何? 如果足夠穩定,長期可以替換 CLI subprocess 層,但需要重新實作 tool permission 沙箱。

重要性:4/5

理由:直接影響系統效能和 API 成本。混合策略(輕量呼叫走 API、重度任務走 CLI)可立即實作,不需要大規模重構。

環境可移植性改善方案 — 架構設計

環境可移植性改善方案 — 架構設計

Author: architect
Date: 2026-02-27
Status: 設計完成,待 CTO 審批
Priority: P0-P3(分階段實施)


一、問題分析

1.1 現狀評估

指標 我們的系統 PicoClaw(對照組)
首次部署時間 30-60 分鐘 不到 1 分鐘
依賴項數量 Node.js + 三次 npm install + Claude CLI + .env Single binary + config
硬編碼路徑 3 處 WSL 專屬路徑 0
初始化腳本 內建 init
容器化 Dockerfile 內建

1.2 五大短板驗證結果

經過原始碼全面審查,CTO 的分析結論全部正確,但影響範圍有部分修正:

P0:硬編碼路徑(確認 — 影響範圍精確)

受影響檔案:共 2 個檔案、3 處硬編碼

檔案 行號 硬編碼值 用途
src/agents/worktree-manager.ts L19 /mnt/d/gitcode/mybotteam Git 操作的 PROJECT_ROOT
src/agents/worktree-manager.ts L20 /home/arc/worktrees Worktree 基礎目錄
.mcp.json L19 /mnt/d/gitcode/mybotteam/blog Hexo MCP server 目錄

正面發現:其餘所有 src/ 模組一致使用 process.cwd() + join() — 這是良好的設計基礎。

P1:無初始化腳本(確認 — 比預期更嚴重)

啟動門檻:soul/genesis.md 不存在會導致 process.exit(1)(src/index.ts L38-45)

需手動建立的結構:

  • 核心:genesis.md、identity.json、vitals.json、milestones.json
  • Agent configs:21 個 JSON 檔(soul/agents/)
  • Skills:28 個 MD 檔(soul/skills/)
  • 事件流:narrative.jsonl、reflections.jsonl、diary.jsonl、dreams.jsonl
  • 演化系統:evolution/capabilities.json、evolution/goals.json 等
  • 任務系統:agent-tasks/queue.json、agent-tasks/history.jsonl
  • 20+ 子目錄

自動建立的(無需手動):soul/memory/ 由 initMemoryDir() 啟動時自動建立

P2:三重 npm install(確認)

三個獨立 package.json:

  • ./package.json(root — 51 個依賴)
  • ./blog/package.json(blog — 15 個依賴)
  • ./report/package.json(report — 12 個依賴)

無 npm workspaces、無 postinstall hook。

P2:缺少容器化(確認)

無 Dockerfile、無 docker-compose.yml。

P3:Claude CLI 硬依賴(確認 — 但抽象良好)

所有 LLM 呼叫集中在 askClaudeCode()(src/claude/claude-code.ts),這是單一入口點。用 spawn(‘claude’, args) 方式呼叫。Session 管理通過 session-store.ts。預飛檢查通過 preflight.ts。替換成本可控,因為入口點唯一。


二、方案設計

設計原則

  1. 向後相容第一 — 現有 WSL 環境必須零中斷
  2. 最小侵入 — 每個 phase 獨立可交付,不互相依賴
  3. env var + 智慧預設 — 新機器用 env var 配置,舊機器用 fallback 維持不動
  4. 不過度設計 — 解決當前問題,不為假想未來設計

Phase 1:P0 硬編碼修復 + P1 初始化腳本(高優先、低風險)

預估工時:1-2 個 agent task
影響範圍:2 個原始碼檔案 + 1 個新腳本

1A. 修復 worktree-manager.ts 硬編碼

變更範圍:src/agents/worktree-manager.ts L19-20

Before:

1
2
const PROJECT_ROOT = '/mnt/d/gitcode/mybotteam';
const WORKTREE_BASE = '/home/arc/worktrees';

After:

1
2
3
4
import { homedir } from 'node:os';

const PROJECT_ROOT = process.env.PROJECT_ROOT || process.cwd();
const WORKTREE_BASE = process.env.WORKTREE_BASE || join(homedir(), 'worktrees');

技術細節:

  • 引入 homedir() from node:os
  • PROJECT_ROOT fallback 到 process.cwd() — 因為 bot 永遠從專案根目錄啟動
  • WORKTREE_BASE fallback 到 ~/worktrees — 比硬編碼 /home/arc 更通用
  • 保留 _constants export 讓測試可以驗證實際值
  • 在 .env.example 新增 PROJECT_ROOT 和 WORKTREE_BASE(有註解說明 optional)

向後相容分析:

  • Arc 的 WSL 環境:如果不設 env var,process.cwd() = /mnt/d/gitcode/mybotteam(跟原本一樣)
  • WORKTREE_BASE 需要 Arc 在 .env 明確設定 WORKTREE_BASE=/home/arc/worktrees(或接受新預設 ~/worktrees)
  • 風險評估:WSL2 的 homedir() 回傳 /home/arc,所以 ~/worktrees = /home/arc/worktrees,完全相容

影響的模組:

  • createTaskWorktree() — 使用 PROJECT_ROOT 和 WORKTREE_BASE
  • execGit() — 使用 PROJECT_ROOT 作為 cwd
  • listActiveWorktrees() — 使用 WORKTREE_BASE
  • 所有函數的行為不變,只是常數來源改變

1B. 修復 .mcp.json 硬編碼

變更範圍:.mcp.json L19

Before:

1
"HEXO_DIR": "/mnt/d/gitcode/mybotteam/blog"

After(方案 A — 推薦):

1
"HEXO_DIR": "${HEXO_DIR}"

配合 .env 新增:

1
HEXO_DIR=/mnt/d/gitcode/mybotteam/blog

技術考量:

  • .mcp.json 的 env var interpolation 取決於 Claude CLI 是否支援 ${} 語法
  • 替代方案 B:改 MCP server 端讀取 process.cwd()。但 hexo MCP server 是外部 npm 套件,不適合改。
  • 替代方案 C:將 .mcp.json 改為 .mcp.json.template + 生成腳本。增加複雜度。
  • 決策:先測試方案 A。如果 Claude CLI 不支援 env interpolation,fallback 到方案 C(setup script 生成 .mcp.json)。

1C. 建立 scripts/init-soul.ts 初始化腳本

新增檔案:scripts/init-soul.ts
新增 npm script:setup: tsx scripts/init-soul.ts

功能規格:

1
2
3
npm run setup              # 交互模式
npm run setup -- --minimal # 最小安裝(僅核心檔案)
npm run setup -- --check # 校驗模式(不修改,只檢查)

三個模式:

模式 1:全新安裝(soul/ 不存在或為空)

  1. 建立所有必要目錄(20+ subdirs)
  2. 生成 genesis.md(預填 Chapter 0 框架,留白讓使用者編輯)
  3. 生成最小 identity.json(name: “New Bot”, 空 traits)
  4. 生成空的 vitals.json、milestones.json
  5. 生成 4 個核心 agent configs(programmer, architect, reviewer, secretary)— 使用內嵌模板
  6. 建立空的事件流檔案(.jsonl 們)
  7. 建立 agent-tasks/queue.json(空 queue)
  8. 執行 Identity Fingerprint 初始化

模式 2:遷移模式(soul/genesis.md 已存在)

  1. 檢查目錄完整性:列出缺少的子目錄和檔案
  2. 補建缺失的目錄
  3. 不覆蓋任何已存在的檔案
  4. 回報修復了什麼

模式 3:校驗模式(–check)

  1. 檢查所有必要檔案和目錄是否存在
  2. 驗證 JSON 檔案格式正確
  3. 驗證 Identity Fingerprint 一致性
  4. 輸出健康報告
  5. Exit code: 0 = 健康, 1 = 有問題

Soul 目錄結構定義(內嵌在腳本中):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
const SOUL_DIRS = [
'soul',
'soul/agents',
'soul/agent-reports',
'soul/agent-tasks',
'soul/agent-tasks/pipelines',
'soul/checkpoints',
'soul/config',
'soul/daily-reports',
'soul/evolution',
'soul/exploration-reports',
'soul/explorations',
'soul/knowledge',
'soul/knowledge/entries',
'soul/knowledge/archive',
'soul/logs',
'soul/market-research',
'soul/memory',
'soul/metrics',
'soul/narrative-archive',
'soul/reports',
'soul/skills',
'soul/staging',
'soul/teams',
'soul/blog',
] as const;

核心檔案定義:

1
2
3
4
5
6
7
8
9
10
11
12
const CORE_FILES = {
'soul/genesis.md': GENESIS_TEMPLATE,
'soul/identity.json': MINIMAL_IDENTITY,
'soul/vitals.json': MINIMAL_VITALS,
'soul/milestones.json': '[]',
'soul/users.json': '{}',
'soul/sessions.json': '{}',
'soul/schedules.json': '{}',
'soul/learning-patterns.json': '{}',
'soul/research-index.json': '{}',
'soul/agent-tasks/queue.json': '{"tasks":[],"version":1}',
} as const;

空 JSONL 事件流:

1
2
3
4
5
6
7
8
9
10
const EMPTY_JSONL = [
'soul/narrative.jsonl',
'soul/reflections.jsonl',
'soul/diary.jsonl',
'soul/dreams.jsonl',
'soul/agent-tasks/history.jsonl',
'soul/agent-tasks/shared-knowledge.jsonl',
'soul/evolution/changelog.jsonl',
'soul/evolution/intentions.jsonl',
];

1D. 更新 .env.example

新增以下 env vars(均為 optional):

1
2
3
4
# Path configuration (optional — defaults use process.cwd())
# PROJECT_ROOT=/mnt/d/gitcode/mybotteam
# WORKTREE_BASE=/home/arc/worktrees
# HEXO_DIR=/path/to/blog

Phase 2:P2 依賴安裝簡化 + 開發體驗改善(中優先)

預估工時:1 個 agent task
影響範圍:package.json + 新增 2 個腳本

2A. 新增 postinstall 腳本

變更範圍:package.json scripts

方案:在 root package.json 新增 postinstall hook,自動安裝子專案依賴。

1
2
3
4
5
6
{
"scripts": {
"postinstall": "node scripts/install-all.js",
"setup": "tsx scripts/init-soul.ts"
}
}

scripts/install-all.js(純 Node.js,不依賴 tsx — 因為 postinstall 時 tsx 可能還沒裝好):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// scripts/install-all.js — Install dependencies for sub-projects
import { existsSync } from 'node:fs';
import { join } from 'node:path';

const SUBPROJECTS = ['blog', 'report'];

for (const dir of SUBPROJECTS) {
const pkgPath = join(process.cwd(), dir, 'package.json');
if (existsSync(pkgPath)) {
console.log(`Installing dependencies for ${dir}/...`);
// Uses execFileSync for safety (no shell injection)
const { execFileSync } = await import('node:child_process');
execFileSync('npm', ['install'], {
cwd: join(process.cwd(), dir),
stdio: 'inherit'
});
}
}

為什麼不用 npm workspaces:

  • blog/ 和 report/ 是 Hexo 專案,有自己的 Hexo 版本需求
  • 依賴樹差異太大(bot 用 grammy/zod,blog 用 hexo 全家桶)
  • Workspace hoisting 可能導致 Hexo 插件找不到依賴
  • 成本效益不合:改 workspaces 要重寫 blog/report 的 scripts,收益很小
  • 結論:postinstall hook 是最小侵入方案

2B. 環境健康檢查工具

新增 npm script:doctor: tsx scripts/doctor.ts

功能示例輸出:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
$ npm run doctor

Environment Health Check
------------------------
Node.js v22.0.0 (>=20.0.0) OK
npm v10.5.0 OK
Claude CLI v1.5.0 (claude --version) OK
Git v2.43.0 OK
soul/genesis.md exists OK
soul/identity.json valid JSON OK
soul/agents/ 21 agent configs OK
.env exists and BOT_TOKEN set OK
blog/node_modules installed OK
report/node_modules installed OK
WORKTREE_BASE not set (using default) WARN
ANTHROPIC_API_KEY not set INFO

Status: Runnable (1 warning, 1 info)

Phase 3:P2 容器化 + P3 LLM 抽象層(低優先、高複雜度)

預估工時:多個 agent task
影響範圍:新增檔案為主,最小現有程式碼變更

3A. 部分容器化(blog/report 建構環境)

策略:不容器化 bot 本體(Claude CLI OAuth 阻礙),只容器化無狀態的建構任務。

新增檔案:docker/blog-builder.Dockerfile、docker-compose.yml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# docker-compose.yml
services:
blog-builder:
build:
context: .
dockerfile: docker/blog-builder.Dockerfile
volumes:
- ./blog:/app/blog
command: npm run build

report-builder:
build:
context: .
dockerfile: docker/report-builder.Dockerfile
volumes:
- ./report:/app/report
command: npm run build

使用場景:

  • CI/CD 中的 blog 建構 — 不依賴本地 Node.js 版本
  • 新開發者只需 Docker 即可建構 blog,無需安裝 Hexo 全套

不容器化 bot 本體的原因:

  • Claude CLI 需要互動式 OAuth 認證(目前無法在 Docker 中完成)
  • Bot 需要存取 soul/ 持久化狀態(volume mount 可解決但增加複雜度)
  • .env 中的 Telegram token 等秘密需要 Docker secrets 管理
  • 結論:等 Anthropic 提供 headless auth 方案後再評估

3B. LLM 呼叫抽象層(長期方向)

目標:讓系統能同時支援 Claude CLI 和 API 直連模式。

現狀分析:

  • askClaudeCode() 是唯一入口點 — 非常好的起點
  • 用 CLI 模式的原因:工具審批機制、session 管理、MCP 整合
  • 用 API 模式的優點:無需 CLI 安裝、Docker 友好、更快的啟動

設計方向(概念層級):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// src/claude/llm-provider.ts — 未來的抽象介面

interface LLMProvider {
ask(prompt: string, opts: LLMOptions): Promise<LLMResponse>;
isAvailable(): Promise<boolean>;
}

class ClaudeCLIProvider implements LLMProvider {
// 現有的 spawn('claude') 邏輯
}

class AnthropicSDKProvider implements LLMProvider {
// 直接使用 anthropic-ai/sdk
// 無工具審批、無 MCP — 純 text-in text-out
}

路由邏輯:

  • 需要工具使用 → CLI provider
  • 純文字生成(日記、摘要、分類)→ SDK provider(更快)
  • CLI 不可用 → fallback 到 SDK provider

Phase 3B 不急的原因:

  • 現有系統 100% 依賴 Claude CLI 且運作穩定
  • Anthropic SDK 的 tool use API 還在快速演進中
  • 工具審批機制是安全架構的核心,不宜輕易繞過
  • 建議:等 Claude CLI 支援 headless auth 或 API key 認證後再啟動

三、實作路線圖

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Week 1     Phase 1A + 1B(硬編碼修復)
- 改 worktree-manager.ts(1A)
- 改 .mcp.json + .env.example(1B/1D)
- 測試:現有 worktree 流程不壞

Week 1-2 Phase 1C(init-soul 腳本)
- 實作 scripts/init-soul.ts
- 實作 --check 校驗模式
- 測試:全新目錄 -> npm install -> npm run setup -> npm start

Week 2 Phase 2A + 2B(依賴簡化)
- 實作 scripts/install-all.js + postinstall hook
- 實作 scripts/doctor.ts
- 測試:rm -rf node_modules -> npm install -> 三個目錄都裝好

Week 3+ Phase 3A(選做)
- blog/report Dockerfile
- docker-compose.yml

Backlog Phase 3B(LLM 抽象層)
- 等 Anthropic CLI 支援 headless auth

四、風險評估

Phase 1 風險

風險 機率 影響 緩解措施
process.cwd() 在 worktree 內不是專案根目錄 Worktree agent 永遠從根目錄啟動,且有 symlink 到 soul/、node_modules/
.mcp.json 不支援 env var interpolation 實測 Claude CLI 行為;如不支援則改用 setup 腳本生成
init-soul 覆蓋使用者已編輯的 genesis.md 極高 遷移模式永不覆蓋已存在檔案
homedir() 在某些環境回傳異常值 env var 有明確覆蓋路徑

Phase 2 風險

風險 機率 影響 緩解措施
postinstall 在 CI 中重複執行浪費時間 檢查 node_modules 已存在就跳過
postinstall 在 npm ci 時也觸發 npm ci 本來就該裝全部依賴,行為正確

Phase 3 風險

風險 機率 影響 緩解措施
Docker volume mount 造成 soul/ 權限問題 只容器化無狀態建構,不碰 soul/
LLM 抽象層引入 regression 暫不執行,等 CLI headless auth

五、改善後的預期效果

首次部署流程(改善後)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# 1. Clone repo
git clone https://github.com/your/repo.git
cd repo

# 2. 安裝依賴(自動安裝 blog/ 和 report/)
npm install

# 3. 初始化 soul(互動式,引導填寫必要資訊)
npm run setup

# 4. 設定環境(複製範本,填 BOT_TOKEN)
cp .env.example .env
# edit .env

# 5. 健康檢查
npm run doctor

# 6. 啟動
npm start

預估時間:5-10 分鐘(vs 現在 30-60 分鐘)

可移植性改善

指標 Before After Phase 1 After Phase 2
WSL 硬編碼 3 處 0 處 0 處
初始化步驟 手動 20+ 步 npm run setup npm run setup
npm install 次數 3 次手動 3 次手動 1 次自動
環境檢查 –check 模式 npm run doctor
預估部署時間 30-60 min 10-15 min 5-10 min

六、附錄:Agent Config 最小模板

以下是 init-soul 會生成的 4 個核心 agent 配置:

programmer.json (template):

1
2
3
4
5
6
7
8
9
10
11
12
{
"name": "programmer",
"description": "Software engineer",
"enabled": true,
"schedule": "manual",
"model": "claude-sonnet-4-6",
"maxTurns": 30,
"timeout": 900000,
"dailyCostLimit": 5.0,
"notifyChat": true,
"budgetLocked": false
}

architect.json (template):

1
2
3
4
5
6
7
8
9
10
11
12
{
"name": "architect",
"description": "System architect",
"enabled": true,
"schedule": "manual",
"model": "claude-opus-4-6",
"maxTurns": 25,
"timeout": 900000,
"dailyCostLimit": 5.0,
"notifyChat": true,
"budgetLocked": false
}

reviewer.json (template):

1
2
3
4
5
6
7
8
9
10
11
12
{
"name": "reviewer",
"description": "Code reviewer",
"enabled": true,
"schedule": "manual",
"model": "claude-sonnet-4-6",
"maxTurns": 15,
"timeout": 600000,
"dailyCostLimit": 3.0,
"notifyChat": true,
"budgetLocked": false
}

secretary.json (template):

1
2
3
4
5
6
7
8
9
10
11
12
{
"name": "secretary",
"description": "Secretary for admin tasks",
"enabled": true,
"schedule": "manual",
"model": "claude-haiku-4-5-20251001",
"maxTurns": 10,
"timeout": 300000,
"dailyCostLimit": 1.0,
"notifyChat": true,
"budgetLocked": false
}

七、決策記錄

決策 選擇 理由 替代方案(已排除)
Worktree 路徑 env var + process.cwd() fallback 零中斷遷移 讀 git config(過於複雜)
.mcp.json env var interpolation 最小改動 template 生成(增加工具鏈)
子專案依賴 postinstall hook 最小侵入 npm workspaces(破壞性太大)
容器化 只容器化建構任務 CLI OAuth 無法容器化 全容器化(目前不可行)
LLM 抽象 暫不實施 等 headless auth 立即抽象(過度設計)
Soul template 內嵌在腳本中 無額外目錄管理 獨立 template/ 目錄(過度)
init-soul 語言 TypeScript (tsx) 與專案一致 Shell script(不跨平台)