Coder：把 AI 编程代理放进控制平面，工作区不再持有 API 密钥

它解决的是密钥散落和闲置资源两个问题

开发环境平台很多，但 Coder 把两件事绑在一起卖：一是用 Terraform 定义云开发环境，二是让 AI 编码代理跑在你的基础设施上。前者解决的是环境一致性和成本，后者解决的是 LLM 凭据安全。README 里明确写着 "no API keys in workspaces"，即工作区里没有 API 密钥。传统的做法是在每个开发容器里配置模型供应商的密钥，代理在容器内直接调用模型。Coder 把代理的循环移到控制平面，工作区只是一个被管理的执行环境。适合的对象很明确：已经用云 VM、Kubernetes Pod 或 Docker 容器跑开发环境，并且对凭据泄露有真实担忧的团队。个人开发者未必需要这套复杂度。

控制平面代理循环，工作区只是被管对象

Coder Agents 的架构核心是代理循环不在工作区里跑。README 的原话是 "whose loop executes in the control plane on your infrastructure"。这意味着你部署的 Coder 服务器（控制平面）持有模型 API 密钥，代理的决策循环、模型调用、工具调用都在这里执行。工作区通过 Wireguard 隧道与控制平面通信，隧道是 Coder 连接工作区的默认方式。用户身份在每次代理动作上都保留，README 说 "user identity on every action"，这为审计提供了基础。模型选择是开放的：Anthropic、OpenAI、Google、Bedrock、自托管都行。这种设计的直接好处是，即使工作区被攻破，攻击者也拿不到 LLM 凭据，因为凭据根本不在那里。代价是控制平面成为新的高价值目标，它一旦失守，所有模型的访问权都暴露。文档没有详细说明控制平面的隔离措施，这是采用前需要自己查证的点。

从安装脚本到生产部署，两条路径差异很大

快速体验很简单。README 给出的命令是：

curl -L https://coder.com/install.sh | sh

然后启动服务器：

coder server

默认监听 localhost:3000，打开浏览器创建初始用户，选一个 Docker 模板就能创建第一个工作区。这个模式使用内置数据库，并且自动分配一个 *.try.coder.app 的访问 URL，仅用于评估。生产部署则是另一套要求：

coder server --postgres-url <url> --access-url <url>

需要 PostgreSQL 13 或更高版本，以及一个外网可访问的 URL。README 指向了 validated architectures 文档，说明生产环境的规模和基础设施选择是有官方建议的。CLI 的全部参数和对应环境变量通过 coder --help 查看。注意安装脚本只覆盖 Linux 和 macOS，Windows 用户需要从 GitHub Releases 下载二进制或安装器。这个差异意味着，从评估到生产不是改一个 flag 的事，数据库和网络拓扑都要重新设计。

AI Gateway 是控制平面的一部分，不只是代理

Coder Agents 不是孤立功能，它和 AI Gateway 配套。README 把 AI Gateway 描述为 "Centralize authentication, auditing, and cost controls for AI tooling"。也就是说，所有 AI 工具（不只是 Coder 自己的代理）的认证、审计和成本控制都集中在一个网关里。这解释了为什么代理循环要放在控制平面：只有所有模型调用都经过网关，才能做统一的成本追踪和审计日志。模型治理也是集中式的，README 提到 "Centralized model governance"。这意味着管理员可以决定哪些模型可用、哪些用户能用、花费多少。对需要合规审计的团队，这个设计比每台机器各自配置密钥要干净得多。但要注意，这个网关是 Coder 平台的一部分，不是独立产品，你无法单独把它接到现有的开发流程里。

模板和注册中心，生态的入口

工作区由 Terraform 定义，这是 Coder 与其他开发环境平台最大的不同。你不用学一套新的配置语言，直接用 Terraform 描述 EC2、Kubernetes Pod 或 Docker 容器。Coder Registry 提供官方模板、模块和集成，搜索 tag 为 agent 的模块可以找到 Claude Code、Codex、OpenCode 等代理的现成配置。还有 coderd Terraform Provider，可以用代码声明式地管理 Coder 部署本身。这意味着整个平台从工作区到平台配置都能纳入 GitOps 流程。Dev Containers 支持让你用 devcontainer.json 在 Docker、Kubernetes 和 OpenShift 上构建环境。生态是完整的，但依赖 Terraform 技能。如果团队没人写过 Terraform，上手成本会比用纯 UI 的平台高。

限制：控制平面是单点，AGPL 是分水岭

最明显的限制是控制平面成为新的信任根。所有模型凭据、代理循环、审计日志都在那里，它一旦宕机，所有 AI 代理都停摆。工作区本身可以通过 Wireguard 隧道继续存在，但代理功能完全依赖控制平面。另一个限制是生产部署需要 PostgreSQL 13+，这排除了纯 SQLite 的小规模场景。内置数据库只适合评估，README 明确说生产要加外部数据库。许可证是 AGPL-3.0，这意味着如果你修改了 Coder 的源代码并以网络服务形式提供，必须开源你的修改。对于内部使用，AGPL 通常没有强制开源的压力，但如果你计划把 Coder 作为产品的一部分提供给客户，需要仔细评估。文档没有提到企业版或 Premium 的具体功能清单，只提到付费版面向大型团队，具体差异要看定价页面。

替代方案：Gitpod 和 Eclipse Che 的思路不同

Gitpod 也是云开发环境平台，但它默认是托管服务，自托管版本是后来的事。Gitpod 的工作区基于容器，也支持 IaC，但它的核心抽象是预构建（prebuilds），用来加速环境启动。Coder 的核心抽象是 Terraform 模板，你可以定义任意基础设施，不限于容器。Eclipse Che 是另一个自托管选项，它基于 Kubernetes，工作区是 Pod，但它的配置模型是 DevWorkspace 规范，不是 Terraform。如果你已经重度使用 Kubernetes，Che 可能更贴合。但 Che 没有 Coder 那样的 AI 代理控制平面设计，它的 AI 集成通常是外部工具。Coder 的差异点在于把 AI 代理当成一等公民，并且把凭据安全放在架构中心。选择哪个，取决于你更信任 Terraform 还是 Kubernetes 原生的方式。

维护成本：升级节奏快，社区依赖 Discord

从发布记录看，v2.36.3 和 v2.35.6 在同一天发布，v2.36.1 在五天前，说明维护活跃，补丁迭代快。这意味着你需要跟上版本节奏，否则会积累技术债。支持渠道是 GitHub Issues、Discord 和 GitHub Discussions，没有邮件列表。付费的 Premium 才包含专属支持，社区用户只能靠公开渠道。集成方面，官方提供了 VS Code 扩展、JetBrains 插件、GitHub Actions 等，但这些都是额外组件，需要单独维护。还有 Kubernetes Log Stream 这类辅助工具，把 Pod 事件流到 Coder 启动日志，属于锦上添花。整体上，Coder 不是装完就完事的软件，它需要你持续关注版本更新和基础设施变化。如果你的团队没有 DevOps 人力，维护成本可能会超过它节省的成本。

编辑结论

适合已经用 Terraform 管理基础设施、并且不想把模型 API 密钥散落到每个开发容器的团队。不适合只想快速搭一个远程 IDE 的个人用户，也不适合没有 PostgreSQL 运维经验的小组，因为生产部署要求外部数据库和访问 URL。采用前先验证三件事：你的模型供应商是否在官方支持的列表里（Anthropic、OpenAI、Google、Bedrock、自托管），代理循环在控制平面的资源消耗是否符合你的预算，以及 AGPL-3.0 对你内部工具链的再分发方式是否可接受。Coder Agents 把安全边界画在控制平面，这是它与多数在容器内跑代理的方案最本质的区别，也是你决策的锚点。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes