Kastor: 为 AI Agent 提供 Terraform 式的声明式层

Kastor 为 AI agent 提供了一个声明式的单一事实来源层，使开发者能够使用 HashiCorp Configuration Language (HCL) 来定义 agent、tools、prompts 和 models，并将其编译为可运行的框架代码或托管平台资源。这种方法将 agent 配置视为可版本化、可审查的契约，而不是分散在框架代码、prompt 文件和平台 UI 中的碎片化设置。

声明式 Agent 规范

Kastor 使用一套声明式文件来定义 AI agent 的完整契约。Kastor 将定义与执行分离，而不是将配置嵌入到运行时代码中。

文件类型与结构

一个 Kastor 模块由包含以下文件类型的目录树组成：

• .agent: 定义 agent 的 model、prompt、tools、inputs 和 outputs，以及它对其他 agent 的依赖关系。
• .tool: 指定 tool 接口及其实现来源。
• .prompt: 包含 prompt 模板并识别所需的变量。
• *kastor.hcl / .kastor: 用于定义 models、targets 和全局默认值的项目文件。

这些文件中的引用通过地址（例如 model.fast 或 tool.web_search）而不是文件路径来连接代码块，这使得 Kastor 能够在编译时构建并验证依赖图。

工作流：构建、计划与应用

Kastor 实现了一套模仿 Terraform 工作流的工具链，以确保 agent 的预期状态与实际部署状态一致。

代码生成路径 (kastor build)

Kastor 可以将模块编译为可运行的框架代码。例如，它可以从 Kastor 规范生成一个完整的 LangGraph 项目。生成的代码是输出产物，不应作为单一事实来源；任何更改都应在 HCL 规范中进行并重新构建。

协调路径 (kastor plan / apply)

对于托管型 agent，Kastor 提供协调工具：

• kastor plan: 一个只读操作，通过将当前规范与状态文件和远程资源进行比较，来识别偏差或所需的更改。
• kastor apply: 将托管的 agent 与规范进行协调。
• kastor destroy: 移除托管的 agent。

与 LangGraph 和 MCP 的集成

Kastor 目前支持生成 LangGraph 项目并与 Model Context Protocol (MCP) 集成。

LangGraph 生成

当为 LangGraph target 执行 kastor build 时，它会将生成的项目写入指定的输出目录。该项目包含一个 README.md，详细说明了 agent 的 input/output 契约和 tool 绑定。

MCP Tooling

Kastor 中的 tools 可以通过 spec URI（例如 mcp://search-server/tavily_search）绑定到 MCP server 和 tool。实际的连接详情（如 URLs 和 API keys）通过部署配置（如 mcp_servers.json）进行处理，而不是通过 spec 本身，从而避免了敏感信息进入版本控制的 HCL 文件。

架构与定位

Kastor 不是一个 agent runtime；它位于 runtime 层之上，以提供标准化的配置接口。

与框架和 Terraform 的比较

• Vs. LangGraph: 虽然 LangGraph 是执行 agent 的 runtime 框架，但 Kastor 定义了契约并生成项目。Kastor 不是 LangGraph 的替代品，而是位于其之上的一个层。
• Vs. Terraform: 虽然 Terraform 用于管理远程基础设施资源，但 Kastor 专注于 agent 规范本身。这使得 Kastor 能够同时支持本地框架代码的生成以及托管平台 agent 的协调。

当前状态与能力

Kastor 目前处于早期概念验证阶段。其当前可用的功能包括：

• 解析 .agent, .tool, .prompt, 和 kastor.hcl 文件。
• 验证引用和 prompt 变量。
• 内存中平台支持: plan 和 apply 工作流可以在内置的内存中平台 target 上进行测试，无需 API keys。
• 状态管理: 本地状态文件、三方差异对比 (three-way diffs) 以及偏差检测 (drift detection)。
• 示例实现: 包括一个 weather agent 和一个 content scheduler。