PID与Agent双环控制：跨时间尺度反馈的嵌入式实践

1. 从一个真实系统的控制难题说起

做过嵌入式控制的人大概都有过这种体验：一个温控箱，PID参数调得漂漂亮亮，稳态误差压到0.1度以内，结果某天环境温度骤变，或者换了批次的加热丝，整个系统就开始震荡，超调大得离谱。你重新调参，又能稳住一阵子，但下次工况一变，问题照旧。这不是PID本身的问题，而是单一时间尺度上的反馈环，天生就管不了跨时间尺度的扰动。

我最早接触这个矛盾是在一个恒温水浴项目上。当时用的就是经典的增量式PID，采样周期10ms，控制周期100ms，参数是齐格勒-尼科尔斯法整定出来的。实验室里跑了一整天，曲线平得像尺子画的。结果搬到现场，水箱从50升换成200升，同样的参数直接失控，加热管全功率输出，水温冲过头8度才拉回来。那次之后我才真正理解了一件事：PID是一个短时间尺度上的反射弧，它擅长处理秒级到分钟级的偏差修正，但对系统结构变化、工况迁移、长期漂移这类慢变量，它没有记忆，也没有推理能力。

这几年Agent概念火起来之后，我一直在想一个问题：能不能把Agent看成是一个长时间尺度上的反馈环？PID管毫秒到秒级的执行层，Agent管分钟到小时级的决策层，两者叠在一起，是不是就能覆盖一个真实系统从底层执行到上层策略的完整控制链路？这个想法在我脑子里转了很久，也做了一些原型验证，下面就把整个思路拆开来讲。

这篇文章适合谁看？如果你做过嵌入式控制、写过PID、调过参数，同时对Agent和大模型有兴趣但不知道怎么跟传统控制结合，那这篇内容应该对你有用。如果你是大模型应用开发者，想理解控制理论里的反馈环怎么映射到Agent架构上，也能从中找到一些对应关系。我会尽量用实际项目里的例子来说明，不堆公式，讲人话。

2. 反馈环的本质：不同时间尺度上的控制逻辑

2.1 PID到底在控制什么

先把PID的本质说清楚。PID控制器做的事情非常简单：读当前值，跟目标值比，算出误差，然后根据误差的比例、积分、微分三项加权求和，输出一个控制量。比例项管当前误差，积分项管历史误差累积，微分项管误差变化趋势。这三项加起来，本质上是在一个固定的时间窗口内，对偏差做连续修正。

关键点在于“固定时间窗口”。PID的采样周期和控制周期是人为设定的，一旦确定，它感知世界的时间粒度就固定了。10ms采一次，它就只知道10ms间隔上的变化。你让它去感知“过去三小时水温缓慢漂移了0.5度”这种事，它做不到，因为积分项虽然理论上能累积，但积分饱和和积分限幅会把它限制在一个很窄的范围内。

我做过一个测试：用一个标准PID控制加热台，目标温度60度，环境温度从25度慢慢降到15度，降幅速率大概是每小时2度。PID在头两个小时能把温度稳在60±0.3度，但到第三个小时，积分项已经累积到限幅值，输出饱和，温度开始往下掉，最终稳定在58.7度左右。这就是短时间尺度反馈环的天然局限——它能处理快扰动，但处理不了慢漂移。

2.2 Agent在控制链路里扮演什么角色

Agent这个词现在被用得很泛，但在控制语境下，我倾向于把它定义为一个具备感知、推理、决策、执行四个环节的自治单元，而且它的决策周期比PID长得多，通常在秒级到分钟级甚至更长。

拿大模型驱动的Agent来说，它的工作流程大概是这样的：感知层收集系统状态（温度曲线、功率输出、环境参数、历史日志），推理层用大模型或者规则引擎分析当前状态跟预期的偏差模式，决策层生成调整策略（比如修改PID参数、切换控制模式、调整目标值），执行层把策略下发到控制器。整个过程可能几十秒跑一轮，也可能几分钟跑一轮，取决于系统动态。

这跟PID形成了鲜明的对比。PID是毫秒级的条件反射，Agent是分钟级的深思熟虑。PID管“现在偏差多少我就补多少”，Agent管“过去半小时的偏差模式说明系统可能变了，我该换个策略”。

2.3 两个反馈环怎么叠在一起

把PID和Agent叠在一起，不是简单地把Agent的输出接到PID的输入上。这里面有一个关键设计问题：两个环的耦合点在哪里，耦合方式是什么。

我试过三种耦合方式，下面这张表是实测对比：

我最终选的是模式切换型为主、参数整定型为辅的方案。原因是纯参数整定在工况突变时容易产生参数跳变，引起执行器动作过大；纯模式切换又不够精细。两者结合，Agent先判断当前处于哪种工况模式，然后在该模式下微调参数，这样既有粗粒度的模式切换，又有细粒度的参数优化。

这里有一个很重要的设计原则：Agent的决策周期必须远大于PID的控制周期，否则两个环会互相干扰。我的经验值是至少100倍。PID控制周期100ms，Agent决策周期至少10秒。如果Agent决策太快，它会频繁修改PID参数，导致系统一直在过渡过程中，永远稳不下来。

3. 核心细节拆解：从PID调参到Agent决策的完整链路

3.1 PID层的实现细节与常见坑

先讲PID层。虽然大家都会写PID，但真正在真实系统里跑稳，有几个细节必须处理好。

第一个是积分限幅。很多人写PID只做输出限幅，不做积分限幅，结果系统一旦长时间存在偏差，积分项就累积到非常大，等偏差反向时，积分项需要很长时间才能退回来，导致超调巨大。我的做法是积分项单独限幅，限幅值取输出限幅的30%到50%。比如输出范围是0到100，积分限幅就设30到50。

第二个是微分项的处理。微分项对噪声极其敏感，真实系统里传感器噪声不可避免，微分项一放大，输出就抖得厉害。我一般会加一个一阶低通滤波器在微分项上，截止频率取采样频率的1/5到1/10。如果系统噪声特别大，干脆用不完全微分，或者直接用增量式PID避开微分项。

第三个是采样周期与控制周期的关系。采样周期必须小于控制周期，而且最好是整数倍关系。我见过有人采样周期10ms，控制周期15ms，结果每次控制用的都是不同时间间隔的数据，积分项和微分项算出来全是错的。正确的做法是采样周期5ms，控制周期10ms或者20ms，保证每次控制用的数据时间戳是规整的。

下面是我常用的一个增量式PID实现框架，用C写的，跑在STM32上：

typedef struct { float Kp; float Ki; float Kd; float target; float feedback; float error; float last_error; float last_last_error; float output; float output_max; float output_min; float integral; float integral_max; float integral_min; } PID_Handle; float PID_Compute(PID_Handle *pid) { pid->error = pid->target - pid->feedback; float delta_output = pid->Kp * (pid->error - pid->last_error) + pid->Ki * pid->error + pid->Kd * (pid->error - 2 * pid->last_error + pid->last_last_error); pid->output += delta_output; if (pid->output > pid->output_max) pid->output = pid->output_max; if (pid->output < pid->output_min) pid->output = pid->output_min; pid->last_last_error = pid->last_error; pid->last_error = pid->error; return pid->output; }

这个实现里，积分项是通过Ki乘以当前误差隐式累积的，增量式的好处是不需要单独处理积分饱和，因为输出本身有限幅。但要注意，增量式PID在目标值突变时输出变化会比较剧烈，所以目标值变化最好加一个斜坡函数。

3.2 Agent层的感知与推理设计

Agent层要做的事情比PID复杂得多。它需要感知的不只是当前温度值，还包括：

• 温度曲线的时间序列（过去5分钟、30分钟、2小时的趋势）
• PID的输出功率变化
• 环境参数（如果可测）
• 系统运行日志（有没有报警、有没有异常事件）
• 历史工况记录（之前类似工况下用了什么参数）

这些数据汇总之后，Agent需要做推理。推理的方式有两种路线：一种是基于规则的专家系统，一种是基于大模型的推理。我两种都试过，下面说说区别。

规则系统的优点是确定性强、响应快、可解释。比如我可以写一条规则：“如果过去10分钟温度标准差大于0.5度，且平均输出功率大于80%，则判定为系统增益变大，切换到低增益PID参数组。”这种规则跑起来很稳，但问题是规则覆盖不全，遇到没预设过的工况就抓瞎。

大模型推理的优点是泛化能力强，能处理没见过的工况组合。比如我把温度曲线、功率曲线、环境参数用自然语言描述给大模型，让它判断当前系统处于什么状态、建议怎么调整。实测下来，大模型在模式识别上确实比规则系统强，但有两个问题：一是推理延迟大，一次调用可能几秒到几十秒；二是输出不稳定，同样的输入可能给出不同的建议。

我最终的方案是规则系统做快速判断，大模型做慢速复核。规则系统每10秒跑一次，如果判断系统正常，就不调用大模型；如果判断异常或者处于模式切换边缘，再调用大模型做二次确认。这样既保证了响应速度，又利用了 compat大模型的泛化能力。

3.3 两个环的通信与协调机制

PID层和Agent层之间的通信，我用的是共享内存加消息队列的方式。PID层跑在实时任务里，Agent层跑在非实时任务里，两者通过一个环形缓冲区交换数据。

PID层每100ms往缓冲区写一条状态记录，包括时间戳、当前值、目标值、输出值、误差。Agent层每10秒读一次缓冲区，取最近100条记录做分析。Agent层决策完成后，往另一个缓冲区写一条指令，包括指令类型（修改参数/切换模式/调整目标）、指令参数、生效时间。PID层在每个控制周期开始时检查指令缓冲区，如果有新指令就应用。

这里有一个关键细节：指令生效时间要留缓冲。如果Agent在PID控制周期中间下发指令，PID可能正在用旧参数计算，突然切到新参数会导致输出跳变。我的做法是Agent下发指令时指定一个生效时间戳，PID层在控制周期开始时检查当前时间是否超过生效时间，超过才应用。生效时间一般设在下发后1到2个控制周期。

还有一个协调机制是优先级仲裁。如果Agent下发的指令跟PID的安全逻辑冲突，比如Agent要求输出100%但PID检测到温度已经超过安全上限，PID的安全逻辑优先。这个仲裁逻辑必须硬编码在PID层，不能交给Agent，因为Agent可能因为推理错误给出危险指令。

4. 实操过程：从零搭建一个PID+Agent控制系统

4.1 硬件与软件环境准备

我用的硬件平台是STM32F407加ESP32双核方案。STM32跑PID和实时任务，ESP32跑Agent通信和轻量级推理。两者通过UART交换数据，波特率921600。为什么不用一颗芯片全包？因为PID对实时性要求高，Agent对算力和网络要求高，分开跑互不干扰。

软件环境方面，STM32这边用FreeRTOS，PID任务优先级设最高，通信任务次之，日志任务最低。ESP32这边跑MicroPython，方便快速迭代Agent逻辑。大模型推理走HTTP请求到本地部署的模型服务，模型选的是7B参数级别的量化版本，跑在一台带GPU的工控机上，局域网延迟在50ms以内。

如果你没有GPU工控机，也可以用规则系统先跑起来，等验证了整体架构再上大模型。我一开始就是用纯规则系统跑了两个月，确认控制逻辑没问题之后才接入大模型。

4.2 PID参数整定与基线建立

在接入Agent之前，必须先把PID单独调好，建立一个基线。这个基线是Agent判断“系统是否正常”的参照。

整定步骤我一般这样走：

1. 先把Ki和Kd设为零，只留Kp。从小到大增加Kp，直到系统出现等幅震荡，记录此时的Kp为Ku，震荡周期为Tu。
2. 根据齐格勒-尼科尔斯法，Kp = 0.6 * Ku，Ki = 2 * Kp / Tu，Kd = Kp * Tu / 8。
3. 在这个基础上微调，先调Kp到超调可接受，再调Ki到稳态误差消除，最后调Kd到动态响应满意。

整定完成后，让系统跑至少24小时，记录温度曲线、输出功率、环境温度。这些数据就是基线数据。Agent的规则阈值就是根据基线数据的统计特征来设定的。比如基线温度标准差是0.15度，那规则里“温度标准差大于0.5度”就是一个合理的异常阈值。

4.3 Agent规则引擎的搭建

规则引擎我用的是JSON配置加C解释器的方案。规则写在JSON文件里，STM32启动时加载解析。每条规则包含条件、动作、优先级三个字段。

{ "rules": [ { "name": "high_gain_detection", "condition": { "std_dev_10min": {">": 0.5}, "avg_output_10min": {">": 80} }, "action": { "type": "switch_pid_group", "group": "low_gain" }, "priority": 10 }, { "name": "slow_drift_detection", "condition": { "trend_2hour": {"<": -0.3}, "integral_saturation": true }, "action": { "type": "adjust_target", "offset": 0.5 }, "priority": 5 } ] }

这个规则引擎每10秒跑一次，遍历所有规则，按优先级从高到低匹配。匹配到第一条就执行动作，然后跳出。如果没有规则匹配，就不做任何调整，保持当前PID参数。

规则的设计有几个经验：一是条件不要太复杂，两三个指标组合就够了，太多指标会导致规则难以维护；二是动作要幂等，同样的条件重复触发不应该产生累积效果；三是优先级要留间隔，方便后续插入新规则。

4.4 大模型推理的接入与提示词设计

大模型接入是在规则引擎跑稳之后做的。接入方式很简单：规则引擎判断需要大模型复核时，把当前状态序列化成一段文本，通过HTTP发给模型服务，模型返回建议，规则引擎解析建议并执行。

提示词的设计是关键。我试过很多版本，最终稳定下来的提示词结构是这样的：

你是一个工业控制系统专家。当前系统状态如下： - 目标温度：60.0度 - 当前温度：61.2度 - 过去10分钟温度标准差：0.8度 - 过去10分钟平均输出功率：85% - 过去2小时温度趋势：-0.1度/小时 - 当前PID参数组：default - 最近一次参数切换：30分钟前 请判断当前系统处于什么状态，并从以下选项中选择最合适的调整策略： A. 保持当前参数 B. 切换到低增益参数组 C. 切换到高增益参数组 D. 调整目标值 E. 其他（请说明） 请只输出选项字母和一句话理由。

这个提示词的关键是限定输出格式。如果不限定，大模型会输出一大段分析，解析起来很麻烦。限定成选项加一句话，解析就很简单，而且决策速度也快。

实测下来，大模型在模式识别上的准确率大概在85%左右，比纯规则系统的70%高不少。但大模型有5%左右的概率给出明显错误的建议，所以我在执行层加了一道安全检查：任何大模型建议的调整，如果会导致输出变化超过20%，就拒绝执行，转人工确认。

4.5 联调与现场验证

联调阶段我做了三组测试：

第一组是稳态测试，系统在恒定工况下跑48小时，看Agent会不会误触发调整。结果是规则引擎触发了3次，大模型复核后都建议保持，最终没有执行任何调整。这说明误触发率可以接受。

第二组是扰动测试，人为改变环境温度、改变负载、改变传感器读数，看Agent能不能正确识别并调整。这组测试里，规则引擎在扰动发生后10到30秒内触发，大模型在1到2分钟内给出建议，整体响应时间在可接受范围内。

第三组是长期运行测试，系统连续跑了30天，记录每次Agent调整的原因和效果。30天里Agent共调整了47次，其中规则引擎触发42次，大模型复核后执行了38次。调整后系统恢复稳定的平均时间是3.5分钟，没有出现震荡或失控。

现场验证阶段遇到的最大问题是网络延迟。大模型服务跑在局域网工控机上，正常情况下延迟50ms，但工控机偶尔会跑其他任务，延迟飙到2秒以上。这导致Agent决策周期从10秒变成12秒，虽然不影响稳定性，但响应变慢了。解决办法是给模型服务设了CPU亲和性和实时优先级，保证推理任务优先调度。

5. 常见问题与排查技巧实录

5.1 PID层常见问题速查

5.2 Agent层常见问题与排查

Agent层的问题比PID层更隐蔽，因为涉及推理和决策，不容易直接观察。我整理了几个典型问题：

问题一：Agent频繁切换参数组。现象是PID参数组每隔几分钟就切一次，系统一直在过渡过程中。原因是规则引擎的阈值设得太敏感，或者大模型复核不够稳定。解决办法是加一个切换冷却时间，比如两次切换之间至少间隔10分钟，除非系统出现严重异常。

问题二：Agent决策延迟导致响应不及时。现象是系统已经明显异常了，Agent还在等下一个决策周期。原因是决策周期设得太长，或者大模型推理太慢。解决办法是加一个紧急通道，规则引擎检测到严重异常时直接执行预设动作，不等大模型复核。

问题三：大模型给出矛盾建议。现象是同样的状态，大模型这次建议切换参数，下次建议保持。原因是提示词不够明确，或者模型本身有随机性。解决办法是降低模型温度参数，设成0.1或0.2，减少随机性；同时在提示词里加入历史决策记录，让模型参考之前的决策。

问题四：Agent和PID的安全逻辑冲突。现象是Agent要求增大输出，但PID的安全逻辑限制了输出，导致Agent反复下发指令。原因是Agent不知道PID的安全限制。解决办法是在Agent的感知数据里加入当前安全限制状态，让Agent知道哪些动作是被禁止的。

5.3 两个环协调的独家避坑经验

第一个坑是时间同步。PID层和Agent层跑在不同芯片上，如果时间戳不同步，Agent分析的数据时间轴就是乱的。我的做法是ESP32定期通过UART给STM32发时间同步信号，STM32收到后校准本地时钟。同步周期1分钟，精度可以做到10ms以内。

第二个坑是数据缓冲区溢出。PID层每100ms写一条记录，Agent层每10秒读一次，如果Agent层读取速度跟不上，缓冲区就会溢出。我的做法是缓冲区设成环形结构，写满后覆盖最旧的数据，同时Agent层读取时只取最近N条，不要求全量。

第三个坑是参数组切换的过渡处理。直接切换PID参数组会导致输出跳变，因为新旧参数算出来的输出可能差很多。我的做法是在切换时加一个渐变过渡，比如用5秒时间把参数从旧值线性插值到新值，这样输出变化就平滑了。

第四个坑是Agent的冷启动。系统刚上电时，Agent没有历史数据，规则引擎和大模型都无法做出准确判断。我的做法是设一个冷启动保护期，上电后前5分钟Agent不执行任何调整，只收集数据，5分钟后再开始决策。

6. 这套架构还能怎么扩展

这套PID加Agent的架构，本质上是一个分层反馈控制框架。PID是最底层的执行反馈环，Agent是上层的策略反馈环。这个框架可以继续往上叠，比如再加一个学习层，用历史数据训练一个模型来预测工况变化，提前调整Agent的策略。也可以往横向扩展，把多个PID回路的数据汇总到一个Agent，做多变量协调控制。

我目前正在试的一个方向是用Agent做PID参数的自整定。传统自整定方法需要注入阶跃信号或者继电反馈，对系统有扰动。用Agent的话，可以在系统正常运行中，通过分析历史数据来估计系统模型，然后在线优化PID参数，不需要额外扰动。这个方向还在验证中，目前的效果是参数优化后稳态误差能再降20%左右，但收敛速度还不够快，需要继续调。

另一个方向是多Agent协作。一个复杂系统可能有多个控制回路，每个回路一个PID，但回路之间有耦合。用多个Agent分别管各自的回路，Agent之间通过消息传递协调，这样比单个Agent管所有回路更灵活，也更容易扩展。这个方向我还没深入做，但架构上是可行的。

最后说一个实际体会：不要为了用Agent而用Agent。我见过一些项目，明明一个规则系统就能解决的问题，非要上大模型，结果延迟大、成本高、还不稳定。Agent的价值在于处理规则覆盖不了的复杂工况，如果你的系统工况简单、扰动模式固定，那PID加规则系统就够了。只有当系统需要跨时间尺度的推理和决策时，Agent才真正有价值。