当我们需要深入了解某个技术主题或行业趋势时，传统的做法是在单个平台上进行搜索，然后手动汇总信息。然而，这种方式存在明显的局限性：Reddit 的讨论可能遗漏 X（原 Twitter）上的实时热点，YouTube 上的深度解析可能被搜索引擎忽略，而预测市场中的真实资金流向更是传统搜索无法触达的领域。last30days 项目正是为了解决这一痛点而设计 —— 它是一个能够同时扫描八个社交和内容平台、聚合预测市场数据、并合成结构化研究摘要的 AI 智能体。本文将从工程实践的角度，深入解析其核心技术架构与实现细节。

多平台数据聚合的整体设计

last30days 的设计目标非常明确：在过去 30 天内的互联网上，针对任意主题找到社区真正在关注、讨论、分享和押注的内容。为了实现这一目标，项目采用了多源并行搜索加统一评分排序的架构。当前支持的平台包括 Reddit、X（通过官方 GraphQL API 或 xAI 后端）、YouTube（带字幕提取）、TikTok、Instagram、Hacker News（通过 Algolia API）、Polymarket 预测市场，以及传统网页搜索。每个平台都有独立的搜索模块，负责将统一的查询意图转换为平台特定的搜索语法，并获取平台原生的返回结果。

这种设计的关键优势在于平台解耦。当某个平台的 API 发生变化或失效时，只需要修改对应的适配器，而不会影响其他平台的搜索功能。项目使用了环境变量来管理不同平台的 API 密钥，包括 SCRAPECREATORS_API_KEY（覆盖 Reddit、TikTok、Instagram 三个平台）、AUTH_TOKEN 和 CT0（用于 X 的 GraphQL 认证）、可选的 XAI_API_KEY 作为 X 搜索的后备方案，以及 BRAVE_API_KEY、PARALLEL_API_KEY 等用于网页搜索的密钥。这种密钥隔离机制确保了每个 API 密钥只会被发送到对应的服务端点，增强了安全性。

两阶段搜索架构的工程实现

理解 last30days 的搜索流程，需要重点关注其两阶段设计。第一阶段称为 “广度发现”（Broad Discovery），它使用大语言模型的 Web Search 工具对各个平台进行初步搜索。以 Reddit 为例，项目使用 OpenAI Responses API 的 web_search 工具将搜索范围限定在 reddit.com 域名下；X 搜索则通过内嵌的 Twitter GraphQL 客户端或 xAI 的 x_search 后端完成；YouTube 搜索依赖 yt-dlp 工具获取视频元数据并提取自动生成的字幕；Hacker News 和 Polymarket 分别通过 Algolia API 和 Gamma API 进行查询，这些 API 都是免费的且不需要认证。

第二阶段是 “智能补充搜索”（Smart Supplemental Search），这是提升搜索质量的关键所在。在第一阶段返回结果后，系统会自动提取关键实体：X 帖子中的 @handle、Reddit 帖子中的 subreddit 名称。然后，它会针对这些实体运行有针对性的后续查询。例如，如果第一阶段发现了关于 Claude Code 的讨论，系统会进一步搜索特定 subreddit（如 r/ClaudeAI、r/ClaudeCode）中的相关内容，或者直接搜索相关作者的最近帖子。这种方式能够发现关键词搜索完全遗漏的内容，尤其是那些标题中不包含目标关键词但实际高度相关的帖子。

这种两阶段架构的设计灵感来自于信息检索中的 “查询扩展” 概念，但其实现更加智能化。第一阶段的查询构建器会主动剥离研究类和元信息词汇（如 “best”“prompt”“techniques” 等），将原本过于具体的查询简化为核心主题。系统还会实现自动重试机制 —— 当某个查询返回零结果时，它会自动尝试使用更少的关键词重新搜索。这种看似简单的优化在实际测试中效果显著：研究 “vibe motion” 相关主题时，从零结果变成了找到 12 条以上的相关帖子。

多信号质量排序算法

当多个平台的搜索结果汇聚到统一 pipeline 中时，如何决定哪些内容应该排在前面？last30days 实现了一套复杂的多信号质量排序算法，该算法在 2.5 版本中经过重大升级后，在盲测中的质量评分从 3.73/5.0 提升到了 4.38/5.0。

排序算法的核心是文本相似度引擎。系统采用双向子字符串匹配结合同义词扩展和 token 级别重叠评分的方式。例如，“hip hop” 会匹配到 “rap”，“MacBook” 会匹配到 “Mac”，"AI video" 会匹配到 "text to video"。通过这种方式，一个原本相似度只有 0.33（几乎被过滤掉）的嘻哈音乐混音视频标题，相似度可以提升到 0.71。YouTube 视频的匹配还会额外检查视频字幕内容，即使标题中没有提到目标关键词，只要字幕中讨论了该主题，同样可以被正确识别。

对于 Polymarket 预测市场这一特殊数据源，系统使用了专门的五因素加权评分模型：文本相关性权重 30%、24 小时交易量权重 30%、流动性深度权重 15%、价格变动速度权重 10%、以及结果竞争度权重 10%。值得注意的是 outcome-aware scoring 机制 —— 当某个主题是某个更大市场的具体结果时（例如 “Arizona” 作为 NCAA 冠军竞猜中的一个选项），系统会使用双向子字符串匹配和 token 重叠，将主题与各个独立的市场仓位进行匹配，而不仅仅是与市场标题匹配。

跨平台收敛检测是另一个重要特性。当同一个故事或话题在多个平台上同时出现时（例如 Reddit 和 Hacker News 都在讨论同一个新闻），系统会标记这些内容为 [also on: Reddit, HN]，这意味着该信息通过了多个独立信源的验证。检测算法使用了混合相似度计算方法 —— 结合字符级别的 trigram Jaccard 相似度和 token 级别的 Jaccard 相似度，即使不同平台上的标题表述完全不同，也能够正确识别出它们指向同一事件。

预测市场作为信息源的价值

在 last30days 引入的所有数据源中，Polymarket 预测市场是最具创新性的一个。传统搜索只能告诉我们 “人们在说什么”，而预测市场能够揭示 “人们愿意拿真金白银赌什么”。这两者之间往往存在显著差异 ——Reddit 上某家公司可能负面评论缠身，但预测市场可能给出完全不同的概率，因为交易者基于的是更全面的信息。

系统通过两阶段查询扩展来处理预测市场的发现。第一阶段并行搜索所有目标主题词，从返回结果中提取结构化的类别标签（如 "NCAA CBB"、"Geopolitics" 等）。第二阶段使用这些领域标签进行扩展搜索，发现那些通过标题关键词完全无法找到的市场。例如，搜索 “Arizona Basketball” 时，系统不仅会找到直接提及 Arizona 的市场，还会发现 NCAA 冠军竞猜中 Arizona 的具体赔率。

对于 Polymarket 的多结果事件（如每个球队都是一个独立的 Yes/No 市场），系统实现了 “负风险二进制市场合成” 功能。它能够检测这种多结果模式，从市场问题中提取实体名称，并合成统一的结果展示 —— 直接显示 "Arizona: 12%, Duke: 18%, Houston: 15%"，而不是让用户面对一堆 "Yes: 12%, No: 88%" 的原始数据。

处理与存储：Watchlist 与持续研究

除了单次研究功能，last30days 还提供了一个 “开放变体”（Open Variant），专为持续监控设计。该变体允许用户维护一个主题 - watchlist，并为每个主题设置研究频率（每天、每周、每月等）。当与 cron 任务或类似 Open Claw 的常驻机器人配合使用时，系统可以按照设定的时间表自动重新研究这些主题，并将结果累积到本地的 SQLite 数据库中。

用户可以随时向系统查询历史研究成果，例如 “过去一个月关于 AI 视频工具的研究发现了什么？” 系统会从本地数据库中检索相关记录，并基于累积的发现合成新的摘要。这种设计特别适合需要持续跟踪竞争对手动态、技术趋势或行业新闻的场景。

研究成果会自动保存到 ~/Documents/Last30Days/ 目录，每个研究主题一个 Markdown 文件。用户无需额外操作，即可逐步构建个人的研究知识库。

性能权衡与配置选项

多平台深度搜索需要付出时间成本。项目文档明确指出，全量搜索可能需要 2 到 8 分钟，取决于主题的冷门程度。为了满足不同场景的需求，系统提供了三种模式选择：

--quick 模式牺牲深度换取速度，每个平台只搜索 8 到 12 个结果，跳过补充搜索阶段，YouTube 只分析 10 个视频和 3 个字幕。--deep 模式则进行最彻底的研究，Reddit 搜索 50 到 70 个帖子，X 搜索 40 到 60 条推文，YouTube 分析 40 个视频和 8 个字幕，并通过扩展的补充搜索发现更多相关内容。默认模式在两者之间取得平衡，适合大多数日常研究需求。

用户还可以通过 --days=N 参数自定义回溯时间范围，默认是 30 天，但可以设置为 7 天获取周报，或 14 天获取双周汇总。--sources 参数允许限定只搜索特定平台，例如 --sources=reddit 只研究 Reddit 讨论。

环境配置与项目隔离

项目支持全局配置和项目级配置两个层次。全局配置存放在 ~/.config/last30days/.env 文件中，包含了跨所有研究任务共享的 API 密钥。对于需要在不同项目中使用不同 API 密钥的场景（例如使用不同的 X 账户或 API 配额），可以在项目根目录下创建 .claude/last30days.env 文件，项目级配置会覆盖全局配置。

当 Claude Code 会话启动时，系统会进行配置检查，验证所有必要的 API 密钥是否已正确配置。这种设计减少了因配置遗漏导致的运行时错误。

架构启发与扩展思考

last30days 项目的架构为构建类似的多平台聚合系统提供了有价值的参考。首先，平台适配器的解耦设计使得添加新数据源变得相对简单 —— 只需要实现标准的搜索接口和结果转换逻辑。其次，两阶段搜索架构在广度和深度之间取得了良好平衡，第一阶段保证覆盖率，第二阶段提升精确度。预测市场的集成则展示了一种有趣的信息源思路 —— 资金流向往往比言论更能反映真实的预期和共识。

对于希望在本地部署类似系统的开发者，项目也指明了一些挑战：搜索时间与结果质量成正比，需要根据实际需求选择合适的模式；某些平台（特别是 X）的认证方式依赖浏览器 cookie，配置过程相对繁琐；API 密钥的管理需要谨慎处理，确保不同密钥的隔离和安全性。

总体而言，last30days 展示了一种将多个异构数据源统一在一个研究 pipeline 中的工程可行方案，其核心技术思路 —— 两阶段搜索、多信号排序、跨平台收敛检测 —— 可以在其他信息聚合场景中得到广泛应用。

资料来源：