场景：你的 AI Agent 散落在不同平台上无法统一管理？Kastor 用 Terraform 式声明规范让 Agent 定义可版本化、可审查、可复现

TL;DR： 当前 AI Agent 定义散落在 LangGraph、CrewAI、OpenAI Assistants 等不同框架的代码和 UI 中，没有统一的可版本化的真相源。Kastor 提供了一种 Terraform 式的声明规范（.agent、.tool、.prompt 文件），加上 Go 工具链，让 Agent 定义像基础设施代码一样可管理、可审核。

问题：AI Agent 定义的碎片化困境

如果你用过多个 AI Agent 框架，一定遇到过这种场景：

• 一个 Agent 在 LangGraph 中定义，另一个在 OpenAI Assistants 的 UI 里点出来，第三个在 Bedrock 上配置
• 团队成员之间无法通过 Git 审查 Agent 的配置变更——因为 Agent 定义是代码和 UI 点击的混合体
• 部署环境切换时，Agent 的行为差异很难追踪——没有「规划→审批→应用」的标准流程
• Agent 使用的工具、提示词、模型参数散落在不同地方，版本管理靠人工记忆

这就是 Agent 基础设施的「Infrastructure as Code 荒漠期」——就像 2015 年之前手动 SSH 到服务器改配置一样混乱。

Kastor 要解决的就是这个问题：把 Agent 定义变成基础设施代码（Infrastructure as Code）。

Kastor 是什么

Kastor（GitHub，Apache-2.0，Go 语言）是一个声明式规范和工具链，让你用 Terraform 式的方式定义和管理 AI Agent。它不是又一个 Agent 运行时框架——它专注于 Agent 的声明定义和生命周期管理，生成目标框架可运行的代码。

整个工具链围绕四个核心概念构建：

1. 声明规范（Spec） — 用 .agent、.tool、.prompt 文件在 HCL 中定义 Agent
2. 构建（Build） — 将声明规范编译成目标框架（目前支持 LangGraph）的可运行项目
3. 规划与应用（Plan/Apply） — 像 Terraform 一样，先规划变更再应用到目标平台
4. 状态管理与漂移检测 — 本地状态文件跟踪已应用的 Agent，检测远程平台上的无授权变更

核心理念：声明式 Agent 规范

Kastor 用 HCL（HashiCorp Configuration Language）定义 Agent。一个简单的天气查询 Agent 是这样的：

agent "weather" {
  description = "查询某个地点和日期的天气信息"

  model         = model.fast
  system_prompt = prompt.weather_system
  tools         = [tool.web_search]

  input "location" {
    type        = string
    description = "要查询天气的地点"
  }

  input "date" {
    type     = string
    optional = true
  }

  output "weather" {
    type = string
  }
}

你还会定义模型（model）、工具（tool）、提示词（prompt）等资源，它们共同构成完整的 Agent 声明。所有定义都是纯文本、可版本化、可通过 Pull Request 审查的。

工作流：Plan → Build → Apply

Kastor 的工作流借鉴了 Terraform 的成熟模式：

1. 验证与规划

kastor validate examples/weather/
kastor plan examples/weather/

kastor plan 是纯读操作——它对比声明规范、本地状态文件和目标平台的实际状态，输出三路对比结果：

$ kastor plan examples/weather/
  + agent.forecast (not in state)
  + agent.geocoder (not in state)
  + agent.weather (not in state)

Plan for target.memory: 3 to create, 0 to update, 0 to delete, 0 unchanged.

如果 Agent 在远程平台上被无授权修改，kastor plan 还会输出漂移警告。

2. 编译构建

kastor build examples/weather/

kastor build 将声明规范编译成目标框架的可运行项目。当前版本生成 LangGraph 项目，输出到 gen/langgraph/ 目录。编译输出是可重现的——给定同样的规范，每次都生成同样的代码。

3. 应用与销毁

kastor apply examples/weather/
kastor destroy examples/weather/

apply 将声明规范同步到平台目标（当前支持内置的内存平台，计划支持 OpenAI Assistants 和 AWS/Azure）。destroy 移除已创建的 Agent 资源。

安装与上手

安装方式很简洁——Homebrew 或一键安装脚本：

brew tap weirdGuy/tap && brew install kastor

curl -fsSL https://raw.githubusercontent.com/weirdGuy/kastor/main/scripts/install.sh | sh

go install github.com/weirdGuy/kastor/cmd/kastor@latest

然后编译天气示例：

go build ./cmd/kastor
./kastor build examples/weather/

cd examples/weather/gen/langgraph
python3 -m venv .venv
. .venv/bin/activate
pip install -r requirements.txt

配置 MCP 工具服务器和模型凭据后，运行 Agent：

python3 main.py weather --inputs '{"location": "Lisbon", "date": "tomorrow"}'

技术架构

Kastor 是纯 Go 实现，无需 Agent 运行时依赖。整体架构分三层：

工具链还包含 MCP 工具服务器的 URI 绑定机制——声明规范中的工具通过 mcp:// URI 引用，实际部署配置（服务器地址、认证凭据）通过 mcp_servers.json 文件注入，实现了规范与配置的分离。

适用场景

Kastor 当前是早期概念验证（proof of concept），但解决的问题非常清晰：

• 团队协作：Agent 定义通过 Git 审查，变更历史可追溯
• 多平台管理：同一组 Agent 规范可部署到不同平台目标
• 审计合规：kastor plan 的变更记录和漂移检测提供完整的变更审计链
• 标准化：团队有统一的 Agent 定义语言和生命周期管理流程

如果你正在生产环境中管理多个 AI Agent，或者在团队中推动 Agent 开发的标准化流程，Kastor 的声明式思路值得关注。

总结

Kastor 把基础设施即代码（IaC）的思想引入 AI Agent 管理。在当前 Agent 定义分散在代码和 UI 中的背景下，这种声明式、可版本化、可审查的 Agent 管理方式，正好填补了 AgentOps 工具链中的一个关键空白。

相关链接

• Kastor GitHub 仓库
• Kastor 设计规范 SPEC.md
• 天气示例 Agent