lobehub采用agent outside sandbox架构突破AI Agent能力上限

这个问题其实上半年就有社区在讨论了，如果抽象出来看其实是 agent in sandbox 和 agent outside sandbox 的方向性差异。现在主流的做法其实都是agent in sandbox ，而我给 lobehub 的做法是后者。这使得我们能实现极高的agent 能力上限。

譬如 场景一： 当我在 1c2g 的机器中执行typecheck 导致整个机器卡死时，我们的agent loop由于在sandbox外，这个loop仍然能够正常运行，并且在发现机器卡死时，可以自主尝试切换并激活另外一台设备，甚至尝试自行去declare一台更大规格的机器，resume env 后继续执行。而这在 agent in sandbox 模式下是根本做不到的。沙箱一卡，整个agent 进程就死了 场景二： 在我们的 goal 模式下，主 agent 可以自行创建不同的 task 下发给不同的agent 执行，此时可以动态选择每个 agent 的具体执行设备环境(比如我自己有三台 mac 同时可以跑)，甚至当我们给到主 agent 相应的设备负载时，主agent 将能够自行选择合适的设备来派发任务。

而这也是 agent in sandbox 无法做到的。当然，agent outside sandbox 的技术难度很高，因为原本在一台设备里都不存在的问题，在这样的分布式环境下都涌现了出来。譬如设备连接突然下线或者连接不稳定，工具调用转成 RTC (Remote Tools Calling) 模式下的幂等重试， serverless agent loop 的竞态与并发… 过去大半年我们几乎把分布式场景下能踩的坑全踩了一遍，才逐步做到我自己都愿意在 coding 场景下用的程度。

正是由于这种架构级别的差异，我们才能做到远比当前 agent in sandbox 模式低很多的单次执行成本和高 1-2 个数量级的并发能力。而据我所知，我们现在在 cloud 跑 agent 的量级，都够得上前沿模型 middle training 阶段需要的量了🤯