你的AI Agent为什么总在“来回改“一次真实实验给出的答案 ——融合控制工程PID的Harness实践文章目录你的AI Agent为什么总在“来回改“一次真实实验给出的答案 ——融合控制工程PID的Harness实践从真实实验说起结果一览1. 你的Agent迭代系统其实就是一个反馈控制系统2. 一个实证发现 两个理论预测实证发现无反馈重试会振荡退步有数据支撑已验证发现2激进反馈/强模式更容易退步 ✅ 实验B1数据已验证发现3间隔反馈省50%评估成本 ✅ 实验B2数据3. PID控制精确反馈是核心PID提供系统化框架真实实验中的PID计算PID控制信号如何映射到PromptT3中PID增强模式的实际反馈内容4. Lyapunov监控什么时候该停下来5. 实战Quick-Start什么时候该用PID增强模式基于真实实验的选择指南判断你的任务是否需要PID增强模式完整PID增强模式实现6. 实验局限性诚实声明常见坑坑1: 无脑重试——再跑一次说不定就好了坑2: 反馈不精确——请改进代码坑3: 过度工程——简单任务上硬套PID总结精确反馈是核心PID提供系统化框架参考你是不是遇到过这些情况让Agent迭代优化代码改了4轮反而中间比第2轮更差无反馈重试时模型随机发挥引入新Bug分数断崖下跌想加个连续N轮没提升就停的规则但不知道阈值怎么设如果你点头了这篇文章就是写给你的。这不是假设是我们刚刚跑出来的真实数据LRU Cache任务10个测试用例——简单重试的分数轨迹 Round 1: 7/10 Round 2: 8/10 ← 有改善 Round 3: 4/10 ← 断崖退步popitem方向改反了 Round 4: 10/10 ← 终于蒙对了第3轮从8/10退步到4/10。模型没有收到任何反馈独立重新生成了代码结果引入了更多Bug。这种振荡退步不是概率事件——它是无反馈重试系统的结构性缺陷。而同样的任务使用PID增强模式精确反馈控制信号轨迹是这样的Round 1: 7/10 Round 2: 10/10 ← 一步到位精确反馈告诉模型T3/T7/T10失败是因为get()未更新访问顺序同时验证put()的recency更新——模型一次性修复了所有关联Bug。本文基于我们2026年5月的真实对比实验分享一套经过初步验证的方法论用精确反馈PID控制让迭代收敛更快同时诚实说明它的适用边界和局限。从真实实验说起我们设计了3个编程任务的对比实验测试三种迭代策略策略方法简单重试每轮独立重新生成不提供任何上轮信息Self-Refine给上轮代码“请改进”不给具体失败信息PID增强模式精确失败用例root cause分析控制信号调节反馈强度实验环境Generator和Evaluator均为Claude测试用例为确定性Python单元测试pass/failPID参数 Kp0.6, Ki0.2, Kd0.15。结果一览任务难度测试数简单重试Self-RefinePID增强模式T1: 合并有序链表简单51轮通过1轮通过1轮通过T2: 螺旋矩阵中等102轮通过2轮通过2轮通过T3: LRU缓存困难104轮(振荡)3轮2轮关键发现简单任务T1、T2三种策略完全无差异。只有在复杂多Bug任务T3上PID增强模式的优势才显现出来。1. 你的Agent迭代系统其实就是一个反馈控制系统把你的Generator-Evaluator架构画成框图和经典控制系统一一对应控制系统概念Agent系统对应参考输入 r(t)任务目标/评估标准“通过全部10个测试用例”控制器 C(s)Evaluator的反馈策略如何组织critique被控对象 G(s)GeneratorLLM本身输出 y(t)生成的代码误差 e(t)(目标通过率 - 当前通过率) / 目标通过率反馈通道 H(s)测试用例执行结果关键洞察你的系统是一个离散时间闭环反馈系统。每一轮迭代就是一个采样周期。控制论的工具——增益调节、稳定性分析——可以直接应用。传统做法简单重试相当于没有反馈通道——每轮独立生成系统是开环的。Self-Refine有反馈但不精确——相当于传感器精度不够。PID增强模式提供精确反馈增益控制——这才是完整的闭环控制系统。2. 一个实证发现 两个理论预测实证发现无反馈重试会振荡退步有数据支撑在T3LRU缓存实验中简单重试策略的轨迹为7→8→4→10。第3轮从8/10暴跌到4/10原因是Round 2: 使用OrderedDict, 修好了get的move_to_end, 但put更新时遗漏 → 8/10 Round 3: 重新独立生成, 用了dict时间戳方案, popitem(lastTrue)方向错误 → 4/10没有反馈意味着每轮都是从零开始赌运气。模型可能换一个实现方案而新方案引入的Bug比旧方案更多。这不是模型不够强的问题是系统设计的问题。对比之下Self-Refine保留了上轮代码作为参考轨迹7→8→10单调递增无振荡PID增强模式给出精确失败信息预防性提示轨迹7→10一步到位已验证发现2激进反馈/强模式更容易退步 ✅ 实验B1数据实验B1在LRU缓存任务上对比了两种模式普通模式精确修改指令40→80→100→100→100 单调收敛0次退步 激进模式要求彻底重写40→50→90→100→90 出现退步R5从100跌到90激进模式要求彻底重写所有相关代码结果模型放弃了已经正确的实现引入新Bug。这就像方向盘太灵敏——轻轻一动就打满舵车就蛇形走位。实践建议用更强模型或更激进的prompt时必须降低反馈增益用更温和的修改指令。已验证发现3间隔反馈省50%评估成本 ✅ 实验B2数据实验B2在TTLCache任务上对比了每轮反馈(N1)和隔轮反馈(N2)N1每轮反馈8次评估第3轮收敛到100% N2隔轮反馈4次评估第3轮收敛到100%同样的收敛速度但N2只用了一半的评估调用。Generator在没有新反馈的轮次继续消化上一轮的修改建议效果不打折。实践建议当评估成本高人工评审或昂贵API调用时间隔反馈是有效的成本优化策略。3. PID控制精确反馈是核心PID提供系统化框架我们的实验表明PID增强模式的真正优势来自两个层面精确反馈告诉模型具体哪些测试失败、为什么失败、关联Bug是什么系统化框架PID控制信号决定反馈强度级别避免每次都全力重写真实实验中的PID计算T3第1轮结束后的PID计算# 实际实验参数target1.0# 目标100%通过率score0.7# 当前70%通过率 (7/10)etarget-score# e 0.30integral_e0.30# 首轮积分等于当前误差delta_e0.30# 首轮变化量等于当前误差# PID计算Kp,Ki,Kd0.6,0.2,0.15uKp*eKi*integral_eKd*delta_e u0.6*0.300.2*0.300.15*0.30u0.180.060.045u0.285# light intensity轻度修改u0.285 意味着什么系统判断只需要轻度修改而非重写。这个信号决定了反馈的语气和要求强度。PID控制信号如何映射到Promptdefphi_map_to_prompt(u,failed_tests,diagnosis,original_output): 将控制信号u映射为不同强度的反馈prompt u 0.3: 轻度修改——保留主体修复具体Bug u 0.3~0.6: 中度修改——重构问题部分 u 0.6: 重度修改——考虑换方案 ifu0.3:# light — 实验中T3的情况returnf上一版本整体框架正确只需修复具体Bug 失败用例{failed_tests}根因分析{diagnosis}修复建议针对性修改同时检查是否有关联的相似Bug。 保留原有架构仅修改有问题的方法。elifu0.6:returnf上一版本有结构性问题需要修改 失败用例{failed_tests}根因分析{diagnosis}请重构问题部分但保留正确的逻辑。else:returnf上一版本问题较多建议换实现方案 失败用例{failed_tests}根因分析{diagnosis}考虑使用不同的数据结构或算法。T3中PID增强模式的实际反馈内容这是实验中第1轮后发给Generator的精确反馈u 0.285 (light intensity) Failed: T3 (got 2, expected -1), T7 (got 3, expected -1), T10 (got 1, expected -1) Diagnosis: get() does not update access order. - T3: After get(1), key 1 should be most recent, key 2 should be evicted - T7: After get(1),get(2), key 3 is LRU and should be evicted - T10: After get(2), key 1 is LRU and should be evicted Action: Add move_to_end in get(). Also verify put() for existing keys updates recency.注意最后一句Also verify put() for existing keys updates recency——这是PID增强模式的预防性提示。它基于root cause分析推断出如果get()遗漏了move_to_endput()更新现有key时很可能也遗漏了。正是这个预防性提示让模型一次性修复了两个关联Bug——而Self-Refine没有这个提示花了两轮才分别修复它们。4. Lyapunov监控什么时候该停下来迭代系统还有一个经典问题什么时候该停用T3简单重试的数据来说明问题——轨迹 7→8→4→10deflyapunov_monitor(scores,target10): V(i) 0.5 * (target - score)^2 —— 不满意程度 ΔV V(i) - V(i-1) ΔV 0: 系统在改善 ΔV 0: 系统在恶化 V[0.5*(target-s)**2forsinscores]foriinrange(1,len(V)):delta_VV[i]-V[i-1]status改善ifdelta_V0else恶化⚠️print(fRound{i1}:{scores[i]}/10, ΔV{delta_V:.1f}({status}))# 简单重试轨迹lyapunov_monitor([7,8,4,10])# Round 2: 8/10, ΔV-2.5 (改善)# Round 3: 4/10, ΔV16.0 (恶化⚠️) ← 严重退步# Round 4: 10/10, ΔV-18.0 (改善)# Self-Refine轨迹lyapunov_monitor([7,8,10])# Round 2: 8/10, ΔV-2.5 (改善)# Round 3: 10/10, ΔV-2.0 (改善) ← 单调收敛如果在Round 3看到ΔV16.0这样的剧烈恶化Lyapunov监控会触发WARNING。配合PID控制此时应该降低控制增益避免过度修改或切换为带反馈的模式别再盲目重试了5. 实战Quick-Start什么时候该用PID增强模式基于真实实验的选择指南场景推荐方案理由实验支撑简单任务首轮70%通过直接生成或Self-RefineT1/T2数据三策略无差异PID的overhead不值得复杂多Bug任务PID增强模式T3数据2轮 vs 3轮 vs 4轮含振荡需要避免退步PID增强模式或Self-RefineT3数据带反馈的策略不会振荡退步多Agent系统待验证未测试已从skill功能中移除不知道何时停Lyapunov监控比3轮没提升就停更精确能检测退步如果你希望把这套方法直接接到 Codex 的工作流里我把实验里的判断逻辑整理成了一个可复用的 Skillharness-design。它做的不是每个任务都强行上PID而是先用 Generator-Evaluator 跑出首轮结果简单任务走普通迭代复杂多Bug、出现退步或需要控制反馈强度时再自动升级到PID增强模式。这也正是本文反复强调的工程边界先评估再决定反馈力度。判断你的任务是否需要PID增强模式defshould_use_harness_pid_mode(first_round_pass_rate,num_distinct_bugs,has_correlated_bugs): 基于实验观察的决策函数 iffirst_round_pass_rate0.7:return不需要 — 简单重试或Self-Refine就够ifnum_distinct_bugs1:returnSelf-Refine够用 — 单Bug类型不需要root cause分析ifhas_correlated_bugs:return推荐PID增强模式 — 精确反馈预防性提示能一次修复关联BugreturnSelf-Refine或PID增强模式均可完整PID增强模式实现classPIDHarness:def__init__(self,generator,evaluator,target1.0,Kp0.6,Ki0.2,Kd0.15,max_rounds8):self.generatorgenerator self.evaluatorevaluator self.targettarget self.Kp,self.Ki,self.KdKp,Ki,Kd self.max_roundsmax_rounds self.scores[]self.integral_e0.0defrun(self,task):outputself.generator(task)# 首轮无反馈forround_iinrange(self.max_rounds):score,failed_tests,diagnosisself.evaluator(output)self.scores.append(score)ifscoreself.target:print(f[Round{round_i1}] 达标:{score:.0%})break# PID计算eself.target-score self.integral_ee delta_eeiflen(self.scores)2else((self.target-self.scores[-1])-(self.target-self.scores[-2]))umax(0.0,min(1.0,self.Kp*eself.Ki*self.integral_eself.Kd*delta_e))# Lyapunov监控iflen(self.scores)3:V[0.5*(self.target-s)**2forsinself.scores]ifV[-1]V[-2]andV[-2]V[-3]:print(f[Round{round_i1}] Lyapunov STOP: 连续恶化)break# Phi映射 生成promptphi_map_to_prompt(u,failed_tests,diagnosis,output)outputself.generator(task,feedbackprompt)returnoutput,self.scores6. 实验局限性诚实声明在你决定在生产环境中使用PID增强模式之前你需要知道这些局限局限说明样本量极小仅3个编程任务每个只跑1次。无统计显著性。仅1个任务显示差异T1/T2完全无差异只有T3复杂多Bug看到了优势Generator和Evaluator是同一模型Claude既生成又评估虽然评估是确定性测试用例仅测试了编程任务写作、设计等任务未测试多Agent场景未验证未测试已从harness-design skill功能中移除PID参数未调优使用推荐默认参数未验证是否最优k_G估计流程未实测Skill中描述的灵敏度估计方法未在实验中使用我们能确信的结论精确反馈具体失败用例root cause比模糊反馈“请改进”有效无反馈重试在复杂任务上会振荡退步PID提供了一个系统化的框架来组织反馈但它的数学公式本身不是魔法我们不确信的PID是否在所有任务类型上都优于精心设计的Self-Refine最优PID参数是多少可能因任务而异强模型是否真的比弱模型更不稳定常见坑坑1: 无脑重试——“再跑一次说不定就好了”症状代码任务通过了8/10测试不给任何反馈就再跑一轮结果变成4/10。真实数据T3简单重试策略Round 3从8/10退步到4/10。原因是模型换了实现方案从OrderedDict换成dict时间戳新方案的popitem方向搞反了。解法至少给Self-Refine级别的反馈保留上轮代码告知通过率。如果任务有多个关联Bug升级到PID增强模式的精确反馈。坑2: 反馈不精确——“请改进代码”症状每轮只修复一个Bug需要3轮才能全部修完。真实数据T3 Self-Refine策略Round 2修好了get()的move_to_end但遗漏了put()的相同问题。因为反馈只说8/10请改进没有指出put更新现有key时也需要move_to_end。解法在反馈中附带root cause分析和预防性提示。PID增强模式的Also verify put()就是这种预防性提示的例子。坑3: 过度工程——简单任务上硬套PID症状花了很多时间配置PID参数、设计反馈模板最后发现直接跑就能一次通过。真实数据T1合并有序链表和T2螺旋矩阵三种策略表现完全相同。LLM首轮就能做对或一轮修复的任务不需要控制论加持。解法先跑一轮看首轮通过率。70%通过就别折腾了。总结精确反馈是核心PID提供系统化框架基于真实实验我们能说三件事精确反馈显著优于无反馈或模糊反馈——在复杂多Bug任务上精确的失败信息root cause分析预防性提示让模型一次修复关联Bug2轮 vs 4轮。PID控制信号提供了结构化的反馈强度决策框架——u0.285告诉你轻度修改就够避免了每次都请大幅重写的冲动。但诚实说目前实验中PID数学公式的贡献可能不如精确反馈内容本身大。简单任务不需要这些——先评估再决定。首轮通过率70%的任务Self-Refine甚至直接重试就够了。下次你的Agent系统出现振荡时不要急着换模型、加重试。先问自己你给了模型精确的反馈吗它知道具体哪里错了、为什么错、还有哪些关联的坑吗这是工程思维也是实验结论。参考Tsien, H.S. (1954).Engineering Cybernetics. McGraw-Hill.Madaan, A. et al. (2023). Self-Refine: Iterative Refinement with Self-Feedback.NeurIPS.Shinn, N. et al. (2023). Reflexion: Language Agents with Verbal Reinforcement Learning.NeurIPS.An, S. et al. (2018). PID Controller Approach for Stochastic Optimization of Deep Networks.CVPR.Zheng, L. et al. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena.NeurIPS.AICE: AI Control Engineering — 将经典控制理论应用于LLM迭代优化的系统框架.