Kimi Work 把 300 个 Agent 搬进桌面：普通人需要的不是更多聊天窗口
周白｜OC 产品体验编辑
周白｜OC 产品体验编辑
据 Kimi 官方介绍，Kimi Work 是面向 Mac 和 Windows 的本地工作 Agent，可读取项目文件、通过 WebBridge 操作浏览器、执行定时任务，并按任务复杂度组织最多 300 个子 Agent 并行处理。
一句话结论： Kimi Work 的重点不是让用户观看 300 个 Agent 忙碌，而是把本地文件、浏览器和持续任务放进同一工作空间；并行数量只有在结果能合并、成本可控时才有意义。
网页聊天适合问一个问题，却不适合管理一项持续几天的竞品研究。用户要反复上传文件、解释目录、打开网页，再把结果搬进文档。Kimi Work 试图直接驻留桌面，让任务围绕项目而不是围绕一次对话存在。
WebBridge 让 Agent 操作真实浏览器，适合需要登录状态、动态页面和多步骤交互的任务；本地文件连接则让它读取用户已有材料。两者组合后，Agent 才能把网上数据与内部文档放到同一份交付物中。
“最多 300 个子 Agent”很吸引眼球，但并行并不自动更聪明。搜索不同公司可以拆开，修改同一份报告则容易重复、冲突和浪费 Token。用户更需要看到每个 Agent 做了什么、哪些来源重复、总成本多少，以及怎样中途停止。
它与 ChatGPT/Codex 合并方向其实相似：聊天负责表达目标，执行层负责文件、工具和长期工作。区别在于 Kimi 更强调并行研究、本地材料和金融数据。最终胜负不会由 Agent 数量决定，而是由完成结果后还需人改多少决定。
关键事实
- Kimi Work 于桌面客户端提供 Work 模式，目前仍处 Beta。
- 支持本地文件、WebBridge、定时任务和最多 300 个子 Agent。
- “本地 Agent”不代表所有推理都在本机完成，模型服务仍可能依赖云端。
OC 判断
Kimi 正把竞争从模型排行榜拉到工作入口。真正需要改进的是任务可见性、权限和结果合并，而不是把“同时启动更多 Agent”当作产品价值本身。
为什么重要
- 对开发者： 并行任务需要去重、预算和可恢复状态。
- 对企业： 本地文件与浏览器权限必须分项目授权。
- 对用户： 先用可验证任务测试，别从一开始就放 300 个 Agent 出去。
评论
围绕这篇文章补充信息、提出问题或分享观察。