ibegyourpardon

@codehz 谢谢啦，我也发现了这点。正在换方案。

@modao526 应该不至于……

@ddosakurax 对，langchain 使用的是 duck-duck-scrape ，它底层是 xmlhttprequest ， 但是在 cloudflare 上不支持，它家的 worker 只支持 fetch ，所以我才改了下。

主要是给一些个人项目需要白嫖的时候可以用用。

升级到 14.1.2 ，通知中心卡死再也打不开了。notification center 进程还 99.9 CPU 掉不下来，网上一搜虽然不普遍，但只要出现了这个问题的都还没什么完美解决办法。

Gen 系列除了贵其实我觉得没什么缺点

作为主功能来说确实不是很适合，但作为非主业务的补充，一些边缘化的事情，写进主单体或者部署个微服务反而头疼，如果正好用量占比又不大，云函数我觉得非常合适，我自己就有大概二三十个类似的云函数。

它们有一些共同特征，本身逻辑简单，没太多状态，放进哪个仓库或者服务都觉得不是很符合语义或者模块划分，单起个又恶心，这个云函数的服务本身甚至可有可无，也许只是个实验特性，这一类我现在优先会选择用个简单的云函数快速跑起来，先满足了业务需求再说。

当然云函数也有一些问题，本身写起来如果依赖的东西多，放云函数里跑限制一堆，很麻烦，数量也很容易暴涨。但数量保障我觉得就是没规划好，说明不是一些适合放到这里面的服务。

我大概二三十个，有的一两年前的我都快忘了代码了，真要更新迭代我十有八九不会去修改这个云函数，而是去直接快速重写一个，很大可能一天内就搞定了。这也是我会把云函数用的地方，有一些属于不需要长期更新迭代，但会长期使用的轻量级业务，我都会扔进去。

而一个足够大型的系统，十有八九总能找到这样一些类似的边缘的业务。当然要不要上云函数那是见仁见智。

我这周才刚又写了一个近似于采集系统的东西，非典型业务，不适合抽象起来放进现有架构，又急需，以后又基本没什么更新，用量不大，一天目测就几百次调用，这种我就是一天写完，一天测试，丢上去完事。

过几个月也许有迭代了再说，大迭代就重写拉倒。

我个人目前在用也是我推荐的方式其实是 LangPilot ……

但事实上我真正主力依赖的还是 GitHub Copilot 的那些东西。Copilot 和 Chat 类不一样，最大的难点我觉得不是在 server 端或者说 LLM ，而是在 client 怎样更好的构建上下文，理解不同窗口和 tab 的关系，理解文件夹树，理解项目结构，这些在端侧构建的东西的好坏极大程度影响 copilot 的质量。

go 。

我 30 分钟就不行了