智能体开发做到第三个月的时候，我遇到了一个特别典型的问题：一个用来做数据清洗的Agent，在测试集上跑得漂漂亮亮，任务完成率能到92%，但只要上游数据格式稍微抖一下——比如某个字段从字符串变成了数字，或者多了一个空行——它就开始胡言乱语，要么陷入死循环反复调用同一个工具，要么直接输出一段看起来像模像样但完全错误的结论。更让人头疼的是，它不会报错，不会崩溃，就是安安静静地把事情搞砸。这种“脆弱的聪明”让我开始重新思考一个问题：我们是不是把太多精力花在了让Agent“更聪明”上，而忽略了让它“更稳定”？
这个困惑在我脑子里盘旋了很久，直到有一次翻控制论的老书，看到PID和自抗扰控制（ADRC）的章节，突然有种被击中的感觉。控制论研究的是什么？是在不确定环境中让系统稳定输出。这不就是智能体可靠性问题的本质吗？一个AI Agent本质上就是一个在不确定环境中执行任务的控制器——它感知环境状态，根据目标计算偏差，输出动作，然后根据反馈调整。这套逻辑和工业控制里的闭环反馈惊人地相似。区别在于，工业控制领域已经积累了一百年的稳定性理论，而我们做Agent的，还在靠“多试几次”“加个重试机制”这种土办法硬扛。
所以这篇文章想聊的，就是怎么把控制论里那些被验证了几十年的稳定性设计思路，迁移到AI Agent的架构里。我会从PID的局限性讲起，解释为什么传统反馈控制在Agent场景下会失效，然后重点拆解ADRC的核心思想——扩张状态观测器——怎么用来解决Agent的“未知扰动”问题。中间会穿插具体的代码实现思路、参数整定方法，以及我在实际项目中踩过的坑。如果你正在做智能体开发，或者对AI Agent的工程化落地感兴趣，这篇文章应该能给你一些不一样的视角。
1. 为什么PID那套反馈逻辑在Agent身上会失灵
1.1 从恒温箱到Agent：反馈控制的迁移困境
PID控制器的逻辑非常直观：测量当前值和目标值的偏差，然后按比例（P）、积分（I）、微分（D）三项加权求和，输出控制量。在恒温箱里，这套逻辑跑了几十年，稳定可靠。我第一次尝试把PID思路套到Agent上时，想得很简单：把任务完成度当作被控量，把Agent的决策参数当作控制量，偏差大了就加大调整力度，偏差小了就微调。听起来没毛病对吧？
但实际跑起来完全不是那么回事。恒温箱的模型是确定的——加热功率和温度变化之间的关系可以用微分方程精确描述。而Agent面对的环境，模型根本写不出来。用户输入的自然语言可能有一万种表达方式，工具返回的结果格式可能随时变化，外部API可能超时也可能返回脏数据。这些扰动在PID框架里被当作“可以被反馈回路吸收的噪声”，但实际上它们的量级和频率远远超出了PID的调节能力。
更麻烦的是，PID的积分项在Agent场景下会积累出灾难性的后果。积分项的作用是消除稳态误差，但如果Agent连续几次决策都偏了，积分项会越积越大，导致后续的调整动作过猛。在控制领域这叫“积分饱和”，工业上有很多成熟的抗饱和方案。但在Agent里，这个“过猛”可能表现为：Agent突然放弃当前策略，切换到另一个完全不相干的工具链，或者开始输出极端保守的答案。你没法像调恒温箱那样，给Agent装一个抗饱和阀门。
1.2 时滞问题：Agent决策的“滞后反馈”陷阱
PID还有一个隐含假设：反馈是及时的。恒温箱的温度传感器几乎实时反映当前温度，控制器能在毫秒级做出响应。但Agent的反馈链路长得离谱。一个典型的Agent任务流程是：接收输入→理解意图→规划步骤→调用工具→等待返回→解析结果→判断是否完成→输出。这个链条里，每一步都有延迟，而且延迟还不固定。
我实测过一个客服场景的Agent，从用户发消息到Agent给出最终回复，中间要经过意图识别模型、知识库检索、话术生成模型三个环节，端到端延迟在2到8秒之间波动。这意味着当Agent根据“用户不满意”这个反馈信号调整策略时，用户可能已经又发了两条消息，情绪状态完全变了。PID的微分项对时滞特别敏感——它根据偏差的变化率来预测趋势，但时滞会让这个预测完全失真。微分项越大，系统震荡越厉害。在Agent里，这表现为Agent在两种策略之间反复横跳，每次跳转都基于过时的反馈。
1.3 多变量耦合：当Agent同时控制多个“旋钮”
工业PID通常控制单变量，或者通过解耦矩阵处理多变量。但Agent天然就是多变量系统。一个销售智能体在对话时，同时要控制：信息收集的进度、用户情绪的走向、产品推荐的时机、价格谈判的节奏。这些变量之间高度耦合——你多问一个问题，用户情绪可能下降；你早一点报价，谈判空间可能被压缩。PID的SISO（单输入单输出）框架根本处理不了这种耦合。
我试过给每个变量单独配一个PID控制器，结果它们互相打架。情绪控制器的输出是“多安抚”，进度控制器的输出是“加快节奏”，两个信号叠加到Agent的决策层，Agent就懵了。这就像同时踩油门和刹车，车没散架已经是万幸。工业上处理多变量耦合要用MPC（模型预测控制），但MPC需要精确的模型，Agent场景下同样不现实。
1.4 一个真实案例：PID式重试机制如何把Agent逼疯
去年我参与过一个文档审核Agent的项目，最初的架构就是典型的PID式反馈：Agent输出审核结果，如果和人工标注不一致，就调整Agent的阈值参数，偏差越大调整幅度越大。前几轮效果不错，准确率从70%爬到了85%。但到了第10轮左右，准确率突然崩了，直接掉到60%以下。
排查了两天才找到原因：积分项累积导致的参数漂移。因为有些文档的审核标准本身就模糊，人工标注也不完全一致，Agent在这些样本上反复被“纠正”，阈值参数被推到了一个极端值。然后这个极端值又影响了其他本来能正确判断的样本，引发连锁反应。这就是典型的积分饱和——系统在无法消除的误差上持续积分，最终失控。
这个案例让我彻底放弃了在Agent上直接套PID的想法。不是PID不好，而是它的假设和Agent的现实差距太大。我需要一个能处理未知扰动、不依赖精确模型、对时滞不敏感的控制框架。这就是后来转向ADRC的起点。
2. ADRC的核心武器：扩张状态观测器如何“看见”未知扰动
2.1 从“对抗扰动”到“估计扰动”的思维转变
传统控制对付扰动的思路是“对抗”：扰动来了，我通过反馈把它压下去。PID的鲁棒性就来自这种对抗——你扰动再大，我增益够高就能压住。但对抗的代价是能量消耗和震荡风险。ADRC换了个思路：我不跟你对抗，我先“看见”你，然后把你抵消掉。
这个“看见”扰动的东西，就是扩张状态观测器（ESO）。它的核心思想非常巧妙：把系统里所有不确定的东西——外部扰动、内部未建模动态、参数变化——统统打包成一个“总扰动”，然后把这个总扰动扩张成系统的一个新状态变量，用观测器去估计它。估计出来之后，在控制量里减去这个扰动的估计值，系统就变成了一个近似确定的积分器串联形式，控制起来就容易多了。
我第一次理解ESO的时候，觉得这简直是控制领域的“降维打击”。它不要求你知道扰动是什么、从哪来、什么规律，只要扰动是可观测的（通过系统输出能间接反映出来），ESO就能把它估出来。这对Agent来说太重要了——Agent面对的环境扰动，绝大多数都是未知的、时变的、没法建模的。
2.2 ESO的数学直觉：用“扩张状态”捕捉Agent环境的不确定性
ESO的数学形式不复杂，但直觉很重要。假设Agent的任务执行过程可以近似描述为一个二阶系统：
y'' = f(y, y', w, t) + b*u其中y是任务完成度，u是Agent的决策输出，b是控制增益，f是“总扰动”——包含了所有你不知道的东西：环境变化、模型误差、外部干扰。ESO的做法是把f扩张成一个新的状态变量x3，然后构造一个观测器：
e = z1 - y z1' = z2 - beta1*e z2' = z3 - beta2*e + b*u z3' = -beta3*ez1、z2、z3分别是对y、y'、f的估计。beta1、beta2、beta3是观测器增益。只要增益选得合适，z3就能快速跟踪上真实的f。然后在控制律里，用u = (u0 - z3)/b，把扰动抵消掉，系统就变成了y'' ≈ u0，一个干净的双积分器。
这个思路迁移到Agent上，意味着什么？意味着我不需要知道用户为什么突然改变了需求，不需要知道工具为什么返回了异常格式，不需要知道外部API为什么变慢了。我只需要一个“观测器”，从Agent的执行轨迹中估计出“当前环境的总扰动水平”，然后在决策时把这个扰动补偿掉。
2.3 把ESO搬到Agent架构里：状态变量怎么定义
理论很漂亮，但落地第一步就卡住了：Agent的状态变量怎么定义？工业控制里y是温度、压力、位置，都是连续可测的物理量。Agent的“任务完成度”是个抽象概念，怎么量化？
我的做法是构造一个多维状态向量，每个维度对应一个可观测的执行指标。比如对于一个数据清洗Agent，状态向量可以包括：
- 当前批次数据的清洗通过率（0到1之间的连续值）
- 最近N次工具调用的平均响应时间
- 最近N次决策的置信度均值
- 当前任务队列的积压程度
这些指标都是可以从Agent的执行日志里实时提取的。然后我用一个轻量级的在线学习模型（比如带遗忘因子的递归最小二乘）来拟合状态转移关系，ESO的观测器部分就用这个模型来实现。beta增益的整定参考了工业ADRC的经验公式，但根据Agent的响应速度做了缩放。
这里有个关键细节：Agent的状态更新频率远低于工业控制系统。工业ESO的带宽可以做到几千赫兹，Agent可能几秒才更新一次状态。这意味着ESO的增益不能照搬工业参数，需要根据实际的任务周期重新整定。我一般先用带宽参数化方法给一个初值，然后根据实际执行数据微调。
2.4 观测器带宽整定：从工业经验公式到Agent参数映射
ADRC的观测器增益通常用带宽w0来参数化：
beta1 = 3*w0 beta2 = 3*w0^2 beta3 = w0^3这个参数化方法来自高志强教授的研究，它把三个增益的整定简化为一个带宽参数的整定。w0越大，观测器跟踪扰动越快，但对噪声也越敏感。工业上w0通常取控制器带宽的3到5倍。
在Agent场景下，我用的映射方法是：先确定Agent的任务周期T（比如一次决策循环平均耗时2秒），然后取w0 = k/T，k在0.5到2之间根据任务对扰动的敏感度调整。对于数据清洗这种对格式扰动敏感的任务，k取大一点，w0约等于1；对于对话生成这种对实时性要求高的任务，k取小一点，避免观测器被对话中的正常波动带偏。
实测下来，这套参数映射方法在三个不同场景的Agent上都跑通了，观测器估计的总扰动和实际扰动的相关系数能到0.7以上。当然，这只是一个起点，具体项目还需要根据执行数据做精细调整。
3. 自抗扰Agent的工程实现：从理论到可运行代码
3.1 整体架构：把ADRC嵌入Agent的决策循环
把ADRC嵌入Agent不是简单加一个模块，而是要把整个决策循环重新组织。我采用的架构是三层结构：
最底层是执行层，就是Agent原有的工具调用、模型推理、输出生成这些动作。这一层基本不动，保持原有的灵活性。
中间层是观测层，运行ESO，从执行层的日志中提取状态变量，估计总扰动。这一层是新增的，也是ADRC的核心。
最上层是决策层，原本Agent的规划逻辑在这里，现在要加入扰动补偿。具体来说，决策层输出的动作指令，要先减去观测层估计的扰动补偿量，再下发给执行层。
这个架构的关键在于观测层和决策层的接口设计。观测层输出的不是原始扰动估计值，而是“扰动补偿建议”——比如“当前环境扰动水平偏高，建议降低决策激进程度20%”。这样决策层不需要理解ESO的内部数学，只需要根据补偿建议调整自己的输出。
3.2 状态提取器的实现：从Agent日志到数值化状态
状态提取器是观测层的输入模块，负责把Agent的非结构化执行日志转换成数值化的状态向量。这部分没有通用方案，必须针对具体Agent定制。我一般会定义一个状态提取配置，用YAML描述每个状态维度的提取规则：
state_dimensions: - name: task_success_rate source: execution_log field: task_result aggregation: moving_average window: 10 transform: binary_to_float - name: tool_latency source: tool_call_log field: response_time_ms aggregation: moving_average window: 5 transform: log_scale - name: decision_confidence source: decision_log field: confidence_score aggregation: exponential_moving_average alpha: 0.3这个配置驱动一个通用的状态提取引擎，从日志流中实时计算状态向量。实测下来，这套配置化方案能覆盖80%的常见状态提取需求，剩下的20%需要写自定义提取函数。
有个坑要注意：状态提取的窗口大小很关键。窗口太小，状态噪声大，ESO估计的扰动会抖；窗口太大，状态滞后严重，扰动补偿不及时。我的经验值是窗口大小取Agent任务周期的3到5倍。比如任务周期2秒，窗口取6到10秒的数据。
3.3 扰动补偿的注入点：在决策链的哪个环节动手
扰动补偿注入的位置直接影响效果。我试过三个注入点：
第一个是规划层注入，在Agent生成任务计划之前，根据扰动估计调整规划参数。这个注入点影响最大，但也最危险——如果扰动估计错了，整个计划都会跑偏。
第二个是动作层注入，在Agent选定具体动作之后，根据扰动估计微调动作参数。这个注入点比较安全，但补偿能力有限。
第三个是输出层注入，在Agent生成最终输出之前，根据扰动估计做后处理。这个注入点最安全，但只能做表面修补。
我最终采用的是混合注入策略：扰动估计的绝对值小于阈值时，只在动作层做微调；超过阈值时，触发规划层重新规划；输出层始终做一轮安全检查。这套策略在保证安全的前提下，给了扰动补偿足够的发挥空间。
3.4 一个可运行的ADRC-Agent核心代码框架
下面是我在实际项目中用的核心代码框架，基于Python实现，依赖numpy和scipy。这个框架不绑定任何特定的Agent平台，可以嵌入到大多数Agent架构里。
import numpy as np from collections import deque from dataclasses import dataclass from typing import Callable, Optional @dataclass class ADRCConfig: bandwidth: float = 1.0 # 观测器带宽w0 control_gain: float = 1.0 # 控制增益b state_dim: int = 4 # 状态向量维度 window_size: int = 10 # 状态平滑窗口 compensation_limit: float = 0.5 # 补偿量限幅 class ExtendedStateObserver: """扩张状态观测器，估计Agent环境的总扰动""" def __init__(self, config: ADRCConfig): self.config = config self.z = np.zeros(config.state_dim + 1) # 状态估计 + 扰动估计 self.beta = self._compute_gains(config.bandwidth) self.history = deque(maxlen=config.window_size) def _compute_gains(self, w0: float) -> np.ndarray: """带宽参数化计算观测器增益""" n = self.config.state_dim gains = np.array([w0 ** (i + 1) for i in range(n + 1)]) # 二项式系数加权 from math import comb gains = gains * np.array([comb(n + 1, i + 1) for i in range(n + 1)]) return gains def update(self, measurement: np.ndarray, control: np.ndarray) -> np.ndarray: """更新观测器状态，返回扰动估计""" # 预测误差 error = self.z[0] - measurement[0] # 状态更新 for i in range(self.config.state_dim): self.z[i] = self.z[i] + self.z[i+1] * 0.01 # dt=0.01 self.z[i] -= self.beta[i] * error * 0.01 # 扰动状态更新 self.z[-1] -= self.beta[-1] * error * 0.01 # 平滑处理 self.history.append(self.z[-1].copy()) smoothed_disturbance = np.mean(self.history, axis=0) return smoothed_disturbance def reset(self): self.z = np.zeros(self.config.state_dim + 1) self.history.clear() class ADRCAgentWrapper: """ADRC增强的Agent包装器""" def __init__(self, base_agent, config: ADRCConfig): self.base_agent = base_agent self.config = config self.eso = ExtendedStateObserver(config) self.state_extractor = self._build_extractor() def _build_extractor(self) -> Callable: """构建状态提取器，从Agent日志提取状态向量""" def extract(log_entry: dict) -> np.ndarray: state = np.zeros(self.config.state_dim) # 根据实际日志结构填充状态 state[0] = log_entry.get('task_success_rate', 0.5) state[1] = log_entry.get('tool_latency_normalized', 0.5) state[2] = log_entry.get('decision_confidence', 0.5) state[3] = log_entry.get('queue_pressure', 0.5) return state return extract def step(self, observation: dict, goal: str) -> dict: """执行一步决策，带扰动补偿""" # 提取状态 state = self.state_extractor(observation) # 获取基础Agent的决策 base_action = self.base_agent.decide(observation, goal) # 估计扰动 control = np.array([base_action.get('intensity', 0.5)]) disturbance = self.eso.update(state, control) # 计算补偿量 compensation = -disturbance / self.config.control_gain compensation = np.clip( compensation, -self.config.compensation_limit, self.config.compensation_limit ) # 注入补偿 adjusted_action = self._inject_compensation(base_action, compensation) return adjusted_action def _inject_compensation(self, action: dict, compensation: np.ndarray) -> dict: """将补偿量注入到Agent动作中""" adjusted = action.copy() # 根据补偿量调整决策参数 if 'intensity' in adjusted: adjusted['intensity'] = np.clip( adjusted['intensity'] + compensation[0], 0.0, 1.0 ) # 补偿量过大时触发保守模式 if np.abs(compensation).max() > self.config.compensation_limit * 0.8: adjusted['conservative_mode'] = True adjusted['reason'] = 'high_disturbance_detected' return adjusted这个框架的核心是ExtendedStateObserver类，它实现了ESO的离散更新逻辑。ADRCAgentWrapper类负责把ESO嵌入到Agent的决策循环里。实际使用时，只需要把原有的Agent实例传进去，然后在每一步决策后调用step方法即可。
有几个实现细节值得说明。第一，观测器的更新频率要和Agent的决策频率匹配，不能太快也不能太慢。第二，扰动估计做了滑动平均平滑，避免单次噪声导致补偿量剧烈波动。第三，补偿量做了限幅，防止观测器发散时把Agent带偏。第四，当补偿量接近限幅值时，触发保守模式，让Agent切换到更安全的策略。
3.5 参数整定的实操流程：从默认值到场景适配
ADRC的参数不多，但整定需要耐心。我总结了一个四步整定流程：
第一步，确定控制增益b。b的物理意义是“单位控制量能产生多大的状态变化”。在Agent场景下，我通常用历史数据做回归：收集一批（控制量，状态变化量）的样本，做线性回归，斜率就是b的估计值。如果数据不足，可以先取b=1，后续再调。
第二步，整定观测器带宽w0。从w0=0.5开始，逐步增大，观察扰动估计的跟踪速度和噪声水平。跟踪太慢就增大w0，噪声太大就减小w0。我的经验是，w0取Agent决策频率的0.5到1倍比较合适。
第三步，调整补偿限幅。限幅太松，补偿量可能过大导致震荡；限幅太紧，补偿效果不明显。一般从0.3开始试，根据实际效果调整到0.5左右。
第四步，在线微调。部署后持续监控扰动估计的统计特性，如果发现估计值长期偏大或偏小，说明b或w0需要调整。我一般会设置一个自动微调机制，根据长期统计偏差缓慢调整参数。
这套流程在三个项目上跑下来，平均整定时间在2到3天左右。比PID的整定要复杂一些，但换来的是对未知扰动的鲁棒性，我觉得很值。
4. 实测对比：ADRC-Agent在三个场景下的稳定性表现
4.1 场景一：数据清洗Agent的格式扰动测试
第一个测试场景是数据清洗Agent，任务是从各种格式的表格数据中提取结构化信息。测试方法是注入不同强度的格式扰动：字段类型变化、缺失值增加、编码格式切换、表头位置偏移。
基线Agent用的是“重试+回退”策略：解析失败就重试，重试三次还失败就回退到默认值。ADRC-Agent用的是本文的扰动补偿框架。
测试结果如下：
| 扰动强度 | 基线完成率 | ADRC完成率 | 基线平均耗时 | ADRC平均耗时 |
|---|---|---|---|---|
| 无扰动 | 94% | 93% | 1.2s | 1.4s |
| 轻度扰动 | 78% | 89% | 2.8s | 1.9s |
| 中度扰动 | 52% | 81% | 6.5s | 2.7s |
| 重度扰动 | 23% | 68% | 12.1s | 4.3s |
关键发现：在无扰动时，ADRC-Agent因为多了观测器开销，完成率略低、耗时略长。但一旦有扰动，ADRC的优势立刻显现。中度扰动下完成率高出29个百分点，耗时只有基线的40%。重度扰动下差距更大，基线基本崩溃，ADRC还能保持68%的完成率。
这个结果符合ADRC的理论预期：它的价值不在于提升理想情况下的性能，而在于扰动情况下的鲁棒性。
4.2 场景二：对话Agent的情绪扰动测试
第二个场景是客服对话Agent，测试的是用户情绪波动对Agent稳定性的影响。测试方法是用模拟用户注入情绪扰动：突然发怒、反复改变需求、长时间不回复、发送无关内容。
这个场景的评估指标不是任务完成率，而是“对话崩溃率”——Agent输出完全无关内容、陷入循环、或主动终止对话的比例。
| 扰动类型 | 基线崩溃率 | ADRC崩溃率 |
|---|---|---|
| 突然发怒 | 18% | 6% |
| 反复改需求 | 31% | 11% |
| 长时间不回复 | 12% | 4% |
| 发送无关内容 | 25% | 9% |
ADRC-Agent的崩溃率全面低于基线。分析日志发现，ADRC的扰动估计器能提前2到3轮对话检测到“用户情绪扰动水平上升”，然后触发补偿机制：降低推荐激进程度、增加确认性提问、缩短单次回复长度。这些补偿动作在用户看来就是“Agent变得更谨慎了”，但实际上背后是ESO在实时估计扰动并驱动补偿。
有个有趣的发现：ADRC-Agent在检测到高扰动时，会主动降低对话的“信息密度”，用更简单、更确认性的语言。这在基线Agent里是没有的，基线只会按照固定策略继续推进，直到崩溃。
4.3 场景三：多工具编排Agent的时滞扰动测试
第三个场景是多工具编排Agent，任务是根据用户需求调用多个外部工具完成复杂操作。测试的是工具响应时滞对Agent稳定性的影响。测试方法是在工具调用链路中注入随机延迟，延迟范围从0到10秒。
评估指标是“任务完成率”和“无效调用率”（调用了一个工具但结果没被使用的比例）。
| 延迟水平 | 基线完成率 | ADRC完成率 | 基线无效调用率 | ADRC无效调用率 |
|---|---|---|---|---|
| 无延迟 | 88% | 87% | 8% | 9% |
| 低延迟(0-2s) | 76% | 84% | 15% | 11% |
| 中延迟(2-5s) | 54% | 78% | 28% | 14% |
| 高延迟(5-10s) | 31% | 65% | 42% | 19% |
时滞场景下ADRC的优势非常明显。中延迟下完成率高出24个百分点，无效调用率只有基线的一半。原因在于ESO能估计出“当前工具链路的时滞水平”，然后在决策时补偿：当时滞高时，Agent会减少并行调用、增加串行确认、延长等待超时。这些补偿动作减少了无效调用和重复调用。
4.4 稳定性提升的代价：计算开销与响应延迟分析
ADRC不是免费的午餐。ESO的每次更新需要做矩阵运算，状态提取需要解析日志，补偿注入需要修改决策输出。这些都会增加计算开销和响应延迟。
我实测的开销数据：
| 指标 | 基线Agent | ADRC-Agent | 增幅 |
|---|---|---|---|
| 单步决策耗时 | 45ms | 58ms | +29% |
| 内存占用 | 120MB | 135MB | +12% |
| CPU使用率 | 15% | 19% | +27% |
| 端到端延迟 | 1.8s | 2.0s | +11% |
单步决策耗时增加了29%，但端到端延迟只增加了11%，因为决策耗时在总延迟中占比不高。内存和CPU的增幅在可接受范围内。
我的优化经验：ESO的更新可以异步化，不阻塞主决策流程；状态提取可以用增量计算，避免每次全量解析；补偿注入可以用查表法替代实时计算。这些优化能把开销增幅压到15%以内。
5. 落地ADRC-Agent的五个关键决策点
5.1 什么时候该上ADRC，什么时候用简单重试就够了
ADRC不是万能的，也不是所有Agent都需要。我的判断标准是：如果Agent的失败模式主要是“随机性失败”（比如网络抖动导致的偶发超时），简单重试就够了。如果失败模式是“系统性失败”（比如环境变化导致Agent策略整体失效），ADRC才有价值。
具体来说，我会看三个信号：第一，Agent在测试集上表现好但线上表现差，说明存在环境扰动；第二，失败案例有明显的聚集性，不是随机分布；第三，简单重试和回退策略的效果在边际递减。这三个信号出现两个以上，就值得考虑ADRC。
5.2 状态变量选多少维合适：维度灾难与信息损失的平衡
ESO的状态维度不是越多越好。维度高了，观测器收敛慢，参数整定难，计算开销大。维度低了，扰动估计不准确，补偿效果差。
我的经验是：从3到5维开始，根据实际效果增减。选择状态变量的原则是：选那些“变化能反映环境扰动”的指标，而不是“变化只反映Agent自身行为”的指标。比如“工具响应时间”是好的状态变量，因为它反映环境；“Agent输出长度”是差的状态变量，因为它主要反映Agent自身。
另外，状态变量之间要尽量正交。如果两个状态变量高度相关，保留一个就够了，多了反而增加观测器负担。
5.3 扰动补偿的“度”：补偿过度比不补偿更危险
扰动补偿的幅度控制是个精细活。补偿不足，效果不明显；补偿过度，Agent行为会变得过于保守或过于激进，反而降低性能。
我的做法是设置三层限幅：第一层是单步补偿限幅，防止单次补偿过大；第二层是累积补偿限幅，防止补偿量持续累积；第三层是补偿速率限幅，防止补偿量突变。三层限幅的参数根据场景调整，一般单步限幅在0.3到0.5之间，累积限幅在1.0到1.5之间，速率限幅在0.1到0.2之间。
还有一个经验：补偿的方向比大小更重要。宁可补偿方向对但幅度小，也不要方向错但幅度大。方向错了，幅度越大危害越大。
5.4 与现有Agent框架的集成方式：包装器还是原生改造
ADRC和现有Agent框架的集成有两种方式：包装器模式和原生改造模式。
包装器模式是把ADRC做成一个外挂模块，不修改Agent内部逻辑，只在输入输出层面做扰动补偿。优点是集成快、风险低、可回退。缺点是补偿能力受限，只能做表面调整。
原生改造模式是把ADRC嵌入Agent的决策循环内部，修改规划、决策、执行各环节。优点是补偿能力强、效果好。缺点是改造工作量大、风险高、回退困难。
我的建议是：先用包装器模式快速验证ADRC的价值，如果效果明显再考虑原生改造。大多数场景下，包装器模式已经能带来显著的稳定性提升。
5.5 监控与告警：怎么知道ADRC在正常工作
ADRC上线后需要监控几个关键指标：扰动估计的均值、方差、趋势；补偿量的均值、方差、触发限幅的频率；Agent性能指标的变化趋势。
如果扰动估计的均值持续偏高，说明环境扰动大或者观测器参数偏保守；如果方差很大，说明观测器带宽可能太高，噪声被放大了；如果补偿量频繁触发限幅，说明限幅设置太紧或者扰动估计有偏。
我一般会设置三级告警：扰动估计均值超过历史均值2个标准差时发提醒；补偿量触发限幅频率超过10%时发警告；Agent性能指标连续下降超过3个周期时发严重告警。
6. 从PID到ADRC：一个Agent开发者的控制论思维升级
6.1 控制论视角给Agent开发带来的三个认知转变
第一个转变是从“优化单点”到“优化回路”。以前做Agent，我关注的是每个模块的准确率——意图识别准不准、工具调用对不对、生成质量高不高。但控制论告诉我，系统的稳定性不取决于单点最优，而取决于回路的整体特性。一个90%准确的意图识别模块，放在一个震荡的回路里，可能还不如一个80%准确但回路稳定的模块。
第二个转变是从“消除误差”到“管理误差”。PID的积分项追求零稳态误差，但Agent场景下很多误差是消除不了的——用户需求本身就是模糊的，环境扰动本身就是随机的。ADRC的思路是“估计误差、补偿误差”，而不是“消除误差”。这个思维转变让我不再纠结于把每个指标做到100%，而是关注系统在误差存在时的整体行为。
第三个转变是从“静态调参”到“动态适应”。以前调Agent参数，调好一套就固定下来。但环境在变，用户在变，任务在变，固定参数迟早会失效。ADRC的ESO本质上是一个在线估计器，它持续跟踪环境变化并调整补偿。这让我意识到，Agent的参数也应该是动态的，应该根据实时反馈持续调整。
6.2 哪些Agent场景最适合引入ADRC思维
根据我的经验，三类场景最适合引入ADRC：
第一类是环境扰动频繁且不可预测的场景。比如数据清洗、多工具编排、外部API集成。这些场景的扰动来源多、变化快，传统重试策略效果有限。
第二类是对稳定性要求高于对峰值性能要求的场景。比如客服对话、医疗咨询、金融风控。这些场景下，一次崩溃的代价远大于十次平庸的表现。
第三类是任务链路长、误差累积效应明显的场景。比如多轮对话、复杂规划、长流程执行。这些场景下，早期的微小扰动会被逐级放大，ADRC的扰动补偿能在早期就抑制扰动传播。
反过来，如果Agent的任务链路很短、环境很稳定、失败代价很低，那ADRC的投入产出比就不高，简单重试就够了。
6.3 从ADRC延伸出去：还有哪些控制论工具值得Agent开发者关注
ADRC只是控制论工具箱里的一件。我在研究ADRC的过程中，还发现了几个对Agent开发有启发的控制论工具：
模型预测控制（MPC）：MPC的核心是“预测未来、优化当前”。Agent可以用MPC的思路做多步规划——不是只规划下一步，而是预测未来N步的状态，然后优化当前动作。这对长流程Agent特别有价值。
滑模控制：滑模控制的核心是“设计一个滑模面，让系统状态强制滑向目标”。Agent可以用滑模的思路设计“强制收敛”机制——不管环境怎么扰动，Agent的状态都被强制拉向目标方向。
鲁棒控制：鲁棒控制的核心是“在最坏情况下保证性能”。Agent可以用鲁棒控制的思路做“最坏情况规划”——不是规划最优路径，而是规划在最坏情况下也能完成任务的路径。
这些控制论工具都有几十年的理论积累和工业验证，把它们的思想迁移到Agent开发上，我觉得是未来几年一个很有价值的方向。
6.4 一个未解决的问题：ADRC的自适应参数调整
最后聊一个我还没完全解决的问题：ADRC的参数自适应。目前我的做法是离线整定加在线微调，但微调的规则是手工设计的，不够智能。理想情况下，ESO的带宽w0和控制增益b应该能根据环境扰动水平自动调整——扰动大时增大w0加快跟踪，扰动小时减小w0降低噪声。
我试过用强化学习来做参数自适应，但效果不稳定，训练成本也高。也试过用简单的规则引擎，根据扰动估计的统计特性调整参数，效果还行但不够优雅。这个问题我还在探索，如果你有好的思路，欢迎交流。
另一个未解决的问题是ADRC和Agent学习机制的融合。目前的ADRC-Agent是“控制层”的增强，Agent的“学习层”（比如微调、强化学习）和“控制层”是分离的。理想情况下，学习层应该能感知到控制层的扰动估计，并据此调整学习策略。这个方向我还没深入，但觉得很有潜力。
踩了这么多坑，我最大的体会是：Agent的可靠性问题，本质上是一个控制问题。我们花了太多时间在“让Agent更聪明”上，却忽略了“让Agent更稳定”同样重要，甚至更重要。ADRC给了我一套系统化的稳定性设计框架，虽然它不完美，虽然还有很多工程细节要打磨，但它至少让我从“凭感觉调参”走向了“有理论指导地设计”。如果你也在为Agent的稳定性发愁，不妨试试从控制论的视角重新审视你的架构，可能会有意想不到的收获。
