AgentSky AgentSky 是一个云托管智能体服务,用户可通过 WhatsApp、Telegram 等平台一键启动和调用多种 AI 智能体,适合需要远程执行长周期任务的开发者。 热门评论 PH 用户嘿,Product Hunt 社区的朋友们 — 感谢大家的热情关注和提问!我们将于太平洋时间周三晚上举办一场实时实操活动,你可以带上你的 bot,几分钟内把它部署到云端,还能实时解答更多问题。点击这里加入:lu.ma/e94dqa2m---嘿,Product Hunt!👋我构建 AgentSky 是因为生产级的 AI 智能体所需的基础设施远超大多数人的预期。这个想法源于构建 tycoon.us 的过程,我们遇到了同样的挑战:测试多种 harness/LLM 组合(更别提 harness 版本更新了 😱)、快速且安全的沙箱、扛过重启,以及把它们连接到用户期望的每个渠道。AgentSky 帮你把这些底层工作都做了。选一个 harness — Claude Code、Codex、Hermes 或 OpenClaw — 选一个模型,一键启动,或者用一条 CLI 命令。你的智能体会常驻运行在独立的云沙箱里,拥有完整历史记录、产物持久化、状态快照、备份和恢复。你的用户在哪里,它就能在哪里触达 — WhatsApp、iMessage、Telegram、Slack、网页、CLI,或者我们的开发者 API。同样的协议,同样的记忆,每个 harness,每个渠道。AgentSky 已经在生产环境中久经考验,支撑着 tycoon.us,处理了超过 10K+ 个智能体会话。停放一个智能体是免费的 — 只有它在实际工作时你才付费。非常期待你的反馈,特别是你接下来希望支持哪些 runtime 和渠道!PH 用户暂停和恢复是很有意思的部分,我觉得这里有一个盲点,值得现在而不是以后就设计好。如果停放免费,只有智能体在工作时才付费,那么一个悄悄停止工作的智能体就不会让我花钱。这很美好,直到一个死掉的智能体和一个便宜的月份在账单上看起来一模一样。对于长周期任务来说,账单历来是告诉人们出了问题的东西,而这种定价方式故意去掉了这个信号。从外部看,一个暂停的智能体、一个完成的智能体,和一个崩溃后从未恢复的智能体,表现都一样:没有活动,没有费用,渠道里也没有任何动静。那么,操作者怎么知道他们面对的是哪一种?我想要的是,长周期智能体在启动时就声明一个预期的节奏,这样平台就能说“这个早该醒来了但还没醒”,而不是让沉默去代表读者以为的任何意思。第二个问题,它来自快照与消息渠道的结合。如果你对状态做快照然后恢复,当快照是在某个外部副作用执行到一半时拍摄的,会发生什么?一个被恢复到刚发送 WhatsApp 消息之前的智能体,无法判断那条消息到底发出去没有。重发和跳过都不对,而另一端的人只能看到其中一种情况——他们收到两次。副作用会被记录在快照之外吗?这样恢复后的智能体就知道哪些事情已经发出去了?PH 用户很喜欢这种只在工作时付费的模式,定价很聪明。好奇你们如何处理沙箱之间的安全?智能体这样常驻运行的话。PH 用户这正是那种大家没遇到之前都会低估的基础设施难题。你们花了多久才让重启在不同 harness 之间可靠地工作?PH 用户恭喜!智能体能同时在多个渠道与用户通信吗?例如,一个智能体能否在 Slack 上开始对话,然后在 WhatsApp 上继续同一个对话?PH 用户我喜欢 AgentSky 把不同的模型和智能体工具放在一起。测试想法的时候能省不少时间,尤其是对不想自己折腾配置的人来说。不过在用到一个更大的项目之前,我还是想看到更多真实案例。 热门产品Darren2026-08-03原文 打开互动版
---
嘿,Product Hunt!👋
我构建 AgentSky 是因为生产级的 AI 智能体所需的基础设施远超大多数人的预期。这个想法源于构建 tycoon.us 的过程,我们遇到了同样的挑战:测试多种 harness/LLM 组合(更别提 harness 版本更新了 😱)、快速且安全的沙箱、扛过重启,以及把它们连接到用户期望的每个渠道。
AgentSky 帮你把这些底层工作都做了。选一个 harness — Claude Code、Codex、Hermes 或 OpenClaw — 选一个模型,一键启动,或者用一条 CLI 命令。你的智能体会常驻运行在独立的云沙箱里,拥有完整历史记录、产物持久化、状态快照、备份和恢复。
你的用户在哪里,它就能在哪里触达 — WhatsApp、iMessage、Telegram、Slack、网页、CLI,或者我们的开发者 API。同样的协议,同样的记忆,每个 harness,每个渠道。
AgentSky 已经在生产环境中久经考验,支撑着 tycoon.us,处理了超过 10K+ 个智能体会话。
停放一个智能体是免费的 — 只有它在实际工作时你才付费。
非常期待你的反馈,特别是你接下来希望支持哪些 runtime 和渠道!
如果停放免费,只有智能体在工作时才付费,那么一个悄悄停止工作的智能体就不会让我花钱。这很美好,直到一个死掉的智能体和一个便宜的月份在账单上看起来一模一样。对于长周期任务来说,账单历来是告诉人们出了问题的东西,而这种定价方式故意去掉了这个信号。
从外部看,一个暂停的智能体、一个完成的智能体,和一个崩溃后从未恢复的智能体,表现都一样:没有活动,没有费用,渠道里也没有任何动静。那么,操作者怎么知道他们面对的是哪一种?我想要的是,长周期智能体在启动时就声明一个预期的节奏,这样平台就能说“这个早该醒来了但还没醒”,而不是让沉默去代表读者以为的任何意思。
第二个问题,它来自快照与消息渠道的结合。如果你对状态做快照然后恢复,当快照是在某个外部副作用执行到一半时拍摄的,会发生什么?一个被恢复到刚发送 WhatsApp 消息之前的智能体,无法判断那条消息到底发出去没有。重发和跳过都不对,而另一端的人只能看到其中一种情况——他们收到两次。
副作用会被记录在快照之外吗?这样恢复后的智能体就知道哪些事情已经发出去了?
好奇你们如何处理沙箱之间的安全?智能体这样常驻运行的话。
你们花了多久才让重启在不同 harness 之间可靠地工作?