Phase 2 / Ep 10: 外部深海区预警（API Research）

⏱ 预计阅读 3 分钟 更新于 2026/4/13

任何一个应用一旦涉及到需要通过网络握手连接外部实体（Google、微信、Stripe 等），其难度就不是线性攀升的，而是呈指数级跳跃。

在 T-Block 中，我们的业务生命线——双向同步 Google Calendar，可能潜藏着无限个导致架构推翻的隐坑。比如：

  • 获取到的 Event token 半小时就过期了该怎么续期？
  • Google 是否允许我们频繁地通过 Pull 拉取数据？（API Query 上限会直接杀死我们的应用）。

1. 放飞自动探查兵 (Auto-Researcher)

我们不要自己去啃那无聊且反人类的 Google Cloud 文档。我们要调用大模型最新的 search_web 和 browser_subagent。

向 Agent 下达如下高级战术命令：

“这是关键性的风险阻断预研局。我现在需要你化身为 API 攻防合规专家。请利用你的联网抓取能力，去深度查阅 Google Calendar API V3 的限制章节。

我特别需要搞清楚：第一，我们要如何保持一个非 Web 长连状态的后端能安全且永久拿到 Refresh Token 同步日历；第二，如果想要监听日历库外部修改，有没有比死循环轮询（Polling）更好、成本更低的办法（是否支持 Webhook Push）。

请把你查阅到的硬核结论和代码开发时可能踩的暗雷，梳理成指南，追记到 docs/findings.md 中的 [深度前哨雷区] 标签下。”

2. 让 AI 完成闭环认知

这时候，如果你查看它背后的工具链运行记录（在普通聊天里你是看不到的机制），你会发现 Agent 会花好几分钟在终端发起多次 search 与网页抓取逻辑。

它最终也许会像一个探子一样满头大汗地跑回来告诉你（并且已写在 findings 里）：

  1. 警告：Google OAuth refresh_token 只有在首次授权弹窗强制带上 prompt=consent&access_type=offline 的时候才会派发！如果不写代码规避这点，一旦 session 失效，用户数据就成僵尸了！
  2. 狂喜：Google 支持 Push Notifications 频道订阅这种高级的 Webhook，当外部改了日程它直接发 POST 告诉你服务器，能省掉 90% 的无效轮询成本。

至此，那些坑死过无数入门小团队的代码“天坑”，在还没有开始写一行真正的业务代码之前，已经被这位具有互联网知识池和探查能力的 AI 工程师用文件彻底“封印”并排除了！