Qwen Code 贡献记录

Web Shell 在侧栏列出无工作区会话。daemon 会拒绝删除仍有活动提示或客户端附着的会话；批量删除接口在 HTTP 200 响应的逐项 errors[] 中报告 session_busy。

较早的 #12636 改动禁用了当前行的 Delete。维护者将先离开再删除的另一方案留给后续 Issue #12669。当前标签页可以 detach，但其他标签页仍可能附着在同一会话上。

在未修改的源码基线上，当前无工作区会话行虽然显示 Delete，却始终禁用。若只放开按钮，本标签页仍附着时就会请求删除，并收到 daemon 的 session_busy。

普通 New task 的返回值不能证明 detach 成功：clearSession 会吞掉 detach 异常，SDK 在缺少 clientId 时还会把 detach 当作空操作。侧栏列表计数也可能滞后于实时状态。

上游对 PR 首版的审查另发现一项 Critical：异步 detach 或删除进行中，Cancel 等关闭入口仍能关掉确认弹窗，但删除会继续执行。

客户端缺少一条针对当前行的有序流程：先确认删除，再离开准确的原会话，证明 detach 已完成，最后请求删除固定的原 ID。daemon 的繁忙保护本身正确，应当保留。

已有回调丢弃了 New task 的执行结果，而普通 clearSession 路径可能掩盖 detach 失败，两者都不足以充当删除请求的前置保证。

侧栏两处 Delete 入口现在允许空闲的当前无工作区会话进入原有确认框。确认时再次检查 App 实时运行状态和原会话 ID；运行中的工作仍受保护。

删除专用、可等待的回调复用 createNewSession({ kind: 'global' })，并启用严格的 clearSession 检查：要求预期会话 ID 和两处匹配的非空 clientId，上报 detach 失败，等待 detach 完成后才按固定原 ID 请求批量删除。

只有 removed 或 notFound 才移除列表行。逐项 session_busy 或请求失败时保留行并提示错误；已离开时还会刷新列表。daemon 的繁忙保护及独立的 /delete 选择器均未修改。

上游审查后，我在操作期间禁用弹窗的所有关闭入口，并为 onClose 加上同步 busy 防护；detach 或删除未结束时确认弹窗保持可见。

按审查建议，提交 a2b39eb405 在删除进行中显示进度（Deleting... 与 aria-busy），会话附着就绪前保持 Delete 禁用，把离开失败和导航取消统一成同一条提示，移除可选回调的无效分支，并补上重试、刷新和严格 detach 的回归测试；英文和中文设计文档同步更新。

daemon 在启动时会预热一个独立的 ACP 子进程，好让第一个会话不必承担冷启动开销。代价是存在一个时间窗口：daemon 已经对外提供 HTTP 与 WebSocket 服务，而这个子进程还在解析命令行参数、初始化配置。

ProcessRegistry 登记 daemon 派生的全部子进程，并负责在关机时给出它们确实都已消失的证明。ACP 子进程以 detached 方式派生，自己成为进程组组长，因此向负的进程组标识发信号可以一次触及整棵进程树。

自 #10140 起，关机契约被刻意收紧：除非能同时证明子进程已退出且其进程组已不存在，daemon 就以非零状态码退出。放宽这个证明的任何一个分支都属于涉及安全性的改动，这也是它不能走自动修复路径的原因。

在 macOS 与 Node.js v26.8.2 上，在预热尚未完成时向 daemon 发送 SIGTERM，它会以状态码 1 退出。持久日志里出现了向进程组发送 SIGKILL 失败、ACP 子进程关机失败和 daemon 关机不完整这三条记录；但事后用 ps、进程组查询和 lsof 检查，都确认没有任何残留。

临时插桩还原了完整时序：向进程组发送的 SIGTERM 成功；约两毫秒后预热中止逻辑调用了同步 kill；此刻子进程其实已经结束，但 Node 还没有派发它的 exit 事件，因此向进程组发送的 SIGKILL 返回 EPERM；随后 exit 事件到达，整个进程组消失。一个使用 detached 子进程的最小 Node 探针可以稳定复现同样的内核与运行时可见时序。

这个现象最初是在验证 #12277 时撞见的，因此我用未修改的官方提交做了一个隔离构建，完全不调用 Local Control 再测一次。同样出现 EPERM 和状态码 1，这排除了端口修复是原因的可能，也让它成为一份独立报告而不是那个分支的回归。

进程组信号路径只在 ESRCH 时摘除进程组，其余 errno 一律用空值合并赋值写进清理证明错误，于是第一个错误就被锁存在整个子进程生命周期内，而整份文件里没有任何重置点。干净路径随后会在到达非干净退出判定之前就把这个锁存的错误抛出来。因此只要出现过一次瞬时错误，一次完全干净的关机也会变成非零退出。

这份文件自己前后矛盾：判断存活进程组的辅助函数就在把 EPERM 当作致命错误的信号路径下方十五行，却明确容忍 EPERM；直接杀子进程的调用更是吞掉所有错误。也就是同一个 EPERM，从一个调用来就被忽略，从另一个调用来就致命；而全仓库的既有约定站在容忍这一侧——进程存活性辅助函数把 EPERM 读作进程仍然存活的正面证据。

第二层原因独立存在于子进程一侧：完整的 ACP 信号处理器安装得太晚，因此在启动期到达的 SIGTERM 会走默认动作，子进程按信号退出，父进程依据其严格契约正确地判定这是非干净退出。只修第一层之后，daemon 仍然以 1 退出，错误变成关机期间非干净退出——第二层是这样被发现的，而不是被猜测出来的。

进程组信号路径现在按进程组暂存 EPERM，而不是全局锁存。当后续的存活性检查或进程表证明该组已经消失、或只剩僵尸与终止态条目时，这个组和它对应的暂存错误会被一起忘掉。如果确实有活着的成员一直存活到十秒的截止时间，原始的 EPERM 会被取回并计入最终失败。其余 errno 仍然保持失败即拒绝的行为。

子进程改为分三段安装信号处理，并做同步交接：先在 CLI 打包入口装一个最轻量的处理器，进入主启动流程后换成会执行通用清理的启动期处理器，等会话、writer、MCP 与传输状态都具备后再换成完整的受管 ACP 处理器。每一段都先装上新处理器再移除旧的，因此不存在监听空窗。

如果信号在交接完成之前到达，待处理的关机会被转交给完整处理器，同时阻止较早的清理 Promise 直接退出进程，以免跳过 writer、会话与 MCP 的清理。这条新路径以精确的 ACP 参数、daemon 标记和 daemon 私有的父级能力三者同时成立为前提，因此普通命令行使用、编辑器直连 ACP 以及父进程严格的非干净退出判定都不受影响。

qwen serve 启动的常驻进程默认只监听 127.0.0.1，也就是只有本机能连。Local Control 让同一局域网内的手机也能访问它，做法不是把主监听改成对外开放，而是在同一个进程里再开一个 HTTP 监听器，绑在选定的局域网 IPv4 地址上，运行的仍是同一个 Express 应用。

这两个入口的认证强度必须不同。主监听器认的是 daemon 运行令牌，等同完整 API 权限，包含代码执行；局域网监听器只认一次性的配对令牌，它放在 URL 片段里并生成二维码供手机扫描。区分权限靠的是请求从哪个监听器进来，因此每个监听器上记录的 authority 与 origin 同时供 HTTP 的 Host 校验和 WebSocket 的 Origin 校验使用。

TCP 绑定的是地址与端口的组合，因此 127.0.0.1:51873 和 10.131.53.163:51873 正常情况下是两个互不冲突的端点，这正是原代码敢直接复用主端口号的理由。冲突只在那个局域网端点本身被占用时才发生，而 --port 0 让这件事变得相当可能：操作系统分配临时端口的池子，和本机所有出站 TCP 连接挑选源端口用的是同一个。

在未修改的源码基线上，以及在官方 npm 0.24.1 包上独立复现：先用一个临时 socket 占住局域网端点，再请求开启 Local Control，会得到 HTTP 500，错误码为 local_control_enable_failed，底层错误是 listen EADDRINUSE: address already in use 10.131.53.163:51873。

daemon 日志里只记录了这次请求返回 500，没有记录 EADDRINUSE 这个原因，因为运行期错误日志处理器要等首次绑定成功之后才注册。用户看到的是一个查不出原因的失败；状态本身是正确的：active 为 false，没有残留的 Local Control 监听器。

释放占用的 socket 后，完全相同的请求返回 200，此时 lsof 显示同一个 daemon 同时监听 127.0.0.1:51873 和 10.131.53.163:51873。这证明同一个端口号绑在两个本机地址上本来就没问题，主监听器本身不是这次冲突的来源。

LocalControlService 在绑定之前就把局域网端点算好了：它读取主 daemon 端口，据此拼出 authority、origin 和配对 URL，注册监听器身份与凭据，之后才用同一个端口调用 listen。端口的选择和端点元数据被耦合在了一起。

正因为元数据先于绑定生成，只改传给 listen 的端口是不够的：配对 URL、跨域 origin、监听器身份和对外返回的状态都会继续指向旧端点。结果要么放行了本该拒绝的请求，要么把配对 URL 发给的那台手机自己挡在门外。

失败路径本身会正确撤销临时状态，但没有换端口重试，错误也从未进入持久日志。路由把所有非已知网卡或目标错误统一映射成一个笼统的 500 local_control_enable_failed。

局域网监听器仍然优先使用主端口，只有在错误确实是带类型的 EADDRINUSE 时，才回退一次到端口 0。其他 errno 照常失败，避免用盲目重试掩盖权限或地址问题。

正常路径和回退路径现在都无条件地在同步的 listening 回调里，从 server.address() 推导端点，这去掉了原先正常路径先于绑定预算元数据的双路径设计。authority、origin、配对 URL、监听器身份和对外状态全部依据实际拿到的端口填充。回退开始时先移除旧 origin，并把监听器标记为缺少 authority 的 Local Control，使 Host 校验在新身份注册完成前默认拒绝。

最终绑定失败不再统一返回一个不透明的 500，而是映射成可操作的错误码：409 address_in_use、403 bind_denied 和 409 invalid_address；同时注入既有的 DaemonLogger，让回退和最终失败都能进入持久日志。日志调用单独包了异常边界，日志写入失败不会回滚一个已经成功启动的监听器；运行令牌和配对令牌都不写入日志。

Web Shell 编辑器用带有准确 [start,end) 区间的 CodeMirror inline tag 表示选中的文件引用。提交时将 tag 序列化进 prompt；UserMessage 根据 inputAnnotations 把选中的引用显示成 chip。

用户可以手工输入相同的序列化文本。仅凭文本匹配，无法区分普通文字与通过文件选择器选中的引用。

在 literal @foo then [foo] 中，编辑器正确地把第二个 @foo 作为 chip。发送后，注解却指向前方普通文本的 [8,12)，而不是实际选中 chip 的 [18,22)，消息记录因而错误表达了用户的选择。

本人的组件复现中，原始 prompt 字符串未变；它证明了注解及界面错配，未证明模型输入或文件解析发生变化。

提交时利用编辑器的真实 inline placement 构造 prompt，生成 inputAnnotations 时却丢弃这些区间。注解 helper 从头用 indexOf(serialized, cursor) 搜索，因此较早的同名字符串抢占了 chip 的注解。

渲染校验只比较注解文字与对应的文本片段。两处都包含 @foo，所以这一检查无法识别位置指错。

我调查源码，将真实 CodeMirror 编辑器、提交 hook 与 UserMessage 串联复现，核对上游相关报告，并按 Bug Report 模板提交 #12980；未提交产品补丁。

维护者 yiliang114 编写 #12992，将真实 chip placement 传入注解生成，并计入 prompt 前缀与 shell 模式偏移。审查后补充回归测试；自定义 provider 的 placement 失配时，仅在序列化文本全局唯一的条件下回退到文本匹配。

Qwen Code 在普通启动时会清理根目录 mtime 超过 30 天、看似没有用户工作的 agent worktree；修改子目录里的文件不一定刷新这个时间。修复前的文档曾承诺用户命名的 worktree 永不自动清理。

用户侧 enter_worktree 与 agent 隔离共用创建 API，而校验器允许精确的 agent-<7hex> 名称，因此目录名不能证明 worktree 的来源。

修复前，用户命名的 worktree 若恰好符合 agent-<7hex> 格式、根目录 mtime 超过 30 天，且没有已追踪改动或分支独有提交，就可能被选中清理。

清理路径随后强制删除该 worktree。未追踪文件不在 Git 历史中，其被删内容无法从 Git 恢复。

同样的漏检当时也可能影响真正由 agent 创建、留有新文件的 worktree。这个更广的风险来自源码路径分析；实际运行复现使用的是用户命名的 worktree。

清理器把目录名格式当作 agent 来源证明，但用户 worktree 的名称校验也允许相同格式。修复未加入持久来源标记。

修复前的脏检查使用 git status --porcelain --untracked-files=no，新文件对它不可见；随后的 git worktree remove --force 会把新文件删除。

我追踪了源码路径，在一次性 Git 仓库中调用实际清理函数复现问题，查找上游重复报告，并按项目 Bug Report 模板提交 #12735；本人没有修改产品代码。

两项已合并 PR 均由维护者编写：#12763 主要处理相邻的 Issue #12758，并加入覆盖未追踪及未豁免 ignored 内容的共用检查；#12739 为 #12735 补充真实 Git 回归测试、保留原因日志和文档。两个 PR 都不包含本人提交的代码。

给 Qwen Code 提的 Pull Request 会由一个 AI 审查机器人评审。它发出的每条意见都以一个纯文本的严重级别标记开头：**[Critical]** 表示必须修，**[Suggestion]** 表示可改可不改。没有单独的级别字段，评论开头的这个标记就是唯一的信号。

Autofix 是一个 GitHub Actions 工作流（qwen-autofix.yml），它会接管 Pull Request，一轮一轮地按这些意见自动推送修复。为了防止 PR 因为不停采纳建议而越改越大，它从第 6 轮起（或者改动量增长超过预算时提前）切换到 Critical-only 模式：此后只有 Critical 意见、正式的修改请求、失败的检查和合并冲突还能让它改代码，建议只记录为“延后处理”，留给人决定。工作流用 jq（处理 JSON 的命令行工具）读取每条评论的级别，所以一次文字匹配，就决定了机器人接下来做什么。

审查意见会引用证据来证明问题存在，比如把测试输出、日志或 diff 贴进代码块。8 月 28 日合并的 PR #9740 把这条规则扩展到了建议：从此建议也必须附上证据。而审查功能自己的测试输出里，本来就印着 **[Critical]** 这几个字，于是这串文字开始频繁地以“被引用的证据”的身份，出现在建议里。

#10216 是 Autofix 自己开出来的 Issue。它在处理 #9740 时确认了这个误判，但修复要改 qwen-autofix.yml：既不在那个 PR 的范围内，也是 Autofix 被禁止修改的文件。于是它把这条发现延后成 Issue，交给人来修。仓库的设计文档 docs/design/review-tone.md 早就把这项修复列为可以做的后续工作。

一条正常的建议以 **[Suggestion]** 开头，但可能在代码块里的测试输出中引用 **[Critical]**。被引用的只是证据，不是这条评论自己的级别；旧的工作流却在整段正文里找这串文字——工作流里有 12 处、验证脚本里有 4 处，用的都是不看位置的 contains("**[Critical]**")。

进入 Critical-only 模式后，这条建议就会被当成必须修的问题。机器人可能因此去改代码——这恰恰是 Critical-only 模式要阻止的事；同时这条建议会从“延后处理”列表里消失，没人知道它还没处理；每位作者的反馈配额也会算错。

回复让问题更严重：行内讨论里的回复，沿用讨论串第一条评论的级别。所以一条引用了该标记的建议，会让它下面的回复也显得必须处理，尽管两者都不是。

这不是一处笔误，而是同一个按文字匹配的判断重复了 16 次。工作流里有三个地方要用这个结果——告诉修复程序要做什么、延后处理列表、每位作者的配额统计——每处又各自读四种评论：审查评论、行内讨论的第一条、回复的上一条，以及 Issue 评论。只修一处，工作流内部就会前后矛盾。

新规则只看评论源文本的开头：先跳过开头的空白、HTML 注释和看不见的 Unicode 格式字符，再看标记。它刻意不把所有可能显示为空白的 HTML 标签和实体都当成看不见的内容；文档也改为如实写出这个较窄的规则，不再说成是按页面上显示的文字判断。

#9740 也要求审查机器人把证据里引用的标记处理掉。这能减少新的误判，但管不了旧评论、其他机器人、维护者，以及将来会写评论的其他程序。稳妥的做法是在工作流读取这个信号的地方把关；真正的 Critical 评论，以及理应沿用它的回复，照常生效。

16 处判断现在都遵循同一条规则——只有位于评论开头的标记才算数——分别写在容纳它们的 9 个独立 jq 程序里：工作流 7 个、验证脚本 2 个。正文后面引用的标记不再改变级别；真正写在开头的 Critical 依然有效。

生成审查评论的代码也加了对应的保护。一条仍带着 Critical 发现的评论，如果前面被插入了开场白、配额说明或降级提示，就会在最顶上补一个简短可见的 Critical 标题，保证它依然能通过更严格的判断。

测试直接从 YAML 和 shell 文件里抽出真实的 jq 程序，拿样例评论去跑：引用的证据、直接的评论、讨论串与回复的继承、延后列表和配额统计。后续提交让各测试共用一份“引用了 Critical”的样例，把超出配额时的提示从“标上 **[Critical]**”改成“评论以 **[Critical]** 开头”，并把设计文档 review-tone.md、Autofix 的说明和审查机器人的发帖说明都改成新规则，还加了一条测试，防止旧说法被写回去。

在 Qwen Code 里，模型是通过调用工具来做事的：它写出工具名和一组 JSON 参数，程序执行后再把结果交回给模型。send_message 就是其中一个工具，由主智能体（也就是模型本身，不是用户）用来给别的智能体追加指令。收到的一方会把它当成要做的工作，可能接着去改文件、跑命令，所以消息送错对象不是小问题。

主智能体可以指挥两类智能体，它们都和主智能体并行、在后台运行，而且都是用同一个 Agent 工具生出来的，区别只在于调用时有没有传名字。不传名字，生出来的是一个为一件事专门启动的匿名智能体，登记在后台任务表（BackgroundTaskRegistry）里；先用 team_create 建好团队再传名字，生出来的是一个长期在队里的队友，比如 qa-reviewer，登记在 TeamManager 管理的团队名册里。

这两类没有交集：队友从不进入后台任务表，所以没有 task_id，list_agents 也不会列出它；后台的匿名智能体没有名字，用 to 也找不到它。没有任何一个智能体同时拥有这两种地址，所以一次正确的调用只能填其中一栏。

task_id 这个名字很容易让人误会。它不是还要再配一个收件人的“订单号”，而是那个智能体自己的编号，启动时直接返回，形如 general-purpose-<后缀>。后台智能体只为一件事而生，这件事的编号就是它的编号。偏偏团队里又确实有带负责人的任务（共享的 task_list），“任务”这个词两边都在用，就更容易混。

修复前，工具允许一次调用同时填两栏，并且先看 task_id，只有它为空时才看 to。这不是事先定好的规则，只是 if/else 的先后顺序，而且没有检查两栏是否同时有值。于是，如果一次调用同时带着 to: "qa-reviewer" 和一个真实存在的 task_id，消息会送给那个后台智能体，工具照样返回成功，qa-reviewer 却什么也没收到，也没有任何地方提示消息送错了。收到消息的智能体会把它当成工作去做；如果它已经完工，这条消息还会让它重新动起来。

如果 task_id 查不到，调用会报“找不到后台任务”，而 to 即使填对了也被无视。把 qa-reviewer 同时填进两栏也是这个结果——如果以为两栏描述的是同一个智能体，这样填再自然不过。

把队友的名字填进 task_id 一定会失败，因为队友从不进入后台任务表。那条报错说的是实话，却把人往错的方向引：它只提后台任务，不提队友，也不说该怎么改。站在模型的角度，这句话甚至自相矛盾，因为 qa-reviewer 明明就在后台跑着；再去 list_agents 里查也没用，这个列表本来就不显示队友。接下来模型可能反复重试，可能以为队友没了而把活重做一遍，也可能干脆放弃这条指令。这些后续在原始报告里并没有出现，是代码允许发生的情况，不是观察到的事实。

JSON Schema 只把 message 设为必填，两个收件人字段都是可选的。代码里写的是一个先后顺序——先看 task_id，再看 to——却没有写出真正该成立的规则：一次有效的调用必须在两者中选一个，而且只能选一个。

按 task_id 查不到时，方法直接返回，不会去看这个值是不是某个队友的名字。其实 TeamManager 手里就有团队名册和名字匹配的规则。

维护者用真实的 CLI 从头到尾跑了一遍，又发现一处问题：测试辅助代码可以直接读 llmContent 和 returnDisplay，但工具调用失败时，CoreToolScheduler 交给模型的是 error.message。提示本身算对了，却一直到不了模型那里，直到把它也写进这个字段。

这条规则没法直接写进 schema。send_message 以前就用顶层的 oneOf 规定过“二选一”，结果在 Anthropic 的模型上整个工具都用不了（#7984），后来 oneOf 被删掉了。所以只能在运行时检查。

两栏都填的检查放在 validateToolParamValues，也就是每个工具都有的参数校验入口。它在调用创建之前运行，所以有歧义的调用会直接以 INVALID_TOOL_PARAMS 结束，调度器、任务队列和 TeamManager 都还没来得及投递。

只有在 BackgroundTaskRegistry 确认查不到之后，工具才去看当前的团队。它复用现有的 findMemberByName，所以写成 "QA Reviewer" 也能对上规范的 qa-reviewer；只有名册里真有这个队友，才会提示改用 to。

最后一处生产代码改动只有一行：匹配成功时，把已有的提示追加到 error.message 上，也就是 CoreToolScheduler 真正交给模型的那个字段。发给模型服务商的 schema、SEND_MESSAGE_NOT_FOUND 错误类型、任务队列和 TeamManager 的投递方式都没动；无关的未知 task_id 仍然得到原来那句错误，一字不差。