AI智能体（Agent）要真正跑起来，依赖的云资源远比想象中多：跑推理的GPU实例、存放记忆的向量数据库、任务调度用的消息队列、对外提供服务的API网关，再加上一堆安全组、IAM角色和网络配置。如果这些资源全靠手工在云控制台上点出来，团队规模一大就会乱成一锅粥——测试环境和生产环境配置不一致、某个资源被误删后没人说得清它当初是怎么建的、新同事入职要花一周才能把环境搭起来。Terraform作为最主流的基础设施即代码工具，正好能解决这些问题。这篇文章会从零开始，带你用Terraform把一个AI智能体所需的云资源完整管理起来。
为什么AI智能体项目特别需要基础设施即代码
AI智能体的部署有一个很明显的特点：迭代速度快、资源种类杂。今天加一个RAG检索服务，明天加一个工具调用的沙箱环境，后天可能又要为某个批量任务临时开几台GPU机器。这种高频变更如果靠手工操作，出错只是时间问题。
用Terraform管理有几个直接的好处。第一是可重复性，同一份代码在开发、测试、生产三个环境跑出来的资源完全一致，只需要切换变量文件。第二是可审查性，每次基础设施变更都通过Git提交记录下来，谁在什么时候改了什么一目了然。第三是可回滚性，某次变更出了问题，直接revert代码再apply一次就能恢复到之前的状态，不用凭记忆去控制台里一点点改回去。
另外，智能体项目经常涉及按量计费的GPU资源，价格不便宜。Terraform配合terraform destroy可以做到用完即销毁，配合定时任务还能实现夜间自动关停，成本控制会精细很多。
项目结构与Provider配置
先来看一个适合智能体项目的Terraform工程结构。建议按环境拆分目录，公共部分抽成模块：
agent-infra/ ├── modules/ │ ├── compute/ # GPU推理实例 │ ├── vector-db/ # 向量数据库 │ └── networking/ # 网络与安全组 ├── envs/ │ ├── dev/ │ │ ├── main.tf │ │ └── terraform.tfvars │ └── prod/ │ ├── main.tf │ └── terraform.tfvars └── backend.tf # 远程状态配置
以AWS为例，先配置provider和远程状态存储。状态文件千万不要放在本地，多人协作时会产生覆盖冲突，务必放到S3加DynamoDB锁：
terraform {
required_version = ">= 1.6.0"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
backend "s3" {
bucket = "my-agent-tfstate"
key = "prod/terraform.tfstate"
region = "ap-northeast-1"
dynamodb_table = "tfstate-lock"
encrypt = true
}
}
provider "aws" {
region = "ap-northeast-1"
}
这里有个容易忽略的细节：required_version一定要写。Terraform不同小版本之间行为可能有差异，团队成员本地版本不一致时，没有版本约束很容易出现状态文件被高版本写入后低版本读不了的情况。建议再配一个.terraform-version文件配合tfenv使用，把工具链版本也锁定住。
编排智能体核心资源：GPU实例与向量数据库
智能体的推理服务通常需要GPU。以AWS上的g5系列实例为例，声明一个EC2实例并挂载角色：
module "inference" {
source = "../../modules/compute"
instance_name = "agent-inference"
instance_type = "g5.xlarge" # 单卡A10G，适合中小规模推理
ami_id = data.aws_ami.gpu_base.id
subnet_id = module.networking.private_subnet_id
security_groups = [module.networking.inference_sg_id]
# 通过user_data注入启动脚本
user_data = templatefile("${path.module}/scripts/init.sh.tpl", {
model_name = "qwen2.5-7b-instruct"
})
tags = {
Project = "ai-agent"
Env = "prod"
}
}
向量数据库方面，如果用托管服务，直接声明资源即可。以Pinecone为例它有自己的provider；如果选择自托管Milvus，则可以声明EKS节点组或者一个独立的EC2加EBS。自托管方案的Terraform代码量更大，但可控性更强，适合对数据合规有要求的场景。
一个实战建议：GPU实例尽量用竞价实例（spot）跑非关键负载，比如批量文档向量化这类可中断任务，成本能降到按需实例的三分之一左右。但要在Terraform里配好spot_instance_types列表给多个备选机型，并在应用层做好断点续跑逻辑。
状态管理与多人协作的最佳实践
Terraform的状态文件（tfstate）记录了它管理的所有资源的当前映射，是整个体系的核心。智能体项目资源变更频繁，状态管理做不好，后面会非常痛苦。
几条经验值得遵守：第一，按环境甚至按组件拆分state，比如把网络层和计算层分成两个state，网络层基本不动，计算层高频变更，分开后apply速度快、 blast radius也小。第二，敏感信息不要明文写进tfvars，用环境变量或者接 Secrets Manager，Terraform原生支持把数据库密码写到Secrets Manager再只传递ARN。第三，每次apply前先跑terraform plan并让同事review输出，防止出现意外的资源销毁。
如果条件允许，建议接CI/CD流水线。GitLab CI或GitHub Actions里跑plan，人工确认后合并触发apply，这样基础设施变更就和应用发版一样有了完整的审批链路。流水线里记得加-lock-timeout参数，避免并发执行时互相卡锁。
常见踩坑点与排查思路
实际使用中几个高频问题提前说一下。最常见的是资源漂移：有人绕过Terraform直接在控制台改了配置，导致state和真实环境对不上。定期跑terraform plan检查drift，发现漂移要么把改动写回代码，要么用terraform import把资源纳入管理。
第二个坑是GPU实例在某些区域经常缺货，apply时一直报容量不足。解决办法是声明多个备选机型加多可用区，让Terraform自动尝试。第三个坑是安全组规则写在多个地方互相覆盖，建议把所有入站规则收敛到networking模块里统一管理，用aws_vpc_security_group_ingress_rule这种独立资源而不是内联blocks，避免规则互相替换。
最后提醒一句，destroy操作在生产环境前一定要三思，可以先加lifecycle { prevent_destroy = true }保护关键资源，比如存放对话历史的数据库，防止一次误操作把数据全删了。
总结
用Terraform管理AI智能体的云基础设施，本质上就是把部署经验沉淀成代码。前期搭模块会花一些时间，但换来的是环境一致性、变更可追溯和成本可控。建议从小的范围切入，先把网络和计算这两层管起来，再逐步把数据库、消息队列、监控告警纳入进来，最终让整个智能体平台的交付变成一条流水线，而不是一堆靠记忆维护的手工操作。