一些读前须知 叠甲 我没买kimi官方订阅 单纯ZCode一直用着不习惯前几天爆了刚好就完全换到Kimi Code了 用的自定义模型 Kimi Code的CLI和WebUI是开源的 仓库从5月中就有记录了 issue和PR没关 其实除了被迫开源的ZCode好像也没有别的大厂把自己的桌面端APP开源吧 DSH除外（等他们正式发桌面端） Kimi Code默认遥测是打开的 需要关掉 桌面端不算开源 但是仓库里有构建桌面端相关的代码 让AI帮我扫了一下源码和本地的程序 暂时没有发现存在上传相关的代码（CLI+WebUI） 图片 （点击了解更多详细信息） 正文 没有选择的其他Agent 在用的国模多了之后，我想着或许我需要一个harness做的还不错、并且最好能够提供 图形化界面 的agent工具。 Pi我比较喜欢，但比较可惜的是Pi只有CLI界面，图形化界面需要通过插件或者第三方软件来实现。插件用过pi-web，不过比较可惜和我自己装的subagent插件不是很兼容；站内的PiDeck、Pi Desktop、codexhost我都已经用过了，主要考虑到每个人的插件都不太一致，不一定图形化界面会兼容插件的显示， 所以最终还是把Pi作为了CLI来使用 。 那么还有什么呢？DSH提供了webui，不过这个东西破坏性变更较多，一更新插件炸是很正常的事情，并且即使不装插件目前还是rc或者alpha版本，不太适合上生产， 因此装了但没有作为主力 ； 依旧说着说着来个破坏性更新 CodeX的CLI部分是开源的，但是桌面端部分不是，而且对于自家GPT模型的优化较多，不太好确定对于国模有没有负优化的情况，而且部分插件如computer use在使用第三方模型不使用GPT账号登录的时候是会失效的，故也没有考虑； opencode提供了桌面端，但是opencode的harness做的实在是太烂，在诸如frontier harness eval等评测上往往处于垫底的水平，故也没有使用 Why Kimi Code 有个朋友给我展示了他使用的kimi webui（在手机上）我一开始感觉这个webui在移动端上的使用做的还不错，于是就下了下来看了看。 CLI+WebUI的部分是开源的，至于桌面端说实话看了一下和WebUI的区别不是很大，于是并没有安装，等于用的部分已经是完全开源的了。 开源+可视化界面+基本开箱即用的功能+支持自定义第三方模型，于是就在保留Pi和CodeX的同时，把Kimi Code作为主力用了一周。下面是我觉得比较好的点。 第三方模型接入还算不错 在TUI和WebUI中，都有接入第三方模型的设置。预设有国内几家的Coding Plan或者API，如果使用的是opencode go或者cline这种订阅，在 models.dev 这个选项中也可以添加，只要是models.dev这个网站记录了的，都可以在这里添加进来。 同时如果是自己服务器的网关，也可以通过自定义的方式添加，该支持的格式都支持了。 但是美中不足的是，推理强度、支持模态，不能直接在WebUI中进行设置 ，这个如果可以像ZCode那样直接在图形化界面中设置就好了。需要自己去配置文件里面配置一下思考强度。 我把智谱和DS，以及gemini都接了进来，目前暂时还没有发现什么有问题的地方，在Cline之前可以钉上游的情况下，缓存命中率可以达到99%。 主子代理的设计 没有把Pi作为主力的还有一个原因，就是Pi上目前使用子代理的插件，暂时多多少少还有一些问题，实现都不算优雅。再加上之前使用官方max20x订阅用CC的时候，出现了Teammates功能中，两个子代理同时修改一份文件抢活干最后导致文件改的一团糟的情况，让我一度对CC的Teammates敬而远之，用国模就更不敢用了。 其实硬要说，国产harness的Agents Team的功能暂时我都感觉大差不差，不过Kimi Code的子代理允许设置子代理池，并且可以通过自然语言简单进行描述。用过还没有变成屎山的OMO插件的朋友应该知道，这样子就可以把合适的模型分配给对应的子代理。简单活就用便宜快速模型，稍微难一点的就用厉害但是贵一点的大模型。 我没买Kimi官方订阅 另外cline和command code不敢用K3 不然子代理池还可以加上一个用来解决难题的模型 Kimi Code只预置了3中子代理 还好 不像OMO那样都快三省六部制了 每种子代理的权限不同 Coder作为通用子代理 和主代理基本权限相同；Explore没有写文件的权限；而Plan则连shell命令都没有。 同时subagent已经限制了不能再派发孙代理， 话说孙代理子子孙孙无穷尽这事还是CodeX之前干的 。 另外你还可以进行自定义subagent角色，不过我偷懒就没有自己去写了。 蜂群模式和Tower模式 蜂群模式其实就像CC的Teammates模式一样，主代理会把功能拆分给子代理去实现。配合我们上面说的预置角色和自定义的子代理模型池是非常好用的。而且也没有出现我之前使用CC时子代理和子代理打架、主子代理打架的情况。 这个模式似乎用户即使不显示启用，主代理也会自行选择是否要使用。因此在使用Kimi Code的过程中，我明显感觉到其派发子代理的积极性会高一些， 当然这也会带来一些子代理需要重新读取一部分文件或者创建缓存，可能会导致使用的Token偏多的情况 。不过也可以降低主代理的上下文压力，仁者见仁智者见智吧。 但开的子代理数量我觉得还是能接受的，有的时候 从零开始 的项目其最多给我开了7个子代理，一批4个一批3个，我觉得还是可以接受的程度。 另外还存在一个实验性的设置，在官网文档中好像没看到，得在TUI的实验性设置中打开——Tower模式。 Tower模式更像CodeX走git worktree的方式，这个其实也有好处，一个任务就是一个worktree，不会说出现我们上文所说同时修改一个文件导致的打架的问题。 主要有控制塔、worker, reviewer三个角色。控制塔不写代码，只负责规划、派活、路由、合并等任务；worker顾名思义就是实现代码的，reviewer则是和主代理模型一致，负责审查worker的实现。 另外这个功能中子代理之间是可以互相通信的。不过因为是实验性功能，所以我也暂时还没有尝试过。 不错的移动端UI 得先说一嘴，ZCode我记得是登陆了账号就可以给你一个公网链接，让你在外面就可以通过链接直接打开移动端页面访问自己电脑端上的ZCode进行操作。但是Kimi Code如果想要有个公网访问的话，需要你开他们的会员。 但是！Kimi Code本身就已经有WebUI了，而且你只需要使用 kimi web --host 启动，那么就可以在局域网内访问链接来使用WebUI了。 那么也就是说，该使用TailScale了 。这个就不多讲了，TailScale的配置还是很简单的，问问AI就行。 这个WebUI说实话做的还是可以的，只不过比较可惜目前侧边栏的功能感觉做的还是没有ZCode好， 建议学习一下友商已经开源的部分 。 需要注意的权限模式 Kimi有三种权限模式，第一种就是什么都需要批准的模式，这个我们就不多说了。 剩下的两个，一个是yolo，一个是auto。但是这个yolo其实是阉割版的yolo，并不是真正的yolo，真正的yolo其实是下面的auto。 在阉割版yolo中，部分敏感行为比如rm -rf或者读取秘钥等等操作，会弹出权限提醒让你进行确认；而auto模式中，默认的提示词为你不在电脑前面，甚至askuserquestion这个工具都被禁用，所有的决策和选择都由agent帮你决定 说实话auto模式把ask user question这个工具都关掉了我是有点意外的，因为我记得cc即使打开了yolo还是会向用户进行提问的。所以平常我更多还是使用阉割版的yolo模式，有的时候我还是希望agent能问我一下决策我决定之后它再去执行。 写在最后 基本上目前使用起来的感受就是这些了。其实Kimi Code也算有个4个多月的时间了，看了一下他们git和更新日志感觉更新也算比较勤快的，不过可能是确实比起其他家的harness上来说没有什么算的上特色的地方，但实际使用起来感觉还是很不错的。 希望他们从友商那里多优化优化一下他们webui的功能吧。 2 个帖子 - 2 位参与者 阅读完整话题

  • 情报分类：服务器与云资源
  • 分类依据：内容涉及服务器、云资源或网络线路
  • 信息来源：服务器 / LINUX DO - 最新话题
  • 发布时间：2026/9/22 18:16:01