LangBot 4.10.2 更新解读：Sandbox、Skills、RAG 插件化与企业级 AI Bot Framework 功能

沙盒（也称为 Box Runtime）为内置 Agent 提供了一个隔离的执行环境。简单来说，Agent 可以更像开发者一样工作：它可以运行命令、读取和写入文件、编辑文件，并在项目内容中搜索，而无需直接接触主机环境。

原生工具集包括六个核心工具：

沙箱后端是可插拔的。根据部署环境，LangBot 可以使用 Docker、nsjail 或 E2B 作为隔离后端。系统可以自动选择合适的选项。

原作者还指出了一个架构优势：LangBot 已经将插件运行时与主系统分离。这使得设计更容易扩展。例如，WebUI 可以运行在一台机器上，LangBot 后端可以运行在 NAS 上，而插件运行时可以部署在其他地方，例如树莓派上。

Box Runtime 还可以托管 stdio 模式的 MCP 服务器，为 LangBot 提供一种更安全、更灵活的方式来扩展工具能力。

要在 Docker 部署中启用完整配置，请使用：

docker compose --profile all up

要禁用沙箱，请设置：

box:
  enabled: false

技能系统

技能是按需提供的指令包。一个技能可以包含提示词、脚本、流程、模板或参考文件。关键点在于，Agent 不需要始终将每个技能都加载到上下文中。

相反，Agent 通常只能看到可用技能的列表。当某个任务需要特定技能时，只有在那一刻才会加载该技能的完整内容。这减少了上下文浪费，并使长时间运行或复杂的对话更易于管理。

当 Agent 需要专业能力，但不应在系统提示中携带每一条指令时，这种设计就很有用。它让默认上下文保持更轻量，同时仍能在需要时提供更深层的能力。

在 v4.9.x 中已经推出的功能

LangBot v4.9.0：知识库插件化

LangBot v4.9.0 重点将知识库（即 RAG）能力重构为基于插件的架构。作者指出，这是一次酝酿已久的深度更新，尤其是为了更好地与 Dify 等平台集成。

在新设计中，LangBot 不再将内置知识库和外部知识库视为两个独立类别。相反，所有知识库都以统一方式进行管理。不同的知识引擎通过插件提供。

主要变更包括：

1. 统一管理：内置知识库和外部知识库在同一管理模型下处理。

新组件类型：引入了 KnowledgeEngine 插件组件。

• 动态表单：创建知识库时，表单可以根据所选引擎以不同方式呈现。

• 基于 API 的核心能力：嵌入调用和向量数据库操作被封装在 RAGRuntimeService 中，因此插件可以通过 API 调用它们。

• 自动迁移：在旧版本中创建的知识库在升级到 v4.9.0 后可以自动迁移。

截图显示了几个与 RAG 相关的知识引擎插件。原文提到了五种 RAG 选项，其中包括 LangBot 团队自己的研究成果。

其他重要更新

LangBot Cloud 也已正式上线。不想自行托管的用户可以通过官方云服务体验 LangBot。

这一发布线还包含多项修复，涵盖了 Dify 输出解析、WebSocket 消息发送和配置类型转换等方面。

在知识库实现插件化之后，开发者获得了一种更简洁的方式，将自定义知识引擎连接到 LangBot。这对具有更复杂业务需求的团队尤其有用。

已经添加但很少被详细提及的更新

原作者随后不再局限于公开发布说明，而是列出了一些实际上早已变更、但在之前文章中未被充分解释的功能。

LangBot 插件市场已超过 400 个条目

根据原帖，LangBot 插件市场的条目数已经超过 400。作者还指出，团队会审核插件，而纯娱乐类插件相对有限，重复度也较低。

这一点很重要，因为插件生态系统往往比单一的内置功能列表更重要。更大的生态意味着用户可以将 LangBot 扩展到不同工作流程中，而不必等待每一项能力都成为核心产品的一部分。

外部 AI 应用平台兼容性已覆盖超过七个平台

LangBot 持续扩展与外部 AI 应用开发平台的兼容性。原文提到围绕 Weknora 和 Deerflow 的近期更新，强调 LangBot 非常重视可扩展性。

截图展示了多个平台的连接器相关文件，包括 Coze、DashScope、DeerFlow、Dify、Langflow、本地代理、n8n、Tbox 和 Weknora。

LangTARS 与类 OpenClaw 能力持续提升

LangTARS 被描述为一个模块化能力层。LangBot 作为统一基础，能够将模型、工具、知识库和对话历史安全地暴露给本地或第三方 Agent。

这使 Agent 能够专注于业务智能：理解用户意图、调用工具、检索知识并组织答案。Agent 无需担心底层连接细节。

文章还提到，这些能力既可以支持基于沙箱的操作，也可以支持个人计算机控制场景。

SaaS 平台 Agent 更新

SaaS 平台也收到了 Agent 更新。作者在这里没有展开太多细节，但指出 SaaS 用户已经体验到了这些变化，而开源社区可能会在后续几个版本中体验到部分功能。

企业级模型回调路由

LangBot 已新增企业级模型回调路由。当模型调用失败时，消息可以被路由回预先安排好的备用模型。

这一设计的价值在于，它有助于打破围绕 API 密钥和模型供应商的限制。对于企业系统而言，当某个提供商发生故障或达到限制时，这可以提升可靠性。

LangBot 直接或间接支持 30 多个 IM 平台

LangBot 已经实现了广泛的即时通讯平台兼容性。原文指出，LangBot 直接或间接支持 30 多个 IM 平台。

对于机器人框架来说，即时通讯平台覆盖范围非常重要。企业可能需要一套机器人系统能够同时运行在微信、QQ、飞书、钉钉、Telegram、Discord、Slack、LINE 及其他平台上。统一的机器人框架可以减少重复的集成工作。

管线路由：类似 Workflow 的会话路由

文章还提到了管线路由，它的行为有点类似于 Workflow。

借助这一功能，LangBot 可以根据业务关键词或其他条件，将会话路由到不同的管线。不同的管线可以使用不同的提示词、扩展和数据库。它们也可以进行嵌套。

原作者补充了一条重要说明：在可视化 Workflow 更新推出后，这个管线路由功能可能会被移除或替换，因为可视化工作流编排会更加稳定，也更易于使用。

二维码配置

对于一些受支持的开放平台，LangBot 可以使用基于二维码的配置方式。这使得配置开放平台变得更容易，而无需手动输入每一个细节。

未来更新预览

在源文章撰写时，一些即将推出的功能其实已经在开发中了。作者指出，其中一些内容新到连官方网站在当时都还没有更新。

可视化工作流编排已开发完成

可视化工作流编排功能已经完成开发，并且合并时间也已确定。

这是未来较为重要的变更之一，因为它可以让复杂逻辑更容易通过 WebUI 构建和维护。

集成其他 CLI 风格的代理能力

文章还提到，与 cc 相关的项目已经获得了一些关注，因此团队决定增加对其他类似 Claude Code 和 Codex 的 CLI 风格能力的支持。

这一方向符合更广泛的趋势，即让 AI 代理能够更直接地与开发环境、命令行工具和本地项目协作。

更多功能即将到来

作者将其余即将推出的功能作为悬念保留。核心信息很明确：当前的 LangBot 更新并不是终点，路线图中仍包含更多与 Agent 和 Workflow 相关的改进。

关于未经核实的对比的说明

原文还回应了另一篇文章，据作者所述，该文章在进行比较之前没有核实足够多的细节。

截图指出，LangBot 和 AstrBot 都在朝着实用的 AI 机器人生态系统发展，但它们侧重的方向不同。LangBot 更专注于将 AI 应用快速接入聊天生态，而 AstrBot 更专注于将机器人本身打造为一个可扩展的智能平台。

实际结论很简单：比较应基于经过验证的功能、使用场景和部署需求。只有在比较忽略了插件系统、运行时分离、平台集成或企业级路由功能时，一个框架看起来才可能“更小”。

我们都很相似

作者简要补充了一个带有反思性的观点：同一生态中的项目往往看起来很相似，因为它们都在响应相似的用户需求。

AI 机器人框架都在尝试连接模型、工具、知识库、消息平台和用户工作流。相似性未必是问题。真正的差异体现在架构、扩展模型、部署设计，以及团队支持真实世界用例的速度上。

每个人的情况都不同

不同的团队在不同的约束条件下进行构建。有些专注于本地易用性。有些专注于插件丰富度。有些专注于企业部署。有些专注于聊天平台覆盖范围。

这就是为什么严肃的比较不应只问“哪个功能更多？”还应该问：哪个框架更适合部署场景、团队规模、平台要求、维护能力以及长期扩展规划？

高并发积压测试

在原文结尾，作者补充了与性能相关的数据。对于一个框架来说，高并发和多会话处理是重要指标。

测试方法是先让未处理的会话累积到大约 50–70 个，然后逐步降低速度，并观察系统达到负载均衡时的 TPS。

作者指出，测试期间存在会话积压，因此这代表的是高并发环境，并不完全等同于正常的生产流量。不过，它仍然能为框架在压力下的性能提供有价值的参考。

源文章中描述的测试条件：

单位

国内框架 A/B

以下图表来自原文中展示的国内框架 A/B 测试。

根据原作者对图表的解读，TPS 约为 每小时 240 条回复。

LangBot

以下图表来自原文中展示的 LangBot 测试。

根据原作者对图表的解读，LangBot 在这项测试中达到了约 每小时 1260 条回复。

作者还指出，这对 LangBot 来说可能仍然有些不公平，因为 LangBot 一开始就多了一个 Runtime 组件。即便有这个额外组件，在所展示的测试中，结果仍然明显更高。

性能解读注意事项

这些图表很有用，但不应将其视为通用的生产环境基准。作者使用的是 Raspberry Pi 5 和特定的测试方法，因此在不同硬件、不同 API、不同模型延迟以及不同部署拓扑下，绝对数值可能会发生变化。

更有参考价值的信号是在相同测试设置下的相对 TPS 比率。原作者还表示，相关测试软件之后可能会开源。

常见问题

什么是 LangBot？

LangBot 是一个开源、生产级的平台，用于构建由 AI 驱动的即时通讯机器人。它将大语言模型和 AI 应用平台连接到 Discord、Telegram、Slack、微信、QQ、飞书、钉钉等聊天平台。

LangBot v4.10.x 有哪些变化？

最重要的更新是引入了 Sandbox 和 Skills。Sandbox 为 Agent 提供了一个用于命令和文件操作的隔离工作区，而 Skills 则让 Agent 仅在需要时加载专用指令。

什么是 LangBot Box Runtime？

Box Runtime 是 LangBot 的沙箱执行环境。它可以提供诸如 exec、read、write、edit、glob 和 grep 等工具，同时使执行与宿主环境保持隔离。

如何在 Docker 中启用 LangBot 沙箱？

对于 Docker 部署，原文使用 docker compose --profile all up 来启动完整配置。要禁用沙箱，请在配置中设置 box.enabled: false。

LangBot Skills 有什么用途？

技能是供 Agent 按需使用的指令包。它们可以包含提示词、流程、脚本和参考文件，使 Agent 无需在一开始就将所有内容加载到上下文中，也能使用专门知识。

LangBot 比 AstrBot 更好吗？

答案取决于具体使用场景。LangBot 重点聚焦于将 AI 应用连接到聊天生态、企业路由、插件运行时隔离、RAG、MCP 以及多平台 IM 部署。AstrBot 也具备强大的 Agent 和机器人框架能力，因此正确的选择取决于部署场景和功能优先级。

本文中的 TPS 数据是生产环境基准吗？

不是。原始测试使用了特定的 Raspberry Pi 5 配置以及受控的积压场景。这些数据可作为参考，但生产环境中的性能将取决于硬件、API 延迟、部署方式、会话负载和配置。

LangBot 可以用于企业机器人吗？

是的，LangBot 是为生产环境和企业场景而设计的，尤其适用于团队需要多平台即时通讯支持、知识库集成、模型路由、监控以及可扩展插件能力的情况。

相关工具

• LangBot：用于构建 AI 驱动即时通讯机器人的开源平台。

• LangBot 文档：关于部署、机器人配置、模型、流水线、插件、沙箱和技能的官方文档。

• LangBot 插件 SDK：LangBot 的官方插件 SDK、CLI、插件运行时和 Box Runtime 基础设施。

• LangBot Cloud：面向不想自行托管用户的托管式 LangBot 服务。

• AstrBot：开源 AI Agent 助手与聊天机器人框架，此处用作对比参考。

• Docker：LangBot 部署和沙箱后端使用的容器平台。

• Dify：LangBot 可连接的 LLM 应用开发平台。

• n8n：可连接到 LangBot 的工作流自动化平台，用于基于聊天的工作流触发。

相关链接

• 原始 CSDN 文章：源文章已改编为此英文 Markdown 版本。

• LangBot v4.10.0 沙盒与技能发布博客：LangBot 官方文章，解释了沙盒和技能。

• LangBot GitHub 仓库：LangBot 的主要开源仓库。

• LangBot 发布版本：LangBot 各版本的官方发布历史。

• LangBot 官方文档：LangBot 使用、部署和配置文档的入口。

• LangBot 技能文档：安装和使用技能的官方文档。

• LangBot 插件 SDK 仓库：LangBot 插件和沙箱基础设施的官方 SDK 与运行时仓库。

• AstrBot GitHub 仓库：AstrBot 的官方仓库，适合希望比较框架方向的读者。