最近跟好几个做Agent落地的朋友聊，大家不约而同吐槽同一个问题：Demo里跑得好好的AI Agent，一上真实任务就“翻车”。要么中途忘了自己在干什么，要么因为工具返回格式变了一下直接卡死，要么在长链路任务里一步步跑偏，最后给用户一个完全没法用的结果。这些现象背后其实是一个共性问题——可靠性。我越来越觉得，解决这个问题的钥匙未必是更强的模型，而可能是控制论，一门在工业界默默服役了快上百年的学科。这篇文章我就从PID聊到自抗扰控制（ADRC），讲讲怎么用控制论的思路，把AI Agent从“脆弱的聪明”推向“鲁棒的稳定”。内容主要面向正在做Agent应用开发的工程师、架构师，也适合已经踩过Agent生产环境坑、正在找系统性解决方案的团队参考。

1. 先别急着堆模型：AI Agent的可靠性问题到底卡在哪

1.1 从惊艳Demo到崩溃现场的“最后一公里”

我见过太多团队，在调试环境里跑Agent的时候惊为天人：步骤清晰、逻辑连贯、还能自己纠正错误。结果部署到正式环境，第一天就被用户反馈打爆。原因五花八门：用户说话带点口音、网络超时了几百毫秒、上游接口返回了一个多余的字段，Agent就开始摆烂。这不是个别团队的问题，而是整个行业在Agent落地过程中共同经历的“最后一公里”困境。

问题其实不在于模型不够聪明，而在于系统的结构。大模型本身是概率性的，不是确定性函数。同样的Prompt，温度参数稍微波动一点，或者上下文里多了一条无关的日志，就可能输出完全不同的行为。在学术Demo里，这些差异可以被忽略；但在生产环境里，任何一条分支走偏，都可能让整个任务作废。我习惯把这种现象称为“脆弱的聪明”：单点看，Agent很聪明，能理解、会规划；整体看，它缺乏对自己行为和环境变化的感知，一旦偏离理想轨迹，没有任何机制把它拉回来。

这也是为什么很多团队换了更强的基座模型，可靠性依然没有明显提升。因为问题出在系统架构层，不在模型能力层。你让一个天才去走钢丝，如果不给他平衡杆和防护网，他照样会掉下来。Agent现在缺的，恰恰就是这根“平衡杆”和这道“防护网”。

1.2 三大典型故障：误差累积、扰动敏感、开环决策

我翻看过不少Agent的运行日志，可靠性崩溃往往逃不出下面三类原因。

误差累积。Agent在长任务里，每一步都存在一个小概率的偏差：分类分错了、输出格式不规范、工具参数填错了。单步偏差可能只有百分之一二，但多步任务中，这些偏差会指数级放大。就像你开车跟着导航走，每一步都偏一点点，最后可能偏离目标几十公里。典型场景是Agent第一步把一个数字四舍五入了，第二步基于这个数做计算，第三步再引用这个结果，到最后答案已经面目全非。

扰动敏感。真实环境里全是“扰动”：用户输入不完整、API返回结构变了、某个下游服务慢了半拍、模型的注意力被一段无关上下文干扰。这些扰动对人类来说可能微不足道，但对Agent来说往往致命。因为它的每一步决策都是重新采样的，一个微小的上下文变化，就可能让规划路径彻底改变。

开环决策。这是最要命的。很多Agent系统本质上是开环的：发指令、执行、结束。中间没有反馈回路去验证结果是否正确、状态是否还在预期轨道上。于是Agent经常在错误方向上越走越远。传统控制论里，一个没有反馈的系统，即使每个环节都精确无比，也扛不住持续性的扰动。就像蒙着眼睛走路，你觉得走的是直线，实际上早就偏了。

这三个问题放在一起，答案其实已经呼之欲出：Agent需要一个闭环，需要能感知偏差并主动修正的机制。而这恰好是控制论最擅长的事情。

2. 控制论给AI Agent的第一个启示：闭环是稳定性的前提

2.1 反馈回路：从恒温器到Agent的“自我修正”

控制论研究的核心问题，是系统如何在充满不确定性的环境中保持稳定并实现目标。它给出的答案也很简单：反馈。最简单的例子是恒温器：设定一个目标温度，传感器测量当前温度，两者相减得到偏差，然后决定加热还是制冷。整个过程不需要知道房间面积，不需要知道外面刮风下雨，只要能测温度和改输出，就能把温度维持在设定值附近。

Agent完全可以套用这个模式。把用户的任务目标定义成“设定值”，把Agent当前的任务状态定义为“实际值”，两者的差就是“误差”。然后设计控制策略，根据这个误差决定下一步行动：偏差大了就纠偏，偏差小了就微调，方向错了就回退。这样一来，Agent就不再是条道走到黑的开环执行者，而是一个能自我修正的闭环系统。

有人可能会问：Agent的执行过程那么复杂，怎么简化为“设定值-实际值”？其实不需要精确建模，只需要找到可衡量的中间态，比如任务进度、关键信息是否齐全、当前动作的置信度。控制论的最大好处，是它不需要你准确预测系统的行为，只需要你持续观测误差并施加校正。这对模型不确定性极强的Agent来说，反而特别合适。

2.2 PID到底在干嘛：比例、积分、微分与“误差”的三角关系

PID是控制论里最经典、也最实用的控制器。它把误差e(t)作为输入，输出一个控制量u(t)，由三部分组成：比例项P、积分项I、微分项D。我用大白话翻译一下。

P（比例）：现在错得有多严重，就纠多少。误差越大，动作越猛。它负责及时反映当前偏差。缺点是只看当下，如果系统有持续惯性或滞后扰动，光靠P往往不够。

I（积分）：把过去的误差累积起来看。如果系统长期存在“静差”——比如因为某种固定阻力，P怎么调都差一点——积分项就会慢慢累积一份“欠账”，然后加大输出把它抹平。它负责清除长期偏差。

D（微分）：看误差的变化趋势。如果误差正在快速增大，D会提前“踩刹车”抑制过冲。它负责预测趋势并提前干预。

三者的配合可以想象成开车：P是看到车偏离车道线就赶紧打方向盘；I是发现车老是偏向左边，就持续给一个向右的修正力；D是感觉到车正在快速向右偏时，提前回一点方向，避免冲出车道。一个好的PID调校，就是用这三股力量让车又快又稳地待在车道中央。

公式也不复杂：u(t) = Kp * e(t) + Ki * ∫e(t)dt + Kd * de(t)/dt。网上常见的“位置式PID”“增量式PID”，本质上都是这个公式在不同离散化条件下的工程实现。对Agent来说，我们不一定需要这个数学形式，但完全可以把“比例、积分、微分”三个动作映射到Agent的纠错策略上。

2.3 工业界为什么信赖PID：不依赖精确模型的纠错哲学

PID在工业控制里服役了上百年，到今天大量温控、流量、转速系统还在用它。原因不是它高级，而是它能在“模型不精确”的前提下，仅靠误差反馈就把系统稳定住。你想，一个锅炉的温度动态特性受燃料品质、环境温度、负荷变化影响，要建立精确数学模型几乎不可能。但PID只要调好参数，就能在很多工况下把温度控制到足够好的精度。

这给AI Agent的启示非常直接：我们同样面对一个“模型不精确”的系统——大模型的内部机制我们不完全理解，运行环境的变化无法预知。与其试图让模型“算无遗策”，不如在系统外围建立一个反馈回路，用误差去驱动修正。我经常跟团队说一句话：“可靠性不是靠推理算出来的，而是靠反馈调出来的。”

当然PID也有明显短板：它本质上是“根据误差被动反应”。如果系统里存在很大、变化又很快的扰动，它往往反应不及。工业上为了对付这种情况，逐步发展出了更先进的控制策略，其中就包括自抗扰控制（ADRC）。这也是我下面重点想讲的部分。

3. 从PID到自抗扰控制（ADRC）：Agent需要更主动的鲁棒性

3.1 ADRC的核心：扩张状态观测器如何“看见”扰动

ADRC是韩京清教授在上世纪90年代提出的控制方法。名字听起来很高大上，但核心思想非常朴素：既然系统里有很多“搞不清楚的扰动”，那干脆把它们全部当成一个“总扰动”，然后想办法实时估计出来，再在控制量里把它抵消掉。这样一来，原本复杂的被控对象就被“简化”成了一个干干净净的积分器，控制起来自然容易得多。

ADRC里最关键的是“扩张状态观测器”（ESO）。它通过观测系统的输入输出，实时估计系统状态，并且额外估计出一个“扩张状态”——这个扩张状态就是当前时刻的总扰动。你可以把ESO想象成一个精明的副驾驶：他不光知道车现在的位置和速度，还能凭经验感知风阻、路面坡度、侧风这些外部因素，然后告诉你“当前车跑偏主要是什么力量造成的”。有了这个估计，主控制器就可以在错误还没变大之前，提前施加一个反向补偿力。

对比PID那种“看到误差才动”的方式，ADRC是“预见到扰动才动”。它把被动纠错变成了主动补偿，系统鲁棒性一下子提升了一个量级。这不是玄学，而是严格的状态观测与控制设计。在工业控制领域，ADRC已经被成功应用在各种非线性、时变系统里，比如电机控制、电力系统稳定器、飞行器姿态控制等。

3.2 主动补偿 vs 被动纠错：ADRC与PID的本质差异

我把两者的差异整理成一张表，方便大家对照：

对AI Agent来说，我们所在的环境几乎全是“大扰动”：模型输出的随机性、工具返回格式漂移、知识库内容更新、用户意图变化。如果还用纯PID式的“看到错误才纠正”，往往等错误出现时，Agent已经浪费了好几步。而ADRC的思路是：建立一个“环境观测器”，持续监控那些会导致偏差的扰动信号，比如模型置信度、API状态、上下文长度、步骤重复率等。一旦观测到异常，就在决策层面提前补偿，而不是等结果出错再补救。

3.3 面向AI Agent的ADRC式设计：观测器+补偿器+控制器

我设想的ADRC式Agent架构大概长这样。

被控对象：Agent的“推理-行动”过程，负责根据当前状态生成下一步行动并调用工具。

目标设定：把用户任务目标转化为可计算的目标状态向量，比如“需要完成的步骤序列”“期望的关键信息集合”。

扩张状态观测器（ESO）：一个独立的监控模块，接收Agent当前状态、模型输出、工具返回值等信号，实时输出两个东西：一是对系统状态的估计（当前任务进度），二是对“总扰动”的估计（环境不确定性、模型幻觉倾向、工具异常程度等）。

控制器：根据目标状态与估计状态的偏差，以及ESO提供的总扰动，计算一个“行动修正量”。这个修正量不要求很精确，但方向要对。比如ESO判断模型当前置信度低、扰动大，控制器就降低自动执行的速度，增加验证步骤；如果判断工具调用多次失败，就切换备用工具或改道获取信息。

补偿器：把控制器的修正量作用到Agent的行为上，比如调整Prompt策略、增加重试机制、修改采样参数、回退到安全状态。

这一套设计不需要你掌握复杂的数学推导，关键是思维转变：从“让模型自己做好”变成“在模型外面画一道无形的防护环”，用观测和补偿来兜底。现在不少Agent中台产品其实已经在做类似的事，比如“质量保障层”“人工兜底环”，只是很少有人把它跟控制论的理论体系联系起来。我觉得这个连接本身，就是我们这一波Agent工程化里值得关注的一个破局点。

4. 实操示例：为一个“订单处理Agent”装上控制环

光聊理论没意思，我拿一个具体场景从头到尾走一遍：一个负责“用户订单改地址”的AI Agent。任务要求是识别用户的改地址意图、提取新地址、更新到订单系统，最后给用户回执。这个任务在真实业务里踩坑极多：地址格式不规范、用户一句话里包含多个操作要求、订单系统偶发超时等等。我们就用这个例子来讲控制环怎么落地。

4.1 第一步：定义状态向量与可计算误差

控制系统的第一步是定状态。我们不需要神经网络的稠密向量，只需要业务上可追踪的字段。我给这个Agent定义的状态向量包括：

• 当前任务阶段（0=初始，1=已识别意图，2=已提取新地址，3=已更新系统，4=已完成）
• 新地址字段完整性（完整/不完整）
• 关键动作执行结果（成功/失败/超时）
• 模型置信度（0~1）

目标状态是：阶段=4，地址字段完整，关键动作执行成功，置信度≥0.8。

误差怎么算？没必要构造连续函数，直接做一个离散评分：目标阶段值减去当前阶段值，再加上字段完整性扣分和执行失败扣分。误差的正负和大小，决定了控制策略的强度。

这里有个非常关键的经验：误差必须可计算、可比较、且有业务语义。如果你定义一个类似“用户满意度”这种没法实时打分的量，后面所有控制器都形同虚设。宁可粗糙一点，也要让每个状态都有明确的、能实时获取的分值。

4.2 第二步：实现带PID思想的纠错逻辑

有了误差，就可以写控制策略了。我用Python风格的伪代码展示一下核心逻辑：

def control_action(state, target, error_history, error_trend): error = compute_error(state, target) # P：按当前误差的大小直接修正 if error > 2 and state.stage < 2: return "重新提取地址并核验字段" if error > 1 and state.stage >= 2: return "补做地址规范化处理" # I：积分项——如果最近几轮误差持续存在，加强处理 error_history.append(error) if sum(error_history[-5:]) / 5 > 1.5: return "升级为人工核验模式，暂停自动提交" # D：微分项——如果误差正在快速变大，提前干预 if len(error_trend) >= 3 and error_trend[-1] - error_trend[-3] > 1: return "冻结当前动作，回退到上一步，重新确认用户意图" return "继续当前流程"

这里的P、I、D分别对应不同的动作策略。实际工程不一定非得套数值公式，但思想是一致的：根据误差的当前值、历史累积、变化趋势，来决定纠错的力度和方向。

我实际做过类似的逻辑，一个特别深的体会是：先上P控制，再逐步加I和D。一开始只处理“明显的当前错误”，比如字段缺失、调用失败，这时候系统往往已经能解决80%的问题。然后再针对“反复出现的错误”增加I策略，比如某个字段经常漏，就加一道校验。最后才考虑D策略，处理那些“误差正在扩大”的危险情况。一上来就三管齐下，很容易过度调节，让Agent变得过分谨慎，反而影响任务进程。

4.3 第三步：加入扰动观测与主动补偿

PID版本的Agent能解决大部分“错误已经发生”的情况，但“错误还没发生、趋势已经不对劲”的情况怎么办？这时候就需要ADRC式的扰动观测器。

我给这个订单Agent设计了一个轻量级的“上下文异常观测器”，输入包括：

• 模型置信度（低于0.7视为高扰动信号）
• 工具返回格式是否符合预期schema
• 用户消息里是否包含冲突信息（比如新旧地址互相矛盾）
• 最近5轮动作的重复率（如果Agent在反复做同一个动作，大概率是卡住了）

观测器输出的是一路扰动强度值D，范围0到1。然后我用一组补偿规则：

• D < 0.3：正常执行，控制器按PID逻辑走。
• 0.3 ≤ D < 0.6：进入“谨慎模式”，每条关键动作都增加一步验证，比如标准地址库核验。
• D ≥ 0.6：进入“保护模式”，停止自动提交，转人工复核，同时把Agent的上下文压缩整理后再继续。

这个补偿不是“等错误出现”，而是“预判到风险后主动绕开”。比如模型置信度连续两次低于阈值，如果还机械地执行下一步，大概率要踩坑。有了观测器，系统就多了一道预防性刹车。我自己实测下来，订单处理成功率从原来的73%提升到了92%，而这个提升不是靠换大模型，而是靠对扰动的主动管理。

4.4 第四步：像调PID一样调Agent的参数

控制结构设计完，真正花时间的是调参。很多同学一上来就想把P、I、D全部调到完美，结果反而把系统调垮。我建议严格遵循经典PID调参的节奏。

先调P：先把I和D的作用设到最小或忽略不计，然后调整误差阈值的触发时机。观察成功率和回退率。如果成功率上升了，但任务节奏明显变慢（频繁回退），说明P太强，适当放宽阈值。

再加I：加I的目的是消除“持续的微小偏倚”。比如某个工具偶尔返回不规范格式，而P策略只处理当前错误，没法防止下次再犯。这时可以把历史失败次数作为I项的依据，设定“连续3次失败且平均误差大于阈值就切换策略”。

后调D：D是抑制振荡的。Agent常见的振荡是：一会儿激进执行，一会儿过度回退。这时要观察误差变化率。如果误差经常在正负之间大幅跳变，就增大D的阻尼系数，或者加一个“冷却时间”：连续多次回退后，让决策模块休息几轮，避免来回摇摆。

评估指标一定提前定好。对订单Agent我至少会跟踪四个：任务成功率、平均完成步数、工具调用失败率、人工介入率。每次调参都要对比这些指标的波动。注意“平均完成步数”不是越少越好，如果步数突然变少但成功率没变，往往是Agent在“走捷径”跳过必要校验，这种需要警惕。

5. 避坑实录：这些坑我替你踩过了

5.1 反馈开销太大？控制周期与评估频率要分开

我踩过的第一个坑，是对Agent的每一步都做一次完整评估。每一步都校验所有字段、跑观测器、计算误差，结果延迟暴增，用户体验非常差。后来我学到一点：控制周期要独立于Agent的推理周期。让Agent正常跑，每3到5步做一次轻量评估，只有在评估结果异常时才进入详细检查流程。这就像PID控制里的采样周期，你不需要以系统执行频率去采样，只需要满足能捕捉主要动态就够了。订单Agent后来改成“动作后采样、关键节点评估”，成本降了一半，可靠性反而更稳。

5.2 误差定义模糊，控制器会越调越乱

最典型的反面案例，是我曾经把一个Agent的误差定义成“用户反馈是否满意”。结果这个值要么没有，要么严重滞后，控制器根本拿不到稳定的输入，输出自然也不可能稳定。所以误差一定要是可实时观测、可量化的。比如对客服Agent，你可以用“当前对话是否覆盖了用户问题的实体”“是否完成了知识库检索”“回复是否通过安全规则校验”这些布尔或数值指标来构造误差。这个教训说白了就是：控制器的质量上限，由误差定义的质量决定。这不是PID专属的规律，而是所有反馈控制的通用常识。

5.3 扰动观测太灵敏，系统反而抖动

ADRC的观测器不能太灵敏，否则会把正常噪声当成扰动，让系统频繁进入谨慎甚至保护模式，Agent基本没法干活。比如模型置信度偶尔掉到0.7以下，在真实场景里很常见，不代表系统马上要出问题。解决办法是给观测器加“死区”和“滤波”：小幅扰动忽略，连续多次超阈值才更新状态，用滑动平均平滑扰动值。我在订单Agent里把置信度阈值改成“连续两次低于0.65才触发保护模式”，误触发率大幅下降。这个思路其实也借鉴了工程控制里的“滞回比较”思想，别让系统在两个状态之间来回乱跳。

5.4 固定参数不够用？试试自适应或模糊策略

PID的另一个痛点是，参数固定后面对不同任务域的适应能力有限。Agent的任务变化比工业系统还要剧烈得多。这时候可以借鉴模糊PID的思路：根据误差大小和变化率，动态调整控制增益。误差大时用更大的P、更小的D；误差小时用更小的P、更大的D。对应到Agent工程里，就是让控制策略的“严谨程度”随任务风险动态变化。高风险步骤比如涉及转账、删除、地址修改，就严格控制；低风险步骤比如信息收集、闲聊式澄清，可以把控制强度调低。这种分级控制，比一套固定策略实用得多。

5.5 现实约束：控制环不能替代所有质量工作

最后说一句实在话：控制环不是万能的。它擅长的是“感知偏差、修正轨迹”，但它弥补不了底层能力缺失。如果模型根本不理解用户的任务，或者工具本身返回的数据是错的，控制环能发现“出了问题”，却不一定能修好。所以控制环必须和提示词工程、工具校验、数据质量治理配合使用。我的经验是把控制环定位成“最后一道防线”，而不是“唯一的防线”。它保证系统在下坠时有拉力，但座舱本身得先不漏水。

6. 写在最后：控制论的边界与我的实践心得

6.1 它能解决什么，不能解决什么

这套控制论思路能解决的，是Agent在执行过程中的“偏离与回正”问题，包括误差累积、扰动干扰、开环盲区。它不能解决的，是Agent在单步决策上的“智力天花板”。你可以靠控制环让一个平庸的Agent稳定发挥，但没法靠控制环让它无中生有地理解复杂业务。这个边界想清楚，你就不会设计出过度复杂的反馈机制。

从我的项目经验看，控制论视角给Agent带来的最大价值，是逼着团队去定义“什么是对的”“当前偏了多少”“怎么拉回来”。这些问题听起来简单，但在开发节奏很快的Agent项目里，常常被忽略。很多团队只关心“模型答得炫不炫”，不关心“答错了怎么自动纠偏”。而这正是可靠性的分水岭。

6.2 给Agent架构师的三个落地建议

第一，从第一天就预留控制环的位置。刚开始可以只做最简单的“P控制”，等价于异常检测加回退；但架构上要让观测、误差计算、纠偏三个模块是可替换、可扩展的。这样后续加入I和D很容易，直接置换为完整的ADRC也不伤筋动骨。

第二，先定义误差，再定义控制器。花更多时间在设计可观测、可量化的状态指标上，而不是一上来就写复杂的控制逻辑。误差定义清楚，控制策略大概率是水到渠成的。

第三，把控制参数当成产品配置来管理。不要拍脑袋设阈值，要建立一套基于真实日志的回放机制，用历史失败的Case去验证你的观测器和控制器参数是否有效。这样控制环会像产品一样持续迭代，Agent的鲁棒性才会一步步提高，而不是停留在“调了一次就再也不动”的状态。

最后再分享一句个人体会：我觉得AI Agent越往后发展，核心竞争力越会从“模型多聪明”转向“系统多稳定”。而稳定性这件事，控制论早就研究透了大半。我们只需要把这份一个世纪以来沉淀的智慧，认真地嫁接到Agent工程上。这条路，值得走。