AI 编码 Agent 正在重塑开发流程，但大多数团队的使用方式是把代码和数据送进别人的云——SaaS 平台托管 Agent，代码在远端执行，结果再传回来。对于合规要求严格、代码资产敏感的团队，这条路越走越窄。Coder Agents 的核心主张很简单：Agent 留在你的基础设施上跑，模型你可以自己选，代码和数据不出你的边界。
为什么"自托管"不是退回旧时代
云托管 AI Agent 的便利是真实的：开箱即用、不用管运维、按量计费。但便利背后有几个越来越明显的痛点：
- 代码离开边界：Agent 需要读取、修改、运行你的源码，这意味着整个仓库要上传到第三方环境。对金融、医疗、军工等行业，这直接触碰合规红线。
- 执行环境不可控：云平台决定 Agent 在什么 OS、什么网络、什么权限下运行。你无法注入自己的安全策略、网络隔离或审计日志。
- 模型锁定：很多平台绑定特定模型。当你想从 GPT-4 切换到 Claude，或者用本地微调模型时，迁移成本很高。
Coder Agents 的设计直接回应这三点：模型无关（model-agnostic）、基础设施自选、执行环境自建。
架构上的关键选择
Coder Agents 并不是又一个"AI 编码助手 SaaS"，它更像一个编排层——在你自己的服务器上调度 AI Agent，对接你选的模型，运行在你定义的开发环境中。
几个架构要点：
-
Workspace 即开发环境：每个 Agent 运行在独立的 Coder Workspace 里，Workspace 本质是一个容器或 VM，你可以用 Terraform 模板定义它的镜像、资源、网络规则。Agent 的所有操作——读代码、跑测试、执行命令——都在这个隔离环境内完成。
-
Agent 与模型解耦：平台本身不绑定任何 LLM。你可以配置 Agent 调用 OpenAI、Anthropic、本地部署的 Ollama，或者任何兼容 OpenAI API 格式的推理服务。切换模型只改配置，不改流程。
-
代码不外传：因为 Workspace 在你的机房/私有云里，Agent 读写代码全程在内网完成。唯一的外部调用是向 LLM API 发送 prompt，你可以进一步通过私有推理服务把这条链路也收归内部。
实操：用 Terraform 模板定义一个 Agent Workspace
下面是一个最小可运行的 Coder Workspace Terraform 模板，定义了一个带 Python 环境和 Git 的开发容器，供 AI Agent 使用。假设你已经部署了 Coder 服务端（参考 Coder 官方文档用 docker run 或 Helm 快速启动）。
terraform {
required_providers {
coder = {
source = "coder/coder"
version = "~> 0.30"
}
docker = {
source = "kreuzwerker/docker"
version = "~> 3.0"
}
}
}
provider "coder" {}
provider "docker" {}
data "coder_workspace" "me" {}
resource "coder_agent" "main" {
os = "linux"
arch = "amd64"
dir = "/home/coder/project"
# Agent 启动后自动安装常用工具
startup_script = <<-EOT
apt-get update && apt-get install -y git python3 python3-pip
pip install --quiet anthropic openai
cd /home/coder/project && git init
EOT
}
resource "docker_container" "workspace" {
name = "coder-${data.coder_workspace.me.owner}-${data.coder_workspace.me.name}"
image = "ubuntu:22.04"
# 把 Agent 注册进容器
entrypoint = ["sh", "-c", coder_agent.main.init_script]
volumes {
container_path = "/home/coder/project"
host_path = "/data/coder-workspaces/${data.coder_workspace.me.owner}"
}
# 资源限制——防止 Agent 跑飞
memory = 4096
# 网络隔离：只允许内网和指定 LLM API 出站
networks_advanced {
name = "coder-internal"
}
}
使用前需要调整的地方：
coder-internal网络：你需要先在 Docker 中创建一个只允许内网通信的网络，再用 iptables 或防火墙规则限制出站只放行你的 LLM API 地址。/data/coder-workspaces/目录：映射到宿主机上实际存储代码的位置。memory：根据 Agent 工作负载调整，4GB 是保守起步值。
部署流程：
# 1. 启动 Coder 服务端（最简方式）
docker run --rm -it -p 3000:3000 \
-v /data/coder:/data \
coder/coder:latest server
# 2. 在 Coder UI 中创建 Workspace，选择上面的 Terraform 模板
# 3. 在 Workspace 内配置 Agent 的模型后端
# 例如指向本地 Ollama：
export LLM_API_BASE=http://ollama.internal:11434/v1
export LLM_MODEL=codellama:34b
这样，Agent 的代码操作在容器内完成，LLM 调用走内网，整个链路不经过公网。
模型切换：从云到本地，只改一行配置
Coder Agents 的 model-agnostic 设计在实践中意味着：你可以按任务选模型，按成本选部署方式。
一个典型演进路径：
| 阶段 | 模型来源 | 配置方式 |
|---|---|---|
| 早期验证 | OpenAI API | LLM_API_BASE=https://api.openai.com/v1 |
| 成本优化 | Azure OpenAI | LLM_API_BASE=https://your-resource.openai.azure.com/ |
| 合规落地 | 自托管 Ollama / vLLM | LLM_API_BASE=http://ollama.internal:11434/v1 |
切换时只改 LLM_API_BASE 和 LLM_MODEL 两个环境变量，Agent 的编排逻辑、Workspace 模板、权限策略全部不动。
自托管的代价与边界
自托管不是银弹，有几个现实约束需要正视：
- 运维负担：你要自己管 Coder 服务端、Workspace 容器、模型推理服务的可用性。如果团队没有 Kubernetes 或 Docker 运维经验，起步成本不低。
- GPU 资源：本地跑大模型需要 GPU。如果用云 API，GPU 是别人的；自托管后，采购和管理 GPU 成了你的事。一个折中方案是：Coder Workspace 自托管，LLM 推理仍用云 API——代码不出边界，但推理在云端。
- Agent 能力上限：自托管环境的安全限制越严格，Agent 能做的事情越少。比如禁止 Agent 执行
sudo、禁止访问生产数据库，这些限制会让 Agent 在某些任务上退化为"只读建议器"。
落地检查清单
如果你的团队正在评估 Coder Agents 或类似自托管方案，建议按这个顺序推进：
- 先锁定合规需求：明确哪些代码/数据绝对不能出边界，哪些可以放宽。这决定了你需要自托管到什么程度。
- 最小 Workspace 先跑起来：用一个只装 git 和 python 的轻量模板验证 Agent 能正常工作，不要一开始就搞复杂环境。
- 模型先走云 API：早期用 OpenAI/Azure API 验证 Agent 效果，确认流程通畅后再考虑本地推理。
- 逐步收紧网络策略：从开放出站开始，逐步用防火墙规则收窄到只放行必要的 API 地址，观察 Agent 是否还能正常工作。
- 审计日志必须开：自托管的优势是你可以记录 Agent 的每一条 shell 命令、每一次文件修改。把审计日志接入你的 SIEM，这是云平台很难给你的东西。
把 AI 编码 Agent 拉回自己的机房，不是为了拒绝云的便利，而是为了在便利和可控之间找到属于你团队的平衡点。Coder Agents 提供了编排层和隔离机制，剩下的——模型选型、运维投入、安全策略——需要你自己掂量。