Lean & Secure — lsbot 的设计哲学

我们不能相信任何聊天服务器，也不能允许把我们电脑上最重要的数据分享给任何聊天服务器。

精简即安全

lsbot 的名字有两层含义：

Lean & Secure Bot — 安全不是事后加上去的功能，而是第一设计原则。

ls — Unix 最基础的命令之一。第一次拿到一台新机器，你会敲的第一个命令。lsbot 的目标是成为你工具箱里同等级别的基础设施：永远在，永远可信，永远如你所期。

精简和安全不是对立的取舍。精简本身就是安全的实现方式：

• 代码越少，攻击面越小
• 依赖越少，供应链风险越低
• 执行路径越清晰，行为越可预测
• 可审计的二进制，没有运行时"惊喜"

复杂已死

当你运行一个 AI Bot，你交给它的是你机器的钥匙：文件、终端、数据库、浏览器会话、凭据。它读你的代码，你的笔记，你的私人文档，它以你的名义执行命令。

问题不是你的 Bot 有没有用。问题是：还有谁能读到它看到的东西？

几乎所有主流 AI Bot 框架都建立在一个隐含假设上：消息通过开发者的服务器路由是安全的。这个假设在以下任何场景中都会失效：

• 服务商被攻击或遭受数据泄露
• 政策变更导致日志保留或内容审查
• 内部员工滥用访问权限
• 法律程序要求披露用户数据
• 服务商出售或被收购

基于 Node.js 的 AI Bot 框架还额外带来结构性问题：

卡巴斯基等安全工具对此类框架的扫描结果往往揭示 500+ 漏洞。这不是危言耸听，这是依赖链膨胀的必然结果。

lsbot 的回答：单一静态二进制

Copycurl -fsSL https://files.lingti.com/install-lsbot.sh | bash

一行命令，一个 35 MB 的静态二进制，没有 runtime，没有包管理器，没有 node_modules。

零依赖不只是"体积小"的问题——没有供应链攻击面，没有版本地狱，没有"在我机器上能跑"。

端到端加密：默认开启

Copylsbot relay --provider deepseek

一条命令启动安全 Bot。它：

1. 首次运行时在本地生成 E2EE 密钥对（~/.lsbot.pem）
2. 通过 WebSocket 连接中继
3. 只发布公钥——私钥永不离开你的机器
4. 在每条响应离开你的进程之前加密
5. 在每条消息到达你的进程之后才解密

中继服务器（lsbot.org，国内镜像：bot.lingti.com）只看到密文。它无法读取你的消息，无法记录你的对话，无法推断你在用什么工具、访问什么文件。

Copylsbot e2e pubkey
# Key file:    ~/.lsbot.pem
# Public key:  BK3x9f2...
# Fingerprint: sha256:29f8954f

打开 Bot 页面，点击「安全」，粘贴公钥，验证指纹匹配。此后每次访问自动启用加密。公钥验证是离线的——中继服务器无法替换它自己的密钥。

数据永不离开你的机器

lsbot 没有云端数据库。

云中继只做一件事：路由加密后的消息。消息转发后立即丢弃，不落库，不分析，不记录。即使 lsbot.org 明天关闭，你所有的数据、配置、历史记录都完好无损在你的机器上。

这不是承诺，这是架构决定的结果。

原生中国，不是改装版

lsbot 从第一天起就为中国市场设计，平台支持是原生的、经过生产验证的：

中国企业 90% 的日常沟通发生在钉钉、企业微信、飞书上。一个不支持这三个平台的 AI Bot 框架，在中国市场就是一个没有腿的工具。

国内平台的 AI Bot 集成历来是个痛点：回调验证、消息加解密、Access Token 管理、IP 白名单……lsbot 把这些复杂流程封装为分钟级方案：

合规友好

静态编译的 Go 二进制对政府机构、金融、医疗等强监管行业意味着：

• 行为确定，没有动态加载路径
• 可以离线审计二进制内容
• 没有 Node.js / Python 层面的越权执行风险
• 数据完全本地化，满足数据驻留要求

当你在凌晨处理线上问题时，你需要的是一个行为可预测的工具，而不是一个"功能齐全但无从排查"的黑盒。

一句话

AI Bot 不是装在机器上的玩具，它是你团队里最便宜、最勤快、从不请假的那个人。 选错了框架，迁移成本极高。选对了，它就是你的基础设施。

lsbot 是为在中国落地 AI 自动化而生的工具。精简、安全、本地化，这三件事不是妥协，是设计。

→ 快速开始 · E2EE 加密 · 平台接入指南 · GitHub