PID、MPC、Agent、RAG：多时间尺度反馈环的协同控制实践

1. 从一个真实系统的失控说起去年冬天我接手了一个挺有意思的活儿给一套小型恒温循环装置做控制升级。这套装置本身不复杂一个加热棒、一个循环泵、一个温度传感器加上一块跑Linux的嵌入式板子。原来的方案是裸机跑PID参数是上一任工程师拍脑袋定的Kp8Ki0.3Kd0.1。结果就是设定值一变温度能冲过头五六度然后花十几分钟慢慢荡回来像喝多了走不稳路。我当时的第一反应很朴素——重新整定PID参数嘛这活儿我熟。但整了两天之后我发现问题根本不在PID本身。这套装置的热惯性很大加热棒从全功率到温度探头感知到变化中间有将近40秒的纯滞后。更要命的是循环泵的流量会随着水温变化而漂移也就是说被控对象的模型本身在变。你用一组固定参数去套一个时变的、大滞后的对象怎么调都是按下葫芦浮起瓢。这件事让我重新想了一个问题一个真实系统的控制到底应该由几层反馈环来管我们平时聊PID聊MPC聊Agent聊RAG好像它们是四个平行世界的东西。但如果你真的做过嵌入式控制你会发现它们其实是在不同时间尺度上工作的反馈环而且必须协同。PID管的是毫秒到秒级的快速纠偏MPC管的是秒到分钟级的带约束优化Agent管的是分钟到小时级的策略调整而RAG管的是更慢的、跨会话的知识沉淀与检索。这篇是专栏的收束篇我想把这四个东西放在同一张时间轴上讲清楚它们各自解决什么问题、边界在哪里、怎么衔接、以及我在实际项目里踩过的那些坑。2. 把PID、MPC、Agent、RAG放到同一根时间轴上2.1 时间尺度决定了反馈环的职责分工先建立一个直觉。任何控制系统本质上都是测量—比较—执行的循环。区别只在于这个循环跑得多快、看多远的未来、以及决策的抽象层级有多高。我习惯用一张表来梳理层级典型周期决策对象核心方法约束处理失效后果底层调节1ms~100ms执行器输出PID靠限幅振荡、超调中层优化100ms~10s设定值轨迹MPC显式约束越界、能耗高上层策略10s~10min控制模式/参数Agent规则推理策略僵化知识层分钟~天经验/文档RAG检索相关性重复踩坑这张表不是学术分类是我在项目里实际分层时用的。关键洞察是越往上周期越长但决策的影响面越大。PID调错了顶多这一炉温度不稳Agent策略错了可能整个班次的能耗都上去了。2.2 为什么不能让一个环包打天下很多人会问既然Agent这么聪明为什么不直接让Agent去控制加热棒答案很简单时间尺度不匹配。Agent的推理延迟通常在几百毫秒到几秒而且输出不确定。你让一个大模型每秒去算一次PWM占空比先不说算力够不够光是推理抖动就能让系统疯掉。反过来PID再快它也不知道今天电价高应该提前蓄热这种跨小时的策略。这就是为什么真实系统一定是多环嵌套的。底层环要快、要确定、要可证明稳定上层环可以慢、可以不确定、但要有推理和记忆能力。中间用MPC做过渡是因为MPC天然能处理约束和多变量耦合正好填补PID和Agent之间的空白。2.3 一个容易忽略的事实反馈环之间会互相打架我踩过最深的坑就是上下层环的带宽没有拉开。当时我给温度环加了MPC周期设成2秒结果和底层PID的响应频段重叠了两个环互相抢方向盘系统出现了低频振荡周期大概十几秒。排查了很久才意识到MPC的预测时域和PID的积分时间撞车了。经验法则是上层环的周期至少是下层环的5到10倍。PID如果100ms跑一次MPC至少500ms到1sAgent如果10s决策一次那MPC就别超过2s。这样频域上才能解耦不会互相激励。3. PID这一层快、稳、但别指望它聪明3.1 裸机PID在嵌入式上的真实写法先说说最底层。很多人写PID就是三个系数一乘一加但真到嵌入式上有几个细节不注意就会翻车。位置式PID的经典形式typedef struct { float Kp, Ki, Kd; float integral; float prev_error; float out_min, out_max; float integral_min, integral_max; } PID_t; float PID_Update(PID_t *pid, float setpoint, float measured, float dt) { float error setpoint - measured; // 积分项带限幅 pid-integral error * dt; if (pid-integral pid-integral_max) pid-integral pid-integral_max; if (pid-integral pid-integral_min) pid-integral pid-integral_min; // 微分项用测量值微分避免设定值突变冲击 float derivative -(measured - pid-prev_measured) / dt; pid-prev_measured measured; float output pid-Kp * error pid-Ki * pid-integral pid-Kd * derivative; // 输出限幅 if (output pid-out_max) output pid-out_max; if (output pid-out_min) output pid-out_min; return output; }这段代码里有三个关键点都是我用血泪换来的第一积分限幅必须做。不做的话一旦系统长时间达不到设定值比如加热棒功率不够积分项会无限累积等误差反向时输出会猛冲这就是典型的积分饱和。我见过一个项目因为这个温度直接冲到安全阀动作。第二微分项用测量值而不是误差。如果用误差微分设定值一阶跃微分项会瞬间爆出一个尖峰执行器会被这个尖峰冲击。用测量值微分就平滑得多。第三dt要真实测量。别假设你的控制周期是精确的10ms。在Linux上跑调度抖动可能让实际周期在8到15ms之间跳。如果你用固定dt积分和微分都会算错。我一般用clock_gettime取实际时间差。3.2 大滞后对象PID的天花板在哪回到开头那个恒温装置。40秒纯滞后意味着什么意味着你现在的输出要40秒后才能被传感器看到。这40秒里PID是盲的。对于纯滞后系统PID的稳定边界可以用一个经验公式估算。如果滞后时间L和对象时间常数T的比值L/T大于1PID基本就很难调好了。我那个装置L≈40sT≈60sL/T≈0.67属于能调但很勉强。这时候你有三个选择降低带宽把响应调得很慢牺牲动态性能换稳定。这是最保守的做法。加前馈用可测的扰动比如环境温度提前补偿。上MPC用模型预测来预判滞后的影响。我最后选的是第二条加第三条的组合前馈处理环境温度MPC处理设定值轨迹。PID退化成内环的快速调节器只负责抑制小扰动。3.3 嵌入式PID的工程细节在ARM-Linux上跑PID有几个实操经验定点还是浮点如果板子有FPU比如Cortex-A系列直接用float别折腾定点。如果没有FPUCortex-M0这种定点能快好几倍但要注意Q格式的溢出。控制周期用定时器还是线程我倾向于用一个高优先级线程加clock_nanosleep比硬件定时器中断灵活方便和上层通信。但要注意设置SCHED_FIFO优先级否则会被其他线程抢占。输出限幅和变化率限制除了幅值限幅最好再加一个变化率限制。比如加热棒从0到100%至少要2秒防止热冲击。这个限制放在PID输出之后、执行器之前。4. MPC这一层带约束的预判型调节4.1 MPC到底比PID多算了什么MPC的核心思想一句话用模型预测未来N步的系统行为然后求解一个带约束的优化问题只执行第一步下一步重新预测。这个滚动时域的机制让它天然能处理约束和滞后。用生活类比PID像开车只看后视镜和当前车速MPC像开着导航预判前面三个路口的红绿灯。前者反应快但短视后者看得远但算得慢。MPC的优化问题一般长这样min Σ (y_pred(ki) - y_ref(ki))^2 λ Σ Δu(ki)^2 u i1..N s.t. u_min ≤ u(ki) ≤ u_max Δu_min ≤ Δu(ki) ≤ Δu_max y_min ≤ y_pred(ki) ≤ y_max第一项是跟踪误差第二项是控制增量惩罚让输出平滑约束包括执行器幅值、变化率和输出范围。4.2 在嵌入式上跑MPC的现实约束理论上MPC很美好但嵌入式上跑MPC有几个硬约束算力。一个线性MPC预测时域N20控制时域M5每步要求解一个二次规划QP。在Cortex-A7上用OSQP或者自己写的active-set求解器单次求解大概几毫秒到几十毫秒。如果你的控制周期是1秒完全够用如果是100毫秒就有点紧张。内存。QP求解器需要存Hessian矩阵和约束矩阵。N20的话Hessian大概是20x20还好。但如果状态维度上去了比如多变量系统内存会涨得很快。代码生成。我强烈建议用MATLAB的MPC Toolbox或者ACADO生成C代码别手写。手写QP求解器容易出数值问题而且调试成本极高。生成代码虽然可读性差但稳定。4.3 MPC和PID的衔接方式最常见的架构是串级MPC输出设定值PID跟踪设定值。[MPC] --y_ref-- [PID] --u-- [被控对象] --y-- 反馈 ^ | |______________________________________________|这样分工的好处是MPC负责往哪走PID负责怎么快速走到。MPC的周期可以慢1秒PID的周期快100毫秒。频域上解耦不会打架。但要注意一个坑MPC的输出变化率要限制。如果MPC突然把设定值从50度跳到80度PID会拼命追执行器会饱和。我一般给MPC的输出加一个斜率限制比如每秒最多变2度。4.4 模型不准怎么办MPC最怕模型不准。我那个恒温装置热容和热阻都是标称值实际用久了加热棒老化模型就偏了。应对方法有两个在线辨识用递推最小二乘RLS实时估计模型参数。这个在嵌入式上可行计算量不大。但要注意激励条件如果系统长期在稳态辨识会漂。鲁棒MPC把模型不确定性考虑进去求解min-max问题。这个计算量大一般嵌入式扛不住。我实际用的是折中方案离线辨识一个标称模型在线只估计一个增益修正因子。简单、稳定、够用。5. Agent这一层慢思考的策略调整5.1 Agent在控制系统里到底干什么先说清楚Agent不是用来替代PID或MPC的。它的职责是处理那些需要推理、需要记忆、需要跨会话的决策。具体到我的项目Agent负责这几件事根据电价信号和天气预报决定未来几小时的温度设定值轨迹。监测系统健康状态如果发现PID的跟踪误差持续偏大判断是传感器漂移还是执行器老化。在异常发生时生成排查建议并从历史案例中检索相似情况。这些任务的共同点是周期长分钟到小时、需要符号推理、需要外部知识。这正是大模型Agent擅长的。5.2 Agent的反馈环怎么闭合Agent不是开环的。它也需要反馈只不过反馈的粒度更粗。我的做法是Agent每隔5分钟读一次系统状态摘要当前温度、设定值、跟踪误差、能耗、执行器输出然后决定是否调整策略。调整的输出是一个策略对象比如{ mode: preheat, target_trajectory: [65, 68, 70, 70, 68], pid_params: {Kp: 6.5, Ki: 0.25, Kd: 0.12}, reason: 电价低谷期提前蓄热预计2小时后有生产需求 }这个策略对象被下发给MPC和PID。MPC用新的目标轨迹PID用新的参数。关键点Agent的输出必须经过校验。不能让它直接写执行器。我加了一层策略校验器检查参数是否在安全范围内、轨迹是否满足物理约束。校验不通过就拒绝回退到默认策略。5.3 Agent的并发问题热词里有个ai agent 怎么扛并发这个问题在控制场景里同样存在。如果一个Agent要同时管多个设备或者多个Agent共享一个知识库并发就成了问题。我的经验是控制场景的Agent并发压力其实不大因为周期长。真正的瓶颈在知识检索和推理延迟。如果10个设备同时触发Agent每个推理要3秒串行就是30秒。这时候要么加推理实例要么做请求合并。请求合并是个好办法如果多个设备的请求在时间窗口内重叠可以合并成一个批量推理。大模型对批量输入的处理效率比单条高得多。5.4 Agent的幻觉在控制场景里是致命的这是我最想强调的一点。在聊天场景里Agent胡说八道顶多让人笑话在控制场景里Agent给出一个错误的参数可能导致设备损坏。我的防御措施有三层参数白名单Agent只能从预定义的参数集合里选不能自由生成数值。仿真预演Agent的策略先在数字孪生模型上跑一遍看是否稳定。人工确认对于影响大的策略变更比如改变控制模式需要人工确认。这三层下来Agent的自主性被限制了不少但安全性大大提升。我认为在工业控制场景这种保守是必要的。6. RAG这一层让经验不再随人流失6.1 为什么控制系统需要RAG控制系统有个老问题经验都在老师傅脑子里。设备出了故障老师傅一听声音就知道哪里的问题换了新人对着报警代码查半天。RAG检索增强生成的价值就在这里把历史故障记录、维修日志、操作手册、参数整定记录都存进知识库当系统出现异常时自动检索相似案例辅助决策。热词里有人问rag知识库能存储图片嘛答案是能但要看你的RAG实现。纯文本RAG只能存文字多模态RAG可以存图片、波形图、频谱图。在控制场景里波形图其实很重要——很多故障的特征就藏在振动波形里。6.2 控制场景RAG的特殊性通用的RAG教程比如ollama 简易本地rag知识库那种大多是面向文档问答的。控制场景的RAG有几个特殊需求结构化数据和时间序列。控制系统的历史数据是时间序列不是自然语言。你不能把一万个温度采样点直接塞进向量库。我的做法是先把时间序列做特征提取均值、方差、频谱峰值、趋势然后把特征描述成文本再入库。实时性。故障发生时你希望RAG在秒级返回结果。如果知识库很大检索会很慢。热词里提到的rag瓶颈很大一部分就是检索延迟。我的优化是用分层检索先粗筛关键词元数据过滤再精排向量相似度。因果性。控制场景的检索不只是相似还要因果相关。比如温度偏高可能的原因有十几种你需要检索的是导致温度偏高的原因而不是温度偏高这个现象。这需要在入库时标注因果关系。6.3 一个可落地的RAG架构我在项目里用的架构大概是这样的[历史数据] -- [特征提取] -- [文本化] -- [向量化] -- [向量库] | [实时报警] -- [查询构造] -- [分层检索] -- [重排] -- [LLM生成建议] | [人工确认]几个实操细节文本化的模板要统一。比如2024-01-15 14:30温度从65度在3分钟内升到72度加热棒输出100%循环泵流量下降15%。这种结构化描述比原始日志好检索得多。向量模型的选择。控制领域有很多专业术语通用embedding模型效果一般。我试过用领域语料微调一个小模型检索准确率提升明显。重排很重要。向量检索的top-10里真正相关的可能只有2-3条。加一个cross-encoder重排能把准确率拉高不少。6.4 RAG和Agent的配合RAG和Agent不是二选一而是配合关系。Agent负责决定要查什么RAG负责把相关的知识找出来。比如Agent发现跟踪误差持续偏大它会构造查询温度跟踪误差大 可能原因 传感器漂移 执行器老化。RAG检索出历史案例Agent再结合当前状态做推理给出排查建议。这个配合模式热词里叫agentic rag其实就是让Agent主动驱动检索而不是被动等查询。7. 四个环怎么协同一个完整的控制周期7.1 从毫秒到小时的完整链路把四个环串起来一个完整的控制周期是这样的毫秒级PID每100ms执行一次读取传感器计算输出驱动执行器。这是最内环必须确定、快速。秒级MPC每1秒执行一次读取系统状态求解优化问题输出新的设定值给PID。同时检查约束是否满足。分钟级Agent每5分钟执行一次读取系统摘要结合RAG检索的历史知识决定是否调整策略。输出经过校验后下发给MPC和PID。小时到天级RAG知识库持续更新把新的故障案例、维修记录、参数整定结果入库。这个更新可以是离线的也可以是准在线的。7.2 环间通信的设计四个环之间的通信我用的是一个共享内存加消息队列的混合方案PID和MPC之间用共享内存因为周期快消息队列的开销太大。MPC和Agent之间用消息队列因为Agent周期慢而且可能跨进程。Agent和RAG之间用HTTP或者gRPC因为RAG可能跑在另一台机器上。数据结构要统一。我定义了一个SystemState结构体包含所有环需要的信息每个环读自己需要的字段写自己负责的字段。用版本号或者时间戳来保证一致性。7.3 故障时的降级策略多环系统最怕的是上层环挂了下层环还在傻跑。我的降级策略是Agent挂了MPC用默认策略PID参数不变。系统降级为纯MPCPID性能下降但安全。MPC挂了PID用固定设定值退化为纯PID。系统能维持基本控制。RAG挂了Agent用内置规则库不检索历史。决策质量下降但能工作。PID挂了这是最严重的直接触发硬件保护切断执行器。每一层降级都要有明确的切换逻辑和超时机制。我一般用看门狗上层环如果超过3个周期没更新下层环自动降级。8. 踩过的坑和换来的经验8.1 时间同步问题多环系统里时间戳不一致会导致严重的逻辑错误。我遇到过一次MPC用的状态是500ms前的PID用的是当前的结果MPC基于旧状态算出的设定值和PID的实际状态对不上系统振荡。解决方案所有环用同一个时钟源CLOCK_MONOTONIC状态数据带时间戳使用前检查新鲜度。超过阈值的旧数据直接丢弃。8.2 参数整定的顺序四个环的参数不能同时调。我的顺序是先调PID内环稳定后再调MPC中环最后调Agent外环。每调一层下层必须固定。否则你根本分不清振荡是哪层引起的。8.3 Agent的提示词工程Agent的提示词不是随便写写就行的。我试过很多版本最后稳定下来的结构是角色定义你是一个工业控制策略助手。当前状态结构化的系统摘要。可用动作白名单里的策略选项。约束条件安全范围、物理限制。输出格式严格的JSON schema。关键是输出格式要严格。如果让Agent自由发挥它可能返回一段自然语言你的解析器就崩了。用JSON schema约束配合few-shot示例能大幅提升稳定性。8.4 RAG的更新频率知识库不是越新越好。我一开始每天全量更新结果发现检索结果不稳定今天查到的和昨天查到的差很多。后来改成增量更新加版本控制重要案例人工审核后才入库稳定性好多了。8.5 别过度设计最后一条也是最重要的别为了用Agent而用Agent。我见过一些项目明明一个规则引擎就能搞定的事情非要上大模型结果延迟高、成本高、还不稳定。判断标准很简单如果决策逻辑能用if-else清晰表达就用if-else。只有当决策需要处理模糊信息、需要跨领域知识、需要自然语言交互时才考虑Agent。9. 写在专栏收束之际这个专栏从PID写到Agent从毫秒级写到小时级其实一直在讲同一件事反馈环的本质是在不确定中寻找稳定。PID用快速反馈对抗小扰动MPC用预测对抗滞后和约束Agent用推理对抗复杂策略RAG用记忆对抗经验流失。它们不是替代关系而是嵌套关系各自在自己的时间尺度上工作通过清晰的接口协同。我在实际项目里最大的体会是分层不是为了炫技而是为了解耦。每一层只关心自己尺度上的问题把其他尺度的问题交给其他层。这样每层都可以独立调试、独立优化、独立降级。系统的鲁棒性恰恰来自于这种各管一段的清晰边界。如果你正在做类似的控制系统我的建议是先把PID调稳这是地基然后根据滞后和约束情况决定要不要上MPCAgent和RAG是锦上添花不是必需品。别一上来就搞大架构先把最底层的东西做扎实。最后分享一个小技巧不管你的系统有几层环一定要有一个全局状态记录器把所有环的输入输出都记下来带时间戳。出问题的时候这个记录就是你的黑匣子。我靠这个黑匣子定位过好几次跨层的疑难杂症比任何调试工具都好用。