企业官网建设流程全解析

这些天我一直在想一个挺拧巴的问题：AI Agent 明明脑子越来越聪明，为什么干起活来总是让人提心吊胆？写文案、写代码、查资料单看都是高手，可一旦放进真实业务里跑上一阵，要么链路级联崩溃，要么同一个任务不同上下文里表现忽好忽坏，要么并发一大直接“薛定谔的响应”。我见过太多团队耗费大量精力在提示词上打磨，结果换一个模型版本就前功尽弃。

后来我把注意力转向了一个看起来八竿子打不着的领域——控制论。这些年做 Agent 工程踩坑踩下来，我越来越认同一个判断：让 AI Agent 从“脆弱的聪明”走向“鲁棒的稳定”，本质问题不是“更聪明的模型”，而是“更完整的回路”。控制论里的 PID 控制、自抗扰控制（ADRC）这些经典思想，恰恰是当前 Agent 架构里被严重低估的一类解法。这篇内容我想把这些天从 PID 调到 ADRC 的思考、实验和踩坑记录整理出来，给正在被 Agent 可靠性折磨的团队一个不同的思路切口。

1. 为什么“聪明的 Agent”常常在最简单的事情上翻车——可靠性危机的三种典型样貌

动手调控制策略之前，先得给问题画像。我接触过的 Agent 可靠性事故，大部分逃不出下面三种模式，而且它们往往是叠加出现的。

1.1 级联放大：一步错，步步错，还带自增强

第一种样貌最典型：Agent 在执行多步任务时，前面某一步产生了偏差，这个偏差没有及时被纠正，就顺着工具调用链一路放大。拿一个简单的“AI 助理自动填报报销单”场景来说，第一步解析票据金额就错了，第二步填表时自然跟着错，第三步校验环节如果 Agent 没有“质疑数据”的机制，它甚至会反过来编造一个“看起来合理”的理由把错误洗白。最可怕的是，这种错误往往不是随机噪声，而是单一偏差被 Agent 自身的生成倾向不断自洽化、合理化。

这不是模型能力问题。你让模型单独做每一步，准确率可能都在 95% 以上，但 0.95 的十次方只有 0.6 左右。这一步的误差没人纠正，下一步就在错误基础上继续推演，这就是典型的开环系统误差累积。传统的软件工程里我们有单元测试、断言、类型检查来阻断偏差，但 Agent 系统里这些手段大多失效了，因为每一步的输出是自然语言，语义正确性很难用刚性规则卡住。

1.2 数据漂移：模型能力没变，系统行为却变了

第二种样貌更诡异：代码没动，模型版本没动，Agent 的行为却在一段时间内越来越偏。上周还稳定执行的流程，这个星期开始频繁返工。

原因也很现实：Agent 依赖的外部环境一直在变。上游 API 返回结构微调了、知识库新增了一批文档改变了检索分布、用户输入模式随季节变化（做电商的应该深有体会），这些外部变化对 Agent 来说都是“扰动”。开环系统对扰动天生没有抑制能力，所以一点点外部扰动都会被如实传递到输出端。控制论里把这种问题叫抗扰性不足。咱们做 Agent 的同事往往只盯输入输出，不太会想到要在“扰动通道”上做文章。

1.3 并发压力：并发一上来，延迟和错误率一起失控

第三种样貌是工程层面的，也是搜索热词里“AI Agent 怎么扛并发”能火起来的原因。当一个 Agent 服务被放到高并发环境里，问题会比普通 Web 服务复杂得多：Agent 每一步都是多轮生成式调用，资源消耗高、时间不确定性强；多个用户请求之间还会共享外部限流配额、共享检索服务、共享上下文缓冲。

这时候我们习惯用的“扩容大法”会失灵——因为瓶颈往往不在单机 CPU，而在外部依赖的配额和生成式推理的延迟方差。结果就是，压力一大，错误率和延迟同时飙升，触发了重试，重试又加剧了排队，排队又抬高了延迟，形成正反馈。这就是一个活生生的控制回路失稳问题，只不过我们用错误率曲线画出来时，常常没意识到它是经典的控制论研究对象。

2. 控制论视角下的 Agent 治理：先闭环，再谈智能

面对这三种样貌，我一开始的反应和大多数工程师一样：继续堆提示词、加验证规则、换更强的模型。后来真正让我扭转思路的，是把 Agent 运行过程画成一张控制系统的框图。

2.1 开环与闭环：Agent 当前的主流架构其实是开环的

大多数 Agent 应用的标准架构是：用户输入打入 LLM，LLM 决策调用什么工具，工具返回结果再喂回 LLM，如此循环直到任务结束。很多人觉得这个过程有反馈——毕竟工具结果确实“返回”了。但从控制论的角度，这仍然是开环的，因为这条链路上缺少一个独立的“期望值”通道。

什么是闭环？得有一个明确的参考输入 r(t)，一个传感器实时测量被控量 y(t)，然后用 e(t)=r(t)-y(t) 这个偏差去驱动控制量 u(t)。而现在的 Agent 循环里，谁来定义“这轮迭代输出的质量期望”？谁在实时测量当前输出和期望之间的差距？没人。LLM 自己既当执行器又当测量器，裁判员和运动员是同一个人。

这正是“脆弱的聪明”的根源：模型靠内部隐式的自回归能力在维持“貌似合理”，但系统层面缺乏显式的偏差检测和校正机制。一旦偏差出现，没有独立于执行机构的传感器去发现它，整个系统就表现得像一辆没有仪表盘、没有方向盘纠偏、闷头向前开的车。

2.2 PID 的三项语义：比例、积分、微分在 Agent 系统里各司其职

引入闭环之后，控制器的设计就可以直接借鉴经典的 PID 控制。PID 的控制量由三部分构成：比例项 Kp·e(t)、积分项 Ki·∫e(τ)dτ、微分项 Kd·de/dt。我们家做嵌入式控制器的同事一听就懂，放在 Agent 系统里其实也不难对应：

• 比例项（P）对应“即时纠偏”：Agent 当前这一步的输出和预期质量目标相差多少，立刻决定下一步动作的调整强度。差得多就大幅调整（比如增加一次反思、降低温度、换一个更保守的工具），差得少就微调。
• 积分项（I）对应“历史误差的积累修正”：如果一个 Agent 在过去若干轮里持续性地出现某种偏差（比如总是检索过量的信息、总是生成过于冗长的回复），积分项会累积一个“系统性修正力”，即使某一瞬间的误差看起来不大，也会持续施加反向作用。
• 微分项（D）对应“趋势预测与抑制过冲”：如果当前输出正在以很快的速度偏离目标（误差变化率为正且大），微分项会提前发力，抑制进一步偏离；反过来，当偏差已经收窄但还在快速归零时，微分项会防止修正过头，避免系统在目标值附近来回震荡。

对应到 Agent 工程实践上：P 项像是一次失败的自动重试机制；I 项像是一个跨轮次的记忆惩罚因子，专门对付反复出现的同类型错误；D 项像是趋势检测器，在错误彻底爆发之前就踩刹车。这三个维度的数学表达是同一个公式，但工程语义立刻清晰了。

2.3 为什么说“反馈”是 AI Agent 可靠性的第一性原理

把 PID 放到一边，核心的第一性原理其实是反馈。没有反馈，就没有可靠性讨论的基础。系统狡辩说“我有工具返回结果”这是不够的，因为那个结果是给 LLM 的上下文，不是给控制器的测量信号。反馈的关键在于独立，独立的测量通道、独立的偏差计算，最终转化为独立于模型生成倾向的校正动作。

这也能解释为什么业界的 Agent 测评总给人一种“测试时候天下无敌，上线时候一塌糊涂”的错觉：测评集是静态标注的，相当于在实验室里测开环特性；上线环境是动态扰动的，拼的是闭环鲁棒性。一个系统的鲁棒性不是靠测试覆盖堆出来的，而是靠反馈结构设计出来的。理解了这一点，再看当前 Agent 技术栈里的“自反思”“自我纠错”机制，你会发现它们大多还停留在“用同一个模型做反思”的半闭环状态，离真正意义上的控制回路还差着一个独立的测量环节。

3. 从 PID 跳到自抗扰控制（ADRC）：控制论里更适合 Agent 的方案

PID 虽然经典，但直接在 Agent 系统里套用，很快会遇到三个绕不开的短板。这也是我后来转向自抗扰控制（Active Disturbance Rejection Control，ADRC）的原因。

3.1 PID 在 Agent 场景下的三个短板

第一个短板是误差信号难以定义。经典 PID 直接使用参考值与测量值的差，要求被控量是数值、可测、可比较。但 Agent 的输出是自然语言、工具调用序列、甚至长期规划，怎么量化“这一步做得有多差”？当然可以设计分数量化器、用另一个模型打分，但这本身又是一层噪声。

第二个短板是积分饱和与超调之间的两难。I 项能消除稳态误差，但累积过头了会导致“刹车失灵”——Agent 被过去的错误记忆强烈拉拽，即使当前已经恢复正常，还在继续加大纠正力度，导致行为变得迟钝、倒退。如果你把“重试次数”当作 I 项来调，很容易出现一次小错误触发连续三次重复尝试的过度反应。

第三个短板是对抗动没有显式建模。PID 本质上是被动抵抗：扰动进来之后，先造成误差，然后控制器才反应。对 Agent 这种高延迟、高方差的系统，被动的“先错后纠”代价太高了，一步错了可能就引发级联放大。

3.2 ADRC 的核心思想：不研究扰动是什么，直接观测并补偿

自抗扰控制由韩京清先生提出，核心哲学是：不要花精力去精确建模扰动，而是把系统模型里所有“说不清楚的部分”（未建模动态、外扰、参数变化）统统视为“总扰动”，用一个扩张状态观测器（ESO）去实时估计它，然后在控制量里直接补偿掉。

这个思路放在 Agent 场景里简直是量身定做。Agent 系统的扰动种类繁复杂乱，上游接口波动、用户输入变化、模型本身的不确定性、知识库分布漂移，每一个都精确建模费时费力且不现实。ADRC 的做法是：管你是什么扰动，只要它反映到被控量的变化上，我就能观测到它的等效值，然后反向补偿。这就把一个“模型依赖”的可靠性问题，变成一个“观测能力”的问题。

ADRC 手里的三板斧：**跟踪微分器（TD）**负责安排过渡过程，给系统一个平滑的目标轨迹，避免设定值突跳引起的超调；**扩张状态观测器（ESO）**负责同时估计系统状态和总扰动；**非线性状态误差反馈（NLSEF）**负责用非线性配置来抑制误差。三者的配合比 PID 多了一个“观测器”维度，这是最大的区别。

3.3 ESO（扩张状态观测器）如何映射到 Agent 的“实时状态评估”

把 ESO 翻译成 Agent 工程语言，我习惯把它理解为一个独立的监控评估模块。它观察的对象不是用户的原始输入，而是整个系统在运行过程中的“状态轨迹”：任务走到了哪一步、当前产出和任务目标的偏差有多大、外部反馈指标（延迟、接口错误率、用户纠正率）在怎么变。

ESO 最巧妙的地方在于：它不仅输出当前状态的估计值，还额外输出“扩张状态”——也就是总扰动的估计值。在 Agent 场景里，这个扩张状态可以解释为“当前环境的不可靠程度”：比如某个上游 API 的失败率突然升高、检索结果的匹配质量突然变差，这些都可以被 ESO 观测成一个等效的“环境扰动值”，然后直接用来调整 Agent 的行为策略，比如自动降低对低质检索结果的采信权重、提前切换备用工具链。

这种做法的工程好处是无需精确知道扰动源头。不用写一堆规则去枚举“如果 API X 超时怎么办”的 if-else，只需要一个观测器感知到“整体输出质量在偏离”，就把补偿量叠加到控制策略里。我在实验里把这套机制做成了一个“旁路评估器”，用一个小模型对 Agent 每步输出打质量分，同时用一个滑动窗口计算外部指标，两个信号一起喂给一个简化版的 ESO，效果比单纯堆提示词要稳得多。

4. 把控制论落到 Agent 工程：一套可复现的分层治理回路

理论聊完，讲讲怎么落地。我的实践思路是把控制回路分三层来设计，每一层都有明确的“被控量、传感器、控制器”，越往上关注越宏观。

4.1 层次一：单 Agent 内反馈——把每次工具调用的结果“闭环”回来

第一层是粒度最细的回路，发生在单个 Agent 执行一次任务的过程中。

• 被控量：当前离线任务步进的质量评分（语义完成度、工具返回有效性、上下文一致性）。
• 传感器：一个独立的评估器（可以用一个小参数模型或者规则+模型的混合器），它对每次 Agent 输出进行打分，而不是让 Agent 自己评自己。这里“独立”很重要。
• 控制器：根据偏差 e(t) 的大小，决定下一步动作：偏差小则继续执行；偏差中等则增加一次带结构化反馈的“反思”步骤；偏差大则触发工具切换或回溯到上一个确定正确的状态。

我在具体项目里用 LangGraph 实现过这个回路。关键点在于把评估器节点独立出来，它不参与生成，只产出偏差信号；然后有一个专门的“决策节点”读取偏差信号，决定接下来的图路径。这个结构和传统的“Agent 反思”完全不一样——反思是让 Agent 自己看着自己的输出找毛病，而这里是系统层面的控制器在决定要不要反思、反思的强度多大。两者之间有本质区别，就像让运动员自己在赛场上当裁判 vs 场外有独立的计时和速度传感器。

4.2 层次二：Agent 间协同——用“串级控制”消除子系统波动

当任务要被拆给多个子 Agent 协作完成时，单回路不够了。子 Agent 之间会互相传递中间产物，如果每个子 Agent 都有各自的波动，波动就会在交接处叠加放大。我在这个层面采用的思想是串级控制（Cascade Control）：内环负责快速抑制局部波动，外环负责慢速但更精确地校正整体偏差。

具体做法是：每个子 Agent 先用自己的内部反馈环保证单步质量（内环），同时总控 Agent 在下发下一步任务时，会根据“当前整体任务预期状态”和“实际已经完成的状态”计算偏差，对子 Agent 的输出进行修正（外环）。例如：分析 Agent 负责整理文档摘要，生成 Agent 负责写报告，当总控发现分析 Agent 的摘要密度过高时，不会直接打断它，而是在生成 Agent 的任务指令里附加一条“注意：前序摘要存在密度偏高的问题，请适当扩展背景信息”——这就是外环通过修正参考输入来抑制内环无法消除的偏差。

串级控制的经典好处是：内环把高频扰动就地消化，外环专注低频校正，系统带宽大大提升。映射到 Agent 场景，就是局部小扰动不会一路传导到任务末端才被发现，而是在交接点就被外环校正掉了，级联放大被结构性阻断。这一层对“多 Agent 协作类”可靠性问题尤其管用。

4.3 层次三：系统层面——把“容量控制”当 PID 环来做

回到热词里“AI Agent 怎么扛并发”这个问题，我的控制论解法是：把并发治理也看成一个反馈控制问题。

• 被控量：系统整体吞吐率 / 平均任务完成质量 / 排队长度。
• 参考输入：目标吞吐率 L（比如每秒 10 个任务完成）。
• 传感器：实时测量当前吞吐率、SLO 达成率、外部依赖限流剩余配额。
• 执行器：动态调节最大并发数、请求排队策略、重试退避参数、甚至降级开关。

常见的限流算法（令牌桶、漏桶）本质上是一个开环控制：按预设速率放行，不关心实际完成率。但如果外部依赖变慢了，同样的入口速率会导致排队堆积、延迟飙升，最终吞吐率掉下去。正确的做法是用吞吐率误差 e(t)=L−y(t)去动态调整入口并发上限：误差为正（完成率低于目标）时，适当降低并发、减少对脆弱依赖的压力；误差为负（系统有富余）时，再稳步放量。

这里“稳步”两个字很关键。直接把并发从 100 跳到 300，十有八九会过冲——这正是 PID 里微分项要抑制的东西。我在项目里用了一个带积分限幅的简单 PI 控制器来调节并发数：比例项快速响应吞吐率下滑，积分项记住持续的压力缺口，两者相加得到当前允许的最大并发上限。实测在外部依赖慢了一半的情况下，任务完成率维持在目标的 90% 以上，而非用固定限流时直接跌到 40%。这类容量控制的详细调参经验，之前整理过一篇更偏工程的记录，这篇文章里不展开。

4.4 实操中的调参经验与工具选型

控制算法再好，放在 Agent 系统里调参不当也会翻车。我分享几个实操中总结出来的经验：

• 评估器的稳定性优先于准确性。作为“传感器”的评估模型不需要非常精准，但它本身的方差不能太大。一个偶尔打错分的评估器，比一个稳定但略偏的评估器破坏力更大——因为噪声会通过控制器传递成 Agent 行为的抖动。我一般会先跑 200 条历史样本看评估器评分的方差，方差过大会先做平滑。
• 积分限幅必须做。给 I 项加一个上下限，防止历史错误过长时间地惩罚当前行为。对应到工程实践，就是“最近 N 轮的负面记忆”才参与纠偏，超过窗口的直接忘掉。这是一个很小的改动，但对 Agent 行为稳定性的改善非常明显。
• 控制器决策周期要匹配 Agent 执行周期。Agent 一步可能要 5 秒、10 秒甚至更久，反馈控制周期必须大于或等于这个执行周期，不能用机器控制里那种毫秒级调度的思路。在上面提到的容量控制例子里，我的 PI 控制器是每 30 秒算一次误差更新一次并发上限，太频繁反而会带来震荡。
• 工具链选型：我推荐 LangGraph 这类支持显式状态图和人为干预节点的框架——因为它天然适合“控制器作为独立节点插入大循环”的架构；评估器可以用 FastAPI 包装成一个独立服务，方便复用和替换模型，具体的 FastAPI + LangChain 集成方案网上也有不少现成模板可以参照。

5. 我的实践经验与边界：控制论不是万能的，但很可能是被低估的

任何方法都有边界，控制论在 Agent 领域也不例外。我踩过的坑和总结出来的适用范围，这里一并说清楚。

5.1 踩过的坑：把 I 项调太大，Agent 反而变得迟钝

最早尝试 PID 风格纠偏时，我犯过一个很典型的错误：为了让 Agent 记住过去的错误，我把“历史错误记忆”的权重调得很大，相当于积分项过强。结果系统确实不再重复犯某几类旧错，但整体行为变得极度保守，面对新场景时倾向于照搬过去成功过的旧路径，不愿尝试新方案，任务的通过率反而下降了。

这其实就是经典 PID 里“积分饱和导致执行机构饱和”的翻版。在传统的直流电机调速里，积分饱和会让执行器输出顶到极限；在 Agent 里体现为“记忆太顽固、探索太少”，行为曲线变得僵硬。我现在对任何一个“记忆类”机制都会问：你这里是不是在实现 I 项？如果是，那你有没有做限幅和遗忘窗口？没有的话，注定会在某个时间点开始退化。这个问题很多人花了大量精力在调 prompt、调记忆策略，却不知道自己在调 PID 的积分项。

5.2 控制论能解决什么、不能解决什么

先把话撂明白：控制论解决的是动态过程中的稳定性、鲁棒性和跟踪性能问题，它解决不了单点能力天花板问题。如果 Agent 核心模型的语义解析能力本身太弱、或者知识库里根本没有正确答案，任何控制回路都没法让它输出正确结果——这就像 PID 并不能让一辆发动机烂掉的车跑出赛车速度一样。

但反过来看，大部分团队遇到的可靠性问题，其实是混沌问题而非能力问题：系统不稳定、对环境敏感、误差级联放大、并发一高就崩。这些恰恰落在控制论射程之内。我甚至觉得，很多“调 prompt 无效”的场景，问题的根因根本不是提示词内容，而是整个运行过程缺少反馈结构，导致语言模型固有的随机性和外部扰动被完整放大了。

控制论能给的是一套显式的动态系统设计方法：定义被控量、装传感器、设计控制器、调带宽和阻尼。这套方法论比经验性的“加个反思、加个校验”要系统得多，它的收益不是某一步骤偶发提升，而是整个系统的行为曲线被矫正，方差和偏置一起降下来。

5.3 这套思路适合谁，适合什么场景

如果你们的场景是：

• 长链路任务（>5 步工具调用），且对中间结果的正确性敏感；
• 外部依赖多、波动大（API 限流、数据漂移、模型切换）；
• 多 Agent 协作，子模块之间相互传递中间产物；
• 高并发入口，对吞吐率和延迟方差有硬性要求的线上服务。

那我觉得非常值得引入控制论思维。反之，如果场景只是“单轮问答机器人”“一次性文本摘要”这种闭环需求不强的应用，直接上控制回路属于过度设计，不如把精力放在模型选择和数据质量上。

这几年我最大的感受是：AI Agent 工程正在从“堆模型能力”的阶段，转向“做动态系统”的阶段。当模型本身的技术红利逐渐趋平，系统的控制结构会成为可靠性的分水岭。而控制论这个看起来“古老”的学科，恰恰提供了一套现成的、被工业界验证了几十年的方法论。它不是万能的，但很可能，是当前 Agent 可靠性困境里最被低估的一块拼图。

最后分享一条个人体会：无论用什么控制策略，都一定先在离线环境把“传感器—控制器—执行器”这条回路描清楚，再让它上线。控制回路最怕的是回路断了还自以为闭环着——那比没有反馈更危险，因为它会给你一种虚假的安全感。