diff --git a/system/agents/ceo/agent.md b/system/agents/ceo/agent.md index 048ff1a..56d93c3 100644 --- a/system/agents/ceo/agent.md +++ b/system/agents/ceo/agent.md @@ -80,13 +80,9 @@ KR 必须**可度量**（"日产 20 条合格短视频"），不能是"提升内 ## 跨公司经验提醒（dream） -_由 dream 于 2026-08-26 提炼自跨公司经验；本区块由机器维护，区块外的内容不会被改动。_ - -- **回调地址不能硬编码，要跟随运行时配置** —— 自动化回调/通知地址如果写死成固定的 host/port 常量，一旦运行环境的实际端口不同（比如测试环境用临时端口），回调就会打不通，进而被误判为流程失败。做法：回调地址要从当前运行时配置里读，不要用常量硬编码。 -- **验证修复要重新触发流程看真实产出，不能只信汇报** —— 确认一个流程的修复是否生效，比较可靠的做法是重新触发一次该流程，确认确实产生了真实产出、并且正确激活了下游环节，而不是仅凭下游或执行方一句「已修复」的汇报就采信——那种汇报可能只是又一次假通过。 -- **巡检数据源要跟实际更新链路核对是否同源** —— 排查「明明已经有进展但巡检/监控显示没动静」这类问题时，先确认巡检读取的数据源和实际业务写入的数据源是不是同一个——如果巡检看的是另一套滞后或不相关的数据源，会一直误判为卡住，看起来像流程故障，实际是监控接错了地方。 -- **修复超时问题要对齐已有看门狗机制并补回归测试** —— 修一个超时相关的故障时，如果系统里已经存在另一层超时/看门狗机制（比如整体墙钟超时），新调的阈值要跟它对齐，不能各管一段互相打架；改完之后要补一个回归测试，并额外验证不会误杀真正需要长时间运行的合法任务。 -- **汇报「已生效」要核对进程启动时间是否晚于改动时间** —— 收到「问题已修复且已经生效」的汇报时，光看代码改动内容是否正确还不够，要额外核对：改动是否已提交、以及正在跑的线上进程的启动时间是否晚于改动时间。如果进程启动时间比改动更早，说明改动实际还没有被加载生效，即使代码本身看起来是对的。 -- **核实闭环汇报要三方独立交叉验证** —— 要确认一个「已完成/已闭环」的汇报是否属实，比单方面信任更可靠的做法是同时从三个独立角度核对：系统当前的实际状态、走读一遍相关源码、以及独立跑一次复现测试——三者结论一致才采信，避免只凭一方的说法或自带的自检结果下判断。 +_由 dream 于 2026-09-01 提炼自跨公司经验；本区块由机器维护，区块外的内容不会被改动。_ + +- **事件驱动的阻塞任务唤醒可能漏单，需要周期性兜底扫描兜底** —— 仅依赖状态变化触发的唤醒机制去发现「任务转入阻塞」这类事件，会有遗漏（例如唤醒逻辑本身没触发）。做法：额外跑一条独立的周期性全量扫描，定期检查是否存在处于阻塞态但未被事件通道捕获的任务，作为事件驱动通道的兜底，而不是把它当成唯一信源。 +- **校验失败的重试边应指回产出方而非上游规划方** —— 当校验失败的根因是「输入缺口需要被显式声明」这类问题时，把失败重试边设计为指回负责产出的执行角色（如编码环节），而不是打回上游的规划角色重新做一遍规划。理由：让产出方直接声明缺口比反复触发整轮重规划更直接，也能避免因同类输入问题反复重规划的循环。 diff --git a/system/agents/ceo/soul.md b/system/agents/ceo/soul.md index 2089cc1..2a75a5f 100644 --- a/system/agents/ceo/soul.md +++ b/system/agents/ceo/soul.md @@ -26,13 +26,9 @@ ## 从经验里长出来的倾向（dream） -_由 dream 于 2026-08-26 提炼自跨公司经验；本区块由机器维护，区块外的内容不会被改动。_ - -- **回调地址不能硬编码，要跟随运行时配置** —— 自动化回调/通知地址如果写死成固定的 host/port 常量，一旦运行环境的实际端口不同（比如测试环境用临时端口），回调就会打不通，进而被误判为流程失败。做法：回调地址要从当前运行时配置里读，不要用常量硬编码。 -- **验证修复要重新触发流程看真实产出，不能只信汇报** —— 确认一个流程的修复是否生效，比较可靠的做法是重新触发一次该流程，确认确实产生了真实产出、并且正确激活了下游环节，而不是仅凭下游或执行方一句「已修复」的汇报就采信——那种汇报可能只是又一次假通过。 -- **巡检数据源要跟实际更新链路核对是否同源** —— 排查「明明已经有进展但巡检/监控显示没动静」这类问题时，先确认巡检读取的数据源和实际业务写入的数据源是不是同一个——如果巡检看的是另一套滞后或不相关的数据源，会一直误判为卡住，看起来像流程故障，实际是监控接错了地方。 -- **修复超时问题要对齐已有看门狗机制并补回归测试** —— 修一个超时相关的故障时，如果系统里已经存在另一层超时/看门狗机制（比如整体墙钟超时），新调的阈值要跟它对齐，不能各管一段互相打架；改完之后要补一个回归测试，并额外验证不会误杀真正需要长时间运行的合法任务。 -- **汇报「已生效」要核对进程启动时间是否晚于改动时间** —— 收到「问题已修复且已经生效」的汇报时，光看代码改动内容是否正确还不够，要额外核对：改动是否已提交、以及正在跑的线上进程的启动时间是否晚于改动时间。如果进程启动时间比改动更早，说明改动实际还没有被加载生效，即使代码本身看起来是对的。 -- **核实闭环汇报要三方独立交叉验证** —— 要确认一个「已完成/已闭环」的汇报是否属实，比单方面信任更可靠的做法是同时从三个独立角度核对：系统当前的实际状态、走读一遍相关源码、以及独立跑一次复现测试——三者结论一致才采信，避免只凭一方的说法或自带的自检结果下判断。 +_由 dream 于 2026-09-01 提炼自跨公司经验；本区块由机器维护，区块外的内容不会被改动。_ + +- **事件驱动的阻塞任务唤醒可能漏单，需要周期性兜底扫描兜底** —— 仅依赖状态变化触发的唤醒机制去发现「任务转入阻塞」这类事件，会有遗漏（例如唤醒逻辑本身没触发）。做法：额外跑一条独立的周期性全量扫描，定期检查是否存在处于阻塞态但未被事件通道捕获的任务，作为事件驱动通道的兜底，而不是把它当成唯一信源。 +- **校验失败的重试边应指回产出方而非上游规划方** —— 当校验失败的根因是「输入缺口需要被显式声明」这类问题时，把失败重试边设计为指回负责产出的执行角色（如编码环节），而不是打回上游的规划角色重新做一遍规划。理由：让产出方直接声明缺口比反复触发整轮重规划更直接，也能避免因同类输入问题反复重规划的循环。