Kastor 开源：把 Agent 当基础设施来管

有人把 Terraform 那套搬到 Agent 上来了

7 月初，一个叫 Kastor 的项目悄悄挂上了 Hacker News，标题很直白：Show HN: Kastor – Terraform-style specs for AI agents。作者的想法一句话就能说清——既然基础设施可以 terraform apply，Kubernetes 可以 kubectl apply -f，那 AI Agent 为什么还得靠开发者手写一坨 Python 胶水？

这不是第一个想把 Agent 声明式化的项目，但它是目前为止我看到的、把 IaC（Infrastructure as Code）范式贴得最紧的一个。连命名都在致敬：Kastor / Castor，声明式配置、状态管理、diff & apply，几乎是把 HashiCorp 那套心智模型原样搬过来。

它到底解决什么问题

现在写一个稍微复杂点的 Agent，典型流程是这样的：LangChain 或者 LlamaIndex 起一个框架，硬编码 system prompt，注册几个 tool，再手写 retry、fallback、logging，模型换一次就要改一次代码。团队协作的时候，Agent 的"定义"散落在 Python 文件、YAML 配置、环境变量里，review 的时候根本看不出这次改动到底动了 Agent 的哪根神经。

Kastor 的解法是把 Agent 的全部定义——用什么模型、挂什么工具、有什么 guardrail、怎么路由、上下游依赖谁——都塞进一份声明式 spec 里。类似这样：

agent \"support_triage\" {
  model    = \"gpt-4o\"
  fallback = \"claude-3-5-sonnet\"

  system_prompt = file(\"./prompts/triage.md\")

  tool \"search_kb\" {
    source = \"./tools/kb.py\"
  }

  tool \"create_ticket\" {
    source = \"./tools/jira.py\"
    scopes = [\"write:issue\"]
  }

  guardrail \"pii_filter\" {
    action = \"redact\"
  }

  route \"escalation\" {
    when = \"sentiment < -0.5\"
    to   = agent.human_handoff
  }
}

然后 kastor plan 会告诉你这次改动会让 Agent 从哪个状态迁移到哪个状态，kastor apply 才真正部署。对做过 DevOps 的人来说，这套体验熟悉到不用学。

为什么这个思路值得关注

我在 AI 行业待了几年，看过太多 Agent 框架从"炫技 demo"到"生产环境翻车"的循环。真正把 Agent 落到生产的团队，最后都得自己重造一遍下面这几个轮子：

• 版本管理：Agent 定义变了，怎么灰度、怎么回滚？
• 环境隔离：dev / staging / prod 三套 Agent，怎么保证配置一致？
• 依赖追踪：Agent A 调 Agent B，B 挂了怎么办？谁负责监控？
• Review 流程：改一个 prompt 相当于改一段"程序"，但 diff 出来根本看不懂业务意图。

这些恰好是 Terraform 十年前在云资源领域解决过的问题。Kastor 的作者显然是这个思路——Agent 是新的基础设施，就应该用管基础设施的方式管它。

这个判断我认同。过去两年冒出来的 Agent 编排框架，大多还停留在"用 Python DSL 让你写起来更爽"的阶段，本质是 SDK。而 Kastor 更像一个控制平面：它不关心你的 Agent 怎么跑，只关心你声明的状态和实际状态之间的 diff。

技术细节：不止是换了个 YAML 皮肤

翻了下 repo，Kastor 有几个设计选择挺有意思。

第一，state 文件是一等公民。跟 Terraform 一样，Kastor 维护一个 state 记录当前部署的 Agent 拓扑。这意味着你能 kastor state show agent.support_triage 查当前生产的确切配置，而不是靠翻 Git 猜。

第二，provider 模型。模型接入被抽象成 provider，理论上任何符合接口的后端都可以接。README 里已经列了 OpenAI、Anthropic、本地 Ollama 三个 provider，社区补齐 DeepSeek、Gemini 应该是几周内的事。对多模型混用的团队来说，这套 provider 抽象比在业务代码里堆 if-else 干净得多。

第三，模块化。跟 Terraform module 一个思路：一个"客服 Agent 集群"可以打包成 module，里面包含 triage、rag、escalation 三个 agent，暴露几个变量出来。别的项目直接引用，不用复制粘贴。

第四，plan 阶段的 dry-run。这个我觉得是杀手锏。改了 prompt 之后跑一次 kastor plan，系统会用少量测试用例跑一遍新旧配置，把行为差异 diff 出来。这解决了 prompt engineering 里最痛的一个问题——你永远不知道改一个字会让 Agent 变成什么样。

和现有方案比

绕不开的对比对象有几个：

• LangGraph：图结构编排，代码优先，灵活度高，但是重。做原型爽，做生产管理累。
• CrewAI / AutoGen：多 Agent 协作范式，focus 在"角色扮演"上，配置和运行时耦合得比较紧。
• Dify / Coze：低代码平台，UI 拖拽，适合非工程师，但对 DevOps 流程支持基本没有。
• Kubernetes Operator for Agents（比如 kagent）：思路接近，但重度绑定 k8s，学习曲线陡。

Kastor 的定位比较独特：面向已经有 DevOps 心智的工程团队，把 Agent 纳入现有的 GitOps 流水线，而不是让团队再学一套新范式。它不做运行时，只做定义和部署——运行时你可以塞任何东西，包括直接调用聚合 API。

一些保留意见

当然，泼点冷水。

声明式的天花板问题。当年 Terraform 也被吐槽过——一旦业务逻辑复杂，HCL 的表达力就捉襟见肘，只能靠 local-exec 之类的口子逃生。Agent 的行为比云资源复杂得多，很多东西天生是命令式的（"如果用户说 X，先查 A 再决定要不要调 B"）。Kastor 目前用 route 和条件表达式撑着，能覆盖多少场景要打个问号。

生态是硬伤。Terraform 之所以赢，是因为几乎所有云厂商都提供了官方 provider。Kastor 现在还是个人项目，模型 provider、工具 provider 全要社区从零建。头半年会很痛。

测试标准还没建立。kastor plan 的行为 diff 需要测试用例，但 Agent 的"正确行为"本来就难以定义。这块估计要跟 evals 生态（比如 Braintrust、Langfuse）打通才能真正好用。

顺带说一句

如果你想拿 Kastor 试试多模型混用，OpenAI Hub 是个省事的选择——一个 Key 直连 GPT、Claude、Gemini、DeepSeek，兼容 OpenAI 格式，Kastor 里配一个 provider 就能全模型切换，不用为每家单独申请 Key、单独接 SDK。国内直连这点对做 fallback 策略的团队算是刚需。

值不值得跟进

我的判断是：这是一个方向正确、时机也差不多到了的项目。2024 年谈 Agent 声明式还太早，那时候大家连 Agent 该长什么样都没想清楚。到了 2026 年这个节点，多模型、多工具、多 Agent 协作已经是生产标配，"怎么管"的问题终于压过了"怎么写"，Kastor 这类项目才有生存空间。

但作者一个人搞不出 Terraform 的规模，Kastor 能不能起来，看接下来半年有没有大厂或者活跃社区跟进 provider 生态。现在值得 star 一下，起个新项目可以试试；生产环境嘛，再观察一两个版本。

参考来源

• Kastor GitHub 仓库 - 项目主页与文档，包含 spec 语法说明和示例