用 News Search API 做一个早间简报 Agent

创业者、PM、分析师早上 8 点想要的都是同一样东西:一份精炼的「昨夜发生了什么」摘要。一个 News Search API、一次 LLM 调用、一份 cron,下午就能交付。
一句话总结
- •架构:cron → News Search → 对热门稿件 URL Extract → LLM 生成摘要 → 发 Slack/邮箱。
- •用 <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 / 邮件 / 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。