把 666 个会话摊开看：一份 DSH 使用经验与教训的复盘

这是一篇只谈"怎么用"、不谈"做了什么"的复盘。所有案例都做了脱敏：不出现项目名、仓库名、文件路径、文件名、类名与业务专有名词，只保留可迁移的行为模式与过程统计。文中的数字来自对本机全部会话记录的离线解析，口径在第二节说明。

太长不看

如果你只读三百字，记住这八条：

首轮把口径付清。目标、事实源、验收标准、边界、交付形式，五个槽位缺一个，后面就要多花几倍调用去补。首条消息带结构的会话，错误率约为不带的六成。
能自动验证的活，别让人看。靠人眼验收的任务，中位调用 108 次、耗时 70 分钟；能自动验证的只要 65 次、20 分钟。
纠偏要给新事实，不要只说"不对"。纯否定会让代理重复同一种错误；"哪里不对 + 以什么为准"才能收敛。
越早打断越便宜。被中断的会话中位调用只有 5 次------真正贵的是"发现错了还让它跑完"。
一次改一处，改完即验。长会话能活下来，靠的不是每步都对，而是每步都能回滚。
把关键信息写进文件。上下文会被压缩、会话会被重启，文件不会。压缩后第一件事是落盘，不是继续推理。
委派只给可切片的活，并把写入范围划死。310 个团队任务完成 284 个，靠的就是"边界清楚、可独立验收"。
做完就归档、就命名。归档不是删除，是给未来的自己建索引；标题就是你的搜索关键词。

下面从"为什么值得复盘"开始，一层层展开这些结论是怎么来的、在什么条件下成立、以及反例长什么样。

一、缘起：为什么要复盘自己的会话

用 AI 编程代理的人，大多经历过这样的循环：第一次用，惊艳；用一周，开始觉得"它老是改错"；用一个月，摸出一套自己的话术；用三个月，很多做法已经变成肌肉记忆，却说不出为什么。

这个过程最大的浪费在于：经验没有被记录下来，于是每换一个项目、每换一个模型、每开一个新会话，都在重新踩同一批坑。

而代理类工具恰好有一个别的工具没有的好处：它把每一次交互都完整地记了下来。你的每一句指令、它的每一次工具调用、每一个报错、每一次重试、每一次上下文压缩、每一次归档，都在磁盘上留了痕迹。这些痕迹拼起来，就是一部关于"人怎么指挥机器干活"的一手史料。

这次复盘的对象，是本机 DSH 环境里全部 666 个唯一会话（含 216 个已归档、450 个未归档），时间跨度约七周，累计 819,180 条事件、72,275 次工具调用、73,817 个执行步。它们覆盖了 34 个工作目录，从代码仓库、文档工程、桌面端插件、数据处理脚本，到视频与演示材料的生产，形态相当杂。

把这么多会话一次性摊开，能看到的不是"某个项目做得好不好"，而是三类更普适的东西：

任务形态的分布：什么样的活适合交给代理，什么样的活交给代理必然痛苦；
交互契约的形状：一句话的指令、三百字的说明书、两千字的分工简报，各自把会话带向了哪里；
失败与恢复的路径：错误集中在哪些环节，哪些恢复手段真的有效。

下面按"语料与方法 → 总体画像 → 生命周期 → 交互契约 → 委派 → 工具 → 失败 → 恢复 → 上下文 → 环境 → 收尾 → 能力面 → 清单 → 反模式"的顺序展开。篇幅较长，可以按需跳读，但建议至少读完第五章（交互契约）、第八章（失败分类）和第十四章（二十条清单）------这三章是全文的骨架，其余章节都是它们的展开与佐证。

二、语料与方法：这份复盘是怎么做出来的

2.1 数据在哪、长什么样

DSH 把每个会话存成一个按工作目录分桶的压缩事件流。目录结构大致是：

复制代码

会话根目录/
  工作目录编码/
    会话 ID/
      session.vX.jsonl.zstd

每个文件的第一行是会话头（创建时间、工作目录、预设、委托深度、是否种子会话），后面是逐条追加的事件。一次会话的全部行为都能在这里找到：

user/message：用户消息（注意：其中很大一部分是运行环境注入的系统提示，不是人打的字）；
assistant/message：模型输出，含文本与工具调用；
tool/call / tool/result：工具调用与结果，结果里带 isError 标记；
turn/start / turn/end：轮次边界，结束原因有 completed / error / aborted / interrupted / blocked / max-tokens；
llm/retry：模型侧重试，带失败代码（RATE_LIMIT / SERVER / TIMEOUT / TRANSPORT）；
compaction/*：上下文压缩；
todo/write、team/task、subagent/descriptor、goal/change：待办、团队任务、子代理、目标；
deliverables/presented：显式交付动作。

版本上，现存文件有三种格式（v1/v3/v4），其中 v4 占绝大多数（587 个），v3 有 62 个，v1 有 23 个。老版本的字段略有差异，但不影响行为层面的统计。

2.2 口径与陷阱

做这类统计，有几个坑必须先讲清楚，否则数字会互相打架：

第一，文件数不等于会话数。 672 个文件里，有 6 个会话因为版本迁移或跨工作目录被存了两份，去重后是 666 个唯一会话 ID。所有涉及"会话数"的结论都按去重后的口径。

第二，用户消息绝大多数不是人打的。 原始事件里 user/message 有 14,143 条，但其中混入了大量系统注入内容：技能目录、运行时上下文快照、后台任务完成通知、团队消息、任务板提醒。把来源标记为"用户"、且不以系统提示开头的消息筛出来，只剩 1,919 条真正的人话 ，对应 621 个会话。也就是说，平均每个会话只有 3 条左右的人类输入，其余全是由环境自动拼进去的上下文。

这一点极其重要。如果不做这层过滤，你会得出"用户平均每会话发 21 条消息"的错误结论，进而误判交互密度。

第三，归档状态不等于任务成功。 归档只是一个"从列表里收起来"的动作。216 个归档会话里既有跑到 1,892 次调用的超级长跑，也有 16 个工具调用为 0 的空壳。归档反映的是整理习惯，不是质量。

第四，根会话和子代理会话必须分开看。 666 个会话里，委托深度为 0 的根会话 212 个，深度为 1 的子代理会话 408 个，深度为 2 的只有 1 个。子代理会话的"首条用户消息"其实是主代理写给它的分工简报，长度中位数 2,000 字，而根会话的首条消息中位数只有 78 字。把两者混在一起算平均值，会得到一堆没有意义的数。

第五，错误数按事件计，不按会话计。 全量工具错误 3,120 条（去重会话口径 2,859 条），分布在 524 个会话里。错误率用"每百次调用的错误数"衡量更稳，全局约 4.0。

2.3 分析怎么做的

三步：

机器统计：写脚本流式解压全部会话文件，逐事件解析，抽取出每会话的元信息、工具调用分布、错误分类、重试代码、结束原因、人类消息原文、助手文本片段，落成结构化索引；
人工抽样：对若干代表性会话做全文通读，把数字背后的"故事"补上------尤其是那些"看起来只是一个数字、实际上是十轮返工"的会话；
交叉验证：机器统计的结论，用通读得到的行为模式去对撞；对不上的地方回头查口径，而不是硬凑。

下面所有数字都标注了口径，凡是可能引起误读的地方都会写明"这是相关，不是因果"。

三、总体画像：这套系统被用成了什么

3.1 规模：七周、八百小时、七万次调用

先给一组总量数字（去重口径）：

指标	数值
唯一会话	666
已归档 / 未归档	216 / 450
覆盖工作目录	34
事件总数	819,180
工具调用	72,275
执行步（step）	73,817
轮次（turn）	2,236
工具错误	2,859（去重会话口径；按事件计为 3,130，见第八章）
真正的人类消息	1,919
环境注入消息	11,735
出现的模型/供应商组合	12

时间上，第一批会话出现在 9 月上旬，最后一批到 10 月末。按周看，会话数从第一周的 64 个一路涨到第四周的 218 个，之后回落到 157 个。这不是线性增长，而是"摸索期---爆发期---稳态期"的典型曲线：前期在试工具边界，中期把能交给代理的活都交了出去，后期开始按任务类型分流。

有意思的是错误率随时间的走向 ：第一周每百次调用 6.5 个错误，最后一周降到 3.0。这里有两个可能的解释------要么是用法变熟练了，要么是任务结构变了（前期更多是探索性的、边试边改的活，后期更多是有明确验收标准的活）。从数据看，两者都有：前期会话里"首次尝试即失败"的比例明显更高，后期长会话里工具错误占比上升但总量下降。所以更准确的说法是：熟练度提升体现为"少走冤枉路"，而不是"不出错"。

3.2 形态：中位数 23 分钟，长尾 6.6 天

单会话时长（首末事件时间差）的分布非常偏：

中位数 22.8 分钟；
平均值 173.5 分钟（被长尾拉高）；
90 分位 156.7 分钟；
99 分位 4,016 分钟；
最大值 9,571 分钟（约 6.6 天）。

注意：这个"时长"不是"连续工作时长"，而是"这个会话从第一条事件到最后一条事件跨了多久"。一个跨了六天的会话，中间大概率被挂起、第二天再续上。所以它衡量的是会话的生命周期 ，不是注意力投入。

工具调用量的分布同样偏：

中位 67 次；
75 分位 118、90 分位 216、95 分位 296；
99 分位 1,165，最大 1,892；
调用量前 10 的会话吃掉了全部调用的 16.8% ，前 50 个吃掉 36.4%。

这条长尾很重要：代理工具的成本和风险高度集中在少数超长会话上。如果你只盯着"平均每次任务花多少钱"，会严重低估那 5% 的长跑会话带来的时间、token 和心智消耗。

3.3 谁在说话：人类其实很沉默

前面提过，真正的人类消息只有 1,919 条。分布如下：

48 个会话完全没有人类消息（多为子代理会话或自动触发）；
根会话的人类消息中位数是 3 条，均值 6.9 条；
51 个根会话的人类消息达到 5 条以上；
极端个案达到 254 条（一个跨六天、1,892 次调用的会话）。

把这些人类消息按长度分档，呈现明显的双峰：

极短（10 字以内）：约三分之一。内容高度集中------"继续""提交推送""按建议执行""这个不对"；
中等（50--300 字）：约三分之一。是"口径修正"和"补充约束"；
长文（300 字以上）：少量但关键。几乎全部出现在首轮，或子代理分工简报。

这个双峰结构本身就说明了一件事：人类在这个系统里的角色，不是"对话者"，而是"立规矩的人 + 验收的人"。真正密集的信息交换发生在首轮和关键纠偏点，其余时间人类只负责点头或摇头。

3.4 结束原因：八成正常收尾，两成非正常

按轮次结束原因统计（全量 2,606 个 turn/end）：

结束原因	次数	占比
completed	2,277	87.4%
error	163	6.3%
aborted	148	5.7%
interrupted	10	0.4%
blocked	5	0.2%
max-tokens	3	0.1%

只看根会话，completed 占 86.7%，error 4.9%，aborted 7.7%。

aborted 值得单独说 ：148 次主动中断里，绝大多数发生在会话极早期。归档会话里 57 个中断会话的中位调用数只有 5、中位轮次只有 1。这反过来说明一个很重要的经验------发现方向错了，早期打断极其便宜；等到跑了几百步再推翻，代价就是几百次调用的沉没成本。

3.5 一个反直觉的发现：小会话更容易失败

把会话按调用量分档，看结束原因的构成：

调用量	会话数	completed	error	aborted
< 20	62	47.5%	26.2%	26.2%
20--200	530	83.2%	12.0%	4.0%
200--800	66	91.0%	3.4%	4.8%
> 800	8	90.8%	2.2%	6.4%

小会话的失败率是大会话的三到六倍。这个结论乍看反直觉，其实很好解释：调用量少往往不是"任务简单"，而是"没跑起来"------环境没配对、路径不对、依赖缺失、模型侧直接报错，会话在第一分钟就死了。真正跑起来的会话，反而有充足的机会自我修正。

这条对实践的直接含义是：如果你发现自己有很多"一句话就结束"的会话，问题多半不在模型，而在环境准备和任务表述。后面"环境工程化"一节会展开。

3.5.1 把镜头拉近：前 25 次调用是"生死线"

换个切法，把未归档的那批会话（450 个）按调用量切成十分位，只看错误率，会看到一个更锋利的形状：

最低一档（0--25 次调用）：错误率 8.30% ，错误收尾占比 13%；
第二档（25--32 次）：错误率骤降到 4.03%；
中间档继续下降到 1.93%；
到 80 次以上，基本稳定在 2% 上下。

（这一组数来自未归档子集的十分位分析，绝对值与全局 4.0 的口径不同，但"开局陡降"的形状是一致的。）

也就是说，同一个会话，开局阶段的错误率是稳定期的四倍。而一旦越过前 25 次调用这个坎，错误率会自己掉下来。

这个形状很符合直觉：开局时你对代码库不熟、代理对路径不熟、命令在哪个 shell 里能用没试过、依赖装没装不知道。所有的"猜"都集中在这 25 步里。等这些基础事实被摸清，后面的每一步都踩在已知地面上。

先记住这一条：开工前花五步"探路"，比直接动手省得多。 探路的内容很固定：目标目录能不能读、构建命令能不能跑、测试能不能过、有没有网络、编码对不对。这五件事各花一次调用，能换掉后面大概率会发生的失败。

更进一步，这解释了一个常见的困惑："为什么它一开始挺笨，后面突然就聪明了？"------不是它变聪明了，是它在前 25 步里把该踩的坑踩完了。如果你希望它一上来就聪明，那就把这 25 步的事实提前告诉它。

3.6 模型与供应商：十二种组合，一种主用

七周里出现过 12 种模型/供应商组合。按助手消息计数，头部是一家供应商的 flash 级模型（约 4.9 万条），第二是另一家的 flash 级模型（约 2.4 万条），其余是零散的试验性路由，包括若干不同厂商的旗舰模型、以及本地/第三方中转。

这反映的其实是一个很实用的策略：日常推进用便宜快速的模型，遇到"想不清楚"的硬骨头再换强的。数据里能看到这种切换的痕迹------同一个会话中途换模型的次数不多，但换模型之后往往伴随更长的思考文本和更少的试错调用。

四、生命周期：一个会话从生到死的四种结局

4.1 先纠正一个误解：未归档 ≠ 还在进行

刚拿到数据时，有一个数字很扎眼：450 个"未归档"会话里，只有 10 个是根会话 ，其余 439 个是子代理会话。

换句话说，"未归档"这个列表几乎全部由子代理会话构成。原因很简单：归档是人在列表里手动点的动作，而人会归档"我主导的那个会话"，不会去归档"我派出去干活的那个分身"。

这带来两个直接后果：

第一，"会话管理"实际上是"根会话管理"。 216 个归档会话清一色是根会话（委托深度为 0），450 个未归档里 439 个是子代理。也就是说，人真正在打交道的对象只有 212 个根会话，其余四百多个是它派生出来的执行单元。

第二，归档习惯决定了数据可读性。 归档的根会话吃掉了 72,275 次调用里的 40,192 次（55.6%），而不归档的子代理会话吃掉 32,083 次。如果你不归档，下次再想找"上次那个活干到哪了"，就得在几百个几乎同名的子代理会话里翻。

经验一：把归档当成"收件箱清零"，而不是"删除"。 归档的成本极低（一次点击），收益是下一次能三秒找到入口。不归档的代价不是丢数据，是丢索引。

4.2 四种结局的画像

把根会话按结束原因归类，能看到四种非常不同的"死法"：

（1）跑完了（completed，占根会话约 87%）

特征是最后几轮出现"验证陈述 + 交付动作"。典型序列是：改完 → 跑测试/构建 → 贴出通过证据 → 提交/导出 → 声明工作区干净。

这类会话的中位调用量在 100 次以上，且几乎都有待办清单。它们不是"一次做对"，而是"边做边收"。

（2）跑炸了（error，约 5%）

模型侧终止。中位调用量极低，最像"出师未捷"。常见诱因是：供应商侧限流、上下文超限、工具返回了模型无法消化的结构。

（3）人叫停了（aborted，约 8%）

这是最值得研究的一类。它们的共同特征是发生得很早：中位调用 5 次、中位轮次 1 次。

为什么早停？抽样看，原因高度集中：

第一版产物方向就错了（比如把"分析"理解成了"修改"）；
代理开始做用户明确说过不要做的事；
用户在等待期间自己想清楚了，换了个思路重开。

这三种都属于"信息在第一条消息里没有对齐"。它们不是模型的失败，是契约的失败。

（4）卡住了（blocked / interrupted / max-tokens，合计不到 1%）

数量极少，但每一种都指向一个具体的机制问题：规则拦截、外部打断、输出被截断。出现频率低说明这些机制本身是可靠的；一旦遇到，通常意味着任务表述触碰了某个硬约束（比如要求它做被禁止的操作，或单轮输出预算不足）。

4.3 长会话的四个阶段

把 20 轮以上、调用超过 400 次的会话挑出来看结构，会发现它们几乎都遵循同一个骨架：

阶段一：取证（约占总步数 15%）

先读材料，不动手。读的范围包括：既有代码、规格文档、日志、截图、上游依赖。这个阶段的产出通常是一段"我理解的事实是......"的复述，以及一份"需要确认的问题清单"。

高质量的取证有一个特征：把"事实"和"口径"分开列。事实是"文件里写着 A"，口径是"以 A 为准，B 只作参考"。混淆这两者，是后面所有返工的源头。

阶段二：列清单（约 5%）

把要做的事拆成 5--8 条待办。数据上，带显式待办的会话有 163 个，平均 6.7 条，最多 8 条------这个"8 条上限"不是巧合，它大致等于人类一次能有效把握的并列项数量。

阶段三：实施 + 局部验证（约 70%）

每改一处就跑一次验证。这是长会话能活下来的关键：验证频率决定了返工半径。一次改十个文件再统一验证，出错时你面对的是十个嫌疑犯；改一个验一个，出错时只有一个。

阶段四：收尾（约 10%）

清理临时产物、更新文档、执行交付动作、声明工作区状态。这一步最容易被省略，也最容易被下一轮打回------因为"没有收尾陈述"意味着下一个接手的人（或下一个会话）必须重新建立上下文。

经验二：长任务不要按"功能模块"切，要按"可交付段落"切。 一个可交付段落的标准是：做完之后能独立验证、能独立提交、能独立描述。按模块切，你会得到一堆"做了一半的模块"；按段落切，你永远处在一个可回滚的状态。

4.4 同一问题的"重启风暴"

数据里有一个现象值得单独拎出来：同一天、同一工作目录下，出现多个根会话的情况有 47 组，涉及 165 个会话，最多的一组一天内开了 12 个会话。

抽样看这些簇，形态很典型：

有的簇是"拆解"：把一个大任务拆成六个子任务，一个会话干一个，彼此独立；
有的簇是"重启"：同一件事，开了关、关了开，前后隔十几分钟；
还有的簇是"试探"：同一问题换三种问法，看哪种问法给出的答案最靠谱。

"重启"这一类的成本被严重低估。每一次重启都意味着：重新读一遍上下文、重新建立事实、重新试错。如果第一个会话已经跑了两百次调用，重启的代价就是两百次调用的重复劳动。

经验三：重启之前，先写交接。 哪怕只写三行------"做到哪了、卡在哪、下一步是什么"------也能让新会话省掉一半的取证时间。数据里能看到这种做法的痕迹：有 80 个会话的首条消息是"继续/按交接文档继续/下一步是 X"这类接续式表述，它们的取证阶段明显更短。

4.4.1 一组对照：为什么有的重启全军覆没，有的却全成

把归档会话的首轮文本做归一化（抹掉路径、文件名、数字）之后聚类，能看到一组非常有说服力的对照。

第一簇 ：9 个会话的首轮几乎逐字相同，都是同一句简短需求。结果是 6 个以 error 结束、2 个被中断、只有 2 个跑完，且轮次都在 1--5 之间------也就是说，同一句话被反复重开，前几次连第一步都没走完。

第二簇 ：同样 9 个会话，首轮句式也高度相似，但形态完全不同------都带了附件、多个参考物、并且把口径分了层（哪个是形状参考、哪个是数值参考、哪个只作参考不作限制）。结果 9 个全部 completed，其中 7 个在 2--3 轮内收尾，2 个分别续跑到 33 轮和 226 轮。

两簇的区别不在"问题难不难"，而在首轮有没有把参考物和口径交代完整。

这个对照把"重启"这件事说清楚了：重启本身不是问题，带着没澄清的口径重启才是问题。如果第一轮失败的原因是"口径不清"，那么第二次、第三次重启，只是把同一次失败复制了 N 遍。

经验三之二：重启前，先回答一个问题------上一轮为什么失败？ 如果是环境问题，修环境；如果是口径问题，把口径补进新会话的第一条消息；如果是方向问题，先想清楚方向再开。答案没想清楚就重开，大概率是把失败重演一遍。

五、交互契约：人到底该怎么说话

这一节是全文最重要的部分。因为工具、模型、环境都会变，唯独"人怎么把意图表达清楚"这件事，是跨工具、跨模型都成立的。

5.1 首轮决定命运

先看一组对照。把根会话按"首条人类消息的长度"分档：

首条消息长度	会话数	中位调用	每百次调用错误	completed
≤ 80 字	114	96	4.5	83.1%
81--300 字	89	148	4.6	88.1%
301--1000 字	70	46	4.6	89.7%
1001--3000 字	348	60	2.7	83.6%

注意最后一档：会话数突然暴增到 348，错误率也明显更低。这一档几乎全部是子代理会话------主代理写给子代理的分工简报，天然就是一千字以上的结构化文本。

所以这张表不能直接读成"写得越长越好"。正确的读法是：结构化程度高的简报，错误率显著更低（2.7 对 4.5），但这里的"长"是结构带来的副产品，不是原因。

真正可比的是根会话内部。把 212 个根会话按"首条消息是否包含标题/编号列表/约束条款"分成两组：

结构化（含 ##、编号列表、"要求"+"约束"等）：错误率 2.5/百次调用；
非结构化：4.6/百次调用。

样本量很小（结构化只有 5 个），不足以下强结论。但把它和"子代理简报错误率 2.7"放在一起看，方向是一致的：结构比长度重要，约束比修辞重要。

5.2 一份好指令的五个槽位

从那些一次跑通的会话里，可以反推出指令的"标准槽位"。不是每条都要写满，但缺哪个槽位，就会在哪个环节返工。

槽位一：目标（做什么，不做什么）

最常见的问题是"只说了要做什么，没说不要做什么"。代理天然倾向于"多做一点"，于是会把相邻的东西也顺手改了。

有效的写法是显式圈定负面边界：

只改 X 这一个文件，不要动 Y、Z 和配置。

本轮只做分析，不要改代码。

不要引入新依赖。

槽位二：事实源（以什么为准）

这是最容易出事的地方。当同一个东西有多份描述（图纸、文档、旧代码、口述），必须指定唯一事实源，并说明其他来源的地位：

形状以附件图为准，尺寸以表格为准，旧代码只作参考，与图冲突时以图为准。

数据里有大量返工的根因就是"事实源没定"：代理按代码实现，用户按图判断，两边都没错，但对不上。

槽位三：验收标准（怎么算做完）

"做完"必须有可执行的判据：

全量测试通过、构建成功、导出的文件能重新读回来且数值一致。

没有验收标准，代理会用"我觉得可以了"来收尾；有了验收标准，它会自己跑验证。

槽位四：交付形式（产出什么、放哪）

输出一个 Markdown 文件，路径 X；同时给出改动清单和验证证据。

不指定交付形式，你会得到一段聊天记录，而不是一个可复用的产物。

槽位五：节奏（什么时候停、什么时候问）

先给方案，确认后再执行。

遇到不确定的地方停下来问，不要猜。

这一条决定会话是"一路狂奔"还是"分段确认"。

5.3 纠偏的话术差异，比想象中大

把人类消息里带否定意味的挑出来（"不对""错了""还是不行""重新"等），共 144 条，分布在大量会话里。按纠偏是否"有效"（后续是否收敛）粗分，差异非常明显：

低效纠偏：纯否定。

不对，重新做。

还是不行。

这类话术的问题在于：它只告诉代理"结果错了"，没告诉它"哪里错了、以什么为准"。代理的默认反应是"换一种实现再试一次"------于是你得到的是同一个错误的不同写法。

有效纠偏：否定 + 新事实 + 新口径。

形状还是不对。附件是当前生成的结果，对比图 2 可以看出顶部有一个尖角，而正确形状应该是平的。以图 2 为准重新实现。

这条纠偏里包含了三个要素：指出具体差异 （尖角）、给出新证据 （图 2）、明确优先级（以图 2 为准）。数据里那些最终收敛的会话，纠偏消息几乎都长这样。

经验四：纠偏时，先说"哪里不对"，再说"以什么为准"。 只说前者，代理会瞎猜；只说后者，代理不知道旧的在哪儿错了。

5.3.1 加分槽位：输出骨架

这是从数据里冒出来的、性价比最高的一个槽位：把你要的产出结构直接写出来。

报告按四段组织：①结论摘要 ②逐项核对表 ③缺陷清单（按严重度排序，每条给证据位置）④存疑清单。

在委派型会话里，带这种"骨架"的错误率是 2.04% ，不带的 3.49%；而两者的调用量只差几次------多写四行字，少走一大截弯路。

原因不难理解：骨架把"什么算完成"前置了。没有骨架，代理要自己猜"你希望这份报告长什么样"，猜错就得重写；有了骨架，它的每一步输出都有明确的落点。

经验四之二：能用清单和骨架表达的，就别用形容词表达。 "全面一点""详细一点""专业一点"是形容词，"四段结构 + 每段三个要点 + 每条附证据位置"是骨架。形容词要靠猜，骨架不用。

5.4 "先方案后执行"：用时间换方向

数据里明确出现"先给方案/确认后执行/不要直接修改"的会话有 54 个。它们的耗时中位数明显高于直接执行组，但返工更可控。

这个权衡很清楚：方案评审花的是人的注意力，直接执行花的是代理的算力和你的等待时间。当一个任务的方向不确定、或者错误代价高（改错了几十个文件），方案评审是划算的；当任务机械、可逆、验证便宜，直接干更快。

判断标准可以简化成一句话：如果"做错"的修复成本 > "先说清楚"的沟通成本，就先要方案。

5.5 打断的成本曲线

前面提到，aborted 会话的中位调用数只有 5。这其实揭示了一条成本曲线：

第 1 轮打断：损失几分钟；
第 10 轮打断：损失十几分钟；
第 100 轮打断：损失一两个小时，外加你对它的信任；
第 500 轮打断：你大概率不会打断，而是让它跑完然后重开------这才是最贵的。

所以，打断的最佳时机永远是"你第一次觉得不对"的那一刻。不要想着"再看看"，代理不会自己拐回来。

六、委派：把活分给分身，什么能分、什么不能分

6.1 委派的规模

数据里子代理会话 408 个，子代理描述事件 440 条（其中 440 个是"可续"模式，3 个是"一次性"模式）。团队任务 310 个，其中 284 个完成、9 个进行中、17 个待处理------完成率 91.6%。团队消息 266 条。

310 个团队任务里，292 个带写了"写入范围"（writeScopes），14 个带依赖关系（blockedBy）。这说明委派不是"随口一分"，而是有意识地划了边界、排了顺序。

6.2 什么活适合分出去

从子代理的描述看，被分出去的活高度集中在三类：

（1）可切片的产出型工作

写章节、写文档、做素材、生成配图。这类活的特点是：每片的输入输出独立、验收标准明确、彼此不共享状态。数据里最大的一批委派就是"按章节分工写一本书"，十几个子代理各写几章。

（2）只读的侦察型工作

"帮我摸清这个模块的接口""列出所有调用点""这份文档讲了什么"。这类活不写文件，因此不存在写冲突，天然可并行。

（3）独立的验证型工作

跑测试、做端到端检查、核对数据。这类活的输出是一个结论，不是一堆改动，因此风险极低。

反过来，不适合分出去的活也很清楚：

需要频繁跨文件一致性的重构（子代理各改各的，合并时冲突）；
需要"手感"的调试（一个 bug 的根因往往在子代理的视野之外）；
需要与人反复对齐口径的设计决策。

6.3 一份能用的分工简报长什么样

从那些一次跑通的子代理会话里，可以提炼出简报的固定结构（这也解释了为什么子代理的首条消息中位数是 2,000 字）：

复制代码

## 背景
工作目录、项目性质、技术栈、当前状态（一句话说清"现在处于什么阶段"）。

## 你的任务
只做这一件事：<具体到可验收的粒度>。

## 必读
按顺序读这几个文件，读完再动手（附路径与"为什么读它"）。

## 硬性约束
- 只写 <指定文件>，不得修改其他任何文件；
- 事实只能来自 <唯一事实源>，源里没有的数字一律不写；
- 不要引入新依赖 / 不要改构建配置 / 不要提交。

## 验收
<可执行的判据：跑什么命令、看什么输出、达到什么状态>。

## 交付
<产出物路径 + 需要附带的证据>。

这个结构的每一段都对应一个失败模式：

没有"背景"→ 子代理按自己的想象理解项目；
没有"必读"→ 它去读了一堆无关文件，或者干脆不读；
没有"硬性约束"→ 它顺手改了不该改的文件，引发合并冲突；
没有"验收"→ 它说"完成了"，但其实没跑过；
没有"交付"→ 产出散落在对话里，主代理还得再整理一遍。

经验五：分工简报的每一段，都是一次事故的总结。 你写得越啰嗦，通常说明你被坑得越多；但也正因为被坑过，这些啰嗦是有价值的。

6.3.1 一个反直觉的代价：划边界会让工作量上升

把委派会话按"是否给了写入白名单"分组，会看到一组很有意思的数：

组	会话数	平均调用	错误率
显式"只读"	50	55	3.07%
允许"直接实施修复"	29	49	3.58%
带"报告骨架"	12	45	2.04%
带"授权白名单"	11	89	4.60%

白名单组的调用量几乎翻倍（89 对 51），错误率反而略高。这不是"白名单没用"，而是划边界本身是要花成本的：子代理每改一处，都要先确认"这算不算授权区"，于是多出大量核对动作。

但换来的是另一件东西：越界改动为零。在多代理同仓的情况下，这个交换是划算的------因为越界改动的代价不是"多花几次调用"，而是"别人的工作被覆盖，且很难归因"。

经验五之二：边界不是免费的，但越界的代价更高。 单人单代理时可以省掉白名单；只要有两个以上的写手同时动同一个仓库，白名单就是必需品。

6.3.2 并发的隐性成本

同一天、同一工作区出现两个以上委派会话的批次有 22 组，最大一组 9 个并发。这 22 组的总错误率 5.02%，高于单发委派的 3.32%；那组 9 并发的批次还出现了 2 次输出触顶。

这个差异不大，但方向明确：并发不是免费的。成本来自三处：

文件系统竞争：多个子代理同时读写同一个仓库，锁、缓存、构建产物都可能打架；
上下文压力：主代理要同时跟踪多个任务的进度，自己的上下文消耗加快；
裁决成本：多份产出回来之后，合并、去重、统一风格的工作量，往往比"串行做完"更大。

所以并行的正确用法是：只在"写域互斥"且"结果无需合并"时才并行。审查不同模块、补不同目录的测试、各写独立章节，这些都是好的并行；"三个人一起重构同一个模块"是坏的并行。

6.4 委派的三个陷阱

陷阱一：把"上下文"当"背景"传。

主代理以为"我把背景都写清楚了"，实际上写的是"我知道但没说出来"的东西。子代理没有主代理的记忆，任何没有写进简报的事实，对它来说都不存在。

陷阱二：让子代理做"需要判断"的事。

"你觉得这个方案好不好"------这类问题子代理答不好，因为它看不到全局。委派应该给"可判定的任务"，把"需要判断的任务"留给自己。

陷阱三：并行写同一片区域。

即使写了 writeScopes，两个子代理改同一个文件的相邻部分，合并时依然会冲突。数据里 292 个任务写了写入范围，说明这个坑是被反复踩过的。

七、工具：为什么 98.7% 的调用都走同一个入口

7.1 一个极端集中的工具画像

先看工具调用的总量分布：

工具	调用次数	占比
代码执行入口（run_code）	71,367	98.7%
读文件	406	0.6%
本地 shell	189	0.3%
文件匹配	87	0.1%
内容检索	65	0.1%
编辑	45	0.1%
待办写入	37	---
其余（写文件、消息、子代理、后台任务、目标等）	合计 79	---

更极端的数字是：641 个有工具调用的会话里，618 个从头到尾只用了一个工具（就是那个代码执行入口），只有 23 个是混合调用。

这不是"这个工具好用"那么简单，它反映了一种使用哲学：把工具调用当成"写程序"而不是"点按钮"。

具体来说，当代理需要读十个文件、改三个文件、跑一次构建时，它不会发十三个独立调用，而是写一段程序：里面并发读、串行改、最后跑构建，只在程序末尾把需要看的输出打印出来。对外看，这只是一次工具调用。

7.2 这种用法好在哪

（1）上下文效率极高。

一次调用可以完成"读 10 个文件 → 筛选 → 汇总"的全过程，而回到模型上下文里的只有"汇总后的一小段"。传统的一次一调用模式，十个文件的内容会全部灌进上下文，token 消耗是前者的几倍。

数据里有个佐证：会话的助手文本中位数只有 865 字符，但工具调用中位数 67 次。也就是说，大量的工作在"程序内部"完成了，模型看到的是结果而不是过程。

（2）批处理和并发天然可行。

"给 50 个文件统一加一行头注释"这种活，一次调用里写个循环就完了。传统模式下，这是 50 次调用。

（3）错误可以被程序自己消化。

程序里可以先 try/catch，失败了换一种方式再试，实在不行才把错误抛出来。这让"小错误"不至于每次都打断整个流程。

（4）可复现。

一段能跑通的程序可以存下来，下次改个参数再用。而一串"点按钮"的操作，只能靠记忆复现。

7.3 这种用法坏在哪

（1）语法错误成为第一大错误源。

全量 3,130 次工具错误里，JS 语法/解析错误 675 次，占 21.6%，是最大的单一类别。典型信息是"Expected ',', got 'ident'""Expected a semicolon""Unterminated template"。

原因很直接：每次调用都要现场写一段程序，写得越频繁，笔误越多。而且这种错误是"整段程序不执行"------不像单步工具，错了只错一步。

（2）超时成为第二大错误源。

425 次，占 13.6%，典型是"execution deadline reached (120000ms)"。原因是程序里塞了太多活：一次读五十个文件、跑一次全量构建、下载一堆资源。默认的 120 秒预算很容易被打爆。

（3）错误信息可能被"吞掉"。

如果程序里写了 catch 但没打印，或者只打印了半截，模型就看不到真正的错误。数据里有 409 次（13.1%）归入"其他"的错误，其中一部分是错误信息被包装成了无意义的字符串（比如 [object Object]）。

（4）调试成本高。

一个程序跑失败了，你不知道是第几行、哪个文件、哪个参数出的问题。必须重跑、加日志、二分定位。而单步工具天然有"步骤级"的错误定位。

7.4 实践建议

建议一：把"读"和"写"分开。

读取类操作可以一次批量做（并发读、汇总打印），写入类操作应该小步做（一次改一处、改完立即验证）。数据里那些返工最少的会话，几乎都是这个模式。

建议二：给程序加"输出预算"。

每次调用只打印必要的信息：条数、前几条样本、错误摘要。不要把整个文件内容打印出来------那等于把省下的上下文又还回去了。

建议三：长任务用后台，不要硬扛。

数据里有 189 次 shell 调用和一批后台任务记录。跑构建、跑测试、下载依赖这类活，正确姿势是丢到后台，然后去做别的事，最后回来收结果。硬等在 120 秒的超时里，是纯粹的浪费。

建议四：把常用的操作固化成脚本。

同一段逻辑写了三遍，就该把它存成文件。下次调用只需要"执行这个脚本 + 传参数"，既省 token 又少出错。

7.5 验证成本决定会话形态

把会话按"能不能自动验证"分两类，会看到一个非常有解释力的差异。

一类任务可以自动验证：代码能编译、测试能跑、脚本能输出、文档能检查格式。这类会话的中位调用是 65 次 、中位时长 20 分钟。

另一类任务只能靠人眼验收：图形对不对、形状像不像、位置准不准、画面好不好看。这类会话的中位调用是 108 次 、中位时长 70 分钟，几乎是前者的两倍。

再看调用量最高的那批会话------前 10 名里有 6 个属于"视觉/几何验证"类，其中最高的一个跑到 1,892 次调用。

这不是巧合。验证方式的成本，直接决定了会话的长度：

自动验证的任务，代理可以自己判断"对不对"，错了立刻改，收敛快；
人工验证的任务，代理只能等你看，你看一眼说"不对"，它再猜一次。每一轮迭代都要穿过一次人的带宽，而人的带宽是最贵的。

由此得出一条很实用的判断：如果你手上这个任务只能靠"看一眼"来验收，那就要格外小心地定义验收标准。因为自动验证的循环是"改→跑→看结果"，人工验证的循环是"改→跑→截图→发给人→人看图→人描述问题→再改"。后者的每一圈，成本都是前者的好几倍。

经验十七：能自动验证的，绝不让人看；必须让人看的，就把判据写成人能一眼判断的形式。 比如不要让人判断"形状对不对"，而是让人判断"顶部有没有尖角"------后者是一个二元问题，前者是一个开放问题。

八、失败：3130 次错误的分类学

8.1 全量错误分类

对全部工具错误做递归文本提取后分类（共 3,130 条）：

类别	次数	占比	典型信息
JS 语法/解析错误	675	21.6%	Expected ',', got 'ident'
超时	425	13.6%	execution deadline reached (120000ms)
其他	409	13.1%	网络地址被拒、被中断、包装后的错误
目标不可修改	384	12.3%	cannot modify "...": 路径不在可写范围
编辑锚点未命中	329	10.5%	old_string was not found in "..."
目标不可读	236	7.5%	cannot read "...": 不存在或编码非法
目标不可编辑	168	5.4%	cannot edit "..."
检索失败	133	4.2%	grep: 路径不存在 / 正则被拒
JS 运行时错误	109	3.5%	TypeError: Cannot read properties of undefined
目标不可写	67	2.1%	cannot write "..."
编辑空操作	45	1.4%	old_string 与 new_string 相同
参数非无损 JSON	45	1.4%	binding arguments must be lossless JSON
参数超限	41	1.3%	limit must be less than or equal to 200
非法 UTF-8	34	1.1%	invalid UTF-8 text
文件不存在	25	0.8%	ENOENT
认证失败	3	0.1%	401 Authentication failed
超限	2	0.1%	---

8.2 三类错误的根因完全不同

第一类：写代码时的笔误（约 25%）

语法错误 + 运行时错误，合计 784 次。这类错误的本质是"手抖"，不是"理解错"。它们的特征是：重试一次通常就好了。

对策不是"更小心"，而是降低单次程序的复杂度：一次只做一件事、多用现成的脚本、写完先想一遍括号配对。另外，把大程序拆成几个小程序，可以让错误定位从"整段失败"变成"某段失败"。

第二类：对文件系统状态的误判（约 32%）

不可读、不可写、不可编辑、锚点未命中、文件不存在、空操作，合计 1,254 次。这类错误全部指向同一个问题：代理以为文件是某个样子，实际不是。

具体有四种情形：

路径猜错：文件在别的地方，或者名字差一个字符；
内容变了：读取之后、编辑之前，文件被别的进程（或人）改了，于是 old_string 找不到；
权限不对：文件在只读区、被别的进程占用、或者编码不是 UTF-8；
锚点不唯一：old_string 在文件里出现多次，工具拒绝执行。

其中第 2 种最隐蔽，也最值得警惕------它意味着并发修改。数据里有专门的版本冲突标记（FS_STALE_VERSION），但只触发了 2 次，说明大多数"内容变了"是靠 old_string 未命中被动发现的。

对策：编辑前先读、编辑时用足够长的唯一锚点、改完立刻验证。以及在多代理并行时，严格划分写入范围。

第三类：资源与边界（约 17%）

超时 425 次、参数超限 41 次、非法编码 34 次。这类错误的本质是"超出了工具设计的边界"。

超时的对策前面说过：后台化、拆分、加超时预算。参数超限（比如一次最多返回 200 行）的对策是分页读取。编码问题的对策是显式声明编码，或者先用二进制方式探测。

8.3 错误密度与任务规模的关系

全局：每百次调用 4.0 个错误；
有 117 个会话零错误；
错误率超过 10% 的会话只有 19 个；
单会话错误数最多的达到 123 次。

这个分布说明：错误是常态，但"错误泛滥"是少数。绝大多数会话的错误率在 5% 以下，属于"边做边修"的正常损耗。

真正需要警惕的是那 19 个高错误率会话。它们通常有一个共同特征：同一类错误反复出现。比如连续十次 old_string 未命中，说明代理在用一个错误的假设反复尝试，而不是回头重新读文件。

经验六：连续两次同类错误，就必须换方法，而不是重试。 第三次重试同一个动作，成功率不会比第二次更高。

8.4 模型侧的重试：1168 次

除了工具错误，还有模型侧的重试事件 1,168 次，按失败代码分：

代码	次数	含义
TRANSPORT	653	传输层中断（连接被重置、流中断）
RATE_LIMIT	228	供应商限流
SERVER	209	上游 5xx
TIMEOUT	75	请求超时

这些重试大多是自动的，且有退避策略（数据里能看到 500ms 起步、指数增长、上限 10 秒的策略键）。从结果看，重试是有效的：220 个会话出现过重试，其中绝大多数最终正常完成。

值得注意的是 RATE_LIMIT 的信息内容。抽样看到的典型信息是"上游准入被拒，容量已满，请稍后重试"。这类错误跟你的用法无关，纯粹是供给侧的波动。遇到它，正确的反应是"等一会儿"，而不是"改提示词"------很多人会误以为是自己的问题，然后开始瞎改。

经验七：区分"我的错"和"它的错"。 语法错误、锚点未命中是你的用法问题；限流、5xx、传输中断是环境问题。前者要改方法，后者只需重试或换时段。

九、恢复：出错之后怎么办

9.1 五种恢复手段，按有效性排序

从数据里能观察到的恢复手段，大致按有效性从高到低排列：

（1）重读现场（最有效）

当编辑失败、路径找不到、内容对不上时，第一步永远是"重新读一遍真实状态"，而不是"再猜一次"。

数据里那些一次修复成功的会话，几乎都有这个动作：失败 → 读文件 → 发现实际内容与假设不同 → 调整 → 成功。而那些反复失败的会话，往往是"失败 → 换个写法再试 → 又失败"。

（2）缩小改动半径

把"一次改五个文件"改成"一次改一个文件"，把"重写整个函数"改成"改三行"。改动越小，失败时的定位成本越低，回滚越容易。

（3）换执行路径

文件编辑工具失败，可以改用脚本做字符串替换；脚本失败，可以改用结构化解析（读 JSON 改字段再写回）；直接改失败，可以生成新文件再替换。同一个目标通常有三条以上的实现路径，卡在一条上不值得。

（4）拆分任务

一个 120 秒超时的批处理，拆成五个 30 秒的小批。一个改不动的大重构，拆成十个可独立验证的小改动。

（5）重启会话（最后手段）

重启的代价是重新取证。但如果一个会话已经陷入"改不对 → 再改 → 还不对"的循环超过五轮，重启往往比继续更快------因为上下文里已经塞满了错误的假设。

经验八：恢复的第一原则是"回到事实"，不是"再试一次"。 所有的"再试一次"都应该建立在"我确认了当前的真实状态"之上。

9.2 一个典型的恢复序列

把一次成功的恢复拆开看，通常是这样的：

发现：编辑返回"锚点未命中"；
取证：重新读目标文件的当前内容（而不是凭记忆）；
比对：发现实际内容比记忆里多了一段（可能是上一次改动留下的）；
调整：用新的、更长的、唯一的锚点；
验证：改完立刻读回确认；
记录：如果这个偏差会影响后续步骤，把它写进待办或注释。

这个序列里，第 2 步和第 5 步是最容易被省略的，也是最不该省的。

9.3 什么时候该放弃一个会话

有三个信号同时出现时，重启比继续划算：

同一类错误已经出现三次以上，且换过方法；
上下文已经被压缩过（说明信息密度到了临界点，早期的关键细节可能已经丢失）；
你自己也说不清"现在到底做到哪了"。

反过来，如果只是"进度慢"，不要重启------慢是因为任务本身大，重启只会更慢。

十、上下文：长会话真正的敌人

10.1 压缩是"打转"的代理指标

全部 666 个会话里，发生过上下文压缩的只有 20 个，共 47 次。但它们的分布极不均匀：

压缩最多的一个会话：8 次压缩、258 轮、1,892 次调用、123 个错误；
前五个会话吃掉了 27 次压缩；
绝大多数会话（646 个）一次压缩都没有。

这个分布本身就是结论：压缩不是"长会话的必然产物"，而是"反复重新描述同一件事"的症状。

为什么？因为上下文被压缩，通常意味着早期的关键信息（原始需求、已确认的口径、试过的方案）被摘要替换了。如果任务在推进，摘要足够用；如果任务在原地打转，摘要就不够用------于是你需要不断补充细节，补充的内容又把上下文撑爆，再压缩......形成循环。

经验九：看到压缩，先停下来固化口径，而不是继续追加内容。 压缩出现时，最该做的动作是：把当前确认的事实写成文件（而不是留在对话里），然后基于文件继续。文件不会因为压缩而丢失。

10.1.1 一个必须澄清的误区：压缩不等于失忆

上面说"压缩是打转的症状"，容易被读成"压缩之后就没救了"。数据不支持这个结论。

把 20 个发生过压缩的会话单独看：

它们全部以 completed 结束（合计 918 个 completed 轮次，只有 24 个 error 轮次）；
中位轮次 20、中位调用 662，远高于未压缩组的 1 轮、65 次调用；
20 个里有 18 个是归档会话------说明这些长任务最终都被"收起来了"，不是半途而废。

所以更准确的结论是：压缩之后仍然能推进，但推进变得更贵。

代价可以直接量化：压缩组的错误密度是每百次调用 5.8 ，未压缩组是 3.4。而且压缩次数越多，错误密度越高------压缩 1 次的组约 4.9，2--3 次约 5.0，4 次以上约 6.2，最后一组的中位轮次 164、调用超过 1000。

这个"越压越贵"的机制不难理解：每次压缩都会丢掉一部分细节，而代理为了继续工作，必须把这些细节重新找回来------重新读文件、重新试错、重新确认口径。找回来的过程本身就在制造新的错误面。

反过来，那些压缩后依然顺利收尾的会话，有一个共同动作：先把成果落盘，再继续。产物一旦写进工作区，就不再依赖上下文还记得住。数据里 20 个压缩会话有 13 个走到了提交/推送这类检查点，正是这个动作的体现。

经验九之二：压缩之后的第一件事是落盘，不是继续推理。 把已经确认的东西写进文件，让"记忆"从上下文转移到磁盘，是压缩后最划算的一步。

10.2 一个反直觉的现象：上下文越长，越容易说错话

数据里有一个现象值得警惕。那些跑到几百轮的长会话，后期的助手输出往往出现两类问题：

（1）重复自己

把前面说过的话再说一遍，或者把已经做完的事再做一遍。这在压缩之后尤其常见------因为摘要里没有"这件事已经做过了"这条信息。

（2）遗忘约束

前面明确说过"不要改 X"，跑了两百轮之后又去改了 X。这不是模型故意违背，而是约束被挤出了有效上下文。

对策很朴素但有效：把关键约束写进文件，并在每一轮开始时重读。数据里那些带"必读清单"的子代理简报，本质上就是这个做法的制度化版本------每次开工先读一遍约束，而不是指望它一直记着。

10.3 上下文管理的四个层次

按成本从低到高：

层次一：不产生垃圾

最简单的管理是不制造无用上下文。比如读文件时只读需要的片段（而不是整个文件）、跑命令时只打印摘要（而不是全量输出）、搜索时只返回命中行（而不是整段代码）。

数据里"读文件"这个动作只出现了 406 次，而代码执行入口出现了 71,367 次。这说明绝大部分读取是在程序内部完成的，只把摘要带回上下文------这正是层次一的实践。

层次二：及时清理

长会话中途，把已经完成的部分写成一份"已完成清单"，然后告诉代理"这部分不用再看了"。这相当于手动做了一次有选择的压缩。

层次三：外置记忆

把事实、口径、决策记录写成文件，让会话引用文件而不是复述内容。这是最可靠的方式------文件不会因为压缩、重启、换会话而消失。

数据里能看到这种实践：多个会话的首条消息就是"读这几个文件"，说明外置记忆已经是默认做法。

层次四：换会话

当上下文确实撑不住时，写一份交接文档，开新会话。前面提到有 80 个会话是"接续式"开头，说明这个做法被反复使用。

10.4 交接文档该写什么

从那些接续得很顺利的会话看，一份能用的交接文档包含五段：

现在在哪：任务进行到哪一步，哪些已完成、哪些没开始；
确认过什么：已经拍板的口径、已经排除的方案、已经踩过的坑；
下一步是什么：具体的下一个动作，最好细到"改哪个文件的哪一段"；
怎么验证：跑什么命令、看什么输出；
别碰什么：明确的禁区。

这五段写下来通常不到一千字，但能省掉新会话一半以上的取证时间。交接文档的投入产出比，是所有文档里最高的。

十一、环境：把不确定性挡在会话之外

11.1 环境问题伪装成"模型不行"

前面提到，小会话（调用 < 20）的失败率高达 52%。抽样看这些会话，失败原因高度集中在环境层面：

依赖没装、版本不对；
路径不存在、盘符不对；
命令在某个 shell 里可用、在另一个里不可用；
编码不是 UTF-8，读出来是乱码；
权限不足，写不进去；
网络访问被策略拒绝。

这些问题的共同点是：它们跟模型的能力完全无关，但表现出来就是"它不行"。一个会话如果在第一分钟就撞上环境问题，你很难不产生"这工具不好用"的印象。

经验十：先把环境跑通，再谈任务。 在正式开工前，用一个"冒烟会话"验证：能不能读到目标目录、能不能跑构建、能不能跑测试、能不能访问网络。这些验证花五分钟，能省掉后面五十分钟的困惑。

11.2 沙箱与权限：理解边界，而不是对抗

数据里能看到清晰的权限边界痕迹：

大量"不可修改/不可写入"错误（384 + 67 次），说明写操作被限制在特定范围内；
少量"沙箱拒绝"标记，说明存在更严格的拦截；
3 次认证失败，说明外部服务需要凭据。

这些边界的意义不是"阻碍"，而是"防呆"。真正麻烦的不是边界存在，而是你不知道边界在哪，于是反复试探、反复失败。

对策：开工前明确三件事------能写哪里、能读哪里、能不能联网。把这三件事写进简报，代理就不会去试探边界。

11.3 编码：一个被低估的坑

34 次"非法 UTF-8"错误看起来不多，但它背后是一个更大的问题：中文环境下的编码陷阱。

典型场景：

用某个 shell 读文件，输出是乱码；
用某个语言运行时读标准输入，默认编码不是 UTF-8；
写文件时没指定编码，落盘成了本地编码；
正则匹配中文字符时，字节边界和字符边界不一致。

这些问题的对策都很具体：读文件显式声明编码、处理标准输入前先重设编码、写文件统一用 UTF-8、正则用 Unicode 模式。

经验十一：中文环境下，任何涉及文本读写的操作都要显式处理编码。 默认值不可信。

11.4 超时：不是"等久一点"能解决的

425 次超时错误，占全部错误的 13.6%。这些超时的分布很有意思：

短会话里超时占比更高（约 17%），长会话里更低（约 8%）；
说明超时更多发生在"第一次尝试"时------因为第一次往往不知道要跑多久。

对策有三层：

能后台就后台：跑构建、跑全量测试、下载依赖，一律丢后台；
能拆分就拆分：一个批处理拆成几个小批，每批都在预算内；
能缓存就缓存：重复的计算结果存下来，下次直接读。

最不该做的，是把超时当成"网络慢"然后反复重试。超时通常意味着"这次的工作量超过了单次预算"，重试只会再超时一次。

11.5 让环境可复现

数据里有一个细节：同一个工作目录下，不同会话的表现差异很大。有的会话一次跑通，有的会话反复失败。差异往往不在任务本身，而在环境状态------依赖装没装、缓存有没有、后台进程占没占端口。

可复现的环境意味着：任何一个新会话，都能从零开始跑通同样的流程。做法包括：把环境准备写成脚本、把依赖版本锁定、把"跑通"的判据写进文档。

这件事的收益是复利的：环境越稳定，你越敢开新会话；开新会话越便宜，你越愿意把任务拆小；任务拆得越小，返工成本越低。

十二、收尾：为什么"做完了"不等于"交付了"

12.1 交付动作的分布

数据里显式出现"交付"事件（把文件推给用户）的会话有 85 个，共涉及数百个产物。按文件类型分：

类型	数量
Markdown 文档	235
源码文件	183
图片	64
Word 文档	56
视频	37
图纸	35
演示文稿	19
PDF	14
其他（脚本、JSON、字幕、安装包、压缩包等）	约 40

这个分布很说明问题：交付物以"文档 + 代码"为主，其次是"图 + 视频 + 图纸"这类需要人眼验收的产物。

而后者恰恰是最容易出问题的：文档可以自动检查格式，代码可以自动跑测试，但"这张图对不对"只能人看。

12.2 交付的三个层次

层次一：文件存在

最基础的交付是"文件生成在指定路径"。这一层很容易达成，也很容易出问题------路径错了、名字错了、编码错了、内容是空的。

层次二：文件可验证

文件不仅要存在，还要能被独立验证。比如：导出的表格能被重新读回来、数值对得上；生成的文档能打开、目录能跳转；渲染的图分辨率正确、没有截断。

数据里那些高质量的交付，几乎都附带了验证证据："22 项检查全部通过""重新读回比对一致""构建产物大小符合预期"。

层次三：文件可交接

最高层次的交付是"别人拿到就能用"：有说明、有边界、有复现步骤。这类交付的典型形态是一个压缩包，里面除了产物，还有 README、验证脚本、已知问题清单。

经验十二：交付的时候，附上"怎么验证"和"有什么已知问题"。 这两段话的成本很低，但能省掉接收方大量的猜测。

12.3 收尾清单

一个合格的收尾应该覆盖：

产物在约定路径，能打开、内容非空；
验证已跑过，结论已贴出（不是"应该没问题"）；
临时文件已清理（或明确说明保留原因）；
改动清单已列出（改了哪些文件、为什么）；
工作区状态已声明（干净 / 有未提交改动 / 有后台任务在跑）；
已知问题已写明（哪些没做、哪些做了但有边界）；
下一步已说明（如果需要别人接手）。

这七条里，最常被省略的是后三条，也恰恰是最影响"可交接性"的三条。

12.4 归档：给未来的自己留索引

回到最开始的那个观察：216 个归档会话全部是根会话，450 个未归档里 439 个是子代理。

这说明归档这个动作，实际上是在做**"我主导的工作"的索引**。子代理不需要索引，因为它们是一次性的执行单元；根会话需要索引，因为它们是"一件事"的载体。

好的归档习惯是：

一件事一个根会话（不要在一个会话里塞三件不相干的事）；
做完就归档（不要让列表里堆着二十个"看起来还在进行"的僵尸会话）；
标题即索引（标题要能让人三秒想起"这是干什么的"）。

数据里有一个反面例子：有 14 个会话完全没有标题，其中 6 个还被归档了。这些会话在列表里就是"无标题会话 #7"，等于没有索引。

经验十三：会话标题是你未来的搜索关键词。 开题时花十秒写一个准确的标题，比事后回忆强一百倍。

十三、DSH 的能力面：哪些被用起来了，哪些被浪费了

这一节只谈这个具体工具的能力使用情况。它比前几节更"私人"，但恰恰是最有行动价值的部分------因为能力闲置的损失是隐性的，你不会痛，只会一直用不上。

13.1 使用率光谱

把各种能力按"实际触发的会话数"排开，差距非常悬殊：

能力	触发的会话数	使用率（占 666）
代码执行入口（批量程序化操作）	641	96%
子代理委派	440	66%
待办清单	163	24%
显式交付（present）	85	13%
团队任务板	60	9%
目标（goal）	17	2.6%
上下文压缩	20	3.0%
技能（skill）	0	0%
提问用户（ask_user_question）	1	0.15%
联网搜索	1	0.15%

这张表里最扎眼的两行是：技能调用 0 次，提问工具 1 次。

13.2 技能：装了几十个，一次没用

会话开始时的系统提示里，列着一份很长的技能目录------文档处理、代码审查、测试驱动、调试方法论、各类领域工具箱，几十个条目，每个都带触发条件。但七周里，没有任何一个会话真正加载过其中任何一个技能。

这不是"技能没用"，而是三个原因叠加：

（1）技能是"按需触发"的，而人不知道什么时候该按。

技能目录挂在系统提示里，模型看得见，但人看不见。人不知道自己"应该"让它加载什么，于是永远不触发。

（2）任务被拆得太碎，碎片够不上技能的粒度。

技能大多面向"一整类工作"（比如"做一次完整的代码审查""按 TDD 流程实现一个功能"），而实际的会话往往是"改这一处""看这一段"。粒度对不上，技能就落不了地。

（3）人已经形成了自己的流程，不需要技能来教。

这是最根本的原因：当你有了一套稳定的做法（先取证、再列清单、再实施、再验证），技能里写的那套流程对你来说是冗余的。

经验十四：装了不用的东西，等于没装。 技能的价值不在于"存在"，而在于"被想起"。要么在开工时主动点名（"用 X 技能来做这件事"），要么就别装------装一堆不用的技能，只会让系统提示变长、让模型的注意力被稀释。

13.3 提问工具：一次

ask_user_question 七周里只被调用了 1 次。这个数字很能说明问题：代理极少主动提问，它更倾向于"猜一个然后做"。

猜的代价是什么？前面已经量化过：大量返工来自"假设错了"。如果代理在关键分叉点上多问一句，很多返工本可以避免。

但也不能全怪代理。人其实也不喜欢被问------每次提问都意味着一次中断。所以真正的解法不是"让代理多问"，而是在简报里预先指定"什么时候必须问"：

遇到以下情况必须停下来问，不要猜：涉及删除文件、涉及改公共接口、涉及与既有约定冲突、涉及你无法从材料中确认的事实。

把"必须问"的条件写清楚，提问就从"打断"变成了"契约"。

13.4 目标模式：17 个会话

目标（goal）是一个"跨轮次持续推进同一件事"的机制，适合那种"一轮做不完、但方向明确"的任务。17 个会话用过它，占比 2.6%。

用过的会话有个共同特征：任务周期长、验收标准明确、且需要跨多次自动续跑。没用过的会话，大多是"一次对话内能收尾"的活。

这个比例其实是合理的------大部分任务确实不需要跨轮次目标。但如果你发现自己的长任务经常"做着做着就散了"，那可能是该用目标模式了：它会把"目标"钉在系统里，而不是靠你每轮提醒。

13.5 团队任务板：60 个会话，310 个任务

团队任务板是并行协作的中枢：60 个会话用过，累计 310 个任务，完成 284 个（91.6%），292 个带写入范围声明，14 个带依赖关系。

这个使用率（9%）比技能高得多，原因很实际：当你要同时推进五件事时，任务板是唯一能让你不混乱的东西。它把"谁在做什么、做到哪了、能不能开始"从脑子里搬到了界面上。

值得注意的是那 91.6% 的完成率。它说明这套机制是可靠的------但也要注意选择性偏差：会去建任务板的任务，本来就是被拆得比较清楚的任务。

13.6 交付（present）：85 个会话

只有 85 个会话（13%）显式做了"交付"动作。剩下的会话，产物要么散落在对话里，要么只是"文件已生成"而没有被明确推出。

这是一个被低估的损失。交付动作的意义不只是"把文件给用户"，更是"宣告这件事结束了"。没有交付动作的会话，往往在心理上一直"没结束"，于是被反复回访、反复修改。

经验十五：做完就交付，交付即收尾。 哪怕产物只是一个中间版本，显式推出来也比留在工作区里强------它给了这件事一个明确的边界。

13.7 后台任务

数据里有大量后台任务注册与结算事件（约 1.7 万次注册、1.7 万次结算）。这说明"长任务丢后台"已经是稳定的习惯，也是前面反复强调的那条经验的落地形态。

后台任务真正的价值不在于"省时间"，而在于它把"等待"从阻塞变成了并行。当你把构建丢到后台，你可以同时读代码、写文档、准备下一个任务。而同步等待的时候，你什么都做不了。

13.8 一个总的判断

这份能力清单呈现出一个很清晰的模式：这个用户把工具用成了一个"高度自定义的执行器"，而不是一个"功能齐全的助手"。

执行层面用到了极致（96% 的会话用批量程序化操作）；
协作层面用得不错（66% 的子代理、9% 的任务板）；
但"元能力"几乎闲置（技能 0%、提问 0.15%、目标 2.6%）。

这个模式没有对错，它只是选择的结果。但值得问一句：那些闲置的能力，是真的不需要，还是只是没想到？

以我自己的判断：技能和提问这两个，大概率是"没想到"多过"不需要"。前者需要一个"什么时候该点名"的习惯，后者需要一份"什么时候必须问"的清单。这两样东西的成本都很低，收益却是复利式的。

十四、二十条可复用的经验清单

把前面散落的结论收敛成一份可以直接照着做的清单。每一条都标注了依据（数字或观察），便于判断它在你的场景里是否成立。

关于"怎么开口"

1. 首轮把口径一次付清。

根会话首条消息的中位数只有 78 字，但那些一次跑通的会话，首条消息普遍在 200--800 字，且包含目标、事实源、验收、交付、节奏五个槽位。口径留到中途补，会产生"先做错再返工"的额外调用。

2. 显式写下"不要做什么"。

最高频的返工原因不是"做错了"，而是"多做了一点"。写清楚禁区（不要改 X、不要引入依赖、不要提交），比写清楚目标更能减少返工。

3. 指定唯一事实源。

当同一件事有多份描述时，明确"以谁为准"。数据里大量返工的根因是"代理按代码实现，人按图判断"，两边都没错但对不上。

4. 验收标准必须是可执行的。

"做好了"不是标准，"测试全绿 + 构建成功 + 产物能读回来"才是。没有可执行标准，代理会用"我觉得可以"收尾。

关于"什么时候停"

5. 第一次觉得不对就打断。

中断会话的中位调用数只有 5 次。越早打断越便宜；等到跑了几百步再推翻，沉没成本极高。

6. 连续两次同类错误，换方法而不是重试。

第三次重试同一个动作，成功率不会比第二次更高。数据里高错误率会话的共同特征是"同一类错误反复出现"。

7. 方案与执行分离。

方向不确定、错误代价高的任务，先要方案再执行；机械、可逆、验证便宜的任务，直接干更快。判据是：修复成本 > 沟通成本时，先要方案。

8. 看到上下文压缩，先固化口径。

压缩出现意味着早期信息正在被摘要替换。此时应该把确认的事实写成文件，而不是继续追加内容。

关于"怎么分活"

9. 只把"可切片、可独立验收"的活分出去。

章节写作、素材生成、只读侦察、独立验证适合委派；跨文件一致性重构、需要手感的调试、需要与人反复对齐的设计不适合。

10. 分工简报要写满六段。

背景、任务、必读、硬性约束、验收、交付。每一段都对应一类事故。子代理简报的中位长度是 2,000 字，不是因为它啰嗦，而是因为省掉哪段就会在哪段出事。

11. 给每个子代理划死写入范围。

310 个团队任务里 292 个写了写入范围。并行写同一片区域，合并时必然冲突。

12. 委派"可判定的任务"，把"需要判断的任务"留给自己。

子代理看不到全局，让它做判断题，它只能猜。

关于"怎么用工具"

13. 把批量操作写成程序，而不是发一串调用。

98.7% 的调用走同一个代码执行入口，618 个会话全程只用这一个工具。批量读、批量改、批量验证，都在一段程序里完成，只把摘要带回上下文。

14. 读要批量，写要小步。

读取可以并发、可以汇总；写入应该一次一处、改完即验。这是返工最少的会话的共同特征。

15. 长任务丢后台。

构建、测试、下载一律后台化，别在超时预算里硬等。425 次超时错误里，相当一部分是"把太多活塞进一次调用"。

16. 给输出加预算。

只打印条数、样本、摘要。把整个文件内容打印出来，等于把省下的上下文又还回去。

关于"怎么收尾"

17. 交付要附"怎么验证"和"已知问题"。

85 个会话有显式交付动作，质量高的那些都带了验证证据和边界说明。

18. 收尾七件事：产物、验证、清理、改动清单、工作区状态、已知问题、下一步。

最常被省略的是后三件，也恰恰是最影响交接的三件。

19. 一件事一个会话，做完就归档。

216 个归档会话全是根会话，439 个未归档是子代理。归档是给人主导的工作建索引，不是给执行单元建索引。

20. 标题就是未来的搜索关键词。

14 个会话没有标题，其中 6 个还是归档会话。开题时十秒写一个准确标题，比事后翻记录强得多。

十五、十种反模式

经验清单告诉你该做什么，反模式告诉你别做什么。下面每一条都能在数据里找到对应的痕迹。

反模式一：把代理当搜索引擎

一句话丢过去，期待它自己猜出全部背景。结果：它按最字面的理解做了一版，你说不对，它换一种字面理解又做一版。

症状：会话很短、轮次很少、返工很快、你越来越烦躁。

解药：把"我以为它知道"的东西写下来。写的过程本身就是梳理。

反模式二：用否定代替纠偏

"不对""还是不行""重做"。代理不知道哪里不对，只能随机换一种写法。

症状：同一类错误反复出现，你在重复同一句话。

解药：指出具体差异 + 给出新证据 + 明确优先级。

反模式三：一次改十个地方

改完十个文件再统一验证，出错时面对十个嫌疑犯。

症状：错误定位靠猜，回滚靠重来。

解药：一次一处，改完即验。

反模式四：让会话无限延长

一个会话跑三天，中间压缩八次，最后谁也说不清做到哪了。

症状：压缩次数多、轮次多、你开始记不清上下文。

解药：按可交付段落切分，每段结束写交接。

反模式五：不做环境验证就开工

依赖没装、路径不对、编码不对，第一分钟就撞墙。

症状：大量"一句话就结束"的短会话，失败率极高。

解药：先用一个冒烟会话验证环境。

反模式六：把并行当默认

什么事都开三个子代理并行做。结果是三份不一致的实现，合并时互相打架。

症状：子代理产出风格不一、接口对不上、合并冲突。

解药：只并行"天然独立"的工作；有共享状态的部分串行。

反模式七：不看产物只看汇报

代理说"已完成"，你就信了。实际上它只改了文件，没跑验证。

症状：交付后才发现跑不起来。

解药：要求"验证证据"，而不是"完成声明"。

反模式八：把所有东西塞进对话

需求、口径、决策、临时数据，全在聊天记录里。

症状：换会话就失忆，压缩就丢细节。

解药：关键信息落文件，对话只做"指针"。

反模式九：迷信"更强的模型"

遇到问题就换模型，而不是改方法。

症状：换了一圈模型，同样的问题还在。

解药：先判断问题是"表达不清"还是"能力不足"。数据里绝大多数失败是前者。

反模式十：不归档、不命名、不总结

列表里堆着几十个无标题会话，下次全部重来。

症状：找不到上次的成果，重复劳动。

解药：一件事一个会话、做完归档、标题写清楚。

十六、几条更深的体会

16.1 代理的能力边界，其实是你表达能力的边界

这份语料里最反直觉的发现是：失败很少来自"模型不会"，更多来自"人没说清"。

看那些高错误率会话，几乎都能找到同一个模式：代理在一个错误的假设上反复尝试。而这个假设，往往来自指令里的某个模糊之处------"优化一下"是优化性能还是优化结构？"参考这个图"是参考形状还是参考尺寸？"按之前的方案"是哪个方案？

一旦这些模糊点被澄清，同一个模型立刻就能做对。所以，"模型行不行"这个问题的答案，很大程度上取决于"你把问题定义清楚了没有"。

16.2 人机协作的节奏，比工具本身更重要

数据里最健康的会话，节奏都很像：

人给一段结构化的输入（200--800 字）；
代理取证、列清单、给方案；
人点头或修正；
代理实施、验证、交付；
人说"继续"或"提交"。

这个节奏里，人的注意力集中在两个点：开头定义问题 和中途纠偏。其余时间人在等待。

而那些痛苦的会话，节奏是乱的：人在代理干活时不断插话，代理在人的插话中不断切换方向，最后谁也不知道目标是什么。

好的协作不是"多沟通"，而是"在正确的时刻沟通"。

16.3 长跑的关键不是速度，是"可回滚"

那些跑到 1,892 次调用的会话，最终能收住，靠的不是"每一步都对"，而是"每一步都能退回去"。

可回滚意味着：改动是分段的、每段有验证、验证结果有记录、失败能定位到具体哪一段。这四件事做到，再长的任务也不会失控。

反过来，一个"一口气改完再验证"的任务，哪怕只有二十步，失败时也是全盘重来。

16.4 归档是一种认知劳动

归档看起来只是个整理动作，实际上它强迫你做三件事：

判断这件事结束了没有（很多人不敢归档，因为"可能还要改"）；
给这件事起个名字（命名即理解）；
把它从工作记忆里释放出去（这是最被低估的收益）。

216 个归档会话背后，是 216 次"这件事我确认结束了"的判断。这个判断本身，就是项目管理能力的一部分。

16.5 记录本身就是资产

这份复盘能写出来，唯一的原因是：所有的交互都被记录下来了。

如果没有这些记录，我对过去七周的理解只会剩下几个模糊的印象："那段时间老在改几何""有几天一直在调视频"。而有了记录，我能说出"错误率的 21.6% 是语法错误""有 47 组同一天同目录的重启""压缩集中在 20 个会话"。

这些数字不会让你变成更好的使用者，但它们会告诉你该往哪里改。而"知道该往哪里改"，恰恰是经验积累的本质。

十七、结语：把工具用成手艺

七周、666 个会话、819,180 条事件，摊开来看，其实就是一部"人怎么学习指挥机器"的记录。

前期的会话笨拙：一句话丢过去，期待奇迹；中期开始摸到门道：学会写结构化简报、学会划边界、学会要验证证据；后期形成节奏：知道什么活该分、什么活该自己盯、什么时候该停。

这个过程没有什么神秘的技巧，无非是把几件事重复做对：

把问题定义清楚（目标、事实源、验收、边界）；
把工作切成可验证的段（一段一验证，一段一交付）；
把关键信息外置（写文件，别只留在对话里）；
在正确的时刻介入（开头定义、中途纠偏、结尾验收）；
把经验记下来（归档、命名、复盘）。

这五件事，跟用哪个模型、哪个工具、哪个版本，关系都不大。它们更像是手艺人的基本功：下刀之前先看清楚，下刀之后立刻检查，做完之后收拾干净。

工具会一直变。今天的长处可能明天就成了短处，今天的坑可能明天就被填平。但"把意图表达清楚、把工作切成可验证的段、把经验沉淀下来"这三件事，会一直有效。

最后，用数据里最有意思的一组对比收尾。

同一批会话里，首条消息短于 80 字的，中位调用 96 次、完成率 83%；首条消息超过 300 字的，中位调用 46--60 次、完成率 89%。乍看之下，好像"写长一点"就能省下一半调用。

但这里混着一个陷阱：长首条消息的会话里，绝大多数是子代理的分工简报------它们的"长"来自结构（背景、任务、必读、约束、验收、交付），而不是修辞。真正可比的是根会话内部：按"首条消息有没有结构"分组，结构化那组错误率 2.5，非结构化 4.6；但样本只有个位数，不足以下强结论。不过这个方向与子代理那边是一致的。

所以更准确的说法是：省下那些调用的，不是字数的多少，而是结构的有无。差的不是那几百字，而是那几行"边界、验收、交付"------它们通常就是你事后最想补上的那几行。

附录一：文中提到的机制速查

为了不假设读者熟悉这个工具，把文中反复出现的几个机制简单说明一下。这部分偏"说明书"，可以跳过。

会话（session）

一次连续的交互记录。每次开新会话，代理的记忆从零开始------除了系统提示和它自己读到的文件。这是理解"为什么要写交接文档"的前提。

轮次（turn）与步（step）

一轮 = 你发一次消息，它回应（可能包含多步）。一步 = 一次模型调用 + 它发起的工具调用。文中的"1,892 次调用"指的是步这一级。

工具调用 / 代码执行入口

代理不能直接操作你的电脑，它只能调用工具。这个环境里最主要的工具是一个"代码执行入口"：它接收一段程序，在沙箱里跑，把打印出来的内容返回给模型。所以"调用一次工具"往往意味着"跑了一小段程序"。

PTC（programmatic tool calling）

就是上面那种"写程序调用工具"的模式。它的对立面是"一次调一个工具、看一眼结果、再调下一个"。文中的 98.7% 说的是这个模式占了绝大多数。

子代理（subagent）

主代理派生出来的"分身"，有自己的上下文窗口，接收一份任务简报，干完把结果交回来。它看不到主代理的历史，所以简报必须自包含。

团队任务板（team task）

多个代理共享的任务清单。任务有状态（待处理/进行中/完成）、有依赖、有写入范围声明。文中的 310 个任务就是它上面的条目。

目标（goal）

跨轮次持续存在的目标对象。和"待办清单"不同，目标是为了让代理在多次自动续跑中不跑偏。

上下文压缩（compaction）

当对话太长、超出模型窗口时，系统会把早期内容摘要成一段更短的文本，腾出空间。压缩会丢细节，但不会丢"最近发生的事"。

沙箱（sandbox）与权限预设

限制代理能读能写哪些路径、能不能联网、要不要每次操作都问你。文中出现的"cannot modify"错误，多数是沙箱在按规则拦截。

归档（archive）

把会话从默认列表里收起来，不删除。它是一个纯组织动作，不影响文件内容。

会话深度（delegation depth）

0 = 你自己开的会话；1 = 由它派生的子代理会话；2 = 子代理再派生。文中 212 / 408 / 1 的分布就是按这个分的。

附录二：本文数据口径速查

项目	口径
会话总数	666（672 个文件去重后）
归档 / 未归档	216 / 450
根会话 / 子代理	212 / 408（另有 1 个深度 2）
事件总数	819,180
工具调用	72,275
执行步	73,817
轮次	2,236
工具错误	3,130（按事件计）
人类消息	1,919（已剔除系统注入）
系统注入消息	11,735
模型侧重试	1,168（TRANSPORT 653 / RATE_LIMIT 228 / SERVER 209 / TIMEOUT 75）
上下文压缩	47 次，分布在 20 个会话
团队任务	310（完成 284）
子代理描述	443（可续 440 / 一次性 3）
显式交付	85 个会话
覆盖工作目录	34
时间跨度	2026-09-07 至 2026-10-29

说明：错误数在不同统计口径下略有差异（按事件 3,130、按去重会话 2,859），本文正文采用按事件计的口径；涉及"会话数"的结论一律按去重后的 666 计。归档状态来自应用自身的归档记录，与文件是否存在无关。