2026 年 8 月 18 日,YC S26 创业公司 machine0 在 Hacker News 发布《Launch HN: machine0 (YC S26) – Persistent CPU and GPU VMs from the CLI》,83 分上首页讨论 15 条。machine0 给 Agent 提供一个 always-on 的云端 VM——`machine0 new mybox` 一行命令创建 SSH-ready 持久 VM,1 vCPU / 1 GB 起 0.013 美元/小时,封顶 60 vCPU / 240 GB RAM,可挂 H100/H200 GPU,99.99% uptime,VM 永远在线直到你主动 suspend 或 destroy。同月 13 天,Show HN 上线 Decispher,5 分首页关注,主打"persistent engineering context and memory for coding agents"——把企业工程团队已有的 PR、Issue、Slack、ownership、架构决策沉淀成一个 Context Engine + Memory Plane,让 Coding Agent 不再每次重新发现组织级上下文。两件事合起来,正好回答一个企业 Agent 部署正在面对的核心问题——长任务状态保持到底应该靠"基础设施层"还是"上下文层",以及企业级 Agent 平台应该怎么设计才能真正支撑跨天、跨周、跨月的工作流。
一、Agent 工作负载从短暂到 always-on
machine0 创始人 Barnaby 在 HN 帖里直接给出工作负载演化轨迹——Agent 任务从短暂的 demo 时代过渡到 always-on 的生产时代。一个 coding agent 跑一个复杂 feature 要 6 到 8 小时,Agent orchestrating 的训练和 RL 任务要几天,OpenClaw 和 Hermes 这类 always-on Agent 跑 24/7。工作负载一旦进入 always-on 阶段,原来的 ephemeral 模型就扛不住了。
原来的 ephemeral 模型是什么?E2B 这种 sandbox-as-a-service 给一个一次性的 Ubuntu box,跑 30 分钟到 1 小时就被销毁,VM 状态完全丢失,每次新会话要重新装软件、配置环境、重新加载上下文。这种模型适合 demo 和短任务,但不适合长任务,原因是四个具体痛点。
第一个痛点是资源。几个 Agent 同时跑在一个大代码库上,RAM 和 CPU 会饱和;Agent 训练和 RL 需要 GPU,普通开发者本地根本没有。第二个痛点是安全。在本机跑 `--yolo` 模式的 Agent,一次 prompt injection 就能把本机所有凭据外泄出去——HN 评论里多位开发者复述过类似经历。第三个痛点是可用性。关上笔记本 Agent 就死了,跑到一半的任务直接丢失。第四个痛点是隔离。本机环境里 Agent 和用户的最小权限边界很模糊,Agent 能看到用户的 home 目录、SSH 密钥、~/.aws/credentials,这种"最小但其实很大"的权限面是企业 IT 不能接受的。
machine0 的解法是"给每个 Agent 一台自己的电脑"——`machine0 new mybox` 创建的 VM 是 SSH-ready,带 static IP 和 HTTPS endpoint,只要不主动 suspend 或 destroy 就永远在线,99.99% VM-level uptime。bill by the minute,1 vCPU/1 GB 起 0.013 美元/小时,封顶 60 vCPU / 240 GB RAM,可以挂 H100/H200/L40S/MI300X/RTX 4000-6000 Ada,五种 region 同步同价(US East/US West/UK/EU/Asia)。
二、machine0 的工程化细节
machine0 不只是一个简单的 VPS 包装,它针对 Agent 工作负载做了几件针对性的工程化设计。
第一,Agent 可以自服务。machine0 同时提供 CLI 和 MCP server,任何 MCP 兼容的 Agent(Claude Code、Codex、OpenCode)都能直接驱动自己的 fleet——拉一个新 box 跑 build,snapshot,tear down,全程不需要人在回路。这件事的工程价值在于把"基础设施编排"提升为 Agent 可以直接调用的能力,而不是开发者要先 SSH 进去手敲命令。
第二,Suspend + Snapshot + Resume 是核心能力。VM 可以 freeze state、停止计费、稍后 restore;可以从任何 VM 创建 golden image 然后克隆出一整个 fleet。这套机制对长任务至关重要——Agent 跑几天任务,中间要暂停(周末、节假日、开发者休假)、要 fork(并行尝试多种方案)、要回滚(方案失败回到 checkpoint),全部需要 VM 层支持。
第三,Block Storage 做持久化。machine0 提供从 10 GB 到 16 TB 的持久卷,用 intuitive grammar(`--yolo`)挂载到 VM 上。持久卷和 VM 解耦,VM suspend 不影响数据,VM destroy 可以保留 volume 用于审计或迁移。
第四,Profiles 把凭证和 MCP 注入到 VM。Profile 是 credentials、MCP connections、prompts、env vars 的 bundle,在 VM 创建时注入,每个 Agent 拿到刚好它需要的 capability,不多给。这条设计直接对应 OpenAI 内部 Coding Agent 监控实践里反复强调的"分级授权"——Agent 拿到的能力必须精确等于任务所需,不预留扩展空间。
第五,NixOS flakes + Ansible 双重支持 reproducible builds。NixOS 是 Nix 包管理器为基础的操作系统,本身就把"声明式构建"做到内核层;Ubuntu + Ansible 是更主流的栈。两种选择让不同技术栈的团队都能直接落地。
machine0 给出的具体使用场景有三类。第一类是 Agent fleet——pilot agent 拆 work,sub-agent 在各自 VM 上执行,workers 实现并开 PR,一个客户跑几百个 VM 同时启动和销毁。第二类是 Model optimization 和 RL 环境——ML 团队用 machine0 跑 agent-orchestrated RL,一个客户跑 60 vCPU 机器保持几天,另一个客户把 H100 suspend 起来,晚上让 Agent 跑 inference speed optimization。第三类是产品基础设施——一个客户用 machine0 跑 webserver,VM 带 static IP 和 HTTPS endpoint,五个 region 同步同价。
三、Decispher 的另一面:持久 context 而不是持久 VM
如果说 machine0 解决的是"Agent 跑的 VM 不消失",Decispher 解决的则是"Agent 知道的 context 不消失"。Decispher 创始人 Ali 在 HN 帖里直接给出问题定义——coding agent 重复发现已经存在于组织内部的 context。
具体场景是这样:一个开发者写一段功能,需要把已有 PR、相关 Jira ticket、Slack 讨论、ownership 边界、架构决策这些碎片信息拼起来,才能形成完整的实现认知。人类开发者用经验在脑子里把这些拼好,coding agent 每次从 prompt 和 repo 开始,要么花大量 token 搜索、要么完全错过关键信息。这种重复发现不只是浪费 token,更危险的是会基于不完整的 context 做出错误决策。
Decispher 的解法是三层架构。Context Engine 把分散在各系统的工程 context 串起来,组合成"context units"——一个组件的 context 可能包含历史 PR、相关 issue、架构决策、ownership 信息、实现历史。Branch Story 把 AI coding session 的执行过程记录下来,转成 PR 上的结构化 handoff(Prompt → plan → actions → result),让 review 的人能直接看到 Agent 是怎么从指令走到代码的。
Memory Plane 在用户、团队、项目三个层级存持久 context。这包括工作偏好和工程约定,以及团队可以创建的 reusable memory sets——例如 frontend、payments-backend 或者某个 project-specific 的 memory set,根据任务类型注入相关 memory。
Decispher 在 LongMemEval 上披露的实测数据是 89% accuracy on oracle split 用 GPT-4.1-mini 做 extractor 和 reader,81% on LongMemEval-S 数据集(89% with frontier models),38 倍中位 token 减少。换句话说,长任务 memory 的存储和检索精度已经接近上限,核心收益是 token 效率——同样的工程任务,带 Decispher 比不带少用 38 倍 token。
Worker Agent 是 Decispher 的自主执行层,从 Jira、Slack 等源头接任务,检索相关 context 和 ownership 信息,context 不足时主动问人而不靠猜,人的回答又变成下次任务的 context。Context Engine、Memory Plane、Worker Agent 三层可以独立使用,接入方式是 npx decispher init 和 npx decispher link 两个 CLI 命令。
四、把 machine0 和 Decispher 合起来读
把这两件事合起来看,会发现企业 Agent 长任务状态保持其实有两个独立的维度,必须分别解决。
第一个维度是 infrastructure persistence——Agent 跑的 VM 不消失。machine0 把这件事做到 always-on + 99.99% uptime + suspend/resume/snapshot + 持久卷 + Profile 注入。企业落地时,这一层应该由内部基础设施团队按 machine0 的设计模式自建——专用 Agent VM pool,带 CLI + MCP 双向接口,VM 状态可 snapshot、可 fork、可回滚。
第二个维度是 context persistence——Agent 知道的组织信息不丢失。Decispher 把这件事做到 Context Engine + Memory Plane + Branch Story + LongMemEval 89% accuracy + 38x token reduction。企业落地时,这一层应该由内部数据/AI 团队按 Decispher 的模式自建——把工程组织已有的 PR、Issue、Slack、ownership、ADR 这些碎片信息聚合,形成可检索、可注入的 context 层。
两个维度都做对了,Agent 才能真正承担跨天、跨周、跨月的工作流——机器不会因为周末关机而停,知识不会因为切换任务而丢。这两件事的工程价值放在 Agent 真正落地的评估里,远比任何 benchmark 分数更重要。
五、企业 Agent 长任务状态保持的具体设计
把这两件事映射回企业落地,会得到一份 Agent 长任务状态保持的具体设计 checklist。
第一条,VM 层必须是持久化的,不是 ephemeral sandbox。E2B 这种 sandbox-as-a-service 适合 demo 和短任务,但不适合生产 Agent 工作负载。生产 Agent VM 应该至少支持 always-on + suspend/resume + snapshot + 持久卷,99.9% uptime 是底线。machine0 给出的样板是 99.99%,企业自建时应该以这个数字为基线。
第二条,VM 必须支持 Profile 注入。任何 Agent 拿到的凭证和能力必须精确等于任务所需,不允许 Agent 自助扩展权限。machine0 把 profiles 设计成 credential + MCP + prompt + env var 的 bundle,创建 VM 时一次性注入,VM 创建后不允许 agent 自助追加。这一点直接对应 OpenAI 内部 Coding Agent 监控实践里"分级授权"的核心要求。
第三条,VM 必须支持 Agent 自服务,但要保留可观测性。Agent 能自己拉 VM、snapshot、tear down,但每一次操作必须写独立审计日志。这条原则在 machine0 的设计里隐含在 MCP server 接口里,但企业落地时应该把审计独立出来,不允许 Agent 操作和审计流共享同一个 trust boundary。
第四条,Context 层必须有明确的 memory 层级结构。Decispher 给出 user / team / project 三层结构,每层可以独立配置、注入、回收。企业落地时,应该照搬这个三层结构,user 层存个人偏好、team 层存团队约定、project 层存项目特定的 context,绝不允许把三层揉成一个大 context pool。
第五条,Context 层必须支持 proactive questioning。Agent 遇到 context 不足时,应该主动问人而不是猜,人的回答要成为后续可检索的 context。Decispher 的 Worker Agent 设计体现了这条原则,企业 Agent 平台设计时必须把"主动询问 + 答案持久化"作为一等能力,而不是任由 Agent 凭概率猜答案。
第六条,Context 层必须有可量化的质量评估。Decispher 用 LongMemEval 做 oracle split 评估,89% accuracy + 38x token reduction 是基线。企业落地时,必须定期用类似 LongMemEval 的方法学评估 context 检索的准确率和 token 效率,而不是凭印象判断"Agent 看起来挺聪明"。
六、下一步:Agent 平台的两层标准化
把 machine0 和 Decispher 放在一起看,会发现 Agent 平台正在从"协议标准化"过渡到"基础设施 + 上下文双层标准化"。早期 MCP/A2A 等协议解决了 Agent 与工具、Agent 与 Agent 的通信问题,接下来两年的重心会是把"Agent 跑在哪里"和"Agent 知道什么"这两个更基础的问题标准化。
machine0 是基础设施层的样板——CLI + MCP 接口 + 99.99% uptime + suspend/resume/snapshot + Profile 注入。Decispher 是上下文层的样板——Context Engine + Memory Plane + Branch Story + LongMemEval benchmark + proactive questioning。这两件事的样板都会在接下来一年内被多家企业复刻和衍生,形成类似 npm/PyPI 那样的成熟基础设施生态。
对企业 IT 来说,这两个维度的标准化意味着评估 Agent 平台时必须同时看两层——任何只解决"Agent 能调工具"但 VM 是 ephemeral、context 每次重发现的产品,在生产环境都无法承担长任务;任何只解决"VM 一直跑"但 Agent 不知道组织 context 的产品,在企业环境都无法产生真实价值。两层都要做扎实,Agent 平台才能真正成为企业数字化转型的核心基础设施。
回到一开始的问题——machine0 和 Decispher 合起来,把"Agent 长任务状态保持不是一个问题而是两个独立问题"这件事第一次用产品形态清楚地呈现出来。剩下的是企业 IT 在落地时把这两个维度都做对——基础设施层建专用 Agent VM pool,上下文层建 Context Engine + Memory Plane。两层都到位,Agent 才能从"demo 玩具"变成"生产级基础设施"。
