修复报告MiniCode 项目详解7自适应控制系统缺陷的修复报告-CSDN博客之前的详解已全部更新为修复后的版本MiniCode 项目详解3Agent 循环骨架 (agent_loop.py)-CSDN博客MiniCode 项目详解4自适应控制系统上-CSDN博客MiniCode 项目详解5自适应控制系统下-CSDN博客缺陷总览#缺陷严重度影响所在文件1传感器输入数据是假的 严重StateObserver/PredictiveController 基于错误数据做决策agent_loop.py, cybernetic_orchestrator.py2SelfHealingEngine 一半策略是 placebo 严重故障检测到了但修不好self_healing_engine.py3缺少真实 Agent A/B 对比评测 严重现有消融框架主要是合成控制器模拟无法证明真实 Agent 是否受益cybernetic_ablation.py, tests/4DecouplingController 的耦合矩阵没被 PID 消费 中等耦合矩阵虽被计算但没有回写 PID多变量耦合无人补偿decoupling_controller.py, agent_loop.py, cybernetic_orchestrator.py5FeedforwardController 没调 PID setpoint 中等所有任务用同样的 PID 目标值feedforward_controller.py, feedback_controller.py6to_system_state() 的 oscillation_index 是死数据 中等ContextCybernetics 算的振荡检测没被消费context_cybernetics.py, feedback_controller.py7两个独立的振荡检测器 中等重复计算语义不同但名字相同context_cybernetics.py, feedback_controller.py8缺少 conditional integrationPID anti-windup 不完整 轻微误差反转时 PID 有短暂响应延迟feedback_controller.py, context_cybernetics.py9PredictiveController 的预测建议只打日志不执行 轻微预测到了问题但不处理实际压缩由别的模块执行predictive_controller.py, cybernetic_orchestrator.py10集成测试文件缺失 轻微不存在 test_cybernetic_integration.py缺少真实控制器链路的集成覆盖tests/test_cybernetic_integration.py详细说明缺陷 1传感器输入数据是假的症状# cybernetic_orchestrator.py:191 (step_start) measurement MeasurementVector( response_timestep * 2.0, # ← 硬编码假设每步刚好 2 秒 ... ) # cybernetic_orchestrator.py:243 (step_end) snapshot MetricSnapshot( avg_latencystep * 2.0, # ← 同上 ... )影响链response_timestep*2.0→ StateObserver 的 Kalman Filter → internal_load 估计值不准avg_latencystep*2.0→ StabilityMonitor 的快照 → 后续耦合分析不准agent_loop.py中解耦控制的token_usage_to_latency也使用step*2.0/60.0因此 StateObserver、StabilityMonitor 和 DecouplingController 都没有使用同一次 LLM 调用的真实延迟修复方案 在agent_loop.py:950的 LLM 调用前后加计时t0 time.time() next_step _model_next(model, current_messages, ...) actual_response_time time.time() - t0然后将actual_response_time传给step_start()和step_end()替换step * 2.0。需要修改的文件agent_loop.pyLLM 调用处加计时传递实际耗时cybernetic_orchestrator.pystep_start()和step_end()接受actual_response_time参数缺陷 2SelfHealingEngine 一半策略是 placebo症状# self_healing_engine.py:323-330 def _execute_reduce_concurrency(self) - dict[str, Any]: if self._tool_scheduler and hasattr(self._tool_scheduler, _controller): return {success: True, action: Reduced concurrency to minimum...} return {success: True, action: Concurrency reduction logged (no scheduler ref)}两个分支都只返回 dict没有实际修改任何东西。placebo 执行器清单执行器声称做什么实际做什么_execute_reduce_concurrency降低并发返回 dict_execute_reduce_timeout缩短超时返回 dict_execute_safe_mode安全模式返回 dict_execute_force_terminate强制终止返回 dict实际起作用的执行器执行器实际效果_execute_cybernetic_compaction调用orchestrator.try_reactive_recover()→ 真实压缩_execute_dampen_oscillation修改pid.kd*2, pid.kp*0.5, pid.ki0.01_execute_force_compaction调用 orchestrator 或 compactor_execute_model_upgrade调整 token_budget依赖 compactor 存在修复方案 4 个 placebo 执行器需要接入真实的运行时修改逻辑1._execute_reduce_concurrency设置tool_scheduler._force_max_workers 12._execute_reduce_timeout设置tool_scheduler的超时参数如果存在3._execute_safe_mode设置tool_scheduler为串行模式4._execute_force_terminate调用tool_scheduler的取消/终止方法需要修改的文件self_healing_engine.py4 个执行器补充真实逻辑缺陷 3缺少真实环境 A/B 对比评测症状cybernetic_ablation.py有消融框架但它跑的是确定性合成数据不调用真实 LLMtests/test_cybernetic_integration.py当前不存在不是空文件没有enable_work_chainTruevsFalse的真实对比数据修复方案 1.选取 5-10 个真实编码任务如在 xxx 文件中添加一个函数2.对每个任务跑两遍enable_work_chainTruevsenable_work_chainFalse3.对比指标任务完成率、总 token 消耗、工具错误数、总步数4.将对比数据写入cybernetic_ablation的报告需要做的事情编写缺失的tests/test_cybernetic_integration.py准备真实任务集跑对比实验并记录结果缺陷 4DecouplingController 的耦合矩阵没被 PID 消费症状# decoupling_controller.py:176-191 def compute_decoupling_matrix(self) - dict[str, dict[str, float]]: # 计算了 token_usage↔latency, context_pressure↔error_rate 等耦合关系 # 结果没有被任何 PID 参数或控制指令消费当前调用点在agent_loop.py:1352-1363会记录测量并计算矩阵但随后没有应用矩阵结果。该调用位于orch.step_end()之前并不是只在not orch分支执行实际问题是矩阵计算与 PID 控制之间没有闭环。影响5 个独立 PID3 个 FeedbackController 1 个 ContextPID 1 个 CostControl各自独立运行一个 PID 的输出变化会影响另一个 PID 的输入但没有补偿机制。修复方案 将解耦矩阵的计算结果回注到 PID 参数中。例如如果token_usage_to_latency耦合度 0.5则降低性能 PID 的 kp避免过度反应。需要修改的文件decoupling_controller.py增加apply_to_pid()方法cybernetic_orchestrator.py在step_end中调用解耦 → PID 参数调整缺陷 5FeedforwardController 没调 PID setpoint症状 PID 的 setpoint 对所有任务都一样# feedback_controller.py:177-179 self._stability_target 0.85 self._performance_target 0.75 self._efficiency_target 0.60FeedforwardController 能根据任务意图SEARCH/REFACTOR/CODE设置不同的 token_budget、concurrency、timeout但从不修改 PID setpoint。修复方案 1.在PreemptiveConfig中增加三个字段stability_setpoint: float 0.85 performance_setpoint: float 0.75 efficiency_setpoint: float 0.602.在FeedforwardController._INTENT_CONFIGS中为不同意图设置不同目标# SEARCH 任务稳定性要求低效率要求高 IntentType.SEARCH: {..., stability_setpoint: 0.70, performance_setpoint: 0.60, efficiency_setpoint: 0.80} # REFACTOR 任务稳定性要求高效率可以低 IntentType.REFACTOR: {..., stability_setpoint: 0.90, performance_setpoint: 0.80, efficiency_setpoint: 0.50}3.在agent_loop.py初始化阶段将 setpoint 应用到FeedbackController需要修改的文件feedforward_controller.pyPreemptiveConfig增加字段_INTENT_CONFIGS增加映射feedback_controller.py增加set_setpoints()方法cybernetic_orchestrator.pystep_end中应用前馈 setpoint缺陷 6to_system_state() 的 oscillation_index 是死数据症状# context_cybernetics.py:858 oscillation_index1.0 if fb_stats.get(oscillation_detected) else 0.0这个值被写入SystemState.oscillation_index但FeedbackController.observe()从未读取state.oscillation_index。它使用的是自己的_compute_oscillation()。修复方案二选一方案 A删除to_system_state()中的oscillation_index字段方案 B让observe()使用state.oscillation_index替代自己的_compute_oscillation()需要修改的文件context_cybernetics.py方案 A 删除字段或方案 B 传递原始信号feedback_controller.py方案 B 消费state.oscillation_index缺陷 7两个独立的振荡检测器症状检测器 A检测器 B位置CyberneticFeedbackLoop.detect_oscillation()FeedbackController._compute_oscillation()监测对象压缩结果的方向变化稳定性误差的方向变化输出类型bool (0 或 1)float (0.0-1.0)被谁消费SystemState →无人消费ControlSignal → SelfHealingEngine两个检测器做类似的事统计方向变化但检测不同信号输出的名字都叫 oscillation 但含义不同。修复方案 统一为一个振荡检测器放在FeedbackController中。ContextCybernetics 的反馈环只负责提供原始方向变化次数由 FeedbackController 统一计算振荡指数。需要修改的文件context_cybernetics.py移除CyberneticFeedbackLoop.detect_oscillation()暴露direction_changes原始值feedback_controller.py_compute_oscillation()接受来自 ContextCybernetics 的额外信号缺陷 8PID anti-windup 不完整症状 两个 PID 都做了 clamp anti-windup很好但没有conditional integration——当误差穿越 0 时不清零积分项。# feedback_controller.py:133-135 (外层) self._state.integral error * dt self._state.integral max(-10.0, min(10.0, self._state.integral)) # context_cybernetics.py:249-251 (内层) self._integral error * dt self._integral max(-2.0, min(2.0, self._integral))影响当误差由正变负时积分项需要从 clamp 上限降到 0这段时间 PID 输出仍然偏高。在上下文压力突然变化时如大文件读取完成可能有 1-3 步的响应延迟。修复方案 在compute()方法中加条件积分逻辑# 当误差穿越 0 时清零积分项 if error * self._prev_error 0: self._integral 0.0需要修改的文件feedback_controller.pyPIDController.compute()方法context_cybernetics.pyContextPIDController.compute()方法缺陷 9PredictiveController 预测建议只打日志症状# cybernetic_orchestrator.py:212-217 actions self.predictive.generate_predictive_actions() if actions and actions[0].urgency 0.7: action actions[0] if action.recommended_action trigger_compaction and self.context_cybernetics: logger.info(Predictive: trigger_compaction urgency%.2f, action.urgency) # 注意只打日志不调用 context_cybernetics.run_cycle()影响预测到了上下文即将溢出但只记录不行动。真正的压缩由 ContextCybernetics 的 PID 在执行 step_end 时触发但预测的提前量被浪费了。修复方案 当预测urgency 0.7且建议是trigger_compaction时实际调用context_cybernetics.run_cycle()实现预测性压缩不等 PID 反应过来。需要修改的文件cybernetic_orchestrator.pystep_start()中增加实际的压缩调用缺陷 10集成测试文件缺失症状tests/test_cybernetic_integration.py当前不存在。虽然有test_advanced_cybernetics.py658 行控制器的单元测试cybernetic_ablation.py853 行合成数据的消融框架但缺少使用 Mock LLM、真实控制器组合和 Agent 执行链路进行端到端验证的集成测试。修复方案 编写test_cybernetic_integration.py包含 1.Mock LLM 真实控制器的集成测试2.模拟故障场景上下文溢出、错误爆发、振荡验证自愈引擎3.enable_work_chainTrue vs False 的对比测试需要做的事情编写集成测试用例准备 mock 场景
MiniCode 项目详解6：原项目控制系统的10个缺陷（已修复）
修复报告MiniCode 项目详解7自适应控制系统缺陷的修复报告-CSDN博客之前的详解已全部更新为修复后的版本MiniCode 项目详解3Agent 循环骨架 (agent_loop.py)-CSDN博客MiniCode 项目详解4自适应控制系统上-CSDN博客MiniCode 项目详解5自适应控制系统下-CSDN博客缺陷总览#缺陷严重度影响所在文件1传感器输入数据是假的 严重StateObserver/PredictiveController 基于错误数据做决策agent_loop.py, cybernetic_orchestrator.py2SelfHealingEngine 一半策略是 placebo 严重故障检测到了但修不好self_healing_engine.py3缺少真实 Agent A/B 对比评测 严重现有消融框架主要是合成控制器模拟无法证明真实 Agent 是否受益cybernetic_ablation.py, tests/4DecouplingController 的耦合矩阵没被 PID 消费 中等耦合矩阵虽被计算但没有回写 PID多变量耦合无人补偿decoupling_controller.py, agent_loop.py, cybernetic_orchestrator.py5FeedforwardController 没调 PID setpoint 中等所有任务用同样的 PID 目标值feedforward_controller.py, feedback_controller.py6to_system_state() 的 oscillation_index 是死数据 中等ContextCybernetics 算的振荡检测没被消费context_cybernetics.py, feedback_controller.py7两个独立的振荡检测器 中等重复计算语义不同但名字相同context_cybernetics.py, feedback_controller.py8缺少 conditional integrationPID anti-windup 不完整 轻微误差反转时 PID 有短暂响应延迟feedback_controller.py, context_cybernetics.py9PredictiveController 的预测建议只打日志不执行 轻微预测到了问题但不处理实际压缩由别的模块执行predictive_controller.py, cybernetic_orchestrator.py10集成测试文件缺失 轻微不存在 test_cybernetic_integration.py缺少真实控制器链路的集成覆盖tests/test_cybernetic_integration.py详细说明缺陷 1传感器输入数据是假的症状# cybernetic_orchestrator.py:191 (step_start) measurement MeasurementVector( response_timestep * 2.0, # ← 硬编码假设每步刚好 2 秒 ... ) # cybernetic_orchestrator.py:243 (step_end) snapshot MetricSnapshot( avg_latencystep * 2.0, # ← 同上 ... )影响链response_timestep*2.0→ StateObserver 的 Kalman Filter → internal_load 估计值不准avg_latencystep*2.0→ StabilityMonitor 的快照 → 后续耦合分析不准agent_loop.py中解耦控制的token_usage_to_latency也使用step*2.0/60.0因此 StateObserver、StabilityMonitor 和 DecouplingController 都没有使用同一次 LLM 调用的真实延迟修复方案 在agent_loop.py:950的 LLM 调用前后加计时t0 time.time() next_step _model_next(model, current_messages, ...) actual_response_time time.time() - t0然后将actual_response_time传给step_start()和step_end()替换step * 2.0。需要修改的文件agent_loop.pyLLM 调用处加计时传递实际耗时cybernetic_orchestrator.pystep_start()和step_end()接受actual_response_time参数缺陷 2SelfHealingEngine 一半策略是 placebo症状# self_healing_engine.py:323-330 def _execute_reduce_concurrency(self) - dict[str, Any]: if self._tool_scheduler and hasattr(self._tool_scheduler, _controller): return {success: True, action: Reduced concurrency to minimum...} return {success: True, action: Concurrency reduction logged (no scheduler ref)}两个分支都只返回 dict没有实际修改任何东西。placebo 执行器清单执行器声称做什么实际做什么_execute_reduce_concurrency降低并发返回 dict_execute_reduce_timeout缩短超时返回 dict_execute_safe_mode安全模式返回 dict_execute_force_terminate强制终止返回 dict实际起作用的执行器执行器实际效果_execute_cybernetic_compaction调用orchestrator.try_reactive_recover()→ 真实压缩_execute_dampen_oscillation修改pid.kd*2, pid.kp*0.5, pid.ki0.01_execute_force_compaction调用 orchestrator 或 compactor_execute_model_upgrade调整 token_budget依赖 compactor 存在修复方案 4 个 placebo 执行器需要接入真实的运行时修改逻辑1._execute_reduce_concurrency设置tool_scheduler._force_max_workers 12._execute_reduce_timeout设置tool_scheduler的超时参数如果存在3._execute_safe_mode设置tool_scheduler为串行模式4._execute_force_terminate调用tool_scheduler的取消/终止方法需要修改的文件self_healing_engine.py4 个执行器补充真实逻辑缺陷 3缺少真实环境 A/B 对比评测症状cybernetic_ablation.py有消融框架但它跑的是确定性合成数据不调用真实 LLMtests/test_cybernetic_integration.py当前不存在不是空文件没有enable_work_chainTruevsFalse的真实对比数据修复方案 1.选取 5-10 个真实编码任务如在 xxx 文件中添加一个函数2.对每个任务跑两遍enable_work_chainTruevsenable_work_chainFalse3.对比指标任务完成率、总 token 消耗、工具错误数、总步数4.将对比数据写入cybernetic_ablation的报告需要做的事情编写缺失的tests/test_cybernetic_integration.py准备真实任务集跑对比实验并记录结果缺陷 4DecouplingController 的耦合矩阵没被 PID 消费症状# decoupling_controller.py:176-191 def compute_decoupling_matrix(self) - dict[str, dict[str, float]]: # 计算了 token_usage↔latency, context_pressure↔error_rate 等耦合关系 # 结果没有被任何 PID 参数或控制指令消费当前调用点在agent_loop.py:1352-1363会记录测量并计算矩阵但随后没有应用矩阵结果。该调用位于orch.step_end()之前并不是只在not orch分支执行实际问题是矩阵计算与 PID 控制之间没有闭环。影响5 个独立 PID3 个 FeedbackController 1 个 ContextPID 1 个 CostControl各自独立运行一个 PID 的输出变化会影响另一个 PID 的输入但没有补偿机制。修复方案 将解耦矩阵的计算结果回注到 PID 参数中。例如如果token_usage_to_latency耦合度 0.5则降低性能 PID 的 kp避免过度反应。需要修改的文件decoupling_controller.py增加apply_to_pid()方法cybernetic_orchestrator.py在step_end中调用解耦 → PID 参数调整缺陷 5FeedforwardController 没调 PID setpoint症状 PID 的 setpoint 对所有任务都一样# feedback_controller.py:177-179 self._stability_target 0.85 self._performance_target 0.75 self._efficiency_target 0.60FeedforwardController 能根据任务意图SEARCH/REFACTOR/CODE设置不同的 token_budget、concurrency、timeout但从不修改 PID setpoint。修复方案 1.在PreemptiveConfig中增加三个字段stability_setpoint: float 0.85 performance_setpoint: float 0.75 efficiency_setpoint: float 0.602.在FeedforwardController._INTENT_CONFIGS中为不同意图设置不同目标# SEARCH 任务稳定性要求低效率要求高 IntentType.SEARCH: {..., stability_setpoint: 0.70, performance_setpoint: 0.60, efficiency_setpoint: 0.80} # REFACTOR 任务稳定性要求高效率可以低 IntentType.REFACTOR: {..., stability_setpoint: 0.90, performance_setpoint: 0.80, efficiency_setpoint: 0.50}3.在agent_loop.py初始化阶段将 setpoint 应用到FeedbackController需要修改的文件feedforward_controller.pyPreemptiveConfig增加字段_INTENT_CONFIGS增加映射feedback_controller.py增加set_setpoints()方法cybernetic_orchestrator.pystep_end中应用前馈 setpoint缺陷 6to_system_state() 的 oscillation_index 是死数据症状# context_cybernetics.py:858 oscillation_index1.0 if fb_stats.get(oscillation_detected) else 0.0这个值被写入SystemState.oscillation_index但FeedbackController.observe()从未读取state.oscillation_index。它使用的是自己的_compute_oscillation()。修复方案二选一方案 A删除to_system_state()中的oscillation_index字段方案 B让observe()使用state.oscillation_index替代自己的_compute_oscillation()需要修改的文件context_cybernetics.py方案 A 删除字段或方案 B 传递原始信号feedback_controller.py方案 B 消费state.oscillation_index缺陷 7两个独立的振荡检测器症状检测器 A检测器 B位置CyberneticFeedbackLoop.detect_oscillation()FeedbackController._compute_oscillation()监测对象压缩结果的方向变化稳定性误差的方向变化输出类型bool (0 或 1)float (0.0-1.0)被谁消费SystemState →无人消费ControlSignal → SelfHealingEngine两个检测器做类似的事统计方向变化但检测不同信号输出的名字都叫 oscillation 但含义不同。修复方案 统一为一个振荡检测器放在FeedbackController中。ContextCybernetics 的反馈环只负责提供原始方向变化次数由 FeedbackController 统一计算振荡指数。需要修改的文件context_cybernetics.py移除CyberneticFeedbackLoop.detect_oscillation()暴露direction_changes原始值feedback_controller.py_compute_oscillation()接受来自 ContextCybernetics 的额外信号缺陷 8PID anti-windup 不完整症状 两个 PID 都做了 clamp anti-windup很好但没有conditional integration——当误差穿越 0 时不清零积分项。# feedback_controller.py:133-135 (外层) self._state.integral error * dt self._state.integral max(-10.0, min(10.0, self._state.integral)) # context_cybernetics.py:249-251 (内层) self._integral error * dt self._integral max(-2.0, min(2.0, self._integral))影响当误差由正变负时积分项需要从 clamp 上限降到 0这段时间 PID 输出仍然偏高。在上下文压力突然变化时如大文件读取完成可能有 1-3 步的响应延迟。修复方案 在compute()方法中加条件积分逻辑# 当误差穿越 0 时清零积分项 if error * self._prev_error 0: self._integral 0.0需要修改的文件feedback_controller.pyPIDController.compute()方法context_cybernetics.pyContextPIDController.compute()方法缺陷 9PredictiveController 预测建议只打日志症状# cybernetic_orchestrator.py:212-217 actions self.predictive.generate_predictive_actions() if actions and actions[0].urgency 0.7: action actions[0] if action.recommended_action trigger_compaction and self.context_cybernetics: logger.info(Predictive: trigger_compaction urgency%.2f, action.urgency) # 注意只打日志不调用 context_cybernetics.run_cycle()影响预测到了上下文即将溢出但只记录不行动。真正的压缩由 ContextCybernetics 的 PID 在执行 step_end 时触发但预测的提前量被浪费了。修复方案 当预测urgency 0.7且建议是trigger_compaction时实际调用context_cybernetics.run_cycle()实现预测性压缩不等 PID 反应过来。需要修改的文件cybernetic_orchestrator.pystep_start()中增加实际的压缩调用缺陷 10集成测试文件缺失症状tests/test_cybernetic_integration.py当前不存在。虽然有test_advanced_cybernetics.py658 行控制器的单元测试cybernetic_ablation.py853 行合成数据的消融框架但缺少使用 Mock LLM、真实控制器组合和 Agent 执行链路进行端到端验证的集成测试。修复方案 编写test_cybernetic_integration.py包含 1.Mock LLM 真实控制器的集成测试2.模拟故障场景上下文溢出、错误爆发、振荡验证自愈引擎3.enable_work_chainTrue vs False 的对比测试需要做的事情编写集成测试用例准备 mock 场景
