kubeopencode 到了 100 个 star，但我决定对它按下暂停了。
它做对了什么
回头看，kubeopencode 确实有几件事做对了。
用户思维。 它的起点是我们团队自己在开发流程里遇到的痛点，所以从第一天起就是按真实使用场景去设计的。到现在，它依然非常易用——Web Terminal、Agent 作为 Pod 直接运行、Skills 作为 Git 仓库 import、Plugins 通过 npm 注入，这些交互都是站在使用者一侧想的。
前瞻的架构选型。 我们一开始就没有走 LangChain、LangGraph 那条路，而是直接把 OpenCode 编译成 binary，作为 Agent 的 core 运行。后来不少AgentOS类的产品都转向了这个方向——不再依赖 agent 框架，而是直接支持 Claude, Codex, OpenCode 这类完整的Agent 作为 “runtime”。
最好的归宿是被收编。 如果要给 kubeopencode 找一个最佳去向，那就是被某个 Kubernetes 发行商收编，作为它发行的 K8s 里一个面向 DevOps 的 Agentic 工具。这是它最自然的形态。
为什么停下来
但作为个人项目，它已经不能给我带来更多的价值:
定位尴尬：既不是 AI infra，也不是 AI agent
现在的行业有两条主线——AI infra 和 AI agent，kubeopencode 在两条线上都没有踩实。
在 AI infra 这侧，它没有碰到真正硬核的技术点：没有 sandboxing、没有 agent 调度、没有 warm pool、没有高并发。这些才是 infra 的核心难题，而 kubeopencode 把执行环境直接委托给了 Kubernetes。非常有可能被视为一个简单的wrapper。
在 AI agent 这侧，它也没有真正造一个 agent。我们直接用了 OpenCode 作为 core，把它编译成 binary 提供出去，既没有基于 LangChain/LangGraph 开发，也没做 RAG 和 memory——这些工作都 delegate 给了底层 agent。
所以当别人问"这个项目最难的部分是什么"，我很难给出一个有技术深度的回答。它更多展示的是产品能力，而不是工程深度。
资源不匹配：for team 的产品，个人养不起
kubeopencode 从设计之初就是 for team、for enterprise、for production usage 的。这就带来一个致命问题：离职之后，我作为个人，没有办法像一个真实用户那样去使用和测试它。
很多成功的开源工具（比如各种个人 coding agent）之所以能持续精进，是因为作者自己就是第一用户，每天用它，反馈闭环极短。kubeopencode 的形态决定了它无法拥有这个优势——我找不到一个企业级用户来扮演这个角色。
更深一层的问题是集成门槛。一个真正给打工人用的产品，最终一定要和现有的 IM、文档、办公系统打通。目前不管是 Codex、Claude Co-worker、国内的 WorkBuddy, Qcoder 和各家大厂的 AI 助手，都在深度和各种办公或编程生态的产品（飞书，Notion，Canva…）做集成。个人开发者显示无法给 kubeopencode 实现这些。
无法做到极致：K8s 既是便利，也是天花板
如果要把"易用"做到极致，产品应该完全屏蔽掉 Kubernetes 这一层——用户不应该承担 K8s 的心智负担。
未来在这个方向上胜出的产品，一定能在屏蔽 K8s 的前提下，照样能做到团队级 Agent 共享、自定义构建、本地与云端配置同步。而一个基于 K8s 平台组装出来的产品，永远差这一层"完整产品"的形态。
商业逻辑上也很清楚：你不可能把 K8s 的专业知识交给用户去消化，然后还指望它是一个大众产品。
Takeaway
如果未来再做个人跟 AI 相关的开源产品，最关键的一条是：你自己必须能每天使用它。
如果你自己不是用户，或者你的资源和你想做的事不匹配，那不管构想多好，都落不了地。
kubeopencode 已经改成了 MIT 协议。我不会再 actively 地添加功能，但如果有人想继续用，直接 fork、以任何形式使用都可以。