Coder：让 AI Agent 在你的基础设施上写代码，API key 永远不进工作区

Coder：让 AI Agent 在你的基础设施上写代码，API key 永远不进工作区

场景：企业想用 AI Agent 写代码，但安全团队说"不行"

一家大型企业的 CTO 想让开发团队用 Claude Code 和 Codex 提效。安全团队立刻反对："Agent 需要调用 LLM API，API key 放在开发者的工作区里，一旦工作区被入侵，key 就泄露了。而且我们怎么审计 Agent 做了什么？怎么控制成本？"

这个对话在过去一年里在无数企业里发生过。矛盾的核心是：AI Agent 需要基础设施访问权限和 LLM API key 才能工作，但企业不想把这些凭证散落到成百上千个开发工作区里。

Coder 给出了一个答案：把 Agent 的执行循环放在控制面（control plane），而不是工作区（workspace）里。API key 留在控制面，工作区里没有任何凭证。Agent 通过安全隧道操作工作区，但凭证永远不落地。

204 颗星一天涨上来，不如 BrowserSkill 的 1350 颗那么耀眼，但 Coder 解决的是企业级问题——买单的不是个人开发者，而是 CIO。

控制面 vs 工作区：Agent 架构的关键分界

要理解 Coder 的设计，先要理解"控制面"和"工作区"的区别：

• 工作区（Workspace）：开发者写代码的地方。可能是一个 EC2 实例、一个 Kubernetes Pod、一个 Docker 容器。工作区里有代码、依赖、IDE，但不应该有 LLM API key。
• 控制面（Control Plane）：管理所有工作区的中心服务。负责创建/销毁工作区、路由请求、管理凭证。API key 放在这里。

传统做法是：Agent 跑在工作区里，直接调 LLM API。这意味着每个工作区都需要 API key。一百个开发者 = 一百份 API key 散落在各处。

Coder 的做法是：Agent 的执行循环跑在控制面。控制面持有 API key，调用 LLM，然后把 Agent 的决策（"打开文件 X"、"运行命令 Y"）通过 Wireguard 隧道发送到工作区执行。工作区只接收命令，不持有凭证。

这个架构的好处是：

1. 凭证不落地：API key 永远在控制面，工作区里 env | grep API_KEY 什么都找不到。 2. 集中审计：所有 Agent 操作都经过控制面，可以统一记录和审计。 3. 成本追踪：控制面知道哪个 Agent 调了多少 token，可以按团队/项目分账。 4. 模型治理：控制面可以限制哪些团队用哪些模型，防止越权。

Terraform 定义工作区：基础设施即代码

Coder 的另一个核心设计是：工作区用 Terraform 定义。这意味着工作区本身是"基础设施即代码"的产物。

# 伪代码示例
resource "coder_workspace" "dev" {
  agent = {
    os   = "linux"
    arch = "amd64"
  }
}

resource "aws_instance" "dev" {
  ami           = "ami-123456"
  instance_type = "t3.large"
}

开发者选择一个模板（Terraform 定义），Coder 自动 provision 对应的基础设施。这带来几个好处：

• 一致性：所有开发者的工作区是同一个模板，不会出现"在我机器上能跑"的问题。
• 可审计：工作区定义是代码，可以 review、版本控制、回滚。
• 多云：Terraform 支持 AWS、GCP、Azure、Docker、Kubernetes，不锁定云厂商。
• 自动关停：空闲工作区自动 shutdown，省钱。

AI Gateway：LLM 调用的"API 网关"

Coder 还有一个 AI Gateway 组件，本质上是 LLM 调用的反向代理：

• 认证集中：所有 LLM 调用通过 AI Gateway，开发者不需要自己的 API key。
• 审计日志：每次调用记录谁、什么时候、调了什么模型、花了多少 token。
• 成本控制：按团队/项目设置预算上限，超了就拒绝。
• 模型路由：根据任务类型路由到不同模型（简单任务用便宜模型，复杂任务用贵模型）。

这和传统 API Gateway 的思路一样，只不过对象从"HTTP API"变成了"LLM API"。企业用 API Gateway 管理微服务调用已经十几年了，用同样的模式管理 LLM 调用是自然延伸。

Coder Agent：循环在控制面，操作在工作区

Coder Agent 的架构值得细说。传统 AI coding agent（比如 Aider、Cursor、Claude Code 本地版）的循环是：

while not done:
    response = llm.call(messages, tools)  # 在工作区里调 LLM
    action = parse(response)
    result = execute(action)               # 在工作区里执行
    messages.append(result)

问题：llm.call 需要 API key，这个 key 必须在工作区里。

Coder Agent 的循环是：

# 控制面
while not done:
    response = llm.call(messages, tools)  # 在控制面调 LLM
    action = parse(response)
    result = send_to_workspace(action)     # 通过隧道发送到工作区
    messages.append(result)

# 工作区
on receive(action):
    result = execute(action)               # 在工作区执行
    send_to_control_plane(result)          # 返回结果

API key 只在控制面的 llm.call 里出现，工作区只接收 action 和返回 result。这个分离是 Coder 安全模型的核心。

和其他方案的对比

Coder 的差异化在于：它不只是 cloud development environment，而是"AI Agent + cloud development environment"。其他方案解决"开发者在哪里写代码"，Coder 解决"开发者和 AI Agent 如何在企业基础设施上安全协作"。

适用场景与局限

Coder 最适合的场景：

• 大型企业：100+ 开发者，需要统一治理 AI Agent 使用。
• 合规敏感行业：金融、医疗、政府，API key 不能散落在终端。
• 多云环境：需要在不同云上统一管理工作区。
• AI Agent 大规模部署：需要给每个开发者配一个 AI Agent，但要集中管控。

局限：

• 自托管复杂度：需要运维 Coder 控制面 + PostgreSQL + Terraform。小团队可能觉得重。
• 企业导向：个人开发者用 Coder 有点杀鸡用牛刀。
• 付费功能：大规模部署、SSO、审计日志等高级功能需要 Premium 许可证。

深层洞察：从"给开发者 AI 工具"到"治理企业的 AI Agent"

Coder 代表了一个趋势：AI Agent 从"个人工具"变成"企业基础设施"。

当 AI Agent 只是个人工具时，安全问题是个人的——你的 API key 泄露了，你自己负责。当 AI Agent 变成企业基础设施时，安全问题变成组织的——一百个 Agent 同时操作代码库，如何确保它们不越权？如何审计它们的行为？如何控制成本？

这些问题在传统 IT 里有成熟答案（IAM、审计日志、预算控制），但在 AI Agent 领域还是新课题。Coder 的贡献在于：把传统 IT 治理的框架搬到了 AI Agent 上。控制面 = IAM，AI Gateway = API Gateway，Terraform 工作区 = 基础设施即代码。

这个思路可能成为企业级 AI Agent 部署的标准模式。就像企业不会让每个开发者自己管数据库密码一样，企业也不应该让每个开发者自己管 AI Agent 的 API key。

---

Coder 的 GitHub 仓库在 https://github.com/coder/coder ，AGPL-3.0 协议，curl -L https://coder.com/install.sh | sh 即可上手。如果你在一家需要治理 AI Agent 使用的企业里，Coder 值得评估。

"Agent 循环在控制面，操作在工作区"这个架构，可能会成为企业级 AI Agent 部署的标准模式。就像微服务架构把业务逻辑和基础设施分离一样——Agent 的"大脑"和"手脚"也应该分离。