别人卖订阅，他把整套智能体流水线开源了

一个终端里的编码智能体，对一台笔记本上的一个开发者来说很好用。麻烦从公司想把它变成团队工具那天开始：上百个代码仓库、不同角色、评审关卡、审计记录、共享凭证，一样都不能少。

眼下几乎所有想解决这个问题的人，都在卖你一份新的 SaaS 订阅。套路很统一：把 GitHub 组织接到他们的云上，交出私有仓库的写权限令牌，让内部上下文和日志流经他们的多租户黑箱，然后按人头付费，或者按加价的算力分钟付费——而你自己那套 Kubernetes 集群就在旁边闲着。

所以撞见 Kodama 这件事才显得清爽。它没有把容器编排和人工审批包进一个托管付费墙，而是把整套“软件工厂”以Apache-2.0开源软件的形式交出来，用 Go 写成，几分钟内就能在一台 Linux 笔记本上以无根 Podman 跑起来，也能直接跑在你生产环境里已有的 Kubernetes 集群上。

它到底是个什么东西

Louis 在 DEV 上介绍 Kodama 时给了一句很抓人的话：“像 OpenClaw，但是给团队用的。”就算你没碰过 OpenClaw，它的核心产品模型一句话能说完：

• 流水线（pipeline）是一串有序的动作；
• 动作（action）运行一个容器，或者请求一个答复；
• 执行（execution）把一条流水线跑一次；
• 任务（task）是一场对话，由它发起执行。

用过 Drone 这类容器原生 CI 的人，会对前半段立刻感到熟悉：容器按顺序跑，共享一个工作区，以零或非零状态退出。后半段才是把 CI 变成软件工厂的关键。

动作不一定非得跑容器。它可以暂停流水线，向某个角色（比如role/reviewer）或某个自动化策略服务请求一个决定。智能体也只是另一种容器命令——Claude Code、Codex、OpenCode、Pi，或者一个普通 shell 脚本，都能和你的构建、测试镜像并排插进同一条流水线。任务则承载共享历史：人、脚本或编辑器里的智能体通过 REST、MCP 或kodactl提交任务，评审者从角色收件箱里干活，失败的执行落进操作员的收件箱。

架构上的边界画得很干净

Kodama 值得细看的地方，是它把边界划得很清楚。KODAMA.md 用一份可读的规格写清了整个 v2 设计和 20 条验收标准。

• Shell（控制平面）：管租户、项目、OIDC 与服务令牌身份、授权、任务、角色收件箱、信封加密的密钥，以及一个带 REST 和 MCP 边缘的单一操作路由。
• Kernel（执行引擎）：推进有序执行、执行动作超时限制、崩溃后干净恢复，且不依赖 HTTP、Git、OIDC 或消息中间件。
• 持久状态与消息：PostgreSQL 是状态、审批回执和事件表的真相来源，按租户和项目隔离并强制行级安全；NATS JetStream 分发事件和实时日志，消息中间件出问题时集成会等待，但执行不会丢状态。
• 工作负载：本地是无根 Podman 容器，生产环境里每个容器动作就是一个普通的 Kubernetes Job 挂载工作区 PVC，没有自定义 CRD，也没有需要照看的 Kubernetes Operator。
• 用户态服务：Git 托管、编码智能体和外部适配器都待在控制平面内部之外，走公开 API 和审批校验。

开源在这里赢在哪

有些软件品类做成 SaaS 是合理的。但软件交付的控制平面——代码、凭证、评审权限和发布历史交汇的地方——恰恰是开源和自托管最该发光的位置。Kodama 有四个细节说明了原因。

第一，你的密钥、代码和决定都留在自己的集群里。仓库、流水线状态和审批记录待在你自己的数据库和集群中。更进一步：工作负载容器根本不需要原始的ANTHROPIC_API_KEY或OPENAI_API_KEY，智能体把 base URL 指向 Kodama 内置的模型代理，用执行令牌认证，令牌在执行等待或结束时即被吊销。只有智能体发出的提示词会去到你配置的模型提供商。

第二，等人不花算力。很多托管智能体平台里，人在环流程要么别扭要么贵，因为沙箱一直热着，或者会话半小时就超时。在 Kodama 里，流水线走到role/reviewer审批步骤时，等待期间（最长 30 天）零工作负载容器在跑，工作区卷保留，执行凭证被吊销，直到评审者批准。智能体卡在任务中间、向角色收件箱抛出问题时，Kodama 会干净地结束这次执行；回答问题会启动一次全新执行，完整的任务对话挂载在/kodama/task.json。

第三，真正的职责分离，连智能体本身也防。角色检查是有牙齿的：如果一名 Engineer 发起执行，然后试图对 Reviewer 关卡执行kodactl approve，Kodama 会以 forbidden 拒绝；就算握着 Admin 权限，也不自动获得评审权。配合 Kodama 的 Git 服务，main 分支可以要求一个经过校验的审批，绑定到确切的候选提交、目标 ref 和预期基线。智能体也改不了管着它的流水线：Kodama 不会从 Git 推送里自动发现流水线 YAML，流水线必须通过 API 显式应用。一个有分支推送权限的编码智能体，没法偷偷往 .kodama/ 里塞改动来跳过测试或绕过评审。

第四，刻意的简单，以及诚实的边界。SaaS 营销页爱承诺无限灵活，Kodama 的规格却花真笔墨写它拒绝造什么：没有 DAG，没有 when 表达式，没有循环，流水线内部没有并行分支。流水线就是一张有序列表，分支逻辑属于你能真正做单元测试的 shell 脚本或工具；规模来自在 Kubernetes Job 上调度许多独立的任务执行。状态说明也很直白：当前版本0.2.1在 Linux 上用无根 Podman 5+ 本地验证过，并在 Scaleway 的云部署中做过实机验证（AWS 和 GCP 的 OpenTofu 根也已实现）。它的容器隔离通过命名空间、默认拒绝的 NetworkPolicy、KMS 支持的密钥和 PostgreSQL 行级安全来分隔租户——它是为运行可信工程工具的组织准备的，不是不可信恶意代码的沙箱。

本地四条命令跑起来

如果你有一台装了无根 Podman 5+ 的 Linux 机器，可以先看看那份约 100 行的安装脚本——它校验 SHA256SUMS，装进 ~/.local/bin，全程不要 root——然后把整套栈拉起来：PostgreSQL、NATS、Kodama 服务端、Git 服务，以及四个本地角色（admin、engineer、reviewer、operator）。

1. 用 curl 拉取并执行安装脚本；
2. 执行kodama up
3. source 环境变量文件；
4. kodactl whoami确认身份。

玩完了，kodama down --purge会清掉所有容器和卷。项目在 GitHub 上以 Apache-2.0 发布，完整架构与规格在 KODAMA.md，快速上手文档在 optimi.com。

kodama（木霊）是日本民间传说里安静的树灵。有人给它写了三行短诗：看不见，木头在思考；你睡着时树枝在提交；天亮时叶子已经变了。

如果你的团队已经把编码智能体用到了单台笔记本之外，在让这样一个自托管工厂靠近真实仓库之前，你想先看到什么？