Launch HN: Terminal Use (YC W26) – 终端使用 (YC W26) - 文件系统驱动型 Agent 的 Vercel
1 分•作者: filipbalucha•大约 2 小时前
大家好，Hacker News！我们是来自 Terminal Use 的 Filip、Stavros 和 Vivek（<a href="https://www.terminaluse.com/">https://www.terminaluse.com/</a>）。我们构建 Terminal Use 的目的是为了更容易地部署在沙盒环境中运行并需要文件系统才能工作的代理。这包括编码代理、研究代理、文档处理代理以及读写文件的内部工具。<p>这里有一个演示：<a href="https://www.youtube.com/watch?v=ttMl96l9xPA" rel="nofollow">https://www.youtube.com/watch?v=ttMl96l9xPA</a>。<p>我们在托管代理时遇到的最大痛点是，你需要将多个部分拼凑在一起：打包你的代理、在沙盒中运行它、将消息流回用户、跨回合保持状态以及管理文件与代理工作区的交互。<p>我们想要类似 Replicate 的 Cog 的东西，但用于代理：一种从代码库打包代理代码并通过干净的 API/SDK 提供服务的简单方法。我们希望提供一个与你的代理通信的协议，但不对代理逻辑或框架本身进行约束。<p>在 Terminal Use 上，你使用 config.yaml 和 Dockerfile 从代码库打包你的代理，然后使用我们的 CLI 部署它。你定义了三个端点（on_create、on_event 和 on_cancel）的逻辑，这些端点跟踪任务（对话）的生命周期。config.yaml 包含有关资源、构建上下文等的详细信息。<p>开箱即用，我们支持 Claude Agent SDK 和 Codex SDK 代理。通过支持，我们的意思是，我们有一个适配器，可以将 SDK 消息类型转换为我们自己的类型。如果你想使用你自己的自定义框架，你可以使用我们的类型（与 Vercel AI SDK v6 兼容）转换和发送消息。对于前端，我们有一个 Vercel AI SDK 提供程序，它允许你将你的代理与 Vercel 的 AI SDK 一起使用，并有一个消息模块，这样你就不必自己管理流和持久化了。<p>我们认为最不同的部分是存储。<p>我们将文件系统视为一级原生组件，与任务的生命周期分开。这意味着你可以跨回合保留工作区，在不同的代理之间共享它，或者独立于沙盒是否处于活动状态来上传/下载文件。此外，我们的文件系统 SDK 提供了预签名 URL，这使得你的用户可以轻松直接上传和下载文件，这意味着你不需要通过你的后端代理文件传输。<p>由于你的代理逻辑和文件系统存储是解耦的，这使得迭代你的代理变得很容易，而无需担心沙盒中的文件：如果你发布了一个错误，你可以部署并将所有任务自动迁移到新的部署。如果你进行了重大更改，你可以指定现有任务保留在现有版本上，并且只有新任务使用新版本。<p>我们还增加了对多文件系统挂载的支持，具有可配置的挂载路径和读/写模式，因此存储保持耐用和可重用，而挂载布局保持任务特定。<p>在部署方面，我们受到了现代开发者平台的启发：简单的 CLI 部署、预览/生产环境、基于 git 的环境目标、日志和回滚。构建、部署和管理代理所需的所有配置都存储在 config.yaml 文件中，这使得在 CI/CD 管道中构建和部署你的代理变得很容易。<p>最后，我们明确地为你的 CLI 编码代理设计了我们的平台，以帮助你构建、测试和迭代你的代理。使用我们的 CLI，你的编码代理可以向你部署的代理发送消息，并下载文件系统内容，以帮助你了解你的代理的输出。我们测试代理的常用方法是，我们制作带有我们希望测试的用户场景的 Markdown 文件，然后要求 Claude Code 模拟我们的用户并与我们部署的代理聊天。<p>我们还没有的是：与通用沙盒提供商的完全对等。例如，预览 URL 和较低级别的 sandbox.exec(...) 风格的 API 仍在开发中。<p>我们很高兴在下面的评论中听到任何想法、见解、问题和担忧！
查看原文
Hello Hacker News! We're Filip, Stavros, and Vivek from Terminal Use (<a href="https://www.terminaluse.com/">https://www.terminaluse.com/</a>). We built Terminal Use to make it easier to deploy agents that work in a sandboxed environment and need filesystems to do work. This includes coding agents, research agents, document processing agents, and internal tools that read and write files.<p>Here's a demo: <a href="https://www.youtube.com/watch?v=ttMl96l9xPA" rel="nofollow">https://www.youtube.com/watch?v=ttMl96l9xPA</a>.<p>Our biggest pain point with hosting agents was that you'd need to stitch together multiple pieces: packaging your agent, running it in a sandbox, streaming messages back to users, persisting state across turns, and managing getting files to and from the agent workspace.<p>We wanted something like Cog from Replicate, but for agents: a simple way to package agent code from a repo and serve it behind a clean API/SDK. We wanted to provide a protocol to communicate with your agent, but not constraint the agent logic or harness itself.<p>On Terminal Use, you package your agent from a repo with a config.yaml and Dockerfile, then deploy it with our CLI. You define the logic of three endpoints (on_create, on_event, and on_cancel) which track the lifecycle of a task (conversation). The config.yaml contains details about resources, build context, etc.<p>Out of the box, we support Claude Agent SDK and Codex SDK agents. By support, we mean that we have an adapter that converts from the SDK message types to ours. If you'd like to use your own custom harness, you can convert and send messages with our types (Vercel AI SDK v6 compatible). For the frontend, we have a Vercel AI SDK provider that lets you use your agent with Vercel's AI SDK, and have a messages module so that you don't have to manage streaming and persistence yourself.<p>The part we think is most different is storage.<p>We treat filesystems as first-class primitives, separate from the lifecycle of a task. That means you can persist a workspace across turns, share it between different agents, or upload / download files independent of the sandbox being active. Further, our filesystem SDK provides presigned urls which makes it easy for your users to directly upload and download files which means that you don't need to proxy file transfer through your backend.<p>Since your agent logic and filesystem storage are decoupled, this makes it easy to iterate on your agents without worrying about the files in the sandbox: if you ship a bug, you can deploy and auto-migrate all your tasks to the new deployment. If you make a breaking change, you can specify that existing tasks stay on the existing version, and only new tasks use the new version.<p>We're also adding support for multi-filesystem mounts with configurable mount paths and read/write modes, so storage stays durable and reusable while mount layout stays task-specific.<p>On the deployment side, we've been influenced by modern developer platforms: simple CLI deployments, preview/production environments, git-based environment targeting, logs, and rollback. All the configuration you need to build, deploy & manage resources for your agent is stored in the config.yaml file which makes it easy to build & deploy your agent in CI/CD pipelines.<p>Finally, we've explicitly designed our platform for your CLI coding agents to help you build, test, & iterate with your agents. With our CLI, your coding agents can send messages to your deployed agents, and download filesystem contents to help you understand your agent's output. A common way we test our agents is that we make markdown files with user scenarios we'd like to test, and then ask Claude Code to impersonate our users and chat with our deployed agent.<p>What we do not have yet: full parity with general-purpose sandbox providers. For example, preview URLs and lower-level sandbox.exec(...) style APIs are still on the roadmap.<p>We're excited to hear any thoughts, insights, questions, and concerns in the comments below!