低代码 Agent 平台的能力边界：什么时候必须转原生开发
先说结论：大部分场景用低代码平台就够了，别为了显得专业去做定制开发。
我们自己写了不少扣子、Dify、n8n 的实操教程，也真心建议你先用平台试一遍。一个下午能跑通的东西，没必要排三个月的开发。
但确实有三类情况，无论你在平台上怎么折腾都绕不过去。这篇就是讲这三条分水岭在哪，以及怎么在动手之前就判断出来——而不是等做了两个月才发现方向错了。
分水岭一：数据不能出内网
这是最硬的一条，因为它不是技术难度问题，是物理事实问题。
先把一个混淆点拆开
很多人以为「自部署」等于「数据不出网」。这两件事完全无关。
Dify 可以装在你自己的服务器上，n8n 也可以。但自部署解决的是应用本身在哪运行。如果你在这个应用里配置的是在线大模型，那么每一次提问、以及从知识库里检索出来的那些文档片段，都要打包发送给模型厂商的接口。
你的服务器只是个中转站。数据照样出网。
所以真正做到数据不出内网，只有一条路：模型也必须是本地部署的开源模型。 这意味着你需要 GPU，需要考虑显存够不够跑得动你要的模型参数量，需要按并发人数算硬件。投入结构和用在线 API 完全不是一回事。
怎么判断你属不属于这一类
问自己一个问题：如果这些数据泄露了，后果由谁承担？
如果答案是「甲方的合规部门会追责」「这是涉密单位的内部资料」「客户合同里白纸黑字写了数据不得出境」，那你就在这一类里，低代码托管平台从第一步就出局了。
如果答案是「也就是些产品说明书，本来就公开」，那这条分水岭跟你无关，别自己吓自己。
中间地带要警惕
最危险的是模糊地带：甲方在标书里写了「数据安全」四个字，但没人说得清具体要求。这时候如果你笼统承诺「数据不出内网」然后用了在线模型，验收阶段被懂行的人问一句「你们调的哪家 API」，会非常难看。
我们的做法是在方案阶段就把这两条路摆出来，让客户自己选，代价和效果分别是什么讲明白。这不是推卸责任，是让预期和实际对齐。
分水岭二：流程复杂度超出可视化编排的表达能力
可视化工作流是个好东西，但它有个天然属性：节点图适合表达流程，不适合表达逻辑。
什么时候节点图开始失控
几个典型信号，出现两个以上就该考虑换路了：
- 嵌套条件超过两三层。画在图上是一堆交叉的连线，改一个分支要盯着看半天才敢下手。
- 需要维护中间状态。用户上一轮说了什么、这个流程走到哪一步了、哪些信息还缺——这些东西在节点图里要靠变量传来传去，稍微复杂点就理不清。
- 调用顺序要在运行时决定。不是固定的 A 到 B 到 C，而是根据情况动态决定先做哪个。节点图本质上是静态的连线，表达动态调度很别扭。
- 同一段逻辑要在多个地方复用。代码里抽个函数的事，在节点图里往往变成复制粘贴，改一处要记得改五处。
一个判断方法
试着把这个流程用文字讲给同事听。
如果你能用几句话说清楚「先查知识库，查到了就回答，查不到就转人工」，那节点图完全够用。
如果你讲了五分钟对方还在问「那如果这种情况呢」，说明这里面的逻辑分支密度已经超出了图形化表达的舒适区。这种时候写代码不是炫技，是因为代码本来就是为表达复杂逻辑设计的。
分水岭三：长期的成本结构与可控性
这条最容易被忽略，因为它在项目初期完全不显现。
计费机制决定了成本曲线的形状
托管平台的计费大多和调用量挂钩。这个机制在试点阶段非常友好——用得少就花得少，几乎零门槛。
但它的另一面是：成本随使用量线性增长，而且这个增长你控制不了。 用的人越多、问得越频繁、知识库检索出来的上下文越长，账单涨得越快。
自建的成本结构是反过来的：前期硬件和开发投入是一笔固定支出，之后的边际成本很低。
所以真正的问题不是「哪个便宜」，而是你的使用量会稳定在什么规模、会用多久。试点三个月的项目和要跑三年的系统，最优解完全不同。
具体数字我们不在这里写——各家的计费规则会调整，写死了反而误导人，请以官方最新说明为准。要算的是这笔账的结构，不是某个时点的单价。
还有一个隐性成本：你被绑住了
平台改了接口、调整了功能、涨了价，或者干脆停掉某个能力，你只能跟着走。对于一个交付给甲方、要保三年五年的项目来说，这是实打实的风险。
那么原生开发到底能多做什么
讲完边界，说说越过边界之后能做什么。这几件事是我们实际做过的：
换掉任何一层。 主模型可以换成更先进的，分词模型可以换，嵌入模型也可以换。中文场景下嵌入模型的选择对检索效果影响很大，尤其是专业术语密集的领域——平台给你几个选项，自建是想换就换。
切块策略能真正调。 知识库效果好不好，很大程度上取决于文档怎么切。一份按章节组织的规范和一份问答形式的手册，合适的切法完全不同。能不能自己调切块，是判断一个方案能不能落到实处的关键指标。
按需求改代码接进已有系统。 举个我们做过的例子：有客户希望做 AI 客服，需要把对话功能嵌进他自己的小程序里，再按他提供的产品资料去调模型、调知识库、调工具调用。这种「嵌进去」的活，平台提供的发布渠道覆盖不到。
做安全兜底机制。 这是最能说明问题的一个例子。我们在一个心理倾诉场景里做了危机识别与转人工：关键词识别、强制转人工、人工后台管理、留痕告警。
为什么这件事平台做不了？因为它需要和后台系统联动，需要有人能接手，需要留下记录。而且更关键的是——这套约束必须写进代码，不能靠提示词叮嘱 AI「注意安全」。 提示词层面的约束在平时看着挺好，恰恰在最不能出事的时候不可靠。
这类不显眼的部分，才是决定一个项目敢不敢真正上线的关键。
一个简单的自查清单
动手之前过一遍：
- 数据泄露的后果有人担责吗？→ 有，考虑本地模型部署
- 流程讲给同事听，五分钟能讲清吗？→ 讲不清，考虑写代码
- 这套东西要跑多久、多少人用？→ 长期且规模大，算清成本结构
- 有没有必须机械保证的安全底线？→ 有，必须写进代码
- 要不要接进已有系统？→ 要，看平台的发布渠道够不够
五条都不沾，就用低代码平台，别折腾。 我们的平台实操教程会告诉你怎么用好它们。
沾了其中一两条，可以先用平台做个原型验证需求，再决定要不要重做——原型的价值在于把需求想清楚，不在于它最终能不能上线。
沾了三条以上，直接考虑定制开发，中间那一步试错的时间省下来更划算。
如果你正在判断自己属于哪一类，可以直接跟我们聊聊。用平台能解决的，我们会直接告诉你怎么做——这种情况下我们接不到活，但你少走弯路。