单线程写代码的时代，正在被一个叫DAG（有向无环图）的调度机制终结。

开发者@jasonbjust shipped v1.1.0的oh-my-kimi，把Kimi Code CLI（K2.6）包进了一个多智能体编排框架。核心卖点很直白：一个提示词，自动规划、并行执行、交叉评审，输出完整项目。

打开网易新闻 查看精彩图片

它到底改了什么？

传统CLI编程智能体是单线程的——一个智能体，一个任务，排队执行。oh-my-kimi的做法是：解析任务依赖关系，把独立模块丢进隔离的git工作树（worktree）并行跑，最后干净合并。

安装只需要两行：

npm install -g @oh-my-kimi/cli
omk init
omk run "Build a Next.js landing page with dark mode and contact form"

模板系统支持快速复用FAQ或代码片段，减少重复输入。

正方：为什么并行调度是刚需

真实项目的文件依赖天然呈网状。首页组件和联系表单的后端API可以同步开发，但登录态校验必须等两者完成。DAG调度把这种"能并行就并行，该串行就串行"的逻辑自动化了。

git工作树隔离解决了多智能体冲突——每个智能体在自己的沙盒里改代码，合并时用标准git流程解决冲突，而不是在提示词里扯皮。

反方：这套架构的隐藏成本

依赖解析本身需要消耗token。简单项目（比如单页落地页）的调度开销可能超过并行收益。K2.6的上下文窗口虽大，但多工作树同时运行意味着多路API调用，成本曲线需要实测。

另一个问题是调试。当三个智能体同时报错，错误日志的归属和时序追溯比单线程复杂一个数量级。

判断：工具链正在分层

oh-my-kimi的价值不在"让Kimi更快"，而在证明了一件事：大模型编程工具正在从"对话式"向"工程化"演进。DAG调度、工作树隔离、模板系统——这些本是人类工程团队的协作协议，现在被编码成智能体之间的通信标准。

如果你还在用单线程CLI写生产代码，这个工具值得放进评估清单。不是因为它完美，而是因为它展示了下一代编程接口的方向：提示词即项目计划，智能体即线程池，版本控制即状态管理。