Skip to content

[Bug] 子代理偶发以残缺工具集启动(缺 Read/Write/Edit/Bash 等核心工具),重试可恢复 #1271

Open

Description

@sun603

提交前确认 · Pre-submission checklist

  • 我已搜索过现有 issue,确认这不是重复 / I searched existing issues and confirmed this isn't a duplicate.
  • 我已阅读 CONTRIBUTING.md / I've read CONTRIBUTING.md.

问题类别 · Category

稳定性 / 崩溃 · Stability / Crash

涉及的 Agent 框架 · Agent framework

ZCode Agent(自研)

严重程度 · Severity

影响体验 · Major (功能可用但体验受损 / works but degraded)

复现频率 · Reproducibility

偶现 · Sometimes

问题描述 · Description

主会话通过 Task/Agent 派生子代理时,偶发地子代理拿到的工具清单缺少整个
核心工具组:Read / Write / Edit / Bash / Grep / Glob 一个都没有,只剩
WebSearch、browser-use、文档查看器等插件类工具。子代理无法执行任何文件
操作,只能报告无可用工具后结束。同一任务立即重新派生即恢复正常。

复现步骤 · Steps to reproduce

无稳定复现步骤,偶发(大约每十几次派生出现一次),多在系统负载较高或
会话刚启动时出现。重试必好,符合竞态特征。

期望表现 · Expected behavior

子代理首轮请求应在核心工具集(或至少 ToolSearch)就绪后再发出;
或检测到工具清单未就绪时自动重发该请求,而不是让子代理带着残缺
清单跑完整轮。

实际表现 · Actual behavior

  • 工具是延迟挂载的(deferred tools + ToolSearch):正常子代理首轮请求
    只带约 7 个基础工具(Read/Write/Edit/Bash/Skill/AskUserQuestion/
    ToolSearch),随后数秒内随插件/MCP 注册增至 20+。
  • 出问题时缺的是整个核心工具组,推测是首轮请求在某些时序下抢在核心
    工具注册完成之前发出,且该子代理之后整个生命周期都不会补挂,
    只能靠父级重派。

ZCode 版本 · ZCode version

0.17.0

设备 / 系统 / 浏览器 · Device / OS / Browser

Ubuntu 24.04

截图 / 录屏 / 日志 · Screenshots / Recordings / Logs

可能与 #1012(并行派生子代理第 0 轮即 "Turn execution failed")同源,
都属于子代理派生阶段的时序问题;但本 issue 的症状是带残缺工具集跑完整轮
而非启动失败,故单独提报。

Activity

  1. github-actions commented on Oct 28, 2026

    @github-actions

    👋 感谢你的反馈,我们已经收到。

    • 维护者看到后会尽快回复你。
    • 状态保持为 status: 待评估,你可以随时补充信息。
    • 信息不全时我们会打上 needs: 更多信息 标签并 @ 你。

    👋 Thanks — we've received your issue.

    • A maintainer will get back to you as soon as we can.
    • Status stays at status: 待评估 (Triage); feel free to add context.
    • If we need more details, we'll add needs: 更多信息 and ping you.
  2. sun603 commented on Oct 28, 2026

    @sun603
    Author

    补充定位:该问题由"工具搜索"(ToolSearch)实验性设置触发

    进一步排查后,将根因从"派生竞态"收窄到设置中的"工具搜索"功能,补充如下:

    1. 触发条件
    设置 → 工具搜索 处于开启状态(自动)。该设置"新建会话或应用
    重启后恢复会话时生效",而每次派生子代理都会创建新会话,因此子代理
    必然走该模式下的工具目录组装路径。

    2. 证据

    • 开启状态下,子代理首轮请求只携带约 7 个基础工具(Read/Write/Edit/
      Bash/Skill/AskUserQuestion/ToolSearch),随后数轮随插件/MCP 注册
      逐步增至 20+(请求记录中工具数呈 7→17→20→26 递增,即延迟挂载路径)。
    • 出问题的子代理则是整个核心工具组(Read/Write/Edit/Bash/Grep/Glob)
      从未出现在任何一轮请求中——基础工具组注入被跳过,且该子代理整个
      生命周期都不会补挂,只能靠父级重派。
    • 事发时段上述延迟路径处于生效状态;事后将"工具搜索"改为"关闭"。

    3. 建议排查方向
    开启 ToolSearch(自动/本地)时,子代理会话首轮请求的组装逻辑:
    延迟目录未就绪时是否仍会发出请求,且没有保证核心工具组(或至少
    ToolSearch 本身)必然在位。另注:设置页已提示"原生模式对未完整
    支持原生 ToolSearch 的供应商可能导致缓存失效",自动模式下按模型
    选择原生/本地,GLM 侧的原生路径也值得一并核查。

    4. 临时规避
    将"工具搜索"设为"关闭"(发送完整工具目录)。关闭后子代理首轮即应
    携带完整目录,不再经过延迟挂载窗口;代价是 token 用量上升。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions