直接接入实时数据的 low-code 智能体

今年在 Sapphire 大会上，SAP 展示了 Joule Studio 2.0 从一段自然语言描述生成一个完整的智能体—— 不只是代码，还有产品规格、工作流逻辑、多智能体编排，甚至连评估套件都有。它造出来的智能体 「天生扎根于你整个 SAP 体系中的实时业务数据和端到端流程」。 OutSystems 也推出了一个类似的 low-code 智能体平台。卖点都一样：描述你想要的智能体，它就出现了，而且已经接好了你的真实系统。

这是一次真正的飞跃，我不想做那个挥手把它打发掉的人。让一个业务分析师不用在工程队列里排上几周，就能在生产系统上造出一个能用的智能体，这确实很有价值。但我们值得把眼睛擦亮，看清楚到底是哪一部分变简单了——因为造智能体从来就不是有风险的那一步。把它接到你的实时数据上、还放手让它去操作，那才是。

「实时数据上的 low-code」到底是什么意思

剥掉演示里的魔法，剩下的安排是这样的：一个并非工程师的人用一句话描述自己想要什么，然后一个工具产出一个能以机器速度读取并操作你真实业务系统——订单、财务、客户记录——的智能体。扎根于实时数据，正是它好用的原因。也正是它危险的原因，而这两件事密不可分。

决定一个智能体能造成多大破坏的，不是它有多聪明，而是它能碰到多少东西。最近一项评估发现，工具执行——智能体被允许真正去做的事——是 爆炸半径的头号预测指标，能解释其中 76%。 一个一出生就已经连上实时 ERP 的 low-code 智能体，从一开始就拥有最大的触达范围。这正是它的卖点，也正是它的全部问题所在。

大多数公司连已经在跑的东西都管不住

如果「能不能管住」这件事是靠谱的，那这一切都还好。可它不靠谱。那些已经在跑智能体的组织，数据让人清醒： 63% 没法对智能体被允许做的事强制设限，60% 没法迅速关停一个行为失常的智能体，55% 没法把它和网络的其余部分隔离开。 七成的公司有智能体跑在生产环境里，而其中大多数智能体拥有的访问权限，比做同等工作的人类还要多。

现在，把创建这些智能体的能力交给没有工程训练的人，放在一个默认就把他们接到实时数据上的平台上，你就能看到事情会走向哪里。你得到的不是一个精心限定范围的智能体，而是几十个无人治理的智能体，每一个都触达甚广，由那些从没被要求去想权限问题的人随手立起来，而且没人能完全看清或叫停。这不是假设；这是公民开发者模式撞上了 我之前写过的「默认就暴露在外」的现实，只是规模大得多。

那些无聊的护栏更重要，而不是更不重要

下意识的反应是说「那就别让非工程师造智能体」。这既不现实也不对——生产力的提升是真的，而队列也确实是个真问题。正确的回应是：当创建被普及之后，护栏必须内建在平台里，而不是寄希望于敲下那句话的人有没有善意。有几样东西必须是不可商量的：

• 默认最小权限，而不是最大触达。 一个智能体应该从能完成本职工作的最窄访问权限起步，再有意识地去争取更多——这和「一出生就连上一切」恰恰相反。如果平台默认给的是宽泛访问，那就是个 bug。
• 一个真正管用的急停开关。 如果 60% 的组织都没法停下一个行为失常的智能体，那这就是第一件要修的事。不管智能体是谁造的，你都应该能立刻把它暂停。
• 确定性系统与智能体判断之间一道真正的边界。 这和为智能体重新设计工作流是同一个教训：那些保护实时数据的规则、限额和审批，应该是硬性的、确定的关卡，智能体在它们之内推理，而不是它可以随意跨越的东西。
• 把沙箱当作采购门槛。 同一项研究发现，经过测试的沙箱能把残余风险大约降低 2.6 倍。如果一个 low-code 平台没法向你展示它是怎么隔离其智能体能碰到的东西的，那答案就摆在那儿了。

结论

实时数据上的 low-code 智能体很快就会无处不在，因为好处显而易见，演示又让人无法抗拒。我不是叫你躲开它们——我是想告诉你，简单的那一部分刚刚变得更简单了，而难的那一部分一动没动。从一句话生成一个智能体，这个问题已经解决了。但确保那个智能体不会悄无声息地毁掉你的实时业务数据，并且确保有人能看见它、叫停它，这件事的难度和过去一模一样。

所以，当一个平台提出要让任何人都能造一个接入你真实系统的智能体时，在你欢呼之前，先问那几个不光鲜的问题：它能碰到什么，谁能停下它，它的判断和你的事实源头之间那道墙在哪里？如果平台有好答案，这是一份礼物。如果没有，你普及的就不是智能体——你普及的是爆炸半径。