Dify、扣子之后,什么时候该上代码级框架?

Dify、扣子这类平台,几小时就能搭出一个能用的 AI 应用,起步阶段是真香。麻烦出在往深了做——业务一复杂,平台的边界就顶到脸上。所以别纠结「低代码好不好」,它好用得很;真正要纠结的是:你还愿意为它的限制付多少代价。下面几个信号,凑齐两三个,就该认真想代码级了。

先撞上的:能力边界

最早冒出来的信号,是你开始跟平台的抽象打架。想实现的逻辑它没有,你只能用 workflow 硬拼,或者塞一堆 code node 绕过去。等你写的 code node 比配置还多,那已经是在用一种别扭的方式写代码了,还不如直接写。紧挨着的是集成:要接内部系统、私有库、复杂鉴权,或者把 Agent 嵌进现有后端,平台的 connector 常常够不着,给你个浅 webhook 打发。这两条一般一起来。

再往后:工程化和合规

接着你会开始想要版本控制、code review、自动化测试、CI、以及能看清线上到底发生了什么。低代码那套点来点去的东西很难塞进这些流程——改了什么、谁改的、这次改动会不会把上礼拜的用例弄坏,在可视化界面里都不好回答。再往后如果撞上合规,要数据不出内网、要用本地模型,多数 SaaS 平台要么给不了私有化、要么价格劝退,那基本没得选,只能代码级。

还有一条纯算账的:规模

最后一条不谈能力,谈钱。调用量上去之后,平台的按量计费或者性能上限,可能让你自己掌控这一层反而更便宜。到这份上,自研省下来的通常够覆盖投入。

别把这想成非黑即白的一次性抉择。绝大多数团队的路径是:低代码先把需求跑通、验证值不值得做,真要往生产推、往深做,再迁到代码级。迁移是有成本的,所以值得早点判断——你这个场景,最后是不是注定要代码级?想清楚,能省你一次重写。要是判断下来得上,选哪个框架,我另写了一篇:《多智能体框架怎么选》。