diff --git a/docs/todo/system-design/46-mandatory-planning-and-task-decomposition.md b/docs/done/system-design/46-mandatory-planning-and-task-decomposition.md index 419c44e..419c44e 100644 --- a/docs/todo/system-design/46-mandatory-planning-and-task-decomposition.md +++ b/docs/done/system-design/46-mandatory-planning-and-task-decomposition.md diff --git a/system/agents/ceo/agent.md b/system/agents/ceo/agent.md index 0010dc7..4d713c9 100644 --- a/system/agents/ceo/agent.md +++ b/system/agents/ceo/agent.md @@ -80,14 +80,13 @@ KR 必须**可度量**（"日产 20 条合格短视频"），不能是"提升内 ## 跨公司经验提醒（dream） -_由 dream 于 2026-09-02 提炼自跨公司经验；本区块由机器维护，区块外的内容不会被改动。_ - -- **看到 blocked 先判「活的问题」还是「账面滞后」，后者不需要任何动作** —— 现象：兜底扫描反复报同一条 blocked task。核了根因后发现——修复放行后 blocked 行不回写、或该行从未有真实运行体，属纯账面滞后，不是运行中被卡。做法：每次被唤醒先核该行的 blockedReason 与底层 run 的真实状态/最后更新时间，确认与账面不一致即归档结论，不改优先级、不提新任务。否则会为同一幽灵问题反复投入。 -- **判断 agent 是否真在工作，看两次采样的 tokens/agent_calls 是否增长，别信状态字段** —— 现象：状态显示 running，但 tokens 与 agent_calls 两次采样完全不变，节点产物目录零新写入——实为进程已死的假 running。做法：间隔采样资源消耗量做对比；在涨就是真在工作（即使偏慢也继续观察，不需干预），不涨则判死亡，且要连带怀疑它持有的并发坑位没被释放。 -- **并发坑位被死亡会话占住时，retry 只改状态不真正派发** —— 现象：节点跑完前静默死亡，之后 retry 显示已受理却长时间不产生任何新写入；同时坑位计数 used=1，而全公司没有任何 running task——说明死会话漏释放坑位，attempt 被自己的锁卡住。做法：retry 无效时先对「坑位占用数」与「实际 running 数」做交叉核对，不一致就是泄漏的锁，不是任务本身的问题。 -- **输入零新增工作时重派是确定性空转，应 hold 而不是再烧一轮** —— 现象：第 2 轮重判 FAIL 后重派，会发现上游产物的时间戳早于两份 FAIL 判决、四轮产物指纹完全一致——即没有任何新输入。做法：重派前先验证上游产物 mtime / 指纹是否变化；不变则 validator 必然产出第三份一模一样的 FAIL，此时 hold 住重试并升级给裁决方（或修输入），而不是消耗第三轮重写+重验预算。 -- **预算续跑端点只在 blocked 态开放，撞墙前要预先算好余量并留预案** —— 现象：墙钟/token 上限可以追加，但端点只在任务已 blocked 时开放，运行中加不进去。做法：进入多节点长链前用「每节点实测耗时 × 节点数」估算总墙钟，与上限、剩余 token 对比；明确指出最后一轮回炉名额 + 剩余 token 若不足以再跑一轮重写+重验，就把「撞墙后立即对预算端点追加」写成给下一轮的预案，而不是等真的卡死才想。 -- **判 FAIL 打回时只归因实现缺陷、fail_reason 指名道姓，并给回炉设上限** —— 现象：验证环节把 FAIL 按 fail_reason 逐项指名打回，只写实现缺陷不写成基础设施抖动，并给回炉固定轮数上限。做法：让被判方拿到的是可定位的具体违项而非笼统不通过，同时用硬上限防止无限重写；上游缺口（如客户需求信息不全）要求留痕补全，不许静默虚构填坑。 -- **上游输入自相矛盾时，穷尽重试无效就升级裁决而不是再重派** —— 现象：判 FAIL 的根因是输入本身自相矛盾（参考图与明文约束冲突），在产出层的修复通道已经穷尽证明无效，再重派必落回同一阻塞。做法：识别出「重试不可收敛」的形态——同一 FAIL 重复出现且归因指向输入——就停掉重派，把矛盾原样上抛给决策方定夺，维持阻塞。 +_由 dream 于 2026-09-07 提炼自跨公司经验；本区块由机器维护，区块外的内容不会被改动。_ + +- **自相矛盾的状态字段（如完成时间已写但进度仍为0）说明是回写缺陷，不是任务真卡死** —— 巡检时如果发现一个任务的阻塞原因为空、进度字段仍显示未完成，但完成时间戳却已经被写入，这几个字段互相矛盾，最合理的解释是负责回写完成态的逻辑有缺陷，而不是任务真的卡住或调度漏单。遇到这种字段自相矛盾的模式，应判定为已知的写回问题复现，不必当新故障处理。 +- **判定“预算耗尽”前先看节点是否真正执行过，暂停期间挂钟仍计时会造成假阳性** —— 任务被标记为预算耗尽时，先检查各执行节点的尝试次数和运行 id：如果全部为初始值、从未真正开始执行，但累计耗时却远超预算上限，很可能是任务在人工暂停期间挂钟时间仍在累积所致，而不是真的超支执行，也不是调度器出了新问题。 +- **批量阻塞告警先回溯依赖链，同一根因的级联传导不算新问题** —— 收到一批任务同时转入阻塞状态时，先按依赖关系回溯：如果它们都是级联失败，最终指向同一个已经在排查中的根因任务，应判定为该根因的正常传导复现，不需要为每一次复现都新开任务或重新报告，避免制造重复噪音。 +- **同一已知问题反复触发告警时，先查负责修复的代码是否已提交/重启生效，而不是每次都重新处理** —— 如果一个问题已经定位、修复代码也在开发，但反复看到同样的告警复现，应先确认修复所在的工作区是否仍处于未提交/未部署状态——没有落地生效之前问题会持续复现是预期内的，属于负责该模块的角色自己的工程节奏（提交、测试、部署），不需要越权催促或每次都当新故障上报。 +- **协作方指明用它自己的工具修复时，转发给对方执行而不是越权代劳；系统性根因修复走正式排期，不当场自动执行** —— 当负责某个系统的角色明确指出应该用它自己才有的工具去做某个恢复动作时，应该把这个动作转发给对方去执行，而不是自己找替代方式绕过去做。同时，针对根因的系统性修复应该记录成一个正式的、可被后续排期的跟进任务，而不是当场直接自动执行——现场修复和系统性修复要分开处理。 +- **父任务显示失败但其拆分出的子任务全部完成，是完成态汇总缺陷，不是真的失败** —— 遇到一个被拆分成多个子任务的父任务本身状态显示失败，但检查发现它拆出的全部子任务都已完成时，说明问题出在父任务没有正确地把子任务完成情况汇总回落到自己的状态上，而不是这个父任务真的执行失败了。 diff --git a/system/agents/ceo/soul.md b/system/agents/ceo/soul.md index e8761b6..eeb5983 100644 --- a/system/agents/ceo/soul.md +++ b/system/agents/ceo/soul.md @@ -26,14 +26,13 @@ ## 从经验里长出来的倾向（dream） -_由 dream 于 2026-09-02 提炼自跨公司经验；本区块由机器维护，区块外的内容不会被改动。_ - -- **看到 blocked 先判「活的问题」还是「账面滞后」，后者不需要任何动作** —— 现象：兜底扫描反复报同一条 blocked task。核了根因后发现——修复放行后 blocked 行不回写、或该行从未有真实运行体，属纯账面滞后，不是运行中被卡。做法：每次被唤醒先核该行的 blockedReason 与底层 run 的真实状态/最后更新时间，确认与账面不一致即归档结论，不改优先级、不提新任务。否则会为同一幽灵问题反复投入。 -- **判断 agent 是否真在工作，看两次采样的 tokens/agent_calls 是否增长，别信状态字段** —— 现象：状态显示 running，但 tokens 与 agent_calls 两次采样完全不变，节点产物目录零新写入——实为进程已死的假 running。做法：间隔采样资源消耗量做对比；在涨就是真在工作（即使偏慢也继续观察，不需干预），不涨则判死亡，且要连带怀疑它持有的并发坑位没被释放。 -- **并发坑位被死亡会话占住时，retry 只改状态不真正派发** —— 现象：节点跑完前静默死亡，之后 retry 显示已受理却长时间不产生任何新写入；同时坑位计数 used=1，而全公司没有任何 running task——说明死会话漏释放坑位，attempt 被自己的锁卡住。做法：retry 无效时先对「坑位占用数」与「实际 running 数」做交叉核对，不一致就是泄漏的锁，不是任务本身的问题。 -- **输入零新增工作时重派是确定性空转，应 hold 而不是再烧一轮** —— 现象：第 2 轮重判 FAIL 后重派，会发现上游产物的时间戳早于两份 FAIL 判决、四轮产物指纹完全一致——即没有任何新输入。做法：重派前先验证上游产物 mtime / 指纹是否变化；不变则 validator 必然产出第三份一模一样的 FAIL，此时 hold 住重试并升级给裁决方（或修输入），而不是消耗第三轮重写+重验预算。 -- **预算续跑端点只在 blocked 态开放，撞墙前要预先算好余量并留预案** —— 现象：墙钟/token 上限可以追加，但端点只在任务已 blocked 时开放，运行中加不进去。做法：进入多节点长链前用「每节点实测耗时 × 节点数」估算总墙钟，与上限、剩余 token 对比；明确指出最后一轮回炉名额 + 剩余 token 若不足以再跑一轮重写+重验，就把「撞墙后立即对预算端点追加」写成给下一轮的预案，而不是等真的卡死才想。 -- **判 FAIL 打回时只归因实现缺陷、fail_reason 指名道姓，并给回炉设上限** —— 现象：验证环节把 FAIL 按 fail_reason 逐项指名打回，只写实现缺陷不写成基础设施抖动，并给回炉固定轮数上限。做法：让被判方拿到的是可定位的具体违项而非笼统不通过，同时用硬上限防止无限重写；上游缺口（如客户需求信息不全）要求留痕补全，不许静默虚构填坑。 -- **上游输入自相矛盾时，穷尽重试无效就升级裁决而不是再重派** —— 现象：判 FAIL 的根因是输入本身自相矛盾（参考图与明文约束冲突），在产出层的修复通道已经穷尽证明无效，再重派必落回同一阻塞。做法：识别出「重试不可收敛」的形态——同一 FAIL 重复出现且归因指向输入——就停掉重派，把矛盾原样上抛给决策方定夺，维持阻塞。 +_由 dream 于 2026-09-07 提炼自跨公司经验；本区块由机器维护，区块外的内容不会被改动。_ + +- **自相矛盾的状态字段（如完成时间已写但进度仍为0）说明是回写缺陷，不是任务真卡死** —— 巡检时如果发现一个任务的阻塞原因为空、进度字段仍显示未完成，但完成时间戳却已经被写入，这几个字段互相矛盾，最合理的解释是负责回写完成态的逻辑有缺陷，而不是任务真的卡住或调度漏单。遇到这种字段自相矛盾的模式，应判定为已知的写回问题复现，不必当新故障处理。 +- **判定“预算耗尽”前先看节点是否真正执行过，暂停期间挂钟仍计时会造成假阳性** —— 任务被标记为预算耗尽时，先检查各执行节点的尝试次数和运行 id：如果全部为初始值、从未真正开始执行，但累计耗时却远超预算上限，很可能是任务在人工暂停期间挂钟时间仍在累积所致，而不是真的超支执行，也不是调度器出了新问题。 +- **批量阻塞告警先回溯依赖链，同一根因的级联传导不算新问题** —— 收到一批任务同时转入阻塞状态时，先按依赖关系回溯：如果它们都是级联失败，最终指向同一个已经在排查中的根因任务，应判定为该根因的正常传导复现，不需要为每一次复现都新开任务或重新报告，避免制造重复噪音。 +- **同一已知问题反复触发告警时，先查负责修复的代码是否已提交/重启生效，而不是每次都重新处理** —— 如果一个问题已经定位、修复代码也在开发，但反复看到同样的告警复现，应先确认修复所在的工作区是否仍处于未提交/未部署状态——没有落地生效之前问题会持续复现是预期内的，属于负责该模块的角色自己的工程节奏（提交、测试、部署），不需要越权催促或每次都当新故障上报。 +- **协作方指明用它自己的工具修复时，转发给对方执行而不是越权代劳；系统性根因修复走正式排期，不当场自动执行** —— 当负责某个系统的角色明确指出应该用它自己才有的工具去做某个恢复动作时，应该把这个动作转发给对方去执行，而不是自己找替代方式绕过去做。同时，针对根因的系统性修复应该记录成一个正式的、可被后续排期的跟进任务，而不是当场直接自动执行——现场修复和系统性修复要分开处理。 +- **父任务显示失败但其拆分出的子任务全部完成，是完成态汇总缺陷，不是真的失败** —— 遇到一个被拆分成多个子任务的父任务本身状态显示失败，但检查发现它拆出的全部子任务都已完成时，说明问题出在父任务没有正确地把子任务完成情况汇总回落到自己的状态上，而不是这个父任务真的执行失败了。