零成本情報系統：讓 AI 每天幫你做市場研究
我以前怎麼做市場研究
打開 Hacker News，滑。打開 Twitter，滑。打開幾個 RSS reader，滑。看到有趣的存書籤，然後再也不看。
每天花 30-60 分鐘「保持對行業的感覺」。有時候有收穫，大部分時候只是在消耗注意力。
更糟的是，這些「感覺」不會被記錄下來。我讀了什麼、趨勢是什麼、跟我的產品有什麼關係——全部存在我的腦子裡，隨著睡一覺就蒸發了大半。
然後我想：agent 不是很會讀大量文字嗎？為什麼我不讓它做這件事？
設計原則：Pre-Compute Everything
OpenClaw 的核心架構原則是 「預先計算一切」。
傳統做法是：agent 要發文的時候，即時去搜尋資料、分析、寫文。這很貴——每次發文都要好幾次 LLM call。
我的做法是把「收集」和「思考」分開：
收集（0 LLM tokens） → 分析（1 LLM call） → 產出（1 LLM call）
RSS / HN / Jina Reader 整理成 markdown agent 讀完再寫文
收集階段完全不用 AI。用 HTTP 請求就能拿到所有原始資料。AI 只在最後「理解」和「產出」的時候才登場。
這讓整條情報管線的成本降到幾乎為零。
三個免費資料來源
1. RSS Feeds（行業部落格）
最老派但最可靠的資料來源。我訂閱了大約 20 個 AI 相關的 RSS feed：
# feeds.txt
https://openai.com/blog/rss.xml
https://blog.google/technology/ai/rss/
https://anthropic.com/research/rss.xml
https://huggingface.co/blog/feed.xml
# ... 以此類推
用一個簡單的 RSS parser 就能取得最新文章標題和連結。零成本、零 token。
2. Hacker News API（技術社群風向）
HN 有公開的 Firebase API，不需要認證：
# 取得當前熱門文章 ID
top_ids=$(curl -s "https://hacker-news.firebaseio.com/v0/topstories.json")
# 取得每篇文章的標題和分數
for id in $(echo "$top_ids" | jq '.[0:20][]'); do
item=$(curl -s "https://hacker-news.firebaseio.com/v0/item/$id.json")
title=$(echo "$item" | jq -r '.title')
score=$(echo "$item" | jq -r '.score')
url=$(echo "$item" | jq -r '.url // empty')
echo "$score | $title | $url"
done
HN 的熱門文章是技術社群最真實的風向標。如果某個主題在 HN 上有 200+ 分，那就是現在大家在關注的事。
3. Jina Reader API（網頁轉 Markdown）
這是整條管線裡最關鍵的一環。Jina Reader 可以把任何網頁轉成乾淨的 markdown：
# 把網頁轉成 markdown，免費
content=$(curl -s "https://r.jina.ai/$url")
不需要 API key（有免費額度）。它會自動去掉廣告、導航列、側邊欄，只留正文。
這代表 agent 可以「讀」任何文章。 不是讀標題，是讀全文。
完整的 Research Chain
把三個來源串起來就是我們的 research-chain.sh：
每天兩次（05:00, 17:00 CST）
│
├─ 1. 掃描 RSS feeds → 取得新文章列表（0 tokens）
├─ 2. 掃描 HN top stories → 取得熱門討論（0 tokens）
├─ 3. 挑出最相關的 5 篇 → Jina Reader 轉 markdown（0 tokens）
├─ 4. 送進 Gemini → 分析趨勢、提取重點（1 LLM call）
└─ 5. 輸出 → RESEARCH-NOTES.md
第 4 步的 prompt 大概是這樣：
你是 AI 行業分析師。以下是今天的新聞和討論：
[RSS 摘要]
[HN 熱門文章摘要]
請分析：
1. 今天最重要的 3 個趨勢
2. 跟我們產品（AI 安全、社群自動化）最相關的是什麼
3. 有什麼值得寫成文章的角度
輸出格式：markdown，簡潔，有觀點
輸出的 RESEARCH-NOTES.md 長這樣：
## 2026-04-14 情報摘要
### 趨勢 1: Agent-to-Agent 協議標準化
Google 和 Anthropic 分別發布了 agent 通訊協議...
→ 跟 OpenClaw 的 Content Relay 機制有關，可以寫比較文
### 趨勢 2: 企業 AI 安全預算增加 300%
Gartner 報告顯示...
→ UltraProbe 的定位正好在這個趨勢上
### 趨勢 3: 免費 LLM API 的競爭白熱化
Gemini, Claude, Llama 都在搶免費層...
→ 我們的零成本架構文章會有很多人想看
Agent 怎麼用這些情報
重點來了——這份 RESEARCH-NOTES.md 是所有 4 個 agent 共享的。
一次研究，四個 agent 受益。
每個 agent 在自動發文的時候，會把最新的 RESEARCH-NOTES.md 載入 prompt 的 context：
# 在 autopost prompt 裡注入情報
RESEARCH=$(tail -30 "$WORKSPACE/RESEARCH-NOTES.md")
prompt="你是 ${AGENT_ROLE}。
以下是今天的行業情報：
$RESEARCH
根據你的專業角度和品牌定位，寫一篇有觀點的文章。
不要複述新聞，要有自己的分析和見解。"
這帶來了一個非常大的改變：agent 的文章不再是憑空生成的，而是基於真實世界正在發生的事。
以前：「5 個 AI 安全最佳實踐」（空洞的通用文） 現在：「Google 剛發布的 Agent 協議為什麼忽略了安全層——以及你該怎麼補」（有時效性的分析）
競品分析：另一條零成本管線
除了技術趨勢，我們還有一條專門看競品的管線 competitor-watch.sh：
每天 06:30 CST（0 LLM tokens）
│
├─ 1. 抓 Moltbook 熱門文章 → 誰在發什麼、分數多少
├─ 2. 分析 pattern → 平均標題長度、提問比例、how-to 比例
├─ 3. 排除自己的帳號
└─ 4. 輸出 → COMPETITOR-INTEL.md
注意：這條管線完全不用 LLM。 全部是 HTTP 請求 + 本地的 JSON 處理。
輸出範例：
## 競品情報 2026-04-14
### 熱門文章 Top 5
1. "如何用 Claude 建自動化工作流" (score: 89)
2. "LLM 安全漏洞分類" (score: 67)
...
### Pattern 分析
- 平均標題長度: 18 字
- 提問式標題: 35%
- How-to 教學: 42%
- 趨勢分析: 23%
### 建議
- 提問式標題表現較好
- How-to 內容是基本盤
- 差異化機會：實戰案例（目前只有 8%）
Agent 讀完這份情報後，就知道「大家都在寫 how-to，那我可以寫案例來做差異化」。
這不是我教它的策略，是它從數據裡自己推導出來的。
成本計算
讓我算一下整條情報系統每天花多少：
| 元件 | 每日 calls | LLM tokens | 成本 |
|---|---|---|---|
| RSS 掃描 | ~20 HTTP | 0 | $0 |
| HN API | ~20 HTTP | 0 | $0 |
| Jina Reader | ~5 HTTP | 0 | $0 |
| 研究分析 | 2 次 | ~2 RPD | $0 (免費額度) |
| 競品分析 | 1 次 | 0 RPD | $0 |
| 總計 | ~2 RPD | $0/月 |
用 1,500 RPD 配額的 0.13% 就跑完了整個情報系統。
我學到的三件事
1. 情報收集和分析要分開
把它們混在一起，每次都要花大量 token 去「讀」原始網頁。分開後，收集用純 HTTP，分析只需要讀整理好的摘要。
2. 共享勝過重複
一次研究、四個 agent 用。如果每個 agent 各自做研究，就要花 4 倍的 token。集中研究、分散使用，是多 agent 系統的關鍵。
3. 數據驅動比指令驅動好
與其在 prompt 裡寫「你要有原創觀點」，不如給它真實數據讓它自己產生觀點。Agent 有了情報之後，產出的品質提升幅度遠超過你在 prompt 裡怎麼措辭。
動手做
想自己建一條的話，從這裡開始：
- 選 3-5 個你行業的 RSS feed — 不用多，品質比數量重要
- 設一個每天跑一次的 cron/timer — 收集 + 分析
- 輸出成一個 markdown 檔 — 讓你的 agent 或你自己每天讀
- 不要追求完美 — 先跑起來，品質慢慢調
完整的 research-chain.sh 和 competitor-watch.sh 都在 openclaw-playbook。
下一篇
情報系統讓單一 agent 變聰明了。但當你有 4 個 agent 的時候，新的問題出現了：它們怎麼知道彼此在做什麼？怎麼避免重複？怎麼協作？
下一篇：多 Agent 協作架構：怎麼讓 4 個 AI 不打架
這是「一人公司的 AI 團隊」系列第 3 篇。第 1 篇：我為什麼需要 AI 團隊 · 第 2 篇：第一個 Agent 上線那天