响马高见: > 工程师永远不会消失,但是工作方式会变化。工具化永远会进化到 roi 低于人力的边界,然后需要更多的人力来补齐最后的缝隙。 类似于你开了一家餐厅,买了一台洗碗机,一下子替代了 3 个洗碗工,效率高、成本低。这就是工具化带来的 ROI(投入产出比)远高于人力的阶段。 但洗碗机洗不了所有东西。异形的锅、烧焦的铁板、精致的瓷器,这些还得靠人手洗。你可以花大价钱去研发一台能洗一切的超级洗碗机,但为了搞定最后这 5% 的餐具,你可能得投入比前面 95% 多十倍的钱。 这时候你算一笔账:与其砸钱造那台超级机器,不如留一个洗碗工来处理这些边角料,人力反而更划算了。 工具进化到某个点之后,再往前推的成本急剧上升,ROI 跌到比直接用人还低。 另一个角度,工具越强,整个行业的总产出往往也在膨胀。洗碗机让你的餐厅能接待更多客人,于是产生了更多的异形锅、更多的特殊情况,那些“缝隙”的绝对数量反而变多了。所以你可能裁了 3 个普通洗碗工,最后又请了 2 个专门处理疑难杂症的人。 AI 工具会吃掉大量标准化的编程工作,但软件行业的总规模也会因此爆发式增长,而增长带来的各种边界情况、系统集成、业务理解这些“缝隙”,短期内仍然需要人来填。
Pi 今天开始做的这些 「数据库范式」方向的尝试,其实是我们去年开始 agent 转型时候就已经预设好的,而且方向上更加激进 —— 如何实现在 Vercel 这样进程级实例,短单次时长(timeout 可能 300s)的 Serverless 平台上,实现超长程级 agent 的执行。 当时没有 claude code 源码,没有 codex,更没有 pi / open code 框架。我从头开始实现了 LobeHub 现在 agent runtime 这一层,day0 就是云原生友好的。 而且我们现在在我们 Cloud 上已经能实现: - 秒级单用户 1000 级别 agent 并发执行(甚至我们的 eval 是直接跑在我们线上环境); - 我们的用户最长一次单 agent 云端执行 3600 多步,而且正常跑完; - 极低的单次 agent 调度执行成本,可以让我们做到远比行业低 10 倍的 agent 执行成本; 所以,哪怕 pi v2 真正开始落地「数据库范式」,也只是"权威记录"和"执行状态"都塞进同一个 per-lane 的 op log(因为它假设单进程单 writer),而我们是天然分布式的多 worker/serverless 环境。 而 pi 的 non-goal 里写死了"multiple writers"不支持,一个 session 只由一个 harness 进程独占;但在我们的场景下,必须处理多个 worker 可能同时抢一个 operation 的情况,这个问题本身比 pi 的设定更难。 等 pi v2 发布后再过个半年,作者就会意识到 v2 这套架构的局限性。可能又会开始做下一轮的架构升级。 而我们现在已经在往 Long Hornizal Task 和 RSI 迈下下一步了