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

SAP 全新的 Joule Studio 能从一句话生成一整个智能体——工作流、规格说明，甚至连评估套件都有，而且直接扎根于你的实时业务数据。OutSystems 也做了类似的东西。这确实很强：业务分析师现在不用排在工程队列里等，就能在生产系统上立起一个智能体。但这也正是你如何造出一个爆炸半径巨大、却没人能解释、没人能叫停的智能体。门槛降低是真的，危险也是真的，而大多数公司还没为后半句做好准备。

- **Author:** Fedor Chishchin
- **Published:** 2026-06-07
- **Tags:** architecture, business, security
- **Source:** https://fedorthinks.com/zh/blog/low-code-agents-on-live-data

---

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

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

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

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

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

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

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

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

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

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

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

## 结论

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

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