低代码被骂了这么多年，原因无非就一条：能拖出来的表单，写不出业务逻辑；能跑通的流程，做不了复杂决策。
但最近开源的 OpenClaw 把这个逻辑彻底推翻了。它不是给低代码套了个 AI 壳，而是从底层重构了“流程”的定义方式。
今天这篇文章，不吹概念，直接拆技术。
一、OpenClaw 到底做了什么
先说结论：OpenClaw 在低代码引擎里嵌入了一个可执行的“认知层”。
传统的 BPMN 或流程引擎，本质是状态机的可视化。节点是固定的，路径是预设的，所谓的“智能”无非是多画几条条件分支。
OpenClaw 的差异在于，它的每个节点都能挂载一个 LLM 决策单元。这个单元不是简单调 API，而是：
- 读取当前流程上下文（变量、历史、权限）
- 根据自然语言规则动态判断下一个节点
- 可选地生成输出数据或触发外部动作
用代码理解就是：
// 传统分支
if (amount > 5000) {
return 'leader_approval';
}
// OpenClaw 分支
const decision = await claw.decide({
context: processContext,
rule: "金额超过5000，或者费用类型为招待费且金额>3000，或者申请人最近3次报销存在异常，触发合规审查",
fallback: 'leader_approval'
});
规则是自然语言写的，决策是实时推理的，流程路径不是画出来的，而是“想”出来的。
二、架构拆解：认知层如何嵌入低代码
OpenClaw 的核心设计可以概括为三层：
2.1 流程定义层
这一层和传统低代码没有本质区别，节点、连线、表单、权限。差异在于，每个节点多了一个 cognitive 配置：
{
"nodeId": "expense_review",
"type": "cognitive",
"config": {
"model": "gpt-4o-mini",
"promptTemplate": "根据报销单数据判断审批路径",
"outputMapping": "nextNode"
}
}
2.2 上下文组装层
这是 OpenClaw 最务实的设计。LLM 不能直接拿整个流程对象去推理，token 撑不住，准确率也低。
OpenClaw 在每个决策节点前，会动态组装一个 结构化上下文：
- 当前节点输入数据
- 流程级变量（申请人、部门、金额区间等）
- 最近 N 条相似流程的执行记录
- 预定义的业务规则集（向量化检索）
组装逻辑不是写死的，而是通过一个 小型 DSL 声明：
context.include("expense.amount", "expense.type", "applicant.dept")
context.includeRecent("expense_approval", limit=5)
context.includeRules(tag="compliance")
2.3 决策执行层
决策单元执行后，输出结果需要被“降级”成低代码引擎能理解的动作。OpenClaw 做了一件事：将 LLM 输出映射到流程指令。
映射规则支持三种模式：
- 直接映射：
nextNode: "finance_audit" - 条件映射：根据输出值选择不同路径
- 动作映射：触发子流程、调用 API、更新变量
同时内置了 安全围栏：
- 禁止跨权限节点跳转
- 禁止无限循环
- 决策超时自动走 fallback
三、和“AI + 低代码”的区别
很多人把 OpenClaw 归类为“低代码调用 AI”，但这两个思路有本质区别。
| 维度 | AI + 低代码 | OpenClaw |
|---|---|---|
| 定位 | 在流程节点里调用 AI 能力 | 流程节点本身由 AI 驱动 |
| 决策逻辑 | 预设条件分支 | 动态推理 |
| 规则变更 | 改流程配置 | 改自然语言描述 |
| 可观测性 | 看日志 | 看推理过程 + 决策依据 |
前者是把 AI 当工具用，后者是把 AI 当执行单元用。前者是“用 AI 填个表单”，后者是“让 AI 决定填哪个表单、怎么填、填完给谁”。
四、技术上的挑战
OpenClaw 的设计很性感，但落地没那么简单。三个问题绕不开：
1. 确定性 vs 生成性
流程引擎的核心要求是确定性——同一个输入，永远走同一条路径。但 LLM 天生有随机性。OpenClaw 的解法是 温度参数强制为 0 + 输出格式严格约束 + 结果缓存。但遇到复杂推理场景，仍然有抖动。
2. Token 成本
一个复杂流程跑下来，每个决策节点都调用一次模型，token 消耗不小。实测一个中等规模的报销流程，单次执行成本在 0.08。对于高频流程，这个成本需要算清楚。
3. 审计合规
传统流程引擎的审计日志是“做了什么”。OpenClaw 的审计日志是“为什么要这么做”。后者更难追溯，因为推理过程不可复现。OpenClaw 的做法是记录 输入上下文 + 输出决策 + 决策置信度，而不是依赖模型解释。
五、开发者怎么切入
如果你在选型或自研工作流系统，OpenClaw 的思路值得参考，但不一定非要用它。
三种接入方式：
- 直接集成 OpenClaw：适合从零开始的项目，开源协议宽松，社区活跃度还行
- 在现有流程引擎上加认知层：在决策节点前置一个“规则路由”，把复杂判断交给 LLM，其他保持原样
- 用 OpenClaw 的设计思路自研：核心是上下文组装和决策映射，代码量不大，但需要理解流程引擎的状态机模型
我的建议是：先把认知层用在非核心路径上。比如审批驳回后的自动路由、异常流程的兜底处理、跨部门协作的智能分单。这些场景对确定性要求没那么高，但能显著提升体验。
六、写在最后
低代码被唱衰了两年，核心原因不是技术不行，而是它一直停留在“表单 + 流程”的舒适区。企业要的不是拖拽快，而是业务逻辑能跑通、复杂场景能覆盖。
OpenClaw 的价值不在于它用了什么模型，而在于它重新思考了“流程”的本质：流程不是预设的路径，而是在约束条件下不断做决策的过程。
当决策从“画出来的分支”变成“算出来的路径”，低代码才真正走出了表单工具的宿命。
风口是不是真的来了不好说，但这个方向，值得所有做流程引擎的人认真看。
