之前在社交媒体里提过, 我们需要面向六个月以后的模型能力进行应用构建. 这个是我们在反思为什么 Haye 没有出现小龙虾那样的能力后, 做出的一些判断.
很激进, 很加速.
永远使用 SOTA 模型
模型之间的能力差距问题已经到了一个从量变到质变的地步, 最好的模型比没那么好的模型可能贵了 10x 20x, 但是没那么好的模型无法完成任务. 这不再是类似于 MAGI 那样对比输出然后决断的场景, 而是能不能做到的场景.
因此, 我们不再考虑如何做一个 polyfill 让不那么优秀的模型变得优秀, 而是让最优秀的模型, 发挥它最大的能力.
构建应用时, 默认模型可信
即使是 SOTA 模型, 也有可能, 而且较大概率出现失误, 这个不可否认. 我们不是忽视这个房间里的大象, 而是选择相信其他人, 在六个月后会解决这个问题.
我们构建应用层, 我们只管好玩好用.
模型的信任问题, 交给更 infra 的牛逼人去做.
需要给 Agent 一个名份了
最近 Anthropic 收紧了 OpenClaw 这类的用法, 我的小龙虾死了几个小时. 我有瞬间的无力感.
现在 Agent 能做的事情越来越多, 已经成了生产力环节中不可缺少的一部分. 像氧气, 氧气存在的时候, 我觉得一切都那么自然. 氧气不在的时候, 我发现无法生存.
是时候考虑, 如何让 Agent 真正成为我的助手, Agent 理应保持稳定的行为, 产生相对稳定的输出. 我能够信任 Agent 能真正帮我解决问题.
像一个真实的人一样信任.
事前, 事中默认 yolo, 事后 Audit
对于 High Agency 的实体来说, 施加越多的限制, 就会让最后做成的概率越小. 这和之前提到的默认可信有关.
隔离在我看来就是最大的 friction, 我在做 DevOps / SRE 的时候最讨厌的事情就是在执行某件事情的时候, 我没有权限, 而申请权限需要提工单, 两天过后才能继续.
因此为了加速 (🤡), 应用构建默认应该是 yolo.
熟悉项目管理的同学应该知道, 我们无法完全消除项目中的风险, 而是只要 stake holder 认为风险可控就可以了.
所以我们要做的事情相对来说就比较简单:
- 识别 stake holder
- 讲清楚风险
- 模拟环境下, 多轮迭代模拟风险情况后再真正实施
- 后续出现问题, 依赖于事后的报告复盘, 持续迭代