Kastor：用Terraform风格定义AI智能体

背景

当前 AI Agent 的开发方式主要分为两种：在 LangGraph、CrewAI 等框架内用命令式代码定义 Agent 的行为逻辑，或者在 OpenAI Assistants、Amazon Bedrock Agents 等平台 UI 中通过点击配置组合 Agent。这两种方式都缺乏一个供应商中立、可版本控制、可审查的单一事实来源。Agent 的行为、工具、提示词分散在代码、配置文件或平台闭源存储中，难以审计、复用和跨平台迁移。这种状态类似于基础设施管理在 Terraform 出现之前的局面——手动配置、状态不一致、无法回滚。Kastor 正是为解决这一问题而生。

核心内容

Kastor 是一款开源工具（项目地址：github.com/weirdGuy/kastor），核心定位是 “AI Agent 的 Terraform”。它提供了一套类型化、声明式的规范（spec），以 .agent、.tool、.prompt 文件（使用 HCL 语法，即 HashiCorp Configuration Language）描述 Agent 的完整配置。这些文件构成一个供应商无关的、可版本化的事实来源。

Kastor 的 Go 工具链包含两条主要路径：

• kastor build：从声明式 spec 生成针对特定目标框架的可运行项目代码（例如生成 LangGraph 项目）。生成结果可重现（代码由 spec 确定，经过测试保证确定性），且不提交到版本控制。
• kastor plan / kastor apply：将 Agent 作为长期存在的资源在托管平台上进行调和（reconcile），支持状态差异比较（diff）和漂移检测（drift detection）。这意味着你可以像管理 AWS 资源一样管理 Agent 的部署状态。

安装方式支持 Homebrew、一键安装脚本、Go install 以及手动下载验证。环境依赖：Go 1.26+、Python 3.11+、OpenAI API Key 以及 Tavily API Key（用于示例中的搜索工具）。

原文提供了一个完整的天气查询 Agent 示例。该示例中：

1. 使用 kastor build examples/weather/ 生成 LangGraph 项目到 examples/weather/gen/langgraph 目录。
2. 生成的代码中，web_search 工具通过 spec URI mcp://search-server/tavily_search 绑定到 Tavily 托管的 MCP 服务器。服务器连接配置（如 API Key 嵌入的 URL）作为部署配置放在 mcp_servers.json 中（该文件默认 gitignored，视为机密）。
3. 启动 Agent 示例命令：python3 main.py weather --inputs '{"location": "Lisbon", "date": "tomorrow"}'，输出 JSON 格式的天气合约声明（如 {"weather": "..."}）。
4. 一个重要的 v0 限制：如果某个 Agent（如 agent.weather）的可选输入引用了另一个 Agent（如 agent.forecast）的输出，编译时会验证并排序依赖图，但生成的代码不会自动运行上游 Agent——用户需要手动运行 forecast 并将结果通过 --inputs 传递。

完整的 spec 设计文档位于 SPEC.md，日常开发约定记录在 CLAUDE.md。

关键要点

• 声明式规范取代命令式代码：Kastor 使用 HCL 定义 .agent、.tool、.prompt 文件，作为 Agent 的单一事实来源，与 Terraform 管理基础设施的理念一致。
• 供应商无关与可移植性：spec 本身不绑定特定框架或平台，通过 kastor build 可以生成面向 LangGraph 等目标框架的代码。理论上可以扩展支持更多后端。
• 基础设施即代码（IaC）模式：kastor plan/apply 将 Agent 视为可调和的长生命周期资源，支持状态管理、差异对比和漂移检测，使得 Agent 部署更可靠。
• 工具绑定通过 MCP 协议：示例工具 web_search 使用 MCP（Model Context Protocol）连接外部搜索服务器，工具连接配置与 spec 分离，确保 spec 中只声明工具 URI，部署时才配置服务器地址和凭证。
• v0 限制：Agent 间的输出依赖需要手动传递，生成代码不会自动编排依赖链。这一限制在 SPEC.md 中有说明，未来可能改进。
• 安全实践：API Key 和 MCP 配置嵌入在 mcp_servers.json 中，该文件被 gitignore，强制作为机密处理，不得提交到版本控制。
• 确定性与可重现：生成的代码不允许手动修改，通过测试保证代码生成与 spec 一致，确保构建的可复现性。
• 本地开发闭环：提供的示例完整覆盖了从 spec 验证、构建、设置虚拟环境、运行 Agent 的全流程，降低了上手门槛。

意义与影响

Kastor 的出现标志着 AI Agent 开发正在从手工作坊式走向工程化、可管控的阶段。其意义主要体现在以下几个方面：

1. 标准化 Agent 配置：当前各框架和平台的 Agent 配置互不兼容，Kastor 提供了一个通用规范层，使得团队可以统一管理不同后端的 Agent，降低迁移成本。
2. 提升可审计性和协作效率：声明式 spec 可以像代码一样进行 Pull Request 审查、版本回滚、差异对比，符合 DevOps 最佳实践。对于需要合规的企业场景尤为重要。
3. 基础设施思维引入 AI 领域：借鉴 Terraform 的状态管理、漂移检测等成熟模式，有助于解决 AI Agent 部署中常见的“状态混乱”问题，让 Agent 管理变得像管理云资源一样透明。
4. 推动 MCP 生态发展：Kastor 默认使用 MCP 连接外部工具，这可能会加速 MCP 协议的采纳，促进工具市场化和可组合性。
5. 局限性提醒：v0 版本尚未实现 Agent 间自动编排，且当前只支持 LangGraph 作为生成目标（以及托管平台的调和路径尚在实验阶段）。但作为一个开源项目，其设计思路已经展示了 Agent 基础设施治理的可能性。未来若能支持更多框架和平台，有望成为 Agent 领域的“Terraform”标准。