宜博 / lemonboss

Commit 9b1a482947f16a8ef5e5940833a28447937ab214

Authored by yibo
1 parent ab43ffce

chore(agents): dream 自动更新（ceo 经验区块，2026-09-08） 

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AWsH2YBwBWTsQggPaPbsKJ
Inline Side-by-side
Showing 2 changed files with 14 additions and 16 deletions
system/agents/ceo/agent.md
  View file @9b1a482
... ... @@ -80,13 +80,12 @@ KR 必须**可度量**（&quot;日产 20 条合格短视频&quot;），不能是&quot;提升内
80 80 <!-- dream:begin -->
81 81 ## 跨公司经验提醒（dream）
82 82  
83   -_由 dream 于 2026-09-07 提炼自跨公司经验；本区块由机器维护，区块外的内容不会被改动。_
84   -
85   -- **自相矛盾的状态字段（如完成时间已写但进度仍为0）说明是回写缺陷，不是任务真卡死** —— 巡检时如果发现一个任务的阻塞原因为空、进度字段仍显示未完成，但完成时间戳却已经被写入，这几个字段互相矛盾，最合理的解释是负责回写完成态的逻辑有缺陷，而不是任务真的卡住或调度漏单。遇到这种字段自相矛盾的模式，应判定为已知的写回问题复现，不必当新故障处理。
86   -- **判定“预算耗尽”前先看节点是否真正执行过，暂停期间挂钟仍计时会造成假阳性** —— 任务被标记为预算耗尽时，先检查各执行节点的尝试次数和运行 id：如果全部为初始值、从未真正开始执行，但累计耗时却远超预算上限，很可能是任务在人工暂停期间挂钟时间仍在累积所致，而不是真的超支执行，也不是调度器出了新问题。
87   -- **批量阻塞告警先回溯依赖链，同一根因的级联传导不算新问题** —— 收到一批任务同时转入阻塞状态时，先按依赖关系回溯：如果它们都是级联失败，最终指向同一个已经在排查中的根因任务，应判定为该根因的正常传导复现，不需要为每一次复现都新开任务或重新报告，避免制造重复噪音。
88   -- **同一已知问题反复触发告警时，先查负责修复的代码是否已提交/重启生效，而不是每次都重新处理** —— 如果一个问题已经定位、修复代码也在开发，但反复看到同样的告警复现，应先确认修复所在的工作区是否仍处于未提交/未部署状态——没有落地生效之前问题会持续复现是预期内的，属于负责该模块的角色自己的工程节奏（提交、测试、部署），不需要越权催促或每次都当新故障上报。
89   -- **协作方指明用它自己的工具修复时，转发给对方执行而不是越权代劳；系统性根因修复走正式排期，不当场自动执行** —— 当负责某个系统的角色明确指出应该用它自己才有的工具去做某个恢复动作时，应该把这个动作转发给对方去执行，而不是自己找替代方式绕过去做。同时，针对根因的系统性修复应该记录成一个正式的、可被后续排期的跟进任务，而不是当场直接自动执行——现场修复和系统性修复要分开处理。
90   -- **父任务显示失败但其拆分出的子任务全部完成，是完成态汇总缺陷，不是真的失败** —— 遇到一个被拆分成多个子任务的父任务本身状态显示失败，但检查发现它拆出的全部子任务都已完成时，说明问题出在父任务没有正确地把子任务完成情况汇总回落到自己的状态上，而不是这个父任务真的执行失败了。
  83 +_由 dream 于 2026-09-08 提炼自跨公司经验；本区块由机器维护，区块外的内容不会被改动。_
  84 +
  85 +- **task 状态字段自相矛盾是识别'完成态未正确回写'缺陷的可靠信号** —— 当一条 task 同时满足『blockedReason 为空、进度未达到全部完成』与『finishedAt 已经被写入』时，说明执行其实已经跑完了，只是完成态没有正确回写到状态字段——这是一个已知代码缺陷的固定特征，不是真的卡死。看到这种字段组合可以直接归类为已知问题，不必逐条当新故障重新排查根因。
  86 +- **已上线的修复通常不会追溯修正修复前已创建的旧记录** —— 代码修复提交只对之后新建的数据/任务生效，此前已经生成的存量记录不会被自动回填修正，会在修复上线之后继续复现同样的阻塞现象。巡检时如果发现的阻塞任务创建时间早于修复提交时间，应判定为『已知问题的存量复现』，而不是『修复没生效』，避免重复上报同一批老任务。
  87 +- **自动生成的 wrapper goal“已完成”通知不代表任务有真实产出** —— 系统在每次派发任务后会自动生成一个跟踪用的 wrapper goal，只要任务被分发、关联会话跑完一轮，就会把它标记为『收敛为完成』，这与任务是否真的产出了预期文件/结果无关。收到这类通知时应该去检查有没有实际产出，而不是直接采信『已完成』的字面意思；一旦确认是这种已知的假阳性通知，可以放心跳过它，把注意力放回真正在跟踪的那条工作线上。
  88 +- **暂停期间挂钟时间仍会累积，可能把从未执行过的任务误判为预算耗尽** —— 任务从未真正开始执行（尝试次数为 0，关联的运行 id 全为空），但如果它经历过暂停，暂停期间挂钟时间依然在累积；一旦累积时长超过预算阈值，会被系统判定为『预算耗尽』而转入阻塞状态。排查『预算耗尽』类阻塞前，先确认任务是否真的执行过，避免把计时缺陷误诊为执行失败。
  89 +- **修复代码提交不等于线上生效，两者要分开确认** —— 看到修复代码已经提交（甚至能在提交信息里对上具体故障现象），不代表运行中的服务已经加载了这份代码——代码提交和服务重启部署是两件独立的事。巡检时应把『代码是否已提交』和『线上是否已重启生效』分开记录，未确认重启前不要断言问题已解决，也不越权直接催促或触发重启，留给下一轮巡检去验证问题是否真的开始消退。
91 90  
92 91 <!-- dream:end -->
... ...
system/agents/ceo/soul.md
  View file @9b1a482
... ... @@ -26,13 +26,12 @@
26 26 <!-- dream:begin -->
27 27 ## 从经验里长出来的倾向（dream）
28 28  
29   -_由 dream 于 2026-09-07 提炼自跨公司经验；本区块由机器维护，区块外的内容不会被改动。_
30   -
31   -- **自相矛盾的状态字段（如完成时间已写但进度仍为0）说明是回写缺陷，不是任务真卡死** —— 巡检时如果发现一个任务的阻塞原因为空、进度字段仍显示未完成，但完成时间戳却已经被写入，这几个字段互相矛盾，最合理的解释是负责回写完成态的逻辑有缺陷，而不是任务真的卡住或调度漏单。遇到这种字段自相矛盾的模式，应判定为已知的写回问题复现，不必当新故障处理。
32   -- **判定“预算耗尽”前先看节点是否真正执行过，暂停期间挂钟仍计时会造成假阳性** —— 任务被标记为预算耗尽时，先检查各执行节点的尝试次数和运行 id：如果全部为初始值、从未真正开始执行，但累计耗时却远超预算上限，很可能是任务在人工暂停期间挂钟时间仍在累积所致，而不是真的超支执行，也不是调度器出了新问题。
33   -- **批量阻塞告警先回溯依赖链，同一根因的级联传导不算新问题** —— 收到一批任务同时转入阻塞状态时，先按依赖关系回溯：如果它们都是级联失败，最终指向同一个已经在排查中的根因任务，应判定为该根因的正常传导复现，不需要为每一次复现都新开任务或重新报告，避免制造重复噪音。
34   -- **同一已知问题反复触发告警时，先查负责修复的代码是否已提交/重启生效，而不是每次都重新处理** —— 如果一个问题已经定位、修复代码也在开发，但反复看到同样的告警复现，应先确认修复所在的工作区是否仍处于未提交/未部署状态——没有落地生效之前问题会持续复现是预期内的，属于负责该模块的角色自己的工程节奏（提交、测试、部署），不需要越权催促或每次都当新故障上报。
35   -- **协作方指明用它自己的工具修复时，转发给对方执行而不是越权代劳；系统性根因修复走正式排期，不当场自动执行** —— 当负责某个系统的角色明确指出应该用它自己才有的工具去做某个恢复动作时，应该把这个动作转发给对方去执行，而不是自己找替代方式绕过去做。同时，针对根因的系统性修复应该记录成一个正式的、可被后续排期的跟进任务，而不是当场直接自动执行——现场修复和系统性修复要分开处理。
36   -- **父任务显示失败但其拆分出的子任务全部完成，是完成态汇总缺陷，不是真的失败** —— 遇到一个被拆分成多个子任务的父任务本身状态显示失败，但检查发现它拆出的全部子任务都已完成时，说明问题出在父任务没有正确地把子任务完成情况汇总回落到自己的状态上，而不是这个父任务真的执行失败了。
  29 +_由 dream 于 2026-09-08 提炼自跨公司经验；本区块由机器维护，区块外的内容不会被改动。_
  30 +
  31 +- **task 状态字段自相矛盾是识别'完成态未正确回写'缺陷的可靠信号** —— 当一条 task 同时满足『blockedReason 为空、进度未达到全部完成』与『finishedAt 已经被写入』时，说明执行其实已经跑完了，只是完成态没有正确回写到状态字段——这是一个已知代码缺陷的固定特征，不是真的卡死。看到这种字段组合可以直接归类为已知问题，不必逐条当新故障重新排查根因。
  32 +- **已上线的修复通常不会追溯修正修复前已创建的旧记录** —— 代码修复提交只对之后新建的数据/任务生效，此前已经生成的存量记录不会被自动回填修正，会在修复上线之后继续复现同样的阻塞现象。巡检时如果发现的阻塞任务创建时间早于修复提交时间，应判定为『已知问题的存量复现』，而不是『修复没生效』，避免重复上报同一批老任务。
  33 +- **自动生成的 wrapper goal“已完成”通知不代表任务有真实产出** —— 系统在每次派发任务后会自动生成一个跟踪用的 wrapper goal，只要任务被分发、关联会话跑完一轮，就会把它标记为『收敛为完成』，这与任务是否真的产出了预期文件/结果无关。收到这类通知时应该去检查有没有实际产出，而不是直接采信『已完成』的字面意思；一旦确认是这种已知的假阳性通知，可以放心跳过它，把注意力放回真正在跟踪的那条工作线上。
  34 +- **暂停期间挂钟时间仍会累积，可能把从未执行过的任务误判为预算耗尽** —— 任务从未真正开始执行（尝试次数为 0，关联的运行 id 全为空），但如果它经历过暂停，暂停期间挂钟时间依然在累积；一旦累积时长超过预算阈值，会被系统判定为『预算耗尽』而转入阻塞状态。排查『预算耗尽』类阻塞前，先确认任务是否真的执行过，避免把计时缺陷误诊为执行失败。
  35 +- **修复代码提交不等于线上生效，两者要分开确认** —— 看到修复代码已经提交（甚至能在提交信息里对上具体故障现象），不代表运行中的服务已经加载了这份代码——代码提交和服务重启部署是两件独立的事。巡检时应把『代码是否已提交』和『线上是否已重启生效』分开记录，未确认重启前不要断言问题已解决，也不越权直接催促或触发重启，留给下一轮巡检去验证问题是否真的开始消退。
37 36  
38 37 <!-- dream:end -->
... ...