一个完全免费、能在谷歌文档和表格里跑代码的低代码平台，却被钉死在6分钟的执行上限——你还能拿它来做大规模数据处理和AI代理网络吗？

谷歌应用脚本（Google Apps Script）一直是连接谷歌办公套件的“万能胶水”。但它的容器是同步、无状态的，单个脚本实例运行满360秒就被强制终止。这让开发者不得不绕着走：要么靠定时触发器分批干活，但触发器有启动延迟、漏触发，还受调用配额掣肘；要么用 fetchAll 做并行请求，可整个批次仍被拴在父容器的6分钟屋檐下，最慢的那个任务一超时，全部完蛋。

打开网易新闻 查看精彩图片

有人曾用 RunAll 框架试水异步，结果还是没能挣脱容器天花板。转机出现在 UrlFetchApp 工具新增了 timeoutSeconds 参数。这就像在请求里设定一个“秒级自我了断”。如果让派发器向自己部署的 Web 应用发出回环请求，并故意把超时设成1秒，派发器会在发出任务后立即切断自己的等待——它的执fr行配额被释放，而目标 Web 应用已在一个隔离子容器中开始干活，完全不受6分钟制约。这样一来，调用方只承担一个几乎为零的时间成本，被调用的 Web 应用却能跑到任务结束。

把这种1秒超时的鸡贼设计跟谷歌表格组成一个事务性状态机，事情就更有趣了。每项任务在表格里生成一行记录，登记状态、输入参数和结果。派发器扫描待办行，发起1秒超时调用后立刻标记“进行中”；工人跑完回写结果、更新状态。表格天然的行级事务特性，让多个工人同时读写也不会写脏。而派发器本身也能以工人模式被自己唤醒，滚动触发下一批任务，形成自延续的并行管线。这意味着，哪怕所有容器都有生存时间，只要它们能互相喂活、接力推进，整个系统就“无限”运转下去了。

一个过去只能跑跑邮件合并和表单响应的环境，现在能原生化地调度海量并行 MapReduce 任务。原来必须接外部云函数的瓶颈被消解，算力账单省了。更亮眼的是在多轮生成式AI代理场景里，每个代理的上下文状态可以暂存在表格行里，被1秒超时调用启动后，直接从前一回合的表格状态中恢复思考链，不用外挂缓存服务，也不需要维系长连接。

把1秒超时从一个容错参数变成架构核心，这个思路没有发明任何新组件，却重新定义了一个老平台的边界。当基础设施看似捉襟见肘时，恰恰是资源约束逼出了这种“刚刚好”的设计——用最轻的成本换掉限制最大的那把锁，然后让任务飞一会儿。