1. 从一条 X 推文到一次微信提醒Codex 重置雷达配置全流程拆解Codex 重置雷达是一套把公开 X 推文转成微信订阅消息的监控链路核心能力是“认人、认事、只提醒一次”。它适合两类人一类是重度使用 Codex 的开发者想第一时间知道额度或配额是否重置另一类是正在学事件驱动架构的工程师想找一个真实可跑通的小项目练手。整条链路并不复杂但真正落地时会卡在三个地方怎么判断一条推文是“新事件”而不是“内容变化”、怎么保证同一件事不重复打扰、微信发送失败时事件怎么不丢。这篇就把这三道关拆开给你一份可以直接复制的config.toml和settings.json骨架再带你手动触发一次确认从推文到提醒的完整通路能跑通。我试过把这套链路拆成采集器和小程序服务两个进程中间用一个内部接口交接踩过的坑基本都集中在“事件去重”和“失败补偿”上。下面按落地顺序讲你可以边看边改配置。2. TaoToken 前置先把模型调用和 Key 准备好雷达本身不依赖大模型也能跑但如果你想让它在判断“这条推文是不是 Codex 重置信号”时更稳一点可以接一层语义判断。这时候就需要一个稳定的模型调用入口。TaoToken 提供统一的 API 地址兼容常见的 OpenAI 风格调用配置里只需要改base_url和api_key两个字段。官网入口在这里https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册后在控制台创建 Key 即可。API 地址是 https://taotoken.net/api 注意这个地址不带任何查询参数直接填到配置里就行。如果你只是先跑通“推文到微信”这条链路模型判断可以先留空等链路通了再补。但如果你打算长期跑建议把 Key 管理好别硬编码在代码里。控制台地址https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite API Keys 管理页https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。注意Key 只放在服务端环境变量或本地配置文件里不要提交到公开仓库。采集器和小程序服务用同一个 Key 时建议拆成两个方便单独吊销。3. 可复制配置config.toml 与 settings.json 骨架整条链路有两个配置文件采集器用config.toml小程序服务用settings.json。先给采集器的骨架。# config.toml —— 采集器配置 [source] # 监控的公开 X 账号这里以 Tibo 为例 handle thsottiaux # 只接受指向 status 的链接 url_pattern ^https://x\\.com/thsottiaux/status/\\d$ # 采集间隔单位秒 poll_interval 90 [event] # 判断新事件的核心字段最新重置时间 reset_time_field latest_reset_at # 去重键优先级先推文 ID再重置时间 dedup_keys [tweet_id, reset_time] # 历史记录文件用于比对 history_file ./data/history.jsonl [handoff] # 交接给小程序服务的内部接口 endpoint http://127.0.0.1:8787/internal/events # 短重试次数 retry_times 3 # 重试间隔单位秒 retry_backoff [2, 5, 10] # 交接失败后的本地补偿队列 compensate_file ./data/compensate.jsonl [model] # 可选语义判断不填则跳过 base_url https://taotoken.net/api api_key ${TAOTOKEN_API_KEY} model gpt-4o-mini enabled false再给小程序服务的骨架。{ server: { host: 127.0.0.1, port: 8787, internal_token: change-me-internal }, wechat: { appid: your-appid, secret: your-secret, template_id: your-template-id, page: pages/radar/index }, queue: { pending_file: ./data/pending.jsonl, max_retry: 5, retry_backoff: [5, 15, 60, 180, 600] }, dedup: { store_file: ./data/sent.jsonl } }两个文件里最关键的是dedup_keys和retry_backoff。前者决定“同一件事只提醒一次”能不能成立后者决定“微信暂时发不出去事情会不会丢”。internal_token是采集器和小程序服务之间的共享密钥别用默认值。4. 验证请求手动触发一次完整通路配置写好后先别急着开定时任务手动触发一次确认推文到提醒能跑通。分三步。第一步启动小程序服务。python -m radar.server --config ./settings.json看到listening on 127.0.0.1:8787就说明服务起来了。第二步手动跑一次采集器只处理一条测试推文。python -m radar.collector --config ./config.toml --once --dry-run--once表示只跑一轮--dry-run表示不真正发送只打印判断结果。正常输出类似[source] fetched 1 candidate [event] tweet_id1234567890 reset_time2025-01-01T10:00:00Z [event] is_newtrue reasonreset_time_newer [handoff] dry-run, skip post如果is_newfalse说明历史记录里已经有这条去重生效了这是对的。第三步去掉--dry-run真正交接一次。python -m radar.collector --config ./config.toml --once采集器会 POST 到http://127.0.0.1:8787/internal/events小程序服务收到后写入待发送队列后台任务再调微信订阅消息接口。你手机上应该能收到一条“发现新的 Codex 重置公开信号”。如果没收到先看服务日志里有没有wechat send ok再看pending.jsonl里事件是否还在。提示第一次验证时把poll_interval调大一点避免定时任务和手动触发撞在一起日志会乱。5. 本篇常见错排查错误一is_new一直是 false但明明是新推文。大概率是reset_time_field对不上。采集器解析出来的字段名和配置里写的不一致比对时就会拿空值去比结果永远不新。解决方法是先--dry-run打印原始记录确认字段名再改配置。错误二微信发送报40001或40003。这是 access_token 或 appid/secret 的问题。检查settings.json里的appid和secret是否和微信后台一致access_token 是否有缓存过期。服务里建议做一层 token 缓存别每次发送都重新获取。错误三事件交接失败后丢了。看compensate.jsonl有没有写入。如果没写说明retry_times用完后直接抛异常了没进补偿队列。检查handoff段的compensate_file路径是否有写权限。错误四同一件事收到两条提醒。去重键没生效。检查dedup_keys里的tweet_id是否真的从推文里解析出来了有些转发或引用推文的 ID 和原推不同需要单独处理。另外sent.jsonl如果被清空去重也会失效。错误五模型判断开启后采集变慢。每条推文都调一次模型延迟会叠加。建议只在“来源核对通过、但重置时间判断模糊”时才调模型别每条都调。模型对话入口https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。6. 长期跑起来把雷达变成值班员链路跑通一次之后接下来就是让它稳定跑。采集器建议用 systemd 或 supervisor 托管小程序服务的后台发送任务单独起一个 worker别和 HTTP 服务混在一个进程里。补偿队列要定期清理已经成功发送的事件从pending.jsonl里删掉避免文件无限增长。如果你打算长期跑并且想让雷达在判断信号时更聪明一点可以看看 Coding Plan把模型调用额度固定下来避免临时 Key 过期导致判断链路断掉https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。Claude Code 相关的接入配置也可以参考https://taotoken.net/claude-code?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecodeutm_campaignrewrite 。最后留一个实用技巧把history.jsonl和sent.jsonl分开存前者记录所有采集到的信号后者只记录已提醒的。这样排查“为什么没提醒”时先看 history 里有没有再看 sent 里有没有两步就能定位是采集问题还是发送问题。