每个 actor 只在有请求进来时才进入内存。空闲 10 秒后，它会休眠到对象存储里，成本几乎为零。
Durable Actors 很擅长保护人类和智能体共享的资源。比如 Figma 画布、一个 artifact（例如 Claude artifacts）、一个 Word 文档。客户端可以连接/订阅这些资源、提交修改、读取最新状态；而因为每个 actor 一次只处理一个请求，你就能避免 race condition。
我们的托管版本让你和团队可以用声明式、类型安全的 API 来定义 actor。然后你可以在本地用开发服务器测试它们。准备好后，运行 terse deploy，你的 actor 就能通过 URL 访问。把它加进现有项目非常简单，只要运行 generate 命令，它就会给你构建一个零依赖、类型安全的客户端。
很想听听你的想法！有任何问题、bug、顾虑等，欢迎联系 :)
founders@useterse.ai
PH 用户
每个 actor 一个 SQLite、空闲 10 秒后休眠，这个组合最吸引我——我一直在跟这个问题较劲：长时间运行的智能体，状态放在中心 DB 里，一重启就丢失进行中的工作。让每个智能体拥有自己的微型 server、按请求唤醒，感觉方向很对。有个问题：对于实时会话，有没有办法让 actor 保持热启动？还是说唤醒延迟已经低到实际使用时无所谓了？
我们正在做逐渐兴起的 Actor 领域。随着我们从静态、长生命周期的 UI 转向临时、实时生成的 UI，对能快速、低成本启动，并能以极低存储成本保存的小型计算单元的需求会暴涨。
另外，随着每天使用智能体的人越来越多、企业使用更多 AI 工具，人类与智能体之间的协作会变得至关重要。
问题在哪？我们如今的基础设施并不是为此而建的。
中心化的 Websocket server 和 ACID 数据库，根本跟不上创建内容速度比人类快 90 倍的智能体。等超快模型进入市场，这个速度还会提升到 900 倍！！
解决方案？把负载分散出去。让每个智能体写入自己的 SQLite DB，让每个智能体服务自己的 websocket server。这样你的后端就变成无状态的，简单、快得飞起，运行成本也更低。这一群 Durable Actors 负责处理你应用里的实时元素。
每个 actor 只在有请求进来时才进入内存。空闲 10 秒后，它会休眠到对象存储里，成本几乎为零。
Durable Actors 很擅长保护人类和智能体共享的资源。比如 Figma 画布、一个 artifact（例如 Claude artifacts）、一个 Word 文档。客户端可以连接/订阅这些资源、提交修改、读取最新状态；而因为每个 actor 一次只处理一个请求，你就能避免 race condition。
我们的托管版本让你和团队可以用声明式、类型安全的 API 来定义 actor。然后你可以在本地用开发服务器测试它们。准备好后，运行 terse deploy，你的 actor 就能通过 URL 访问。把它加进现有项目非常简单，只要运行 generate 命令，它就会给你构建一个零依赖、类型安全的客户端。
很想听听你的想法！有任何问题、bug、顾虑等，欢迎联系 :)
founders@useterse.ai
不过，当一个智能体对同一个 actor 连续猛发大量写入时会发生什么？？？是就一条条排队，还是到某个点就开始拒绝？等智能体成为主要写入方之后，这大概会很关键。