用 News Search API 做一個早間簡報 Agent

創業者、PM、分析師早上 8 點想要的都是同一樣東西:一份精煉的「昨夜發生了什麼」摘要。一個 News Search API、一次 LLM 呼叫、一份 cron,下午就能交付。
一句話總結
- •架構:cron → News Search → 對熱門稿件 URL Extract → LLM 產生摘要 → 發 Slack/Email。
- •用 <code>start_date = 昨天</code> 控制新鮮度;用 <code>country_code</code> 控制地區。
- •並行多次 News Search 把簡報依主題切塊;讓 LLM 合併並去重。
- •總成本 ≈ 每個主題 15 credits/天,加上 LLM token。5 主題簡報按牌價 < $0.10/天。
一份「有用」的簡報長什麼樣
早間簡報 Agent 應該回答一個問題:「昨夜有哪些我必須知道的變化?」門檻比想像中高。一堆標題不行 —— 那就是 RSS,一週以內會被靜音。能留下來的格式是:5 條帶連結的要點,依主題分組,用使用者的語氣寫。
這條標準拆下來就是一個小管線:
- 抓取 N 個主題的近期新聞 —— News Search API。
- 擷取 模型想要引用的連結正文 —— URL Extract API。
- 摘要 + 分群 —— 任意你信任的 LLM。
- 投遞 Slack / Email / Notion —— 你已有的溝通管道。
- 排程 cron —— Vercel Cron、GitHub Actions、n8n 都行。
Step 1:選好主題
3–6 個主題就夠。12 個主題的簡報會被滑過去。例:
- B2B SaaS 創辦人:「AI 募資輪」、「OpenAI / Anthropic 動態」、「競品動作」。
- 金融分析師:「FOMC 與 Treasury」、「半導體供應鏈」、「特定 ticker」。
- 醫療 PM:「FDA 核准」、「臨床試驗讀數」、「給付規則變更」。
Step 2:抓原始訊號
每個主題並行呼叫一次 News Search。用 start_date 控新鮮度:
from datetime import date, timedelta
import asyncio, aiohttp
KEY = "pk_yourkey"
TOPICS = [
"AI agent infrastructure funding",
"OpenAI Anthropic Google new releases",
"RAG and LLM tool calling research",
]
async def fetch_topic(session, q):
yesterday = (date.today() - timedelta(days=1)).isoformat()
async with session.post(
"https://www.apipick.com/api/search/news",
headers={"x-api-key": KEY},
json={"query": q, "start_date": yesterday},
) as r:
return q, await r.json()
async def fetch_all():
async with aiohttp.ClientSession() as s:
return await asyncio.gather(*[fetch_topic(s, q) for q in TOPICS])每次回傳最多 5 條 ranked 標題(用 num_results 可拉到 10)。3 主題簡報每天 3 × 15 = 45 credits,按 $5 / 5,000 折算 ≈ $0.045/天。新聞 API 在每日總成本裡其實占小頭,大頭是 LLM。
Step 3:選擇性擷取正文
不需要把每條新聞的正文都擷取出來 —— 只要模型可能詳細引用的那幾條。一個簡單的啟發法:每個主題擷取前 2 條。在 API Pick 上一次批次呼叫即可:
import requests
urls = [r["url"] for topic, payload in results for r in payload["results"][:2]]
extracted = requests.post(
"https://www.apipick.com/api/extract",
headers={"x-api-key": KEY},
json={"urls": urls, "extract_effort": "auto"},
).json()每個 URL 2 credits,3 主題簡報擷取這一步約每天 12 credits。
Step 4:摘要提示詞
提示詞決定簡報的「聲音」。一個起點:
You are an assistant that writes a morning briefing in <Sarah's> voice:
direct, no fluff, no marketing language.
Input: a JSON list of {topic, headlines, extracted_bodies}.
Output rules:
- 1 short paragraph per topic, max 60 words.
- Each paragraph ends with up to 3 inline source links.
- If a topic has fewer than 2 substantive stories overnight, omit it.
- If the entire briefing has fewer than 2 substantive topics, output the
literal token SKIP and nothing else.
- Never editorialise. Quote facts and figures verbatim from the sources.
Output format: Slack-flavoured markdown.「低訊號就 SKIP」是單條 ROI 最高的規則。這是簡報不會被 mute 的根本原因。
Step 5:投遞與排程
Python cron 實作整體不到 80 行。Slack 投遞:
if briefing.strip() == "SKIP":
return
requests.post(
SLACK_WEBHOOK_URL,
json={"text": briefing, "username": "Morning Briefing", "icon_emoji": ":sunrise:"},
)排程可用 Vercel Cron(寫在 vercel.json)、GitHub Actions、AWS EventBridge、n8n。在你的時區 7:45 跑 —— 目標是 8 點坐下時它已經在那。
不寫程式碼就用 n8n
- Schedule trigger:每天 7:45(使用者時區)。
- HTTP Request 節點(每個主題一個):POST
/api/search/news,start_date= 昨天。 - Merge 節點合併多主題結果。
- HTTP Request 節點呼叫
/api/extract。 - OpenAI / Anthropic 節點跑摘要提示詞。
- If 節點判斷輸出不是 SKIP。
- Slack 節點發簡報。
正式環境要盯的幾件事
- 主題漂移。「AI agents」這種寬口徑過半年會失效 —— 索引在長大,簡報卻保持具體。每季收緊一次 query。
- 跨日重複。把昨天的 URL 清單傳給模型並要求「不要再講這些故事」。
- 週末偏靜。SKIP 已經處理了;只是別把每日 check-in 習慣綁在簡報上。
持續迭代,不要「發完就忘」
頭一週每天讀一遍簡報。記錄模型在哪兒編造、錯誤歸類或漏掉資訊,然後改提示詞。一週以後簡報會變成習慣 —— 而你也用大約 80 行程式碼、3 次 API 呼叫,跑出了一個能用的 Agent。
常見問題
為什麼不直接用 Google News 或 RSS 聚合器?
都能用 —— 但都把無聊的部分留給了你:分群、去重、摘要、寫出真正的簡報文字。Agent 用 LLM 把這部分搞定了。RSS 給你標題,Agent 給你「這件事重要在哪、附原文連結」的一段話。
News Search API 的新鮮度如何?
近即時索引主流新聞媒體。覆蓋前 24 小時的早間簡報,把 start_date 設為昨天即可。每小時跑一次的突發新聞 Bot,把 start_date 設為今天,並基於上一次結果做去重。
如果今天沒什麼值得說的呢?
把它寫進提示詞:「If fewer than 3 substantive stories changed overnight, return SKIP.」cron 任務收到 SKIP 就別發。簡報疲勞是 Slack 頻道被 mute 的最快路徑。
不用 n8n 也能跑嗎?
可以。下面給的 30 行 Python 腳本配 cron 就夠了。n8n 適合可視化除錯與 Slack 整合,但不是必需。
怎麼避免同一條新聞被多個主題重複摘要?
在同一次執行裡把已涵蓋過的 URL 一併傳給模型,並寫明「不要重複提到這些 URL」;或者一次性多主題搜尋,讓模型自己分桶。兩種都行,第二種更省錢。
本文使用的 API
Sarah Choy 是 API Pick 的 CEO,專注於為 AI Agent 與 LLM 工作流打造可用於正式環境的 API。