Kimi 把自动派子智能体当缺陷修了

编程智能体一次任务开几个子智能体，在 Kimi Code 里从模型自己决定改回了由用户开关决定。月之暗面 10 月 25 日发布的 2.3.2 版，把这件事写在「缺陷修复」一栏，而不是功能调整。

我们的看法是：这次改动的分量不在功能本身，而在归类。一家把「最多同时派出 300 个子智能体」写进宣传的公司，自己承认模型主动分身是需要修的毛病，说明多路并行在日常编程里更适合做成用户打开的选项。对读者更实际的一层是成本：同一个模型做同一件活，默认开一路还是开四路，调用模型的次数就不一样，比较编程工具时这一项和每百万词元的单价一样要看。

发生了什么

据 Kimi Code 官方更新日志，2.3.2 版有两条改动：一是默认直接处理任务，不再主动开子智能体，需要委派时要在消息、AGENTS.md（仓库里给智能体的说明文件）、技能或已开启的多智能体模式里明确提出；二是集群（swarm）只在用户打开集群模式后才会启动，模型不能再自己调起，因此无头命令行 kimi -p 和 Zed 这类通过 ACP 协议接入的编辑器里，暂时用不了集群。

两条改动对应的代码合并请求写得比更新日志具体。据 PR #4386 的复现说明，在中等规模的仓库里提「全面调研一下这个仓库」这类请求，模型通常在前 1 到 5 步就调用子智能体，一次并行开 2 到 4 个，而用户并没有要求委派。开发者找到的原因是提示词：好几处在鼓励模型委派，例如「预计要搜索 3 次以上就开探索子智能体，并优先同时开多个」，却没有一处要求先得到用户同意。修法是删掉这些句子，加一条硬规则「除非用户明确要求，否则不开子智能体」，并写明任务大、要求「深入、彻底」都不算要求。

据 PR #4384，集群那条问题更大：集群工具对主智能体一直可用并且默认自动放行，模型调用后会一次启动大量子智能体，上限 128 个。这一处没有只靠提示词，而是在执行层拦截：集群模式没开，调用直接返回错误。合并请求的影响表也列得清楚，打印模式和 ACP 客户端里的集群「无退路」，依赖旧行为的脚本要自己改。

另据 AlphaSignal 的报道，Kimi 桌面端 1.1.3 版采用了同样的单智能体默认值；这一条我们没有找到官方发布说明，按媒体报道处理。

为什么重要

先看月之暗面自己怎么讲并行。据 Kimi 帮助中心的 Agent Swarm 页面，K2.6 起集群可以同时部署最多 300 个子智能体、单个任务执行 4000 次以上工具调用，比单个智能体顺序执行快 4.5 倍。这些是企业宣称，口径没有写明是哪类任务。速度确实可能更快；分析推断：每个子智能体都要各自读文件、各自调用模型，依据是两份合并请求描述的委派方式，所以并行越多，单件活消耗的词元通常越多。

分析推断：现在比较编程工具，大家习惯拿模型单价和单个基准的每题成本做比较。但在真实使用里，一件活调用几次模型，越来越由工具的默认编排决定。依据是 PR #4386 的复现：同一句「帮我调研仓库」，旧版会开 2 到 4 个子智能体并行，新版由一个智能体自己做。合并请求没有给出前后的词元数对比，所以我们不写具体倍数；可以确定的是，默认值变了，同一模型的单件成本就随之改变，而这在模型发布表里看不到。

第二层是可复现。默认自行分身时，同一个提示词这次开两路、下次开四路，结果和花费都不稳定。AlphaSignal 把额度耗尽、失败难恢复、运行难复现列为可能的原因，这是媒体的分析，月之暗面的两份合并请求只写了「用户没要求」，没有提成本。

最强反方

最有力的反驳是：自动委派本来是好设计，这次是矫枉过正。子智能体能把大量中间文件内容挡在主对话之外，这正是旧版提示词里写的理由；对大仓库调研、批量排查这类能拆开的活，并行既快、主线程的上下文也更干净，总花费未必更高。让用户每次都要明说，等于把一项本该由模型判断的事推回给人，新手反而用不上最强的能力。

我们在两处让步：第一，月之暗面没有公布任何成本或质量数据，我们不能说自动委派「更贵」或「更差」，只能说它让花费变得不受用户控制；第二，能拆开的大活确实适合并行，所以集群和子智能体都还在，只是换成用户打开。我们仍坚持判断的原因是：开发者自己把它归为缺陷，并且在执行层而不只是提示词层拦截集群，并且在 PR #4384 里写明这是「根本修复」、不只靠提示词约束，说明他们把它当成要在代码层堵住的问题。

我们不知道什么

我们不知道旧版自动分身让用户多花了多少词元，合并请求没有给数字；不知道有多少用户和脚本依赖了打印模式里的集群；不知道 Kimi K3.1 Pro 对外公布的智能体类成绩，是在开不开子智能体的设置下跑出来的；也不知道这是长期取向，还是在集群改进之前的临时止血。子智能体那条只改了提示词，模型会不会在某些情况下仍然自行委派，需要实际使用来检验。

接下来看什么

看月之暗面会不会公布改动前后的单件词元或额度消耗；看桌面端的官方说明；看其他编程工具在发布模型或基准成绩时，会不会写明默认开几路子智能体。对正在比较编程工具的团队，一个可以当天做的核对是：拿同一个任务分别在默认设置和关闭并行的设置下跑一次，记下调用次数和花费。