加载失败
Coasts 是一个面向 agents 的“containerized host”工具，目标是让每个 worktree 或任务都能有自己的运行环境，同时尽量保留现有的 Docker 开发方式。它依赖 Docker-in-Docker（DinD，容器里再跑 Docker daemon），这样容器内部还能继续使用 docker-compose、镜像缓存和构建层。评论里围绕的背景是：agent 开发越来越需要同时解决代码执行、数据库隔离、外部 API 认证和 secrets 注入，但又不想把本地开发流程弄得过于复杂。大家还把它和 Cursor（AI 代码编辑器）、Devin（AI 软件工程 agent）以及 macOS 上的 Docker 方案放在一起比较，核心在于本地并行开发、状态共享/隔离和运行时安全边界。
不少评论把 Coasts 看成是对原生 Docker 的一层编排抽象，而不是单纯的容器管理器。它的卖点包括动态端口需要额外 control plane、保留现有 docker-compose 结构、不用为并行 worktree 改造本地环境，以及按 service 选择 none/hot/restart/rebuild 等不同切换策略。评论里还提到共享 volume、内置 UI、secrets 管理和 bind mount 热切换优化，这些都在减少手工写多个 docker-compose 的成本。也有人把它放进与 Cursor、Devin 等远程 agent 工作流的对比里，认为它更适合继续把开发留在本机。
最受关注的技术点是它如何在运行中的 DinD 容器里热切换 worktree。有人指出它利用 umount -l、mount --bind 和 rshared 做到了不重建整套环境就替换代码挂载，这比常见的全量重启更巧。讨论中也追问了多 agent 共享数据库时的状态漂移问题，作者的回答是可以用多个 Coasts 实例分别走隔离数据库或共享数据库，具体规则交给上层 orchestration 和项目里的说明文件来决定。作者还给出一个实际效果：在一个 100 万行以上的仓库里，切换时间从约 2 分钟降到了 8 秒。
评论者担心的另一大块是 agent 的认证和外部 API 调用。有人建议把 per-key rate limiting 和 usage tracking 放在 edge，而不是塞进容器内部，因为 agent 经常要代表用户调用外部服务。作者则说明他们曾尝试把 host 里的 OAuth secrets 注入容器，但由于运行时与 token 签发环境不一致，Anthropic 会很快让 OAuth token 失效；因此更现实的是让 CLI/TUI 走 usage key，浏览器类能力还得额外带上 browser runtime。整体上，Coasts 被明确定位为不是 sandboxing 工具，而是要和其他 host-side sandbox 方案配合。
关于架构选择，作者解释为什么用 DinD 而不是只靠 unshare/nsenter 这类 mount namespace 技术。核心原因是他们想在容器内保留完整 Docker API，这样 image cache、network namespace 和 build layer 都能正常工作，而不用依赖宿主 daemon 或重新实现 Docker。代价是每个 containerized host 约有 200MB 开销，所以他们在考虑 Podman runtime 来降耗，同时提供 shared-services 让 postgres、redis 这类服务只在宿主上跑一次。macOS 上则不是 native containers，而是通过 Docker Desktop、Orb Stack 或 Colima 运行，但作者表示实际延迟并不明显。
Docker-in-Docker (DinD): 在容器内部再运行 Docker daemon 的做法，方便 Coasts 在每个容器化宿主机里继续使用 docker-compose、构建层和网络功能。
worktree: Git 的并行工作树，允许同一仓库同时存在多个分支/状态，适合多 agent 或多任务并行开发。
docker-compose: Docker 的多服务编排配置/命令，用来定义一组容器、端口、volume 和网络；Coasts 尽量让现有 compose 直接复用。
rshared: Linux 的挂载传播模式，配合 mount --bind 和 mount propagation 可以在运行中的容器里热切换挂载目标。
shared-services: 把 postgres、redis 等共享服务放在宿主 Docker daemon 上只运行一次，再供多个 Coasts 实例复用的模式。