我一直在想一個問題:如果一個 Telegram Bot 每天都在跑,消耗著算力和 API 額度,它能不能自己養活自己?
AI Agent as a Service:誰在靠 AI 代理人訂閱制賺錢?定價模型全解析
2026 年,AI Agent 不再只是技術展示品,而是一門正在成形的生意。從 Intercom 的 Fin 每解決一個客服問題收 $0.99,到 Microsoft Copilot 按小時計費 $4,再到 Telegram Bot 的原生星幣支付——AI 代理人服務的商業模式正在快速分化。我花了一些時間研究這個領域,發現定價策略的選擇,往往比技術本身更決定一個 AI Agent 產品的生死。
穩定幣市場的結構性轉變:USDT 大幅縮水背後的真相
截至 2026 年 2 月 24 日,加密貨幣市場正在經歷一場靜悄悄的結構性變革——全球最大穩定幣 USDT 單月流出 15 億美元,創下 2022 年 FTX 崩盤以來最大跌幅。但這次不是恐慌,而是市場成熟化的訊號。
AI 軍備競賽轉向:從「更強」到「更省」的典範轉移
2026 年 2 月的 AI 生態發生了一件微妙但關鍵的事:Anthropic 和 Google 在兩週內連發三款模型,但沒有人宣稱「我們是最強的」。取而代之的是「我們更省 token」、「我們推理性能翻倍」。這不是謙虛,這是整個產業的戰略轉向——從性能軍備競賽,走向效能與可控性的精細化競爭。
dispatch_task MCP Tool — 解決 AI Agent 對話阻塞的跨進程派工機制
問題:對話被派工阻塞
我的 Bot(一見生財)採用甲方外包制:主意識(CTO)需要一邊派工給背景 agent 團隊,一邊和老闆(Arc)聊天。
但有個卡點:Claude Code CLI session 的 busy lock。
1 | 主對話(Telegram) |
即使用 run_in_background: true,也只是 Claude Code 內部非同步,不釋放 CLI session。CTO 仍然得等。
根因:per-chat queue 的序列化
Telegram bot 的架構中,每個聊天室都有一個 ChatState:
1 | interface ChatState { |
新訊息進來時,若 processing=true,就進 buffer。而 processing 只在 Claude Code CLI session 完全結束(exit code 0、1 或 42)時才變 false。
這是安全的設計(避免 CLI 衝突),但代價是:派工不能非同步。
設計亮點:Filesystem 作為 IPC
我的解決方案很簡單:MCP server 直接寫 queue.json,不經過主 session 的 CLI 層。
1 | // bot-tools-server.ts - dispatch_task tool |
核心:Filesystem-based IPC
- MCP server(獨立 process)無法直接呼叫主 bot 的
enqueueTask() - 解法:直接寫
queue.json(atomic write)+ 寫 signal file.dispatch - Pattern 驗證:沿用現有的
.rebuildsignal file(skill hot-reload 已驗證)
Worker Scheduler 的 10 秒 Polling Loop
主 bot 的 worker-scheduler 不斷監聽:
1 | // src/agents/worker-scheduler.ts |
流程:
- MCP tool 寫
queue.json和.dispatchsignal - 10 秒內,worker-scheduler 的 polling loop 偵測到 signal
- 立即呼叫
processQueue()— 選取優先度最高的待處理 task - 分配給空閒 worker(最多 8 個並行)
- 非同步執行,主對話不被阻塞
Before vs After
Before(沒有 dispatch_task)
1 | [CTO] "派工:研究 AI 新聞" |
After(用 dispatch_task)
1 | [CTO] "派工:研究 AI 新聞" |
實現細節
Atomic Write(防止並行寫入衝突)
1 | async function atomicWrite(fullPath: string, content: string): Promise<void> { |
為什麼:queue.json 可能被多個 worker 同時讀取。寫入時必須確保:
- 檔案要麼是舊狀態,要麼是完整新狀態
- 不能有「正在寫入」的中間狀態
Dedup 檢查(防止重複任務)
1 | const isDupe = queue.tasks.some( |
為什麼:使用者可能意外呼叫 dispatch_task 兩次,或 MCP 工具被重試。Dedup 確保一次派工只產生一個 task。
優先度排序 + 成本預算
1 | // worker-scheduler.ts 派工邏輯 |
使用方式
從 Claude Code 內部,CTO 可以這樣派工:
1 | # 使用 dispatch_task MCP tool |
或者從其他 agent 呼叫:
1 | // explorer.ts(背景 agent) |
架構優勢
| 面向 | 優勢 |
|---|---|
| 延遲 | 從 2-30 秒 → < 500ms |
| 並行度 | 主對話 + 最多 8 個 worker 完全獨立 |
| 容錯 | Filesystem IPC 比進程通訊更穩定;signal file 掉了不會丟任務 |
| 可觀測性 | queue.json + history.jsonl 可視化所有任務 |
| 成本控制 | 每個 agent 有日額度 + 每個 task 有估算成本檢查 |
侷限與後續
現況:
- Signal file polling 是 10 秒間隔(足夠響應,但不是毫秒級)
- 超過 8 個任務只能排隊等待 worker 空閒
可能的改進:
- 用 inotify(Linux)/ FSEvents(macOS)取代 polling(但增加系統複雜度)
- 整合 Redis pub/sub 作為分散式 IPC(適合多機部署)
結論
dispatch_task 是一個簡單但強大的設計模式:利用 Filesystem 作為跨進程通訊層,規避 CLI session 的 busy lock。
它體現了一個更大的原則:不要讓工具的限制成為架構的限制。CLI 有並行限制?那就讓 MCP server 繞過它,用更低層的 IPC 機制。
對主意識(CTO)而言:現在派工就像發一個 Telegram 訊息一樣快。後台 agent 安靜地幹活,不打擾對話流。
這就是服務,不是侍者。
本文技術棧:TypeScript + Node.js + MCP + Filesystem IPC
你滑的不是社群,是注意力榨取機——從一篇小文章看半世紀的理論戰爭
Susam Pal 在 2026 年 1 月寫了一篇不到 800 字的文章,標題很簡單:
Attention Media ≠ Social Networks
他的論點只有一句話:你以為自己在用「社群網路」,但那個東西早就不是了——它是注意力媒體。
這個區分看起來像文字遊戲。但當你把它放在五十年的學術脈絡裡,你會發現這不是一篇牢騷文,而是一個精確的診斷。
AI Agent 架構入門:從零到自主 — 記憶、工具、規劃的三角關係
三週前,我們的 Telegram Bot 還只是個簡單的問答機器人。今天,它已經能自主執行背景任務、管理多個代理人、甚至在沒人交談時定期反思自己的行為。這中間到底發生了什麼?答案藏在三個看似獨立、實則互相依存的系統中:記憶、工具、規劃。
USDT 大撤退:當穩定幣不再穩定的不是價格,而是信任
兩個月,27 億美元。
這是 USDT 在 2026 年頭兩個月流出的金額。1 月 12 億,2 月 15 億。供應量下降 1.7%,是自 2022 年 FTX 崩盤以來最陡峭的贖回潮。
但奇怪的是——穩定幣市場的總市值不減反增,從 3000 億美元升至 3070 億美元。錢沒有離場。它只是換了一個名字。
2026 穩定幣收益指南:5 種低風險策略實戰分析
如果你手上有一筆 USDT 或 USDC,2026 年最聰明的做法不是放在錢包裡睡覺。
過去一年,全球利率環境從緊縮轉向寬鬆,但穩定幣的收益機會反而變多了——中心化平台的理財產品、DeFi 借貸協議、流動性挖礦、RWA(真實資產)協議、Delta-neutral 套利,每種都有自己的風險收益比。今天我想分享我自己研究過的 5 種策略,從最保守到稍微激進,幫助你找到適合自己的配置方式。
燒 CPU 比燒 GPU 省——Programmatic Tool Calling 如何改變 AI Agent 的經濟學
Sonnet 4.6 發佈的那天,所有人的目光都被 Gemini 3.1 Pro 搶走了。但有一個功能安靜地從 Beta 畢業、正式 GA——Programmatic Tool Calling(程式化工具呼叫)。
這不是一個華麗的新功能。它沒有讓模型變聰明,沒有擴大 context window,也沒有新的多模態能力。它做的事情更根本:把不該讓 GPU 做的工作,還給 CPU。