64个star的开源工具，算的是谁的账？

在GitHub上刷到一个叫Kastor的项目，64个star，3个fork。扒了一下代码，这哥们是真干活了——拿HCL做规格语言，把agent、tool、prompt全塞进声明式配置里，用validate、build、plan、apply这套连招来管理。对，就是Terraform那一套。

这方向我认。用声明式配置来管agent的生命周期，把配置文件当单一事实来源，这是刚需，不是伪需求。

但真算起账来，这笔账里有个致命的漏项。

Kastor有个目标叫claude_agents，你一条apply命令下去，它直接去Anthropic那边创建真实的托管agent，把远程ID写进本地状态文件。基础设施即代码嘛，看着很爽对吧？但你用destroy命令删一个agent，Anthropic控制台里那个东西会被永久归档，不可逆。

你以为你在管理自己的资源？你以为你在搞多云编排？我以前算基础设施账的时候也吃过这种哑巴亏——一旦你的state file和某个云厂商的私有API深度绑定，你的切换成本就全捏在别人手里了。

Kastor也是这个逻辑。你越是重度依赖这套声明式工作流来管Claude agent，你跟Anthropic绑得就越死。工具的护城河从来不在工具本身，在工作流嵌入和切换成本里。你在GitHub上给它点star，帮它完善文档，拿生产环境喂反馈——结果呢？Anthropic一分钱推广费没花，开发者粘性让你给做起来了。谁赚谁亏？

插一句，这定位其实卡得很聪明。Kastor文档里写得很明白，它不是运行时环境，它是个配置层。像http、script这种客户端执行的源类型直接拒了，实际执行扔给别的平台去跑。不做运行时，就不会陷入模型推理那种无底洞成本——但也意味着它永远是个薄薄的中间层。

这账我半年前算过一次：纯中间层的开源工具，没有自己的数据沉淀，最后只有两条路。要么被大厂吸收，直接把你招了或者抄了；要么被大厂掐死，人家自己出个官方CLI，比你好用十倍。第三条路？也许是搞SaaS托管，但那是另一个深坑了，这个判断我目前不敢下死话，再看看。

所以这工具的红利窗口期，其实是对使用者的，不是对作者的。你是做AI agent的团队，趁这种声明式编排还没被大厂官方收编，赶紧拿它把内部工作流跑通，吃到工程效率的红利，这就够了。别想着拿这玩意儿去创业——一个薄薄的配置层，连运行时都不是，撑不起一门独立生意。你真要在卡位上找长期生意，得往下沉去做运行时，或者往上沉去做特定行业的agent模板，卡住一个别人搬不动的生态位。

本期认知税：以为自己在给开源生态做贡献，其实是在替大厂免费打工养护城河。这笔账，你自己算。咱下篇见。