9.6.8 低代码平台【选修】
本节定位
不是所有团队都想：
- 手写状态机
- 手写工具注册
- 手写调度逻辑
很多团队真正想要的是：
先把流程搭起来，让大家都能看懂。
低代码平台的核心价值，就在这里。
学习目标
- 理解低代码平台为什么容易在 Agent 场景里流行
- 理解它最适合哪些任务形状
- 理解它和代码式框架相比真正的优势与代价
- 建立什么时候该上低代码、什么时候该落回代码的判断
低代码平台最核心的价值是什么？
它不是为了“取代工程师”
更准确地说，它通常是在做：
- 降低原型搭建门槛
- 让非工程同学也能参与流程讨论
- 让工作流更可视、更容易改
所以它真正的价值不是：
“不用写代码”。
而是：
“让流程表达和协作更轻”。
一个类比
低代码平台很像：
- 把系统流程从源代码变成流程白板
白板当然不能替代所有工程细节，但它非常适合：
- 快速试
- 快速改
- 快速讨论
为什么 Agent 场景特别容易出现低代码？
因为很多 Agent 系统天然就长得像：
- 输入
- 判断
- 调工具
- 检索
- 回答
这种“节点 + 流程”的结构一旦可视化，就会很适合：
- 产品
- 运营
- 分析
- 工程
一起讨论。
也就是说，Agent 系统本身就很容易被工作流化表达。
一个最小工作流示意
workflow = {
"trigger": "user_message",
"steps": [
"classify_intent",
"retrieve_docs",
"generate_answer"
]
}
print(workflow)
预期输出：
{'trigger': 'user_message', 'steps': ['classify_intent', 'retrieve_docs', 'generate_answer']}
这个例子真正体现了什么？
它体现的是低代码思维的核心：
先把系统看成若干节点和连接关系，而不是一堆散代码。
这也是为什么低代码平台往往特别适合做原型。
低代码平台最适合什么类型的任务？
特别适合
- FAQ 工作流
- 审批流
- 检索问答原型
- 简单内容生成链
它们通常有这些特点：
- 流程清晰
- 节点职责明确
- 修改频率高
不一定适合
如果你的系统需要：
- 复杂状态机
- 大量自定义逻辑
- 高度优化的底层控制
那低代码平台可能会越来越不够用。
低代码平台最大的优势到底在哪？
可视化沟通
很多时候，能不能“让别人看懂流程”本身就是巨大价值。
原型速度
在这些阶段尤其有价值：
- 需求验证
- 方案试跑
- 跨角色协作
降低流程修改成本
如果业务逻辑经常改， 低代码工作流比硬编码某些流程时会更灵活。
但低代码为什么又常被高估？
它并不能自动消灭复杂度
流程一旦真的复杂起来，可视化图也可能会越来越乱。
很多“低代码系统”最后还是要回到代码
例如：
- 自定义工具
- 特殊状态逻辑
- 复杂权限控制
所以低代码更多像：
先把系统搭起来的快手方式。
而不是所有系统的最终形态。
一个很重要的问题：谁在用这个平台？
如果主要是工程团队自己用
很多时候直接用代码框架也没问题。
如果你希望这些角色也一起参与
- 产品
- 运营
- 分析
那么低代码的价值会明显上升，因为：
- 它更容易被共同讨论
- 更容易做流程共识
所以低代码平台很多时候不是纯技术决策，也是协作决策。
什么时候应该从低代码迁回代码？
这通常发生在这些时刻：
- 节点图越来越复杂
- 自定义逻辑越来越多
- 调试开始变痛苦
- 版本管理越来越难
这时往往意味着：
你的系统已经从“可视原型”进入“工程系统”阶段了。
也就是说，低代码常常更适合：
- 0 到 1
而未必适合：
- 1 到 100
初学者最常踩的坑
因为低代码看起来快，就拿它做所有系统
这通常会在复杂度起来后撞墙。
只看搭建速度，不看长期维护
这是低代码最容易被高估的地方。
误以为低代码就不需要理解系统
其实正相反。 如果不懂系统原理，只是把问题藏到可视化界面里。
小结
这一节最重要的不是判断“低代码好还是不好”，而是理解：
低代码平台最适合那些流程清晰、需要快速试跑、需要多人共同理解的 Agent 场景。
它是非常有价值的一类工具，但不该被当作所有系统的终点。
练习
- 想一个你自己的 Agent 流程，判断它是否适合用节点式方式表达。
- 用自己的话解释：为什么低代码特别适合需求验证阶段？
- 想一想：为什么说“低代码能降低实现门槛，但不能替代理解门槛”？
- 如果你的系统状态回路很多，你还会优先选低代码平台吗？为什么？