缺陷报告MiniCode 项目详解6原项目中的10个缺陷已修复-CSDN博客之前的详解已全部更新为修复后的版本MiniCode 项目详解3Agent 循环骨架 (agent_loop.py)-CSDN博客MiniCode 项目详解4自适应控制系统上-CSDN博客MiniCode 项目详解5自适应控制系统下-CSDN博客修复总览#缺陷严重度修复方式核心改动文件1传感器数据是假的LLM 调用前后计时传入真实耗时agent_loop.py,cybernetic_orchestrator.py2SelfHealingEngine 4/8 策略是 placebo4 个执行器补充真实逻辑self_healing_engine.py3缺少 A/B 对比评测修复基线路径 新增集成测试agent_loop.py,tests/4解耦矩阵没被 PID 消费新增apply_to_pid()方法decoupling_controller.py,cybernetic_orchestrator.py5FeedforwardController 不调 PID setpoint意图→setpoint 映射 set_setpoints()feedforward_controller.py,feedback_controller.py,agent_loop.py6SystemState.oscillation_index 是死数据observe()消费外部振荡并加权融合feedback_controller.py7两个独立的振荡检测器统一信号链路 归一化context_cybernetics.py8缺少 conditional integration两个 PID 都加条件积分逻辑feedback_controller.py,context_cybernetics.py9预测建议只打日志不执行高紧急度时真正调用run_cycle()cybernetic_orchestrator.py10集成测试文件缺失7 个测试场景265 行tests/test_cybernetic_integration.py缺陷 1传感器数据是假的 → 真实计时问题response_time step * 2.0硬编码StateObserver 的 Kalman Filter 和 StabilityMonitor 基于假数据做决策。修复在agent_loop.py的_model_next()调用前后加time.time()计时将actual_response_time传给step_start()和step_end()。数据流变化修复前step * 2.0 → StateObserver / StabilityMonitor / DecouplingController 修复后 LLM 调用 │ t0 time.time() │ _model_next(...) │ actual_response_time time.time() - t0 │ ├──→ step_end(actual_response_time) → StabilityMonitor 用真实耗时 └──→ 下一轮 step_start(actual_response_time) → StateObserver/Kalman 用真实耗时注意step_start用的是上一轮LLM 调用的耗时因为 step_start 在本轮 LLM 调用之前执行首轮默认 0.0。缺陷 2SelfHealingEngine placebo → 全部真实执行问题_execute_reduce_concurrency、_execute_reduce_timeout、_execute_safe_mode、_execute_force_terminate四个方法只返回{success: True}字典没有修改任何运行时参数。修复策略修复内容_execute_reduce_concurrency设tool_scheduler._force_max_workers 1_execute_reduce_timeout检测 scheduler 暴露的超时字段_force_tool_timeout/timeout等减半_execute_safe_mode_force_max_workers 1 启用串行模式_execute_force_terminate遍历 scheduler 的cancel_all/interrupt等方法并调用与 FeedbackController 并发控制的互补FeedbackControllerSelfHealingEngine触发方式PID 渐进式故障阈值一次性降低幅度降到 2降到 1触发条件stability_output 0.3cpu 0.9 / error_rate 3.0类比巡航定速安全气囊缺陷 3缺少 A/B 对比 → 可评测问题enable_work_chainFalse时context_cybernetics等变量未初始化基线路径崩溃无法做 A/B 对比。修复agent_loop.py:560-563将 context_compactor、context_cybernetics、memory_mgr、cost_control 提前初始化为None新增tests/test_cybernetic_integration.py265 行7 个测试场景7 个测试场景测试验证链路A/B 对比Mock LLM enable_work_chainFalse/True → 步数/错误数对比上下文压力ContextCybernetics → SystemState → FeedbackController错误爆发StateObserver 接收连续错误 → SelfHealingEngine 触发解耦强耦合测量 →apply_to_pid()→ PID kp 被降低预测性压缩urgency0.7 →run_cycle()被调用 → 消息同步前馈 setpoint任务初始化 →FeedbackController.set_setpoints()振荡 → 外层控制交替压缩 → oscillation_index → ControlSignal缺陷 4解耦矩阵没闭环 → apply_to_pid()问题compute_decoupling_matrix()计算了皮尔逊相关系数矩阵但结果只用于日志展示没有反馈到任何 PID 参数。修复新增apply_to_pid()方法decoupling_controller.py:194-223def apply_to_pid(self, context_pid, feedback_controller): matrix self.compute_decoupling_matrix() for source, targets in matrix.items(): for target, coupling in targets.items(): if coupling 0.5: # 强耦合 pid 找到对应的 PID 实例 pid.kp * 1.0 - coupling * 0.5 # 降比例增益解耦矩阵元素含义5 对预设变量每对计算皮尔逊相关系数0无关1完全正相关键含义coupling0.8 表示token_usage_to_latencytoken 消耗 ↔ 延迟token 越多延迟越高context_pressure_to_error_rate上下文压力 ↔ 错误率越满越容易出错concurrency_to_stability并发数 ↔ 稳定性并发越高越不稳定model_level_to_cost模型等级 ↔ 成本—skill_complexity_to_timeout任务复杂度 ↔ 超时—为什么降 kp强耦合时两个 PID 会同时对同一个扰动做出反应——相当于打架导致过度调节。降低 kp 让它们反应温和一些。执行时机step_end()中FeedbackController.observe()之后调用。本轮控制信号不受影响kp 微调影响下一轮——渐进式解耦。缺陷 5FeedforwardController 不调 PID setpoint → 意图感知问题PID setpoint 对所有任务都一样stability0.85, perf0.75, eff0.60FeedforwardController 虽然根据意图设置了 token_budget、concurrency但从不修改 PID 目标值。修复PreemptiveConfig增加stability_setpoint、performance_setpoint、efficiency_setpoint三个字段8 种意图类型各有不同的 setpoint 映射FeedbackController新增set_setpoints()方法agent_loop.py:622-625初始化阶段调用意图→setpoint 映射意图stabilityperformanceefficiency逻辑CODE0.850.750.60默认DEBUG0.900.750.50需高稳定REFACTOR0.900.800.50风险最高SEARCH0.700.600.80低风险效率优先DOCUMENT0.700.600.80低风险数据流任务意图REFACTOR → FeedforwardController.preconfigure() → PreemptiveConfig { stability_setpoint: 0.90, ... } → FeedbackController.set_setpoints(stability0.90, ...) → PID 目标值随任务类型变化关键理解FeedforwardController 本身没有 PID——它只是一个查表逻辑告诉 FeedbackController 这次任务你的目标值应该是多少。前馈设定目标反馈根据实际情况追赶目标。缺陷 67振荡检测 → 双源融合统一修复修复前两个问题死数据SystemState.oscillation_index被写入但observe()从不读取——FeedbackController 只用自己内部的_compute_oscillation()两个独立检测器输出类型不同bool vs float语义不同压缩振荡 vs 误差振荡修复后统一链路CyberneticFeedbackLoop └── get_direction_changes() ← 新增方法 │ 统计 _compaction_history 最近 6 个 usage_after 的方向变化次数 │ ├──→ detect_oscillation() ← 兼容旧接口 (3 → True) │ └──→ get_stats()[direction_changes] └──→ to_system_state() └──→ oscillation_index min(1.0, N / 10.0) ← 归一化 │ └──→ FeedbackController.observe() └──→ signal.oscillation_index internal_osc * 0.6 external_osc * 0.4 ↑ 行为层误差振荡 ↑ 上下文层方向变化为什么是内/外和 60/40内部振荡_compute_oscillation()监测 FeedbackController 自身稳定性误差的方向变化——更直接反映控制质量权重 60%外部振荡state.oscillation_index来自 ContextCybernetics监测压缩后水位的方向变化——间接信号权重 40%_compaction_history的数据来源CyberneticFeedbackLoop.record()在每次run_cycle()末尾被调用记录本次压缩的usage_before和usage_after。_compaction_history是最近 N 次压缩的效果记录——方向变化次数就是从这里算出来的。缺陷 8缺少 conditional integration → 两层 anti-windupIntegral积分项是什么PID 公式输出 kp×error ki×integral kd×derivative。integral 是历史误差的累积和integral error * dt。作用是消除稳态误差长期存在但很小的偏差——P 项在 error 很小时输出也很小I 项只要还有 error 就持续累积。修复前只有 clamp anti-windup硬限制积分上限。当误差从正变负时系统从过热变过冷积分里还存着旧方向的累积需要慢慢降到 0 才能响应新方向——有延迟。修复后两个 PID 的compute()都加入了 conditional integrationif error * self._state.previous_error 0: # 误差穿越零点 self._state.integral 0.0 # 清零旧方向积分 self._state.integral error * dt # 从新方向重新累积两层 anti-windup 总结层机制作用外层上限内层上限1Conditional Integration误差穿越 0 清零积分——2Clamp硬限制积分范围10.02.0内层上限更严格2.0 vs 10.0——上下文变化快积分不能积累太多。缺陷 9预测只打日志 → 真正执行压缩修复前if action.recommended_action trigger_compaction: logger.info(Predictive: trigger_compaction urgency%.2f, action.urgency) # 什么都不做修复后if action.recommended_action trigger_compaction: compacted, result, _ self.context_cybernetics.run_cycle( messages, error_rate..., avg_latencyactual_response_time ) if result.effective: messages[:] compacted # 原地替换后续 LLM 调用使用压缩后的上下文设计意图PredictiveController 在step_startLLM 调用前执行压缩——这是前馈防护。不等 step_end 的 PID 反应过来。如果预测性压缩成功了step_end 时上下文压力大概率已降到阈值以下。注意当前只处理了trigger_compaction一种预测动作。其他动作enable_safe_mode、reduce_concurrency需要等本轮实际指标更适合在 step_end 由 FeedbackController 或 SelfHealingEngine 处理。缺陷 10集成测试缺失 → 7 个场景全覆盖修复前tests/test_cybernetic_integration.py不存在——只有单元测试和合成数据消融框架缺少跨模块端到端验证。修复后新增 265 行集成测试文件7 个测试场景使用 Mock LLM 真实控制器链路。模拟故障的核心技巧以错误爆发场景为例构造极端数据喂给 StateObserver连续 8 轮error_count1,2,3...8,success_rate0.2构造故障指标喂给 SelfHealingEnginecpu_usage0.95,error_rate4.5,oscillation_index0.75断言三件事故障被检测到confidence0、修复动作被触发RESOURCE_EXHAUSTION、运行时参数真改了_force_max_workers 1关键原则用 Mock 替代不可控的外部依赖LLM、文件系统让测试快速、确定、可重复。