---
title: "长任务中的子代理调度分布"
description: "冻结聚合显示，子线程创建记录分布在父线程观测跨度的三个区间；后台标记与时间区间重叠只能描述调度形态，不能证明语义任务阶段或真实并行计算。"
---

> Documentation Index
> Fetch the complete documentation index at: https://konghayao.github.io/peri-cool/llms.txt
> Use this file to discover all available pages before exploring further.

# 长任务中的子代理调度分布

一份冻结于 2026-08-09 的聚合快照记录了 42 个超长父线程，以及它们关联的 308 个子线程。把每个父线程从创建到最后更新时间的观测跨度切成三等分后，三个区间都有新的子线程创建记录，计数依次为 193、36 和 79。

这个分布支持一个有限结论。子代理调度没有只出现在父线程观测跨度的开头，后两个区间仍有 115 条创建记录。它不能说明子代理承担了规划、实现或验证中的哪一种语义任务，也不能说明这些子线程在对应区间持续占用计算资源。

## 数据底稿分开三种统计单位

本研究只读取已经冻结的聚合文件，生成脚本仅用于核对统计口径，没有重新执行。样本把消息数不少于 500 的可见主线程定义为超长父线程，共 42 个。冻结文件生成于 2026-08-09 13:58 UTC，但没有保存可靠的样本起止窗口，因此不能从生成时间反推出数据覆盖期。三个观察使用不同分母，不能拼成一张任务流程图。

| 观察 | 分母 | 统计对象 |
| --- | ---: | --- |
| 创建时间分布 | 308 个子线程 | 子线程创建时间在父线程观测跨度中的相对位置 |
| 后台标记比例 | 203 条可见派发 | 父线程可见消息中的子代理派发参数 |
| 区间重叠代理 | 42 个父线程 | 每个父线程下子线程创建与更新时间区间的最大重叠数 |

阶段统计与区间重叠来自子线程关系，后台标记来自父线程中仍可见的派发记录。两种记录的测量差异已在[超长会话统计画像](/peri-cool/posts/research/long-session-study/)中说明，本研究不再解释两者的数量差额。

**公开边界**只允许发布总体聚合。原始消息、任务文本、线程标识、本机路径、精确个案时间与小于 10 的交叉分组均不公开，发布字段也不包含单个任务的直接标识符或个案映射。聚合处理降低了关联风险，但不能证明重识别风险为零。

## 子线程创建分布覆盖三个时间区间

**观测跨度三等分**以父线程创建时间为起点、最后更新时间为终点。每个子线程的创建时间先换算成跨度内的相对位置，低于 0.33 归入前段，低于 0.67 归入中段，其余归入后段。这个人为阈值只提供统一的时间坐标，不代表产品内部存在三个任务阶段。

在 308 个子线程中，前段有 193 条创建记录，中段有 36 条，后段有 79 条。后两个区间合计 115 条，数据不支持子代理只在开头出现这一描述。分布明显偏向前段，也不能据此断言前段工作更重要，因为计数没有衡量任务难度、运行成本或产出质量。

父线程最后更新时间还会受用户停顿、后台通知和后续消息影响。一个跨度很长但中间空闲较多的父线程，会把相同的实际时间差映射到更靠前的位置。因此，这个指标描述的是记录位置，不是墙钟工作进度。

## 39.9% 的可见派发带后台标记

**后台标记比例**来自 203 条仍可见的子代理派发记录，其中 81 条设置了后台运行参数，占 39.9%。这里的分母是可见派发，不是 308 个子线程。消息压缩和旧格式会影响哪些派发仍可见，因此该比例不能外推到全部子线程。

后台参数表达的是调用方选择异步等待方式。它没有记录操作系统调度、模型请求是否同时在途，也不证明父线程在等待期间推进了其他有效工作。39.9% 只能说明可见派发中有相当一部分采用后台形式，不能称为并行效率或资源利用率。

直接按子线程数量计算后台比例也不可行。冻结聚合中的子线程关系没有携带同一口径的后台参数，把父消息参数强行映射到子线程会要求逐条关联原始记录，这既超出当前聚合证据，也会增加隐私风险。

## 时间区间重叠只提供并发代理

**区间重叠代理**把每个子线程从创建时间到最后更新时间视为一个区间，再计算同一父线程下同时覆盖的最大区间数。在 42 个父线程上，这个最大重叠数的 P90 为 3，样本最大值也是 3。该结果说明至少一部分父线程的记录区间存在重叠，却没有证明三个子线程持续同时计算。

最后更新时间可能来自消息落库、状态收尾或其他持久化动作。区间内部也没有 CPU、网络请求或模型推理的占用轨迹。把区间重叠称为真实并发，会把存储时间戳承担不了的语义加到数据上。

更严格的验证需要独立记录启动、首个模型请求、工具执行、最后输出和资源释放事件，再比较这些事件区间。当前冻结文件没有这些字段，因此不能检验重叠期间是否存在真实计算，也不能比较前中后段的资源消耗。

## 三种替代解释限制因果判断

前段计数较高可能来自任务刚开始时更需要拆分探索，也可能来自超长线程的筛选方式。只有达到 500 条消息的父线程才进入样本，较早结束或失败的线程都被排除。观察到的分布不能代表所有 Peri 任务。

中段只有 36 条创建记录，但仍高于公开门槛。这个低谷可能反映调度策略，也可能由父线程观测跨度中的空闲时间造成。没有逐任务语义编码和可靠活动窗口，不能在两种解释之间做选择。

后段的 79 条记录证明观测跨度后部仍发生调度，不证明这些调度是返工、验证或恢复。任务文本与原始消息不会公开，也没有脱敏标签可以支持语义分类。研究因此停在时间位置、后台参数和区间重叠三类描述上。

开头那 115 条位于后两个区间的创建记录，改变的是对子代理调度时点的认识。长任务中的子代理会在观测跨度中后部继续出现；至于它们承担什么工作、是否真正并行以及是否改善结果，当前冻结聚合都没有给出答案。

Source: https://konghayao.github.io/peri-cool/posts/research/subagent-dispatch-phases/index.mdx