Sentō 需要按 token 计费的 API 密钥吗?

不需要。Sentō 使用你在机器上已经登录的同一个 Claude Code OAuth token 进行认证,这个 token 绑定在你的 Claude Pro 或 Max 订阅上,而不是按用量付费的 Anthropic Console 密钥。你的智能体发送的每条消息都记在你的订阅里,而不是另外计量的账单上。如果你更愿意用按 token 计费的 API 密钥,Sentō 也支持。

24/7 运行一个 Sentō 智能体要多少钱?

除了你已经在付的 Claude 订阅,零额外成本。Pro 套餐足够支持一个日常智能体;Max 解锁更重的 24/7 负载。Sentō 还把一切路由到 Claude Code,所以你获得 Claude Code 自带的上下文和缓存优化,同样的 token 用得比原生 API 调用更远。你永远不会看到单独的 token 账单。

大约五分钟。运行 `npx sentoagent init`,回答几个关于模型、频道和 bot token 的问题,智能体就会启动并在 Discord、Telegram、Slack 或 iMessage 上线。

Sentō 的自我修复是怎么实现的?

每个智能体都在 Guardian + Watchdog 配对下运行。Guardian 在智能体进程崩溃时重启它;Watchdog 看着 Guardian。如果智能体挂了,你还没察觉它就重新上线了,而且你可以直接从 Discord 修复一切,不用 SSH 进去。

两个 Sentō 智能体可以互相对话吗?

可以。Sentō 是首个内建安全智能体间通信的框架。每条消息都经 HMAC-SHA256 签名,配对要双方同意,速率限制默认开启。

支持哪些消息平台?

开箱即用支持 Discord、Telegram、Slack 和 iMessage。你可以跑在 VPS、Docker 里,或直接在 macOS 上。

Sentō 是开源的吗?

是,MIT 许可证。源码在 github.com/sentoagent/sento,软件包在 npmjs.com/package/sentoagent。

我是怎么做出 Sentō 的:从 OpenClaw 实验到开源框架

怎么开始的

我一开始就是闲着没事玩 OpenClaw。那些智能体框架看起来挺酷的,我想看看能把它推到什么程度,最后就起了一个小的智能体来帮我做营销:监控广告表现、写博客文章、发社交媒体、在 Discord 上回答问题。我叫她 Mira。M 代表 marketing。

她能跑,而且因为能跑,我就一直在用。

注意到重叠

在过去的几个月里,我开始注意到一个规律。Claude Code 不断原生发布 OpenClaw 拼凑出来的功能:记忆、浏览器工具、插件系统、skills。如果 Claude Code 自己就能做这些大部分事情,那一个显而易见的问题就是:我为什么还要在它上面再跑一个封装?

差不多同一时间,我开始研究是不是能用 Claude Code 自带的工具达到同样的智能体行为,除了一个简单的消息插件之外不用任何第三方胶水代码。只花了几个小时研究,分散在各处,因为我还有别的工作要忙,但看到的东西足以让这件事看起来可行。大概两周后,那封邮件来了。

那封把时间表逼紧的邮件

Anthropic 宣布第三方工具不能再用 Claude Code 的 OAuth token。一夜之间,基于 OpenClaw 的智能体的成本模型翻了:要继续跑它们,你现在需要一个单独的按 token 付费的 API 密钥,意思是盯着计数器而不是付一个固定的订阅费。对我的那一堆智能体来说,这意味着一张真实的账单,或者一次迁移。

我已经说服了自己能直接把所有东西跑在 Claude Code 上,所以这封邮件只是逼紧了时间表。我当天就开始动手了。

第一天:迁移

第一个版本不是一个框架。就是一次迁移。我把 Mira 的记忆、她的 CLAUDE.md、她的 Playwright 配置全部拿下来,移植到一个直接跑在 Claude Code 上的智能体。我写了一个启动脚本,接上 Discord 插件,到下午结束她就重新在线了,跑在我本来就付着的 Claude Max 订阅上,而不是一个要按 token 付费的第三方封装。同样的性格、同样的习惯,下面换了个引擎。

然后我继续干。Kai、Porter、Adrian、Blair。总共五个智能体,全部迁移,全部通过 Claude Code 运行,全部在同一个订阅上。中间某个时候,我问其中一个智能体框架应该叫什么。我们来回讨论了一会儿,最后定在 Sentō(戦闘,日语里"战斗"的意思)。被派去为你征战的智能体。

问题从哪里开始的

裸 Claude Code 加一个 Discord 插件不是一个智能体框架。没有 auto-restart、没有错误恢复、没有 health check。第一个版本就是一堆乱七八糟的 bash 脚本:start-mira.sh 在 tmux 里起 Claude Code,一个 cron 任务在重启时把她拉起来,她崩溃的时候(早期经常发生)我就 SSH 进去手动修。每一个具体的故障都教给我一些东西,那些东西得进到框架里,每一个我踩到的坑我解决时都想着下一个人。

双重响应

我同时跑了一个 systemd 服务和一个 tmux 会话。两个 Claude Code 实例抢着同一个 Discord bot token,所以从 Discord 的角度看,bot 每小时连接和断开几千次。他们重置了我的 token。教训很简单:选一个进程管理器,不是两个,而且让框架强制这一点。

一张图片搞垮了一切

Mira 从网上下载了一张表情包模板,它卡在了她的上下文窗口里。后续的每一次 API 调用都返回"Could not process image."。她还活着但完全不响应,不管怎么在 Discord 上发消息都没用,因为错误发生在 Claude 还没读到 CLAUDE.md 规则之前。我只能 SSH 进去手动重启她。

那时候我意识到了一件重要的事。这个框架的用户不会有我帮他们 SSH 进去修东西。智能体必须自己修自己。

529 天启

Anthropic 的 Sonnet 模型挂了。每一次 API 调用都开始返回"529 Overloaded",我当时的四个智能体全都卡在重试循环里。systemd 服务一直把它们重启,创造更多的连接,让限流变得更糟,直到 VPS 都连不上了。硬重启之后,我加了一个 token refresh 错误缓存:如果 API 挂了,别再捶它,等 30 秒再试。小修复,大区别。

把脚本变成框架

每一个踩到的问题,我解决之后就问自己:怎么保证没人再踩到这个?这个问题就是把一堆 bash 脚本变成 Sentō 的关键。

一条命令的安装

我受够了那个 45 分钟的手动设置过程:装 Node、装 Bun、装 Claude Code、装 17 个插件、配置 Discord、给插件打补丁支持服务器级匹配、设置记忆、创建启动脚本、加 cron 任务。所以我写了一个 Node.js 的 CLI,把所有东西都干了。

npx sentoagent init

五分钟、几个问题,然后智能体就在 Discord 上活了。

Guardian

那个图片 bug 教给我"活着"和"工作着"不是一回事。进程可以在跑,但智能体完全卡死了,天真的进程管理器永远不会注意到。

我做了 Guardian,一个轻量的 Node.js 进程,和智能体并排跑,每 30 秒检查一次健康。没有 AI、没有 tokens,纯 bash 级别的监控。当智能体卡住时,Guardian 通过未回复的消息和 API 错误检测到,在重启前保存智能体的上下文,把智能体拉回来,然后发一条 Discord 消息告诉你发生了什么。如果 auto-restart 失败三次,它会在 Discord 上 ping 你要求手动回"restart",而不是悄悄地循环。用户永远不用打开终端。他们通过 Discord、Telegram、Slack 或 iMessage 完全管理他们的智能体。

智能体间通信

这是我最引以为傲的功能,也是其他框架都没有的。等到我有了 Mira(营销)、Kai(私人朋友兼顾问)、Porter(邮件处理)、Adrian(执行助理)、Blair(家人的私人助理)跑在同一个 VPS 上,他们在做非常不同的工作,但彼此之间还是完全隔离的。如果 Mira 在一个客户的广告表现里注意到了 Porter 需要知道的东西,我得手动转达。

所以我在框架里内建了智能体间消息。每个智能体的 Guardian 跑一个小 HTTP 服务器,消息用 HMAC-SHA256 签名,双方智能体都要同意配对才能通信,整套东西都有限流,而且是纯文本,所以零 token 消耗。第一次我让 Mira 告诉 Kai 有个新的广告活动时,她发了一个签名的请求到 Kai 的 Guardian,Kai 处理并回复了,整个交互过程我没碰任何东西。我看着第一场智能体之间的对话展开的那一刻,感觉未来已经降临在我自己的 Discord 里。

性格 onboarding

大多数智能体框架都是从一个空白的配置文件开始。你编辑 YAML、定义工具、写 system prompts。这是工作,而且是那种挡在你和真正使用智能体之间的工作。

Sentō 的智能体会自我介绍。在第一条 Discord 消息里,智能体会说类似:"嘿!我刚醒过来,准备好出发了。告诉我,我们有什么冒险等着?我们要一起建造、打破、还是征服什么?" 它采访你,学习你需要什么,基于你的回答更新它自己的配置。没有 YAML、没有终端,就是对话。

今天的 Sentō

**13 个 CLI 命令:**init、status、config、channels、skills、logs、update、doctor、start/stop/restart、pair、agents
**自我修复:**Guardian + Watchdog,从崩溃和卡死状态自动恢复
**智能体间:**任何服务器上智能体之间的 HMAC 签名安全消息
**多平台:**Discord、Telegram、Slack、iMessage
**Docker 支持:**容器用户可以用 docker compose up -d
**空闲零成本:**监控消耗零 AI tokens
**兼容你的 Claude 订阅:**不需要按 token 付费的 API 密钥

说实话

Sentō 是胶水。它不构建 AI(那是 Claude 的事),不构建消息层(那是 Claude Code 的插件),也不构建记忆系统(那是 ClawMem)。但 OpenClaw 也是胶水。每一个智能体框架都是胶水。价值不在单独的零件里;在于让它们可靠、安全地协同工作,而且不需要计算机科学学位就能操作。

让 Sentō 不同的东西归结起来是四点。它兼容你已有的 Claude 订阅,所以没有按 token 付费的 API 密钥、没有意外账单。你的智能体自己修自己,所以你不需要 SSH 访问来从卡死状态恢复。你的智能体可以互相对话,这是目前没有其他框架提供的。整个设置五分钟搞定,就在一条命令背后。

接下来是什么

**语音模式:**智能体听 Discord 语音消息并用音频回复
**智能体市场:**下载预制的智能体性格,附带 skills
**托管版本:**一个网页仪表板,让非技术人员不用终端就能设置智能体

为什么开源

我做 Sentō 是因为我需要它。Anthropic 的定价调整让我的 OpenClaw 智能体跑起来很贵,而把它们直接迁移到 Claude Code 结果证明反正也是正确的架构选择。一路上我解决的那些问题,是任何跑一个 AI 智能体跑得够久的人最终都会遇到的:崩溃、卡死状态、成本意外、多智能体协调。把这些修复留给我自己没意义,所以给你们了。

npx sentoagent init

你的智能体就在一条命令之外。

Gabriel Gil 是 Sentō 的创建者。他跑着五个智能体处理营销、个人事务、邮件处理和执行助理的日常工作。他在迈阿密工作,相信每一个 AI 智能体都值得有一种性格。

GitHub: github.com/sentoagent/sento npm: npmjs.com/package/sentoagent