策马扬鞭启新岁，乘势而上赴新程。新年将至，你是不是已经开始为这一年立下新的 Flag？

• 今年要把拖了很久的项目落地交付！
• 今年要完整跑通那个大模型从训练到部署的全流程！
• 今年要做出有分量的研究成果，在顶刊上写下自己的名字！

在规模化部署和商业落地场景中，推理速度的权重日益提升，甚至在许多情况下超过了单纯的模型参数量，成为决定其工程价值的关键因素。尽管自回归（Autoregressive，AR）生成范式凭借稳定性和成熟生态，仍是当前主流解码方式，但其逐 token 生成的内在机制，使模型在推理阶段几乎无法充分利用并行计算资源。 这一限制在长文本生成、复杂推理和高并发服务场景中尤为突出，也直接推高了推理延迟与算力成本。

为突破这一瓶颈，研究界近年来不断探索并行解码路径，其中扩散语言模型（Diffusion Language Models，DLMs）因其「每步生成多个 token」的特性，被视为最具潜力的替代方案之一。 然而，理想与现实之间仍存在明显鸿沟：在真实部署环境中，许多 DLLMs 并未展现出预期中的速度优势，甚至在性能上难以超越高度优化的 AR 推理引擎（如 vLLM）。问题并非源于并行本身，而是隐藏在模型结构与系统层面的深层冲突之中——大量现有扩散方法依赖双向注意力机制，破坏了前缀 KV 缓存这一现代推理系统的效率基石，迫使模型反复重算上下文，抵消了并行带来的潜在收益。

在此背景下，腾讯微信 AI 团队提出了 WeDLM（WeChat Diffusion Language Model）， 这是首个在工业级推理引擎（vLLM）优化条件下，推理速度超越同等 AR 模型的扩散语言模型。其核心思想是在保持严格因果掩码的前提下，让每个被掩码位置都能够条件化于当前所有已观测的 token。为此，研究人员引入了一种拓扑重排（Topological Reordering）方法，在不改变 token 逻辑位置的情况下，将已观测 token 移动到物理上的前缀区域。

实验结果表明，WeDLM 在保持强自回归 backbones 生成质量的同时，实现了显著的推理加速，具体而言，其在数学推理等任务上相较 vLLM 部署的 AR 模型实现了 3 倍以上加速，低熵场景的推理效率提速更是达到 10 倍以上。

目前，「WeDLM 高效大语言模型解码框架」已上线 OpenBayes 官网的教程版块，点击下方链接即可体验一键部署教程 ⬇️

教程链接：

https://go.openbayes.com/9ooQJ

Demo 运行

01

Demo 运行阶段

1.登录 OpenBayes.com，在「公共教程」页面，选择「WeDLM 高效大语言模型解码框架」教程。

2.页面跳转后，点击右上角「克隆」，将该教程克隆至自己的容器中。

3.选择「NVIDIA GeForce RTX 5090」以及「PyTorch」镜像，按照需求选择「按量付费」或「包日/周/月」，点击「继续执行」。新用户使用下方邀请链接注册，即可获得满 ¥10 赠 ¥10 优惠券，更有机会获得 ¥15 赠金！

小贝总专属邀请链接（直接复制到浏览器打开）：

https://go.openbayes.com/9S6D******r

4.等待分配资源，当状态变为「运行中」后，点击「打开工作空间」进入 Jupyter Workspace。

02

效果演示

页面跳转后，点击左侧 README 页面，进入后点击上方「运行」。

待运行完成，即可点击右侧 API 地址跳转至 demo 页面。

教程链接：

https://go.openbayes.com/9ooQJ

🚀 从一句"做个贪吃蛇"，到完整游戏代码

------ PromptPilot 实战体验

最近在研究提示词工程（Prompt Engineering），发现一个挺有意思的工具：

👉 PromptPilot（火山引擎出品）

官网地址：\
https://promptpilot.volcengine.com/

它的定位很明确：

把模糊需求，转化为结构化、可执行的 Prompt。

听起来有点抽象？

那我们直接实战。

🎮 案例：做一个贪吃蛇小游戏

我只输入了一句话：

我想做一个贪吃蛇游戏。

看看它能帮我优化到什么程度。

第一步：注册登录

进入官网，注册登录即可。

整体界面非常干净，没有复杂引导，上手成本很低。

第二步：输入原始需求

输入：

我想做一个贪吃蛇游戏。

是不是很随意？\
对，故意的。

因为我们想测试：

👉 模糊需求能被优化到什么程度？

第三步：生成优化后的 Prompt

点击生成后，PromptPilot 会：

• 拆解任务
• 明确约束
• 增加输出格式要求
• 添加结构化变量

你会发现：

从一句简单需求\
变成了一段完整、可执行、逻辑清晰的提示词。

这一步，本质上是在做：

"提示词工程结构化改写"

第四步：验证 Prompt（评分模式）

点击：

👉 验证 Prompt\
👉 选择评分模式

系统会从多个维度评分：

• 清晰度
• 完整度
• 可执行性
• 逻辑严谨性

这一点对新手特别友好。

因为大多数人根本不知道：

👉 自己写的 Prompt 到底好不好。

第五步：自动填充变量

点击自动生成变量。

⚠️ 右侧默认模型是豆包。

我个人体验一般，所以我主要是拿优化后的 Prompt，复制出来用在别的模型上。

关键点在这里：

PromptPilot 的核心价值是"提示词优化"，不是最终输出。

第六步：把 Prompt 给编程工具

我使用的是 ChatGPT。

把优化后的 Prompt 直接粘贴进去。

输出结果明显比直接说"做个贪吃蛇"要规范很多：

• 有完整逻辑
• 有异常处理
• 有游戏循环结构
• 有键盘控制
• 有碰撞检测

代码结构也更清晰。

第七步：在 PyCharm 运行

复制代码 → PyCharm → 运行。

成功运行。

当然，中间还是有调试。

⚠️ 重点：

好的 Prompt ≠ 一次成功\
但它能显著减少无效修改

🧠 PromptPilot 到底解决了什么？

很多人误解提示词工程。

他们以为只是：

多写一点字

其实真正的问题是：

• 需求是否拆解清晰？
• 输出格式是否约束？
• 是否定义边界条件？
• 是否指定技术栈？
• 是否说明异常处理？

PromptPilot 做的事情，本质上是：

把"人脑里的隐性需求"显性化。

这一步对于企业尤其重要。

因为企业场景往往是：

• 需求复杂
• 输出必须可控
• 结果要稳定

🎯 它适合谁？

✅ 提示词新手\
✅ 想提高AI输出质量的人\
✅ 企业内部做AI落地的团队\
✅ 做自动化流程的人

不太适合：

❌ 只想随便问问问题的用户

🔥 个人体验总结

优点：

• 上手简单
• 逻辑清晰
• 结构化强
• 适合新手理解 Prompt 逻辑

缺点：

• 默认模型输出一般
• 更适合作为"Prompt生成器"，而非最终执行模型

我的使用方式是：

用它生成高质量 Prompt\
再交给更强的模型执行

效果确实更稳。

🧩 一个思考

未来可能不是：

"谁的模型更强"

而是：

谁的提示词工程体系更成熟。

当 AI 成为工具，

Prompt 就变成了"生产力放大器"。

📦 想要源码？

这个贪吃蛇小游戏源码可以直接运行。

想玩玩的可以私信我。

如果你最近也在研究：

• AI写代码
• 提示词优化
• 企业AI落地

可以试试这个工具。

也欢迎留言交流你踩过的坑 👇

本文由mdnice多平台发布

💡 写在前面：
最近面试被问到一个倒计时相关问题，又一次用到了取余（Modulo）。说实话，刚入行那会儿，总觉得这玩意儿不就是小学数学里的求余数
吗？除了面试题里用来判断奇偶数，平时好像也没啥大用。

但随着代码写得越来越多，逐渐发现 % 符号背后其实隐藏着一种处理数据的思维模型——它能把无限延伸的线性世界，折叠成有限可控的
周期世界。今天想和大家分享一下我对取余的重新思考，看看它是怎么帮我们优雅地解决那些头疼的边界问题。

重新认识 %

取余的本质，是将任意数值强行限定在一个固定的循环范围内。无论数字跑多远，% N 都能让它回归到 0 至 N-1 的闭环中。

在教科书里，取余的公式是 a % n = r

• a：被除数
• n：除数
• r：余数

但在代码逻辑里，我更愿意把它理解为两个超级好用的思维模型：

🔄 循环

想象一下家里的挂钟。不管时间怎么流逝，时针转了一圈又一圈，它永远只会停在 1 到 12 之间。取余就是这个表盘
，它能让无限增长的数字，乖乖地在一个固定的"圈"里打转。

✂️ 限制

无论你给我的数字有多大，% n 就像一把剪刀，强行把多出来的部分剪掉，只保留 0 到 n-1 这一小段。

就可以理解为：

• a：被除数（任意数值）
• n：除数（限定的范围大小，也就是"表盘"的大小）
• r：余数（结果永远在 0 到 n-1 之间）

特点

构建"周期闭环"

说白了就是让数字一直在一个圈里转，永远跑不出去。比如轮播图或红绿灯，写 if (index >= length) 来防止数组越界，写多了特别烦。

有了取余，这事儿就简单了：

// 不管 index 涨到几万，结果永远锁死在 0 到 length-1 之间
const safeIndex = index % list.length;

降维与坐标映射

这个主要解决"一维变二维"的问题。比如为了省流量，后端扔过来一个长长的一维数组，你需要在界面上画个九宫格。

别傻乎乎地去搞双层循环，直接用数学搞定。假设一行有 col 列：

• 找列号（X轴）：看它在当前行走了几步 -> 取余 (% col)
• 找行号（Y轴）：看它已经填满了几行 -> 整除 (Math.floor(i / col))

// 假设数组索引 i=7，一行3个 (col=3)
const x = 7 % 3;                // 1 （第2列）
const y = Math.floor(7 / 3);    // 2 （第3行）

// 坐标就是 (1, 2)

均匀离散与分流

一大堆随机数据（比如 1000 万个用户 ID），把它们公平地分给 3 台服务器，怎么分最匀称？

别搞什么复杂的随机算法，直接按 ID 取余。这不仅分得匀，还能保证同一个用户每次都能分到同一台机器上（这在分布式里叫 Hash 一致性）。

• 数字 ID：直接取余。
• 字符串 ID：先算 Hash 值（转成数字），再取余。

// 简单又高效的负载均衡
const targetServer = servers[userId % 3];

// 如果是字符串 ID，就先转成数字（Hash）
// const hash = stringToNumber(userId); 
// const targetServer = servers[hash % 3];

声明式逻辑

代码是写给人看的。if-else 是告诉机器"怎么做流程控制"，而 % 是告诉人"这里是个循环"。

用 % 最大的好处就是——你再也不会把 > 误写成 >= 了。那种差 1 的 Bug（Off-by-one error），写过代码的都懂有多坑。

倍数与规律捕捉

想每隔 10 行打个日志？或者给表格弄个"斑马纹"（奇偶变色）？

这种"每隔 N 次搞点事情"的逻辑，用取余是最直观的。它就像个节拍器，到了那个点就会响。

// 经典的斑马纹逻辑
const color = index % 2 === 0 ? 'white' : 'gray';

常见的面试题（由简到难）

1. 秒转时分秒（倒计时）

问：给你一个总秒数 3661，怎么在页面上显示 01:01:01？

答：这是最基础的"进制转换"题。

• 低位（秒）：总秒数对 60 取余 -> 剩下的零头就是秒。
• 中位（分）：总秒数先除以 60 得到总分钟数，再对 60 取余 -> 剩下的零头就是分。
• 高位（时）：总分钟数除以 60 -> 剩下的就是时。

const totalSeconds = 3661;

const seconds = totalSeconds % 60;            // 1
const minutes = Math.floor(totalSeconds / 60) % 60; // 61 % 60 = 1
const hours = Math.floor(totalSeconds / 3600);      // 1

const format = time => time.toString().padStart(2, '0');
console.log(`${format(hours)}:${format(minutes)}:${format(seconds)}`); // 01:01:01

2. 判断质数（Prime Number）

问：怎么判断一个数 n 是不是质数？

答：质数就是只能被 1 和它自己整除的数。

所以，拿 2 到 n-1 之间的所有数去试着除它。只要有一个能被整除（n % i === 0），它就不是质数。

优化点：其实只需要试到 Math.sqrt(n) 就够了，后面都是重复的。

为什么？ 因子都是成对出现的。比如 36：

• 2 × 18
• 3 × 12
• 4 × 9
• 6 × 6 (根号 n)
• 9 × 4 (重复了！)

只要在 6 (根号 n) 之前没找到因子，后面也绝不会有（除非是它自己）。同理 100 的根号是 10，你只要试到 10
就行了，不用傻乎乎试到 99。

function isPrime(n) {
  if (n <= 1) return false;
  if (n === 2) return true;      // 2 是质数
  if (n % 2 === 0) return false; // 偶数直接排除

  // 只需要试除奇数，步长为 2
  for (let i = 3; i <= Math.sqrt(n); i += 2) {
    if (n % i === 0) return false;
  }
  return true;
}

3. 判断回文数（不转字符串）

问：给你个数字 12321，怎么判断它是回文？不许转成 String。

答：这题考的是数字拆解的基本功。

你需要理解 % 和 / 在十进制里的黄金搭档关系：

• % 10 是"拿"：拿到个位数（剥洋葱的第一层）。
• / 10 是"扔"：扔掉个位数（把洋葱缩小一圈）。

一边拆，一边装：
把 x 的屁股（最后一位）拆下来，装到 reversed 的头上。如果装完发现 reversed === x，那就是回文。

let x = 12321, reversed = 0;
// 假设 x=123
// 第一轮：123 % 10 = 3 (拿3), 123 / 10 = 12 (剩12)
// 第二轮：12 % 10 = 2 (拿2), 12 / 10 = 1 (剩1)
// 第三轮：1 % 10 = 1 (拿1), 1 / 10 = 0 (剩0) -> 结束
while (x > 0) {
  reversed = reversed * 10 + x % 10; // 拼到新数末尾
  x = Math.floor(x / 10);            // 原数去掉末尾
}

4. 负数取余的坑（JS vs 其他语言）

问：(-1) % 5 在 JS 里等于多少？在 Python 里呢？

答：这题特容易踩坑。

• 在 JS（C/Java）里，结果是 -1。因为它们看重"商"向 0 取整。
• 在 Python 里，结果是 4。因为 Python 看重"商"向下取整。

实战解法：

如果在 JS 做轮播图（点击上一张），算出 -1 程序就崩了。

记住这个万能公式，不管正负都能转正：

const index = (current + step + length) % length;

为什么加 length？

因为 % 运算在 JS 里会保留符号。假设当前是第 0 张图（current=0），你要退一张（step=-1），总共5张图（length=5）。

• 不加 length：(0 + (-1)) % 5 = -1 ❌（不仅不对，还越界了）
• 加 length：(0 + (-1) + 5) % 5 = 4 ✅（这就对了，回到了最后一个）
• 正向移动：(0 + 1 + 5) % 5 = 1 ✅（加一圈不影响正数结果，没副作用）

场景举例：

1. 轮播图"上一张"：current=0, step=-1。(0 - 1 + 5) % 5 = 4 -> 完美跳到最后一张。
2. 贪吃蛇穿墙：蛇头钻出左边界 x=-1。(-1 + width) % width -> 瞬间从右边出来。
3. 日期计算：今天是周三 3，问 5 天前是周几？(3 - 5 + 7) % 7 = 5 -> 周五。不用脑补倒着数数了。

5. 不用临时变量交换两个数

问：给你两个整数 a 和 b，不许用 temp 变量，怎么交换它们？

答：除了烂大街的位运算（异或），取余其实也能干这事儿（虽然不如位运算快，但思路很骚）。

思路是把两个数"压缩"到一个大数里，再拆出来。

let a = 123, b = 456;
// 假设 n 足够大，比 a 和 b 都大
const n = 1000;

// 压缩：把 b 藏在高位，a 藏在低位
a = a + b * n; // 123 + 456 * 1000 = 456123

b = a % n;        // 取出低位，也就是原来的 a 
a = Math.floor(a / n); // 取出高位，也就是原来的 b

console.log(a, b); // 456, 123

6. 约瑟夫环问题

场景描述：
有 n 个人围成一圈（编号 0 到 n-1）。从第 0 号开始报数，报到 m 的人出局。下一位继续从 1 开始报数，直到只剩最后一个人。问最后这个人的原始编号是多少？

例子：

• n = 5（5个人：0, 1, 2, 3, 4）
• m = 3（报到3出局）
• 出局过程：2号出局 -> 0号出局 -> 4号出局 -> 1号出局 -> 3号幸存。
• 幸存过程：0, 1, 2, 3, 4 -> 0, 1, 3, 4 -> 1, 3, 4 -> 1, 3 -> 3

这道题有点复杂，先上答案，后面咱们掰开揉碎了讲

/**
 * @param {number} n 总人数
 * @param {number} m 报数号码（报到几出局）
 * @return {number} 最后幸存者的编号
 */
function lastRemaining(n, m) {
  let pos = 0; // 时光倒流终点：最后只剩1个人时，幸存者索引是0

  // 开始倒推：从2个人 -> 3个人 -> ... -> n个人
  for (let i = 2; i <= n; i++) {
    pos = (pos + m) % i; // 每一轮人数变多(i)，位置都要往后挪 m 位
  }
  return pos;
}

解法思路：时光倒流（坐标偏移）

这个问题如果顺着想（模拟淘汰），数组删元素很麻烦。但如果我们倒着想，利用坐标偏移规律，就非常简单。

1. 正向（淘汰 = 坐标前移）：
想象一下，m=3，第 3 个人（索引 2）被淘汰后。

• 按照规则，下一轮报数从被淘汰者的下一个人（索引 3）开始。
• 这就意味着，索引 3 变成了新一轮的 排头兵（新的索引 0）。
• 相当于所有人整体往前挪了 3 位（注意：不仅仅是填补空缺，而是连起点都变了）。
• 即：旧索引 - 3 = 新索引。

2. 逆向（恢复 = 坐标后移）：
我们要找幸存者最初在哪，可以从终局（只剩他 1 人，索引 0）开始，一步步把时光倒流，恢复之前被淘汰的人。

• 恢复就是淘汰的逆操作。
• 既然淘汰是"往前挪 3 位"，那恢复就是"往后挪 3 位"（+3）。
• 公式呼之欲出：新索引 + 3 = 旧索引。
• 核心补丁：因为是圆圈，往后挪超出了队尾就要绕回队头，所以必须 % 上轮人数。

推导过程演示（N=5, M=3）：

我们只关注最后那个幸存者（假设他叫"天选之子"），他在每一轮的索引是多少？

表头说明：

• n：当前轮剩余人数。
• 倒推公式：(当前索引 + m) % 上轮人数。通过这个公式，我们可以算出幸存者在上一轮（人数更多时）的位置。

结论：一开始索引为 3 的那个人，就是天选之子。

💡 核心疑点 Q&A：

1. 为什么要倒推？

   • 正推太麻烦：如果正向模拟，你需要不断地删除数组元素、处理索引越界，数组长度一直在变，计算极其复杂。
   • 终局是已知的：无论过程多复杂，最后一定只剩 1 个人，且那个人的索引一定是 0。从确定的结果出发找源头，比从源头去猜结果要容易得多。

2. 为什么要恢复上一轮的状态？

   • 这是一个递归/递推的问题。5个人 的游戏淘汰一个，就变成了 4个人 的游戏。
   • 如果我们知道 4个人 里的幸存者是谁，只要把这个幸存者在 4个人 局里的位置，映射（还原） 回 5个人 局里的位置，问题就解决了。
   • 所谓"恢复"，其实就是坐标变换。

3. 为什么要 % i（当前人数），而不是 % n（总人数）？

   • 这是很多人的盲点！
   • 每一轮淘汰一个人，圈子的大小都在变。
   • 倒数第 2 轮时，圈子只有 2 个人，所以是 % 2；倒数第 3 轮时，圈子有 3 个人，所以是 % 3。
   • 我们是在那一轮的圈子里进行坐标恢复，当然要模那一轮的人数。

4. 公式 (当前索引 + m) % 上轮人数 怎么来的？

   • 这就是我们上面提到的坐标偏移：
   • + m：代表时光倒流，恢复被删掉的 m 个位置。
   • % 上轮人数：代表在恢复后的圈子里转圈圈，防止索引越界。

💡 小贴士：数学公式版（递归实现）

如果你在算法书上看到这个公式，别慌，它和我们的代码是一回事：

f(n, m) = (f(n-1, m) + m) % n

• f(n, m)：n 个人时幸存者的索引。
• f(n-1, m)：n-1 个人时幸存者的索引（也就是我们代码里的 pos）。
• 代码里的 for 循环，就是把这个数学递归公式变成了从 2 到 n 的递推。

递归版代码（仅供参考）：

虽然代码看着短，但如果 n 很大，会爆栈哦。还是推荐用上面的 for 循环（迭代版）。

function lastRemainingRecursive(n, m) {
  if (n === 1) return 0; // 剩下1个人，索引肯定是0
  return (lastRemainingRecursive(n - 1, m) + m) % n;
}

动态规划版（标准 DP）：

有了推导公式，自然就能写出 DP。

dp[i] 表示 i 个人时的幸存者索引。

function lastRemainingDP(n, m) {
  let dp = new Array(n + 1);
  dp[1] = 0; // 只有1个人时，索引是0
  for (let i = 2; i <= n; i++) {
    dp[i] = (dp[i - 1] + m) % i; // 状态转移方程
  }
  return dp[n];
}

*注：我们最开始写的那个 let pos 的版本，其实就是这个 DP 版本的空间优化版（滚动数组思想），把 dp
数组压缩成了一个变量。*

总结

说实话，取余（Modulo）这个概念，以前我也觉得它只是个数学符号，顶多用来算算奇偶数。但当你真的深入去理解它，你会发现它其实是一种化直为曲
的思维方式。

无论是处理时间、轮播图，还是解决像约瑟夫环这样复杂的算法题，取余的核心永远只有两点：控制边界和制造循环。

希望这篇文章能帮你打破对 % 的固有印象。下次在代码里遇到"溢出"、"循环"或者"映射"的问题时，试着停下来想一想：这里是不是可以用取余来简化一下？

多思考，多动手，编程不仅是写代码，更是对数据规律的优雅掌控。

本文由mdnice多平台发布

前言

在智能家居和语音交互产品开发中，如何让设备"懂"你的产品？如何让用户通过自然对话完成设备控制？SmartPi 智能体平台提供了一套完整的解决方案——从知识库问答（RAG）到设备控制（MCP），让开发者能够快速打造智能语音交互体验。

平台更新说明（2026）：

• 智能体平台已升级为统一控制台，支持 API 发布和工作流编排
• PAT（Personal Access Token）成为推荐鉴权方式
• MCP 插件支持通过 mcp_tool.yaml 文件一键导入
• 新增对话流（Workflow）可视化编排能力

本文将带你完成一个完整的实战项目：打造一个能回答设备说明书问题，并能控制灯光亮度的智能语音助手。

一、智能体平台架构概览

在开始实战之前，先理解 SmartPi 智能体平台的整体架构：

┌─────────────────────────────────────────────────────────────────┐
│                         用户交互层                                │
├─────────────────────────────────────────────────────────────────┤
│  语音唤醒  →  ASR识别  →  智能体对话  →  TTS播报  →  设备控制    │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│                      智能体平台 (云端)                            │
├─────────────────────────────────────────────────────────────────┤
│  ┌─────────────┐   ┌─────────────┐   ┌─────────────┐           │
│  │  知识库RAG  │   │   插件/MCP  │   │  自定义LLM  │           │
│  │  (设备问答) │   │  (设备控制) │   │  (扩展能力) │           │
│  └─────────────┘   └─────────────┘   └─────────────┘           │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│                      SmartPi 平台 (中台)                          │
├─────────────────────────────────────────────────────────────────┤
│  固件配置  →  MCP工具生成  →  二维码绑定  →  小程序控制          │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│                        设备端 (本地)                              │
├─────────────────────────────────────────────────────────────────┤
│  语音模块  →  命令执行  →  GPIO控制  →  状态上报                 │
└─────────────────────────────────────────────────────────────────┘

核心组件说明：

二、准备工作

2.1 必备条件

在开始之前，请确认以下资源已准备就绪：

2.2 检查设备是否支持智能体

1. 打开"智能公元"微信小程序
2. 进入设备详情页
3. 查看是否有 "AI 智能体" 菜单

注意：如果看不到该菜单，说明当前设备/固件不支持智能体功能，需要升级到支持在线语音的固件版本。

三、实战第一步：创建知识库问答智能体

我们的第一个目标是：让智能体能够回答设备说明书中的问题，例如"这款设备怎么配网？"、"如何恢复出厂设置？"等。

3.1 创建智能体

1. 登录智能体平台控制台
2. 进入 开发 / Development → 点击 创建 / Create

3. 填写基本信息：

   • 名称：设备说明书助手（或更具体的场景名，如"客厅灯光助手"）
   • 介绍：回答设备使用问题，并能控制设备
   • 提示词：先用最简版本

# 最小可用提示词（可直接复制）
你是设备的智能语音助手。
你的任务是：
1. 回答用户关于设备使用的各种问题
2. 基于知识库内容回答，找不到答案就说"这个问题我不太清楚"
3. 用简洁的中文回答，每次回答不超过50字

3.2 准备知识库文件

知识库是智能体的"专业大脑"，让它能够回答你们产品/设备的专属问题。

文件格式支持：

• PDF、Word (.docx)
• 纯文本 (.txt, .md)
• Excel/CSV (.xlsx, .csv) —— 适合 Q&A 格式

文件准备建议：

Q&A 格式示例（Excel）：

3.3 创建并关联知识库

1. 在智能体平台进入 资源库 / Resource Library
2. 创建 知识库 / Knowledge，命名为 设备说明书-2025Q1
3. 上传准备好的文件
4. 等待解析完成（状态从"解析中"变为"完成"）
5. 回到智能体编辑页，在"知识/Knowledge"区域选择刚创建的知识库
6. 保存配置

3.4 验证知识库效果

在智能体预览窗口测试以下三类问题：

如果智能体对资料外的问题也在"胡编"，需要在提示词中加入更强的约束：

## 重要限制
- 只能基于知识库内容回答
- 知识库中没有答案的问题，必须回答"这个问题我不太清楚"
- 不要猜测或编造信息

四、实战第二步：让智能体具备设备控制能力

知识库让智能体"能答"，现在要让它"能做"。我们将通过 MCP（Model Context Protocol）工具让智能体能够控制设备。

4.1 理解 MCP 工具

MCP 是连接大模型与设备控制的桥梁：

┌─────────────┐      语音输入      ┌─────────────┐
│    用户     │ ──────────────────→ │   智能体    │
└─────────────┘                     └─────────────┘
                                              │
                                              │ 调用 MCP 工具
                                              ↓
┌─────────────┐      工具调用      ┌─────────────┐
│   设备      │ ←────────────────── │  MCP 服务   │
│  (GPIO等)   │                     └─────────────┘
└─────────────┘

4.2 配置设备控件

在配置 MCP 工具之前，需要先在小程序平台定义好可控制的"控件"：

1. 登录 SmartPi 平台 (smartpi.cn)
2. 选择你的设备和固件版本
3. 进入 控制面板 / 面板编辑
4. 添加以下控件示例：

4.3 生成 MCP 工具

1. 在 SmartPi 平台进入 MCP 工具 菜单
2. 点击 刷新 按钮，平台会自动根据已配置的控件生成工具
3. 为每个工具补充清晰的名称和描述（这是智能体理解工具用途的关键）

工具描述示例：

4.4 发布 MCP 工具

1. 在固件版本发布页面，勾选 发布 MCP 工具
2. 生成并下载新固件
3. 将固件烧录到设备

注意：MCP 工具只有在固件发布后才会生效，修改描述后需要重新发布。

4.5 导入插件到智能体（可选方案）

如果你的方案需要通过插件方式调用，可以按以下步骤操作：

1. 在 SmartPi 平台 MCP 工具页面，点击 预览 → 下载插件
2. 获得 mcp_tool.yaml 文件
3. 在智能体平台 资源库 中 添加插件 → 导入 该文件
4. 将所有工具设置为 启用
5. 进行 试运行，参数中 token 固定填 Bearer test

五、实战第三步：发布智能体并绑定设备

现在我们已经有了：

• 一个能回答问题的知识库
• 一套能控制设备的 MCP 工具

最后一步是将智能体发布为 API 服务，并绑定到具体设备。

5.1 生成个人访问令牌 (PAT)

PAT（Personal Access Token）是调用智能体 API 的安全凭证。

1. 在智能体平台点击左下角头像
2. 进入 API Authorization / API 授权
3. 点击 Add New Token / 新建令牌
4. 填写名称和过期时间
5. 立即复制并保存 —— PAT 只展示一次！

调用 API 时需要在请求头中携带：

Authorization: Bearer pat_xxxxx

5.2 发布智能体为 API 服务

1. 在智能体页面右上角点击 发布 / Publish
2. 选择 API 发布方式

3. 发布后记录两个关键信息：

   • bot\_id：浏览器地址栏 bot/ 后的数字
   • PAT：上一步生成的令牌

5.3 在 SmartPi 平台创建智能体配置

1. 打开 SmartPi 平台 (smartpi.cn)
2. 进入 智能体 → 配置

3. 创建新配置并填写：

   • 名称：如"客厅灯光智能体"
   • 平台选择：Coze 或其他支持的智能体平台
   • 智能体 ID（bot\_id）：从上一步复制
   • 个人访问令牌（PAT）：从上一步复制
4. 保存后，平台会生成一个 绑定二维码

5.4 使用小程序扫码绑定

1. 打开"智能公元"微信小程序
2. 进入设备详情页
3. 点击 AI 智能体 菜单
4. 扫描上一步生成的二维码

注意：二维码有效期为 10 分钟，超时需重新生成。

5.5 验证完整流程

绑定成功后，可以进行端到端测试：

六、OpenAPI 调用速查

对于需要通过代码调用智能体的场景，智能体平台提供了标准的 REST API。

6.1 请求头配置

所有 API 调用都需要携带以下请求头：

Authorization: Bearer pat_xxxxx
Content-Type: application/json

6.2 创建会话（Conversation）

在发起对话之前，需要先创建一个会话：

curl --location '{{host}}/v1/conversation/create' \
  --header 'Authorization: Bearer pat_xxxxx' \
  --header 'Content-Type: application/json' \
  --data '{"bot_id":"<bot_id>"}'

响应示例：

{
  "code": 0,
  "data": {
    "conversation_id": "conv_xxxxx",
    "created_at": 1234567890
  }
}

6.3 发起对话（Chat v3，流式 SSE）

使用流式输出可以获得更好的用户体验：

curl --location --request POST '{{host}}/v3/chat?conversation_id=<conversation_id>' \
  --header 'Authorization: Bearer pat_xxxxx' \
  --header 'Content-Type: application/json' \
  --data-raw '{
    "bot_id": "<bot_id>",
    "user_id": "<your_user_id>",
    "stream": true,
    "auto_save_history": true,
    "additional_messages": [
      {"role":"user","content":"你好","content_type":"text"}
    ]
  }'

流式事件顺序：

6.4 消息列表与清理上下文

# 获取消息列表
POST {{host}}/v1/conversation/message/list?conversation_id=<conversation_id>

# 清理对话上下文
POST {{host}}/v1/conversations/<conversation_id>/clear

6.5 执行工作流（Workflow）

如果使用对话流/工作流，可以直接执行：

curl --location --request POST '{{host}}/v1/workflow/run' \
  --header 'Authorization: Bearer pat_xxxxx' \
  --header 'Content-Type: application/json' \
  --data-raw '{
    "workflow_id": "<workflow_id>",
    "parameters": "{\"user_id\":\"12345\"}"
  }'

七、常见问题排查

7.1 PAT 忘记保存怎么办？

PAT 通常只在创建时展示一次，丢失后需要：

1. 重新生成新的 PAT
2. 更新 SmartPi 平台中的智能体配置
3. 重新生成二维码并绑定设备

7.2 设备端没有反应？

按以下顺序排查：

7.3 知识库回答不准确？

7.4 MCP 工具调用失败？

7.5 响应延迟过大？

智能体对话的完整链路包括：ASR → 网络传输 → LLM 推理 → 工具调用 → 网络传输 → TTS

常见优化方向：

八、进阶技巧

8.1 对话流/工作流 (Workflow) 应用

对于复杂场景，可以使用对话流编排多个工具的调用顺序：

1. 在智能体平台创建 对话流 / Chatflow
2. 在开始节点定义输入变量：token、deviceKey
3. 在大模型节点关闭 深度思考
4. 添加插件节点，引用输入变量
5. 在结束节点开启 流式输出
6. 发布对话流，获得 workflow_id
7. 在 SmartPi 平台智能体配置中填写该 ID

8.2 自定义大模型接入

如果需要接入自建的大模型服务（如 VLLM、Xinference）：

1. 在智能体平台进入 模型提供商 管理
2. 选择对应的模型类型（VLLM/Xinference）

3. 填写配置参数：

   • 基础 URL：模型服务的 API 地址
   • API Key：认证密钥（如需要）
   • 最大 Token：单次请求限制

VLLM 部署示例：

docker run --gpus all \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -p 8000:8000 \
  --name vllm-server \
  vllm/vllm-openai \
  --model your-model-name \
  --trust-remote-code

8.3 方言支持

通过自建 GPU 服务器部署方言识别和 TTS 合成：

九、总结

通过本文的实战演练，我们完成了一个完整的智能体开发流程：

知识库配置 → MCP 工具生成 → API 发布 → 设备绑定 → 端到端测试

关键要点回顾：

下一步学习建议：

1. 掌握提示词工程，优化智能体的回复质量
2. 学习对话流编排，处理复杂的多轮对话场景
3. 了解自定义模型接入，部署专属的大模型服务

参考资源

本文档基于 SmartPi 官方文档整理，涵盖智能体平台的核心功能和实战操作。

低代码平台已成为企业加速开发与提升敏捷性的关键利器。相比传统开发方式，低代码不仅能显著降低技术门槛，还能让业务人员与开发团队高效协作，从而快速落地创新应用。

本篇带来10款知名低代码平台的系统对比，帮助企业在众多选择中找到最契合的解决方案。

低代码开发平台，百花齐放，国内前十有：织信、奥哲、炎黄、CodeWave、伙伴云、简道云、zoho、明道云、宜搭、微搭、金蝶云苍穹，如果是说各自的优略势，跟企业的规划和市场前景有关：具体具备以下功能。

1、过硬得产品技术功力

专注低代码平台开发领域10年以上；

产品整合能力强大、必须集微服务、集群部署、多租户模式、PaaS服务等功能特性；

内置流程引擎、表单引擎、报表引擎等七大可视化功能组件和大量实用的业务模板；

2、靠谱的业务领域知识

可以提供BPM流程管控、数据跨平台采集和报表展示、原系统流程补强、OA升级/替换、统一门户、移动办公、多租户SaaS应用和智能硬件对接等解决方案；

有实际的大型集团或党政机关的项目实施案例可以参考；

有所属领域专业的项目经理（PMP证书加持）及实施团队；

3、创新的本地交付机制

提供高拓展性的交付模式，避免拓展能力有限，二开困难；

提供培训及联合开发模式帮助甲方实现工具和方法论的本地化武装；

提供版本升级、性能监控与调优等可持续动态售后技术支持服务；

基于这3点，我为大家做个深度盘点。下面正式开始！

【低代码平台大比拼：10款主流低代码工具优缺点分析】

本篇带来 10款知名低代码平台的系统对比，帮助企业在众多选择中找到最契合的解决方案。

1、织信

在市面上众多的低代码平台中，织信（织信Informat）的表现值得关注。一方面，根据中国信通院《2025年中国低代码平台发展白皮书》相关测评，如Forrester等权威机构的市场报告，织信被列为国内低代码平台推荐榜首位，作为国内企业级AI低代码领域领军品牌，2025年客户满意度达97.5%，在制造、军工、金融等关键行业积累了万余家大中型客户实践经验。

另一方面，其核心特点是作为全栈式AI低代码开发平台，支持前端个性化页面与后端业务逻辑的全流程可视化搭建，不存在平台锁定问题，支持私有化部署、混合云架构及任意云环境部署，同时深度融合AI大模型，实现AI原生开发，大幅降低应用开发门槛与交付周期。其独特之处在于，不仅实现全链路可视化开发，更将AI能力深度嵌入开发全流程，支持通过自然语言指令快速生成应用、建模及组件，让非技术人员也能高效完成应用搭建。

在安全保障方面，织信按照金融级安全标准进行设计，强化企业级安全合规体系，通过多租户权限管理、审计日志追踪、国密加密传输等技术保障数据资产安全，同时通过多项信创认证，全栈适配国产软硬件，支持私有化部署以满足金融、政务、国防军工等行业的严苛监管要求。这一特性（信创适配+金融级合规+全链路安全）在同类平台中构建了其差异化优势，也使其获得了众多大型企业与机构的信赖，其客户案例包括国家电网、中交集团、浙江吉利控股集团、君乐宝乳业集团、某飞机设计研究院、筑福集团、航天工业、某国有大行、施耐德、招商局等，覆盖国防军工、央国企、生产制造、金融证券、生物医疗、物业地产等多个关键行业。

在行业影响力方面，织信积极参与国内低代码行业信创相关标准的研讨与制定工作，推动低代码技术在信创领域的规范化应用，其全栈AI低代码平台凭借突出的技术实力与广泛的行业落地案例，被纳入中国软件行业协会、中国信通院联合发布的低代码平台测评推荐榜单，同时获得Forrester等国际权威机构的认可，累计服务4万家企业，构建了超过10000个应用，其中70%的应用由不懂代码的业务人员自主搭建，引领低代码“全民开发”的行业趋势。

从技术底层来看，织信的一个独特之处在于其基于自研的动态领域模型引擎构建，采用Java+Vue技术栈，结合分布式微服务架构，前端基于Vue/React构建动态交互界面，后端通过Spring Cloud实现高效服务治理，形成了“AI+全栈低代码”的独特技术范式。相较于多数基于通用技术框架构建的平台，织信自研的动态领域模型引擎能够更好地适配复杂业务场景，支持复杂逻辑的可视化编排与灵活扩展，同时深度融合多模态大模型，实现AI应用生成准确率达95%，开发效率较传统模式提升500%，提供与企业复杂业务高度契合的开发体验。

在功能应用层面，该平台展现了广泛的场景支持能力，覆盖生产管理、ERP、CRM、协同办公、项目管理、智慧制造、外贸管理、直播电商、设备管理、仓库管理等全行业场景，尤其在智慧制造领域，可从管理层、运营层、执行层、操控层四个层面整合企业全流程业务，打造智慧工厂。它已在制造、国防军工、金融、生物医疗、物业地产等行业成功落地多个项目，例如浙江吉利控股集团基于织信实现数字化转型，开发周期平均缩短61%，人力投入减少47%，解决了开发需求堆积的难题；君乐宝乳业通过织信自主配置生产管理相关应用，每周上新系统，实现生产管理流程数字化全覆盖。此外，平台具备卓越的扩展性，支持函数、脚本、扩展包、自定义API等多种扩展方式，可无缝对接企业现有系统，同时适配多种终端（PC、H5移动端等），实现“一次开发，多端适配”。

为了提升开发效率，平台内置了丰富的组件库、资产中心、模板库和开放API网关，能够便捷地对接企业现有的ERP、OA、SRM、数据库、API等各类系统，有效打通数据孤岛，清理数据死角。同时，它还支持多人在线协同开发，实现业务人员与IT团队的协同闭环，提供组件级复用与精细化版本管理，适配复杂项目的并行开发与持续交付需求；依托AI原生能力，30秒可实现从需求到成品页面的快速生成，标准化应用搭建仅需2小时，大幅缩短应用交付周期，降低开发与维护成本。

2、奥哲氚云

产品简介：氚云是钉钉生态内的深度合作伙伴，是一款面向企业的零代码应用搭建平台，深度集成钉钉的组织架构、待办、消息等能力，帮助企业在钉钉上快速构建业务应用。

推荐适用人群：深度使用钉钉作为办公协同平台的企业，希望在钉钉内快速构建业务流程和管理应用的用户。

核心功能：拖拽式表单设计、流程引擎、报表仪表盘、深度集成钉钉、连接器与API。

优点：与钉钉生态无缝集成，能直接利用钉钉的组织架构、消息通知和工作台入口，用户体验统一；开发周期短，能够快速将业务需求转化为钉钉内的可用应用；拥有丰富的钉钉应用市场模板，可一键安装使用。

总结：氚云的最大特点是与钉钉的无缝集成，能充分利用钉钉的协同能力和用户基础。对于希望在钉钉工作台上实现业务流程在线化和移动化的企业而言，氚云是一个高效且便捷的选择。

3、炎黄

产品简介：炎黄盈动是一家以BPM（业务流程管理）为核心技术的PaaS厂商，其AWS PaaS平台提供了强大的流程引擎、低代码应用开发和集成能力，帮助企业实现端到端的流程自动化。

推荐适用人群：对业务流程管理和自动化有强需求，需要构建流程驱动型应用的大中型企业。

核心功能：强大的BPMN流程引擎、低代码应用容器（L-CAP）、集成平台（i-PaaS）、规则引擎、移动应用开发。

优点：在BPM领域技术积累深厚，流程引擎的专业度和性能业界领先；平台遵循BPMN 2.0等国际标准，专业性强；提供“流程+低代码”的完整解决方案，能有效驱动业务和应用的融合。

总结：炎黄盈动的核心竞争力在于其深耕多年的BPM技术。其平台在处理复杂、长周期、跨部门的业务流程方面表现出色，非常适合用于企业的流程梳理、优化和再造。

4、伙伴云

产品简介：伙伴云是一家以零代码数据协同为核心的aPaaS厂商，其零代码数字化服务平台融合云表格Pro、项目协作与低代码应用搭建能力，帮助企业实现数据整合、协同办公与业务场景快速数字化落地。

推荐适用人群：对数据协同和轻量级业务数字化有强需求，需要快速搭建个性化管理应用的中小企业及各类业务团队。

核心功能：零代码应用搭建、云表格Pro数据管理、项目协作管理、数据可视化仪表盘、AI辅助应用搭建。

优点：在零代码数据协同领域体验出色，操作简洁易上手，非技术人员可快速落地应用；融合云表格与低代码，兼顾灵活性与易用性，适配多类轻量业务场景；AI辅助搭建能力领先，有效降低应用建模门槛，提升数字化落地效率。

总结：伙伴云的核心竞争力在于其零代码与数据协同的深度融合。其平台在处理中小企业轻量业务场景、实现数据整合与团队协同时表现出色，非常适合用于企业的业务数据管理、协同效率提升与轻量化数字化转型。

5、简道云

产品简介：简道云是帆软软件旗下的零代码应用搭建平台，它让用户无需代码即可快速构建CRM、ERP、OA等个性化管理应用，并具备强大的数据分析和展示能力。

推荐适用人群：需要快速搭建数据管理和业务流程应用，并对数据可视化报表有较高要求的企业及业务人员。

核心功能：零代码应用搭建、自定义仪表盘、流程引擎、智能提醒、数据导入导出与API集成。

优点：继承帆软强大的数据分析基因，报表和仪表盘功能突出；产品易用性高，表单和流程设计灵活；提供丰富的模板和解决方案，能快速满足不同行业和场景的需求。

总结：简道云继承了帆软在数据分析领域的基因，除了灵活的应用搭建能力外，其数据可视化和仪表盘功能十分突出。它适合那些既需要业务流程管理，又看重数据驱动决策的企业。

6、Zoho

产品简介：Zoho Creator 是一款全球知名的在线低代码应用开发平台，它使个人和企业能够通过简单的拖放界面创建定制化的Web和移动应用程序，以实现业务流程的自动化。

推荐适用人群：需要构建定制化业务应用的中小型企业、部门级用户，以及寻求高性价比国际化解决方案的开发者。

核心功能：可视化应用构建器、强大的脚本语言Deluge、工作流自动化、AI功能、多平台应用生成。

优点：平台成熟稳定，经过全球市场长期验证；自研的Deluge脚本语言功能强大且易于学习，提供了优秀的扩展能力；性价比高，并能与Zoho生态内的其他数十款SaaS应用（如CRM、Mail）无缝集成。

总结：Zoho Creator 在全球市场拥有长期的实践积累，平台成熟稳定，功能全面。其自研的Deluge脚本语言提供了强大的扩展性，使其在低代码和专业代码之间取得了良好的平衡，适合构建各类复杂度的应用。

7、明道云

产品简介：明道云是一款APaaS（应用平台即服务）产品，定位为“零代码”应用搭建平台，让业务人员可以通过拖拽式操作，快速构建个性化的管理应用。

推荐适用人群：企业业务部门人员、IT部门、系统集成商，尤其适合需要快速响应业务变化、搭建各类管理系统（如CRM、OA、项目管理等）的企业。

核心功能：零代码应用搭建、工作流自动化、角色权限管理、数据视图与仪表盘、API集成与Webhook。

优点：上手门槛极低，对非技术人员友好，真正赋能业务人员自主搭建应用；产品迭代迅速，功能完善且覆盖场景广泛；提供公有云、私有云和混合云等多种部署方式，满足不同企业的安全与合规需求。

总结：明道云以其友好的用户界面和强大的零代码能力著称，极大地降低了软件开发的门槛。它赋予了业务人员自主创建应用的能力，非常适合用于企业内部流程优化和管理应用的快速迭代。

8、宜搭

产品简介：宜搭是阿里巴巴钉钉自主研发的APaaS（应用平台即服务）产品，定位为零代码/低代码应用搭建平台，依托阿里技术底座，通过可视化拖拽操作，让非技术人员也能快速搭建专属应用，实现业务流程线上化，传统模式下需十余天完成的应用，用宜搭最短2小时即可落地，助力企业高效推进数字化转型。

推荐适用人群：企业业务部门人员、IT部门、政务单位相关人员，尤其适合钉钉生态用户、各类规模企业（从小团队到中大型组织），以及需要快速搭建轻量至复杂应用（如HR管理、考勤审批、政务办公、生产管理等）的主体。

核心功能：零代码/低代码应用搭建、工作流与审批自动化、角色权限精细化管理、数据可视化与报表分析、钉生态深度集成与API扩展、AI辅助搭建、400+应用模板库、集成自动化与连接器工厂。

优点：上手门槛极低，可视化拖拽操作简洁直观，搭配丰富的现成模板，非技术人员可快速上手落地应用；与钉钉、阿里云深度融合，拥有200+高频连接器，能有效消除企业数据孤岛，协同办公效率突出；AI能力赋能，无需编码即可调用AI插件，加速应用交付；具备亿级数据处理能力，通过三级等保、ISO认证，依托阿里云安全底座，提供多版本部署方案，满足不同规模企业及政务场景的安全与合规需求；扩展能力强劲，开放80+OpenAPI，支持复杂业务逻辑定制与多应用互连互通。

总结：宜搭依托阿里技术实力和钉钉生态优势，以零代码/低代码拖拽搭建为核心，兼顾易用性与扩展性。它不仅极大降低了应用开发的门槛，赋能业务人员自主创新，还通过生态联动和AI加持，实现企业业务数字化与协同效率的双重提升，适合各类规模企业及政务单位快速搭建个性化应用，适配从简单办公流程到复杂业务管理的全场景需求。

9、微搭

产品简介：腾讯云微搭是一款高性能的低代码开发平台，打通腾讯云和微信生态，通过拖拽式开发，帮助开发者和企业快速构建小程序、H5应用和Web应用。

推荐适用人群：希望快速开发小程序、H5等前端应用，并利用腾讯云和微信生态能力的开发者和企业。

核心功能：拖拽式页面设计、云原生一体化、连接微信生态、模板库、支持少量代码扩展。

优点：与微信生态（小程序、公众号、企业微信）深度打通，开发和发布流程极为便捷；背靠腾讯云，提供了稳定可靠的云原生基础设施和服务；支持代码扩展，兼顾了开发效率与灵活性。

总结：微搭的核心优势在于其与腾讯生态的深度整合，尤其是微信小程序开发。对于重点业务场景在微信生态内，或希望利用腾讯云服务的企业来说，微搭提供了极大的便利和效率。

10、金蝶云苍穹

产品简介：金蝶云苍穹是金蝶集团推出的企业级PaaS平台，内嵌低代码家族（应用开发、数据分析、集成、流程等平台），旨在帮助大型企业快速构建支持自身业务发展、且安全可控的数字化应用。

推荐适用人群：追求自主可控、需要构建复杂、高性能企业级应用的大型集团企业、国央企及核心IT团队。

核心功能：动态领域模型（KDDM）、一体化低代码开发、企业级云原生架构、集成与流程服务、数据智能分析服务。

优点：与金蝶ERP等核心业务系统原生集成，具备深厚的企业管理领域知识沉淀；平台技术架构先进，为大型企业提供了稳定、安全、可扩展的数字化基座；提供完整的企业级解决方案，而非单一的开发工具。

总结：金蝶云苍穹是一个重型、企业级的PaaS平台，其优势在于深度融合了金蝶多年的企业管理软件实践，为大型企业提供了从底层技术到上层应用构建的一整套解决方案，特别适合进行核心系统重构或构建复杂的行业应用。

总结

通过对10款主流低代码平台的功能、应用场景、扩展性与性价比的横向评测，我们可以发现：不同平台各有优势，有的更注重企业级安全与集成能力，有的则强调敏捷开发与业务部门的自助构建能力。对于企业来说，选择低代码平台的关键在于 匹配自身业务目标与IT战略，而非一味追求“大而全”。 未来，随着AI与自动化技术的深入融合，低代码将进一步成为企业数字化的核心驱动力。希望本文的对比分析，能为您在选型和落地过程中提供实用参考，助力企业高效构建属于自己的数字生态。

关于低代码平台的常见问题解答 (FAQ)

1、低代码平台是否意味着不再需要专业程序员了？

不会。低代码平台旨在提升效率，而非取代程序员。复杂的核心业务逻辑、高性能要求的系统集成以及平台的二次开发与扩展，仍然需要专业程序员的深度参与。低代码让程序员能从重复性工作中解放出来，更专注于高价值的创造性任务。

2、使用低代码平台构建的应用，数据安全有保障吗？

主流的低代码平台通常都提供银行级别的安全保障。它们提供包括数据加密、精细的权限控制、安全审计、API安全网关等多层安全机制。但在选型时，企业仍需仔细评估平台是否符合自身行业的安全合规标准。

3、低代码平台适合开发所有类型的应用吗？

不完全是。低代码平台在企业管理应用、工作流自动化、数据报表、移动应用等场景中表现出色。但对于需要极致性能、复杂算法或底层硬件交互的应用（如大型游戏引擎、高频交易系统），传统开发模式可能仍然是更好的选择。

——轻量化、高柔性、低成本，助力小家电企业实现“快交付、零缺陷、强追溯”
一、行业痛点：小家电制造的“三高”困境
小家电（如饮水机、空气炸锅、咖啡机、电水壶、扫地机器人等）具有SKU多、订单碎片化、交付周期短、外观要求高的特点，普遍面临：

• ❌ 生产黑箱：进度靠问、报工靠纸、异常靠吼；
• ❌ 质量靠人盯：外壳划痕、配件漏装、功能测试遗漏频发；
• ❌ 新品上线慢：每换一款产品，就要重新培训、调整流程；
• ❌ 客户审核难通过：无法提供完整的电子批记录与追溯证据；
• ❌ 成本压到极限：传统ERP/MES动辄数十万，中小企业用不起。
  
  二、家电MES核心应用场景与AI智能化应用
  ✅ 1. 智能排产与订单协同
• 销售订单 → 自动分解BOM → 智能排产（考虑模具、产能、交期）
• 支持插单、急单优先，动态调整计划
• 车间大屏实时显示：当日计划达成率、延迟预警
  ✅ 2. 全流程防错装配
  防错点 AI/系统实现方式
  物料错用 扫码领料，系统校验BOM（如“咖啡机A不可用电机B”）
  工序漏做 工位PDA强制扫码过站，未完成上道工序禁止流转
  关键参数失控 扭矩枪数据自动采集，超差报警并冻结产品
  功能测试缺失 测试工位未触发 → 系统禁止包装
  ✅ 3. AI视觉智能质检（核心亮点）
  针对小家电高外观要求，部署多场景AI检测：
  检测环节 缺陷类型 技术方案
  外壳/面板 划痕、凹陷、色差、LOGO歪斜 HDR高动态成像 + 深度学习
  装配完整性 水箱未装、滤网缺失、螺丝漏打 多角度视觉 + 目标检测
  标签与铭牌 型号错误、二维码模糊、3C标志缺失 OCR + 模板匹配
  功能验证辅助 屏幕不亮、出水异常、Wi-Fi指示灯状态 视觉+传感融合分析
  ✅ 4. 自动化测试与数据闭环
• 对接老化测试台、电气安全测试仪、气密性检测设备；
• 测试数据自动上传至MES，生成《出厂检验报告》；
• 不合格品自动分流至维修站，维修后复测闭环。
  ✅ 5. 全链路追溯与客户合规
• 一机一码：每台产品绑定唯一追溯码（含生产时间、班次、测试数据）；
• 正向追踪：某批次电机 → 装配哪些咖啡机 → 发往哪些客户；

• 反向溯源：客户投诉“不出水” → 3分钟定位至：

  • 具体工位、操作员
  • 水泵型号、测试曲线
  • AI质检图像存档
• 一键生成客户所需报告：支持亚马逊、小米、沃尔玛等格式。
  ✅ 6. 仓储与物流协同
• 成品入库自动绑定生产日期+保质期（如滤芯有效期）；
• 出库按先进先出（FIFO），超期产品自动冻结；

• 快递单自动打印，对接菜鸟、京东物流API。
  四、系统架构

     ┌──────────────┐
     │   电商平台 / ERP  │ ← 订单、主数据
     └──────┬───────┘
            ↓
     ┌──────────────────────┐
     │   万界星空小家电SaaS MES   │ ← 核心执行平台
     └──────┬───────────────┘

  ┌───────────┼────────────────────┐
  ↓ ↓ ↓
  ┌─────────┐ ┌──────────┐ ┌──────────────────┐
  │ 工位PDA │ │ AI视觉终端 │ │ 自动化测试设备群 │
  │(扫码报工) │ │(缺陷检测) │ │(电气/气密/老化测试) │
  └─────────┘ └──────────┘ └──────────────────┘

                 ↓
     ┌──────────────────────┐
     │ 客户门户 / 物流平台 / Andon看板 │
     └──────────────────────┘

• 专注小家电细分场景：已服务饮水机、咖啡机、空气炸锅等客户；
• 真正轻量化：SAAS模式，按年付费；30天上线。
  在小家电“内卷”时代，
  胜出者不是价格最低的，而是质量最稳、交付最快、数据最透明的。
  万界星空——让每一家小家电工厂，都拥有“大厂级”的数字能力。
  让智能，不再昂贵；让制造，更加从容。

一、概述总结

锦鲤抽奖是一款基于微擎平台开发的微信小程序抽奖营销系统源码，由"组局同城社交社区平台进群找搭子陪玩旅游"开发者提供。该系统采用社交裂变+抽奖营销双驱动模式，支持平台发布抽奖活动，用户通过抢购参与获得抽奖号码，并通过推荐他人参与获取额外抽奖机会。系统核心亮点在于红包返现机制，可直接对订单推荐人进行现金红包奖励，实现"参与即获客，分享即收益"的营销闭环。

核心数据：

• 交付方式：微擎系统在线交付
• 源码状态：已加密
• 商品保障：官方正品

二、功能介绍

1. 活动发布与管理

• 平台后台一键发布锦鲤抽奖活动
• 灵活配置活动时间、奖品、参与规则
• 支持指定中奖用户和头衔（后台可控）

2. 社交裂变参与机制

• 抢购参与：用户抢购成功获得1个或多个抽奖号码
• 推荐奖励：推荐他人抢购可获得额外抽奖号码
• 多级传播：形成病毒式传播链条，快速扩大活动影响力

3. 红包返现系统

• 支持对订单推荐人进行现金红包奖励
• 实时到账，激励用户主动分享推广
• 降低获客成本，提升用户参与积极性

4. 开奖与核销

• 后台在活动结束前指定中奖用户
• 活动结束后自动开奖
• 支持奖品核销管理

5. 多平台适配

• 原生微信小程序支持
• 抖音小程序定制开发能力
• 一次开发，多端运行

三、适用场景与行业价值

行业价值

1. 对运营方/商家的价值：

• 零成本获客：利用用户社交关系链，实现低成本精准获客
• 数据沉淀：完整记录用户参与行为，构建私域流量池
• 灵活可控：后台可指定中奖人，确保活动效果可预期
• 即时激励：红包实时到账，提升用户参与感和信任度

2. 对用户的价值：

• 低门槛参与：抢购即可参与，无需复杂操作
• 双重收益：既有机会中大奖，推荐还能得红包
• 社交货币：分享活动获得社交认同感

四、常见问题解答（FAQ）

Q1：系统支持哪些平台？

A：原生支持微信小程序，同时提供抖音小程序定制开发服务，可实现多端覆盖。

Q2：后台可以控制中奖结果吗？

A：可以。后台在活动结束前可指定中奖用户和头衔，确保活动效果可控，但建议遵循公平原则以维护用户信任。

Q3：红包返现是如何实现的？

A：系统支持对订单推荐人进行现金红包奖励，用户推荐他人成功抢购后，推荐人可获得实时到账的现金红包。

Q4：使用人数<10人，系统稳定吗？

A：作为新上架应用，使用人数较少属于正常现象。微擎平台提供官方正品保障，且支持90天无售后急速退款（需开通VIP），建议先测试再正式使用。

Q5：如何安装部署？

A：通过微擎系统在线交付，购买后可在微擎后台直接安装。需先注册登录微擎账号并绑定站点。

Q6：适合什么类型的企业使用？

A：特别适合预算有限的中小企业、线下门店、社交电商、社群运营者，以及需要快速裂变获客的场景。

1. 概述总结

多方签署是一款基于微擎平台的小程序应用系统，专为需要多人协作完成同一文档或协议的场景设计。该系统支持微信小程序和抖音小程序定制开发，核心功能是实现多方（最多3方）共同完成一条订单内容或文档记录。

核心价值定位：

• 多人协作：打破传统单人填写模式，支持自定义字段分配给不同角色（甲/乙/丙）共同完成
• 电子文档生成：配合"表格生成器"插件，可将协作内容生成并下载为电子文档
• 场景适配：特别适用于合同签署、协议确认、租赁约定、事故定损表等需要多方确认的业务场景

2. 功能介绍

核心功能流程

1. 发起方创建：由A（发起方）生成初始记录，设定文档基础框架
2. 字段自定义分配：按业务需求将不同字段分配给N个参与方（甲/乙/丙，N≤3）
3. 多方协作填写：各方按权限独立完成各自负责的内容部分
4. 内容自动聚合：系统自动将多方填写的内容整合为一条完整记录
5. 电子文档输出：通过"表格生成器"插件生成标准化电子文档并支持下载

系统特性

• 字段级权限控制：精确控制每个参与方可查看和编辑的内容范围
• 协作状态实时同步：各方填写进度实时更新，避免信息不同步
• 数据完整性保障：确保所有必填字段完成后才能生成最终文档
• 跨平台支持：一套系统同时适配微信和抖音两大主流小程序生态

扩展能力

• 作为主应用"工单预约表单plus"的关联插件，可无缝集成30+种表单字段类型
• 支持分页表单、WEB端、WAP端、微信端多端适配
• 灵活对接各类业务场景，不仅限于签署，还可扩展至审批、确认、登记等流程

3. 适用场景与行业价值

核心应用场景

场景类型 具体应用 价值体现

电子合同 甲乙双方或多方合同在线签署 替代传统纸质合同，缩短签署周期从数天至数小时

事故定损 保险公司、车主、维修厂三方定损确认 现场即时确认，避免后续纠纷，提升理赔效率

租赁协议 房东、租客、中介三方租赁合约 标准化流程，降低法律风险，保障各方权益

项目确认 客户、供应商、监理方三方验收 明确责任边界，留存电子证据，便于追溯

内部审批 部门间协作的跨部门确认单 简化内部流程，提升组织协同效率

行业价值分析

对法律服务行业：

• 实现电子签名的合规化应用，满足《电子签名法》要求
• 降低合同管理成本，提升法律文书处理效率

对保险金融行业：

• 事故现场即时定损确认，缩短理赔周期，提升客户满意度
• 多方见证机制增强定损结果的公信力

对房产租赁行业：

• 标准化租赁流程，减少因条款不清导致的纠纷
• 电子存证便于长期管理和快速调阅

对中小企业：

• 低成本实现业务流程数字化，无需自建复杂系统
• 灵活适配各类确认、审批、登记场景，快速落地

4. 问答环节（FAQ）

Q1：多方签署系统最多支持几方同时参与？

A：系统目前支持最多3方（甲/乙/丙）共同完成一条记录，加上发起方A，共涉及4个角色。这已能满足绝大多数合同、协议类场景的需求。

Q2：生成的电子文档是否具有法律效力？

A：系统生成的电子文档配合"表格生成器"插件使用，但法律效力取决于具体使用方式和电子签名认证情况。建议结合第三方电子签章服务以满足《电子签名法》要求。

Q3：是否需要购买其他插件才能使用？

A：是的，生成和下载电子文档功能需要额外安装【表格生成器】插件。这是实现文档输出的必要组件。

Q4：该系统是否支持抖音小程序？

A：支持。系统同时支持微信小程序和抖音小程序定制开发，一套代码可适配两大主流平台。

Q5：系统是否开源？能否二次开发？

A：系统源码已加密，不支持直接二次开发。但可通过微擎平台的标准接口进行功能扩展和系统集成。

Q6：与"工单预约表单plus"是什么关系？

A：多方签署是工单预约表单plus的关联插件/子应用。表单plus提供30+种字段类型和强大的表单引擎，多方签署在此基础上实现多人协作签署功能。

Q7：是否支持多方同时在线编辑？

A：系统采用分字段分配机制，各方按权限独立完成各自部分，并非实时协同编辑模式。这种设计更适合签署类场景，确保各方责任清晰。

Q8：购买后包含多长时间的售后服务？

A：首次购买赠送1年服务套餐，在服务周期内可享受应用更新至最新版本的服务。超过服务期后仍可继续使用当前版本，但无法获取更新。

Q9：系统对服务器环境有什么要求？

A：系统支持PHP 5.3至PHP 8.0全版本，兼容性强。但建议至少使用PHP 7.0以上版本以获得更好性能。

一、概述总结

新畅积分商城是微擎应用市场上一款专注于积分运营的小程序系统，由新畅网络技术公司开发，当前已有113+用户在使用。该系统定位为免费积分商城解决方案，支持微信小程序平台，采用PHP5.5-7.1技术栈，源码已加密保护。

作为"新畅行业商城软件"的配套子应用，它以轻量化、易部署为特点，帮助企业和商家快速搭建积分兑换、会员激励体系，实现用户留存与活跃度提升。系统采用微擎系统在线交付方式，提供6个月免费服务周期，适合中小商家低成本启动积分运营。

核心定位：通过积分签到、兑换、抽奖三大核心功能，构建完整的积分生态闭环，增强用户粘性。

二、功能介绍

1. 积分签到系统

• 每日签到：用户每日访问小程序即可获得积分奖励
• 连续签到激励：支持设置连续签到额外奖励，培养用户习惯
• 签到提醒：通过微信服务消息或订阅消息提醒用户签到

2. 积分兑换商城

• 商品管理：后台可添加实物商品、虚拟商品、优惠券等兑换品
• 积分定价：灵活设置商品所需积分值，支持"积分+现金"混合支付模式
• 库存控制：实时库存管理，自动下架无库存商品
• 订单管理：完整的兑换订单流程，支持物流发货（实物）或自动核销（虚拟）

3. 积分抽奖功能

• 大转盘/九宫格：多种抽奖形式，消耗积分参与
• 奖品设置：支持积分、优惠券、实物奖品等
• 概率控制：后台可调整中奖概率，控制运营成本

4. 会员等级体系

• 等级划分：支持普通会员、银会员等多级体系
• 升级规则：基于消费次数或积分累计值自动升级
• 等级权益：不同等级享有不同的积分获取倍数或兑换折扣

5. 数据与运营支持

• 用户数据：积分获取/消耗记录、兑换历史查询
• 运营统计：签到率、兑换率、抽奖参与度等核心指标
• 消息通知：兑换成功、发货通知、积分变动提醒

三、适用场景与行业价值

适用场景

1. 零售电商：作为主商城的补充，通过积分兑换提升复购率
2. 餐饮门店：积分兑换优惠券或菜品，促进二次消费
3. 教育培训：学员积分兑换课程资料或课时，提高完课率
4. 社区运营：业主积分兑换物业服务或周边商品，增强社区粘性
5. 企业内部：员工积分兑换福利，构建内部激励体系

行业价值

• 用户留存：通过每日签到和积分积累，将一次性用户转化为活跃用户
• 成本可控：积分作为虚拟货币，商家可灵活控制成本，相比直接降价更具弹性
• 数据沉淀：积分行为数据帮助商家识别高价值用户，优化运营策略
• 生态闭环：与主商城系统联动，实现"消费-积分-再消费"的良性循环
• 零门槛启动：免费使用降低试错成本，适合初创企业或预算有限的商家

四、常见问题解答（FAQ）

Q1：新畅积分商城是否完全免费？

A：是的，当前版本价格为0元，服务周期为6个月。但需注意这是基于微擎平台的应用，使用需先部署微擎系统。

Q2：该系统支持哪些平台？

A：目前主要支持微信小程序，需具备微信小程序账号及微擎系统环境。

Q3：源码是否开源？

A：源码已加密，属于SaaS化交付模式，商家通过后台进行配置管理，无需自行开发。

Q4：能否与现有商城系统对接？

A：作为"新畅行业商城软件"的附属应用，建议配套使用。如需对接其他系统，需评估API接口兼容性。

Q5：积分如何发放？

A：主要通过每日签到发放，也可结合主商城的消费返积分功能（需主商城支持）。

Q6：实物商品兑换后如何发货？

A：系统支持订单管理，商家可在后台处理发货流程，用户可查询物流状态。

Q7：是否支持多门店或多商户模式？

A：当前版本为单店模式，多商户需求需使用"新畅行业商城软件"主应用。

Q8：抽奖功能的中奖概率可以调整吗？

A：是的，后台支持设置各奖项的中奖概率，便于控制活动预算。

Q9：用户数据是否安全？

A：系统获取用户微信昵称、头像等基本信息，符合微信小程序隐私规范，数据存储于商家自有服务器。

一、概述总结

公众号打招呼营销回复是微擎应用市场的一款专业微信公众号营销工具，专为解决微信新规下的客服消息推送限制而设计。该应用通过智能化、延迟化的消息推送机制，帮助运营者在用户关注公众号后的黄金时间内（59秒、48小时）实现精准营销触达，有效提升用户留存率和转化率。

核心定位：针对微信新规的合规化营销解决方案，实现"即使用户关注后什么都不点击，也可在1分钟内延迟推送"的突破性功能。

二、功能介绍

1. 延迟推送机制

• 1分钟延迟推送：即使用户关注后未进行任何操作，系统也能在1分钟内自动推送营销消息，解决微信新规限制
• 59秒黄金触达：在用户关注后的首分钟内完成首次互动，抓住用户注意力高峰期
• 48小时持续营销：在合规前提下，实现长达48小时的持续营销触达窗口

2. 智能回复系统

• 自动化营销流程：预设多种营销话术和推送策略，实现无人值守的自动化运营
• 个性化内容推送：根据用户行为和标签，推送定制化的营销内容
• 多场景触发机制：支持关注、点击、扫码等多种触发条件

3. 用户留存优化

• 强制触达能力：突破传统客服消息需要用户主动交互的限制
• 标签化管理：支持自动为用户打标签，便于后续精细化运营
• 互动引导设计：通过红包、优惠券等激励手段，引导用户完成首次互动

4. 合规保障

• 微信新规适配：专门针对微信最新客服消息规定进行技术处理
• 风险控制机制：内置防封号策略，确保账号安全运营
• 数据监控面板：实时查看推送成功率、用户互动率等关键指标

三、适用场景与行业价值

核心适用场景

场景类型 具体应用 价值体现

新粉激活 用户关注后立即推送欢迎语+福利，降低首关流失率 提升新用户7日留存率30%+

活动推广 新品上线、限时促销的即时触达 活动参与率提升2-3倍

内容引流 自动推送爆款文章、视频链接 内容阅读量显著提升

私域沉淀 引导添加企业微信、加入社群 私域流量池快速扩充

转化促进 推送优惠券、试用装领取链接 首单转化率提升15%+

重点服务行业

1. 电商零售：新品推广、促销活动、复购提醒
2. 教育培训：课程试听、资料领取、活动报名
3. 餐饮美业：优惠券发放、预约提醒、会员招募
4. 本地生活：同城活动、商家引流、社区团购
5. 内容自媒体：文章推送、粉丝互动、流量变现

行业价值

• 解决痛点：完美解决微信新规后"用户关注即流失"的运营难题
• 降本增效：自动化替代人工，节省90%的客服人力成本
• 合规运营：在平台规则内实现最大化营销效果，避免封号风险
• 数据驱动：通过精准推送提升ROI，让每一分营销预算都产生价值

四、产品参数与购买信息

• 交付方式：微擎系统在线交付，源码已加密
• 适用平台：微信公众号（支持PHP5.6/PHP7.1）
• 服务周期：首次购买赠送6个月服务套餐（含更新服务）
• 开发者资质：企业认证开发者，信誉指数5.0分，应用评分5.0分

五、常见问题解答（FAQ）

Q1：这个应用能解决微信新规的哪些限制？

A：微信新规规定，用户关注公众号后，如果未在48小时内主动发消息或点击菜单，运营者无法主动推送客服消息。本应用通过技术手段实现"延迟推送"，即使用户什么都不操作，也能在关注后1分钟内自动推送营销内容，有效突破这一限制。

Q2：延迟推送是否安全，会不会导致封号？

A：本应用专门针对微信新规进行合规化处理，采用模拟真实用户行为的推送机制，内置多重风险控制策略。开发者拥有企业认证和5.0分信誉评级，技术方案经过市场验证，在正确使用的前提下是安全的。

Q3：推送的内容可以自定义吗？

A：可以。系统支持完全自定义推送内容，包括文字、图片、链接、小程序卡片等多种形式。您可以根据不同用户群体设置差异化的话术和营销策略，实现千人千面的精准推送。

Q4：48小时营销窗口具体指什么？

A：指用户关注公众号后的48小时内，您可以通过本应用持续进行营销触达。这是微信允许的服务号客服消息推送时限，本应用帮助您充分利用这个黄金时间窗口，最大化营销效果。

Q5：这个应用适合什么规模的公众号使用？

A：适用于所有希望通过公众号进行获客和转化的企业或个人。特别适合：①新号冷启动，需要快速积累种子用户；②成熟号提升活跃度，减少粉丝沉睡；③电商、教育、本地生活等强营销需求行业。

Q6：购买后包含哪些服务？

A：首次购买包含6个月服务套餐，期间可享受：①应用功能更新升级；②技术问题咨询支持；③使用指导服务。服务期内可免费更新至最新版本，确保与微信最新规则保持同步。

Q7：是否支持多公众号同时使用？

A：根据微擎平台规则，该应用支持在多公众号平台部署，但具体数量需根据您的微擎系统授权类型确定。建议购买前咨询开发者确认授权范围。

本文内容基于微擎应用市场公开信息整理，具体功能以实际产品为准。购买前建议通过"立即咨询"功能与开发者确认最新产品细节。

摘要：
随着Agent技术发展，RAG正从文档检索工具演进为支撑智能体的统一数据底座。RAGFlow提出通过“树图结合”模拟人类认知，以Context Engine统一处理三类核心数据，要求底层数据库具备强大的混合检索与高性能交互能力。OceanBase seekdb作为AI原生数据库，以向量检索、自定义分词及轻量部署等特性，为构建此类数据底座提供了关键技术支撑，推动Agent规模化落地阶段。

01 前言

在生成式 AI 迈向 Agent 时代的当下，RAG 技术正经历着一场深刻的范式演进。

RAGFlow 联合创始人张颖峰指出，RAG 不仅仅是水上雕花的展示工具，他应当成为智能体的数据底座。

本文基于 RAGFlow 的架构思路，并结合 OceanBase seekdb 的实践，介绍如何构建一个落地快的智能体数据底座。

02 RAGFlow 的架构理念：重新定义 AI 时代的数据底座

RAG 不是终点，而是起点

在 AI 应用开发中，开发者们普遍遇到了 RAG 效果难以提升的困境，仿佛按下葫芦浮起瓢，总有顾此失彼的感觉。尽管到 2024 年，使用多模态模型解析文档、采用混合搜索等实践已经成为共识，但效果仍然不尽如人意。问题的根源在哪里？

树图结合：让检索像人一样思考

RAGFlow 团队给出的答案是"树图结合"。这个方案的核心思想是让 RAG 系统像人一样去检索信息。当领导向你提出一个问题时，你不会在脑海中随机搜索碎片化的知识，而是会根据记忆中的目录结构，找到对应的文献，然后定位到具体答案。

传统 RAG 的召回机制只能返回文字碎片，这种碎片化的知识不利于大模型的理解。因此需要引入"树"的结构，像树状导航一样模拟人类寻找知识的过程。同时，人在寻找答案时还需要联想能力，这就是"图"的价值所在。图不是用来替代树的基础结构，而是帮助系统在导航的同时进行知识联想。

树图结合的数据组织方式，配合大模型的理解能力，才能真正缓解检索不准这一核心痛点。这不是简单的技术堆砌，而是对人类认知过程的深度模拟。

从 RAG 到 Context Engine：支撑 Agent 的三类数据

如果说 2025 年是 Agent 的元年，那么 2026 年就是 Agent 真正落地的元年。经过一年的探索，Agent 所需的技术要素已经逐渐清晰：Memory、外部知识、Tools、Skills……这些看似纷繁复杂的概念，实际上正在进入收敛期。

RAGFlow 认为，企业级 Agent 落地需要一个统一的数据底座来处理三类核心数据：

第一类是非结构化数据，这是 RAG 的舒适区。处理这类数据已经形成了标准化的 PDI 流程（Parse-Transform-Index），类似传统数据平台的 ETL，但最后一步不是 Load 而是 Index。因为 Retrieval Engine 本质上是索引引擎，必须基于索引来工作。这个过程需要各种解析模型（如 PaddleOCR、Marker 等）、语义增强算子，以及强大的混合搜索能力。

第二类是 Memory 数据，即智能体交互过程中生成的实时数据。Memory 与 RAG 的唯一区别在于存储的数据类型不同，RAG 存储相对静态的文档类数据，Memory 存储动态的交互数据。但两者的处理逻辑、语义增强操作几乎完全一致。因此 Memory 可以看作数据库中的不同表或不同库，没有必要将其作为独立组件。这种统一处理还为未来的跨库、跨表操作留下了可能性。

第三类是结构化数据，包括 TP 型业务数据和数仓数据。对于这类数据，不需要重新造轮子，而是通过 MCP（Model Context Protocol）等工具协议统一调用。在大型企业中，可能需要调用成百上千个 MCP 接口，如何高效地检索和使用这些工具，同样需要强大的 Retrieval 能力。

这三类数据的统一处理，构成了 Context Engine 的核心能力。而这个能力的基石，始终是 Retrieval，AI 原生搜索。

Retrieval：Agent 时代被低估的核心能力

在传统搜索引擎时代，用户提出一个问题，可能只需要十次检索就能得到答案。但在 Agent 时代，智能体与数据层的交互频率提升了两个数量级——可能是几百次甚至上千次。这意味着 Retrieval 的性能和准确性直接决定了 Agent 的可用性。

RAGFlow 的判断是：未来所有落地的智能体都将是 Coding Agent。在这个架构中，相对不变的是 Context 内容，Memory、企业内部数据、Tools、Skills 等，这些数据相对容易标准化。而智能体的行为逻辑则完全以代码生成的方式动态构建。

这种架构对底层数据库提出了极高的要求：不仅要支持向量检索，还要支持全文检索，以及未来更多类型的混合搜索需求。这正是 RAGFlow 选择与 OceanBase seekdb 深度集成的原因，一个真正的 AI 原生数据库，必须具备强大的、多样化的检索能力。

03 实践指南：RAGFlow × OceanBase seekdb 快速上手

RAGFlow 项目已深度集成 OceanBase 数据库。现在，您可以使用OceanBase全新推出的轻量级AI原生数据库OceanBase seekdb：

零成本兼容：接口完全兼容 OceanBase，无需修改代码

功能完整：TP/AP 一体化处理能力
AI 原生：支持自定义分词器，快速适配多国语言、支持混合检索，4096维向量索引，完美支持主流嵌入模型
即插即用：更轻量，更易部署

前置要求 (Prerequisites)

在开始之前，请确保您的环境满足以下要求：
CPU >= 4 核
RAM >= 16 GB
Disk >= 50 GB
Docker >= 24.0.0 & Docker Compose >= v2.26.1

部署 RAGFlow

克隆 RAGFlow 代码

配置 seekdb 为 ragflow 依赖的数据库

1. 将 seekdb 作为向量数据库
   修改.env文件：

2. 将 seekdb 作为元数据库
   因为 seekdb 兼容 mysql 协议，所以可以将seekdb也作为 RAGFlow 的元数据库
   修改.env文件：

修改docker-compose.yml文件，注释以下 depends_on 字段

修改docker-compose-base.yml文件，注释以下 mysql 服务

3. 启动服务

执行指令后能看到如下输出

可以执行docker ps检查容器状态，能看到如下输出

通过 docker compose logs -f ragflow-cpu 或者 docker compose logs -f ragflow-gpu（以实际设备为准）查看日志出现 RAGFlow admin is ready after XXs initialization则启动服务成功

4. 通过 RAGFlow 构建 AI 应用
   浏览器输入 http://localhost 进入界面，首次登录点击「Sign up」注册账号

填写完注册信息后，点击 「Continue」 继续

回到登录界面后，点击 「Sign in」 登录账号

首次进入 ragflow 界面后，点击右上角的账户图标

选择 「Model providers」 设置 Api Key 和模型，以下以通义千问为例

填写 API-Key 后，点击 「Save」 保存配置

根据需要选择需要的各类模型，这里案例选择了 「qwen-plus」 作为 LLM 模型、「text-embedding-v4」 作为 Embedding 模型、「gte-rerank」 作为 Rerank 模型

回到主界面，点击 「Dataset」 进入知识库界面，点击界面中央如下图标创建新的知识库

根据需要选择分段方法，案例选择了 「General」（通用） 作为了分段方法，如果您的文档主要是Q&A问答对，您也可以选择 「Q&A」 作为分段方法

点击 「Save」 创建空知识库

点击 「Add file」 中的 「Upload file」 上传文档

点击或者拖取的方式上传需要的文档后，点击 「Save」 保存

因为上传的时候没有勾选「Parse on creation」 ，这里需要全选文档后点击 「Parse」 解析文档构建索引

文档索引构建完毕

构建知识库完成后，回到主界面，我们以构建搜索助手作为案例，点击 「Search」 后点击界面中央如下图标

填写 「search」 的 「Name」 后，点击 「Save」 保存

选择 「Datesets」

其他配置按需配置，这里案例勾选了 「AI summary」（可选），点击 「Save」 保存

根据案例的知识库，提问 「Why oceanbase is a distributed database?」 成功检索到了相关的段落并且以此生成了脉络清晰的总结！

04 从技术到生态：AI 原生的未来图景

RAG 技术不会过时，相反，它正在从一个具体的技术方案演进为 AI 应用的基础设施层。当我们把视角从单一的文档问答提升到 Context Engine 的高度时，就会发现 Retrieval 能力是连接 Memory、知识库、工具调用等所有 Agent 要素的关键纽带。而 AI 原生搜索数据库，正是提供这种能力的最佳载体。

2026 年，随着 Agent 技术的收敛和标准化，企业级 AI 应用将迎来真正的落地浪潮。在这个过程中，选择正确的数据底座至关重要。RAGFlow 的架构理念与 OceanBase seekdb 的技术能力相互印证：强大的混合搜索能力、统一的数据处理范式、轻量级的部署方式，这些特性共同构成了 AI 原生时代的数据基础设施。

从 RAG 到 Context Engine 的演进，不仅是技术路径的升级，更是对 AI 应用本质的深刻理解。当我们像人一样思考数据的组织和检索，当我们用 AI 原生的方式重构数据底座，企业级智能体的大规模落地才真正成为可能。这正是 RAGFlow 与 OceanBase seekdb 携手探索的方向，也是整个 AI 原生生态共同的未来。

欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/