反馈的回响：从振荡到 Agentic Engineering

1. 振荡

事情发生在去年，一个普通的工作日晚上。

我在用 CodeBuddy 改一个边界条件的 bug，逻辑不算复杂，就是少了一层判空。我把代码甩给它以后，它挺利索地给了一版修改，看着也合理，我还在心里夸了一句。跑测试——挂了，另外一个用例被牵连了。它又看了看，换了种写法，我觉得这下差不多了吧？再跑，还是挂，这次是边界用例过了，正常流程那边反而又出了问题。

然后它开始第三次改。我坐在那里看着它这一版的代码，忽然一阵恍惚——这代码我刚刚不是看过吗？仔细一比对，和第一版只差了一个变量名。它又跑测试，结果可想而知，还是挂。紧接着来的第四版，也是第二版的变体，几乎就是换了个表达方式把老方案又端上来了一遍。

我当时盯着屏幕，脑子里冒出来的第一个词不是 bug，不是“模型还不行”。是一个特别久远的词——振荡。

这个词估计好几年没在我的生活里正式出现过了。

我本科学的是自动化，研究生方向是控制理论与控制工程，后来转了软件开发。传递函数也好，Bode 图也罢，根轨迹画到最后那条往右跑的曲线到底是干嘛的，说实话我毕业两年就已经记不清了。你现在问我 s 域到 z 域是怎么变换的，我搞不好会一本正经地告诉你“好像跟星号有关系”，然后尴尬地笑一下。

可偏偏就是“振荡”这两个字，在那个晚上，像你翻旧抽屉时无意间摸到的一把锈钥匙，“咔嗒”一下就把一扇好几年都没动过的门给推开了。

那天以后，我就没法控制自己不用以前学的那些东西去打量 AI Agent 了。越看越觉得不对劲——不是“不对劲”那种不对劲，而是“太对了”那种不对劲。骨架一模一样，出毛病的方式也一模一样。

所以这篇文章想聊的东西其实挺朴素的。不是“控制理论有多伟大”——狂肝文献写毕业论文的日子已经走远。也不是“AI Agent 有多厉害”——目前 AI 浪潮的布道者多如牛毛不差我一个。

我就是想聊一种我自己经历过的、挺私人的感受——一种跨了好些年才听到的反馈回响：你以为已经丢掉的知识，会在若干年后，穿一身你完全认不出来的衣服，重新站到你面前。这一次它不在考卷上，不在实验室里，而是在 IDE 里，在一个会读代码、会跑测试、有时候还会跟你犟嘴的 Agent 身上。

真要把这件事讲明白，得先补两块底：

• 一块是控制理论到底在研究什么。
• 另一块是 AI Agent 到底是怎么干活的。

底子不打稳，后面的对应关系你看着会觉得是我在硬凑。底子打稳了以后，有些联系我其实不用说，你读到一半自己就会皱起眉头：等等，这个东西我是不是在哪儿见过？

2. 你其实早就会了

“控制理论”这四个字听着就劝退——又硬核又枯燥，好像只有穿白大褂、手边放着示波器的人才有资格谈论。

但事实上，你每天都在做“控制”，你只是不知道它叫这个名字。

2.1 洗澡就是控制

冬天洗澡，你一定经历过这样的场景：

打开花洒，水是凉的。你把热水旋钮往上拧了一下，等了几秒钟——哗，烫了。赶紧往回拧一点。等了一会儿，又有点凉。再拧一下……来来回回折腾了好几次，水温终于稳定在一个你觉得舒服的区间。

你可能不知道，你刚刚手动运行了一套经典的闭环反馈控制系统。

如果拆开来看，每个零件你都已经懂了：

• 你心里想要的水温（比如 40 度）= 参考信号（目标）
• 你皮肤实际感受到的温度 = 输出
• 目标与输出之间的差 = 误差
• 你的大脑根据误差做决策 = 控制器
• 你的手去拧旋钮 = 执行器
• 热水器+水管+混水过程 = 被控对象
• 皮肤温度感受并传回大脑 = 传感器

你看，这就是控制理论课本第一章那张图的现实版：

目标 → 比较 → 决策 → 执行 → 看结果 → 再比较

没什么玄乎的。

后来课程往里塞了拉普拉斯变换、传递函数、状态空间方程……到期末你可能满脑子都是怎么算特征根。但回头看，这张最朴素的框图才是整门课最值钱的东西。

因为它描述的是一种普遍存在的结构：

• 控制水温是这个结构
• 控制飞机高度是这个结构
• 控制化工反应器温度是这个结构
• 控制火箭姿态也是这个结构

差别只在方块内部，骨架是同一个骨架。

2.2 开环和闭环

上面的图里有一条特别关键的线：从输出绕回控制器的反馈线。

• 有这条线：闭环
• 没这条线：开环

什么是开环？

最便宜的定时洗衣机就是。你拧到 15 分钟，按下启动，它就嗡嗡嗡转满 15 分钟然后停。衣服洗干净没有？它不知道。中途停水了？它也不在乎。它只执行预设流程。

什么是闭环？

你手洗衣服：搓两下，看一眼。还有油渍？再搓。再看。直到干净为止。

开环和闭环差多少？

只要被控对象有一点不确定性（比如水压波动、衣服脏污程度不同、路面扰动），闭环就会把开环甩开很远。

你能把车开直，不是因为手腕角度天生精准到毫米级；是因为你一直在看路、一直在微调。

• 眼睛是传感器
• 大脑是控制器
• 方向盘是执行器

你每时每刻都在做闭环反馈控制，只是太自然了，以至于你不觉得这是“控制理论”。

2.3 稳定和不稳定

闭环并不天然安全。它有一个致命风险：

如果反馈后的纠正动作太猛、太急，系统不会稳定，反而会疯掉。

学骑自行车是最直观的例子：

• 不稳定：车往左歪，你猛往右打；又矫枉过正，车往右倒；再猛往左……最终连人带车扑街。
• 稳定：车轻微左偏，你轻轻右带一点；轻微右偏，再轻轻左带一点。每次修正幅度更小，最终收敛。
• 极限环振荡：不会摔，但一直固定幅度左右晃，不收敛也不发散。

为什么新手容易摔？

本质是增益太高（过度反应）。

偏 5 度，你纠 30 度。系统一定振。

后来学会了，其实不是你会了什么绝技，而是你“没那么慌了”：偏一点，纠一点。增益降下来，系统就稳了。

这在控制里叫“加阻尼”——不是让系统变笨，而是让系统别一惊一乍。

还有一个隐蔽杀手：延迟。

洗澡拧旋钮后，水温不会立刻变。热水要在管道里走一段时间。

你要是太急，2 秒没反应就继续拧，等热水真正到花洒时，早就过头了。然后你又猛拧回去，又过头。于是振荡。

延迟 + 过度反应，基本就是振荡温床。

控制理论几十年的核心问题之一，其实就一句话：

怎样让闭环系统稳定、快速、准确地到达目标，而不是振荡、发散，或者原地打转。

我当年学的时候，对这句话感受并不深。直到我在 AI Agent 身上看到一模一样的症状。

3. AI Agent 是什么

控制理论这边先放一下，另一边也要讲清：AI Agent 到底是什么。

“Agent”这两年被说得太多，反而容易越说越虚。

有人说它是 ChatGPT 套壳，有人说它是高级脚本，也有人把它当“无所不能数字员工”。这些都沾边，但都不够准确。

要看懂 Agent，必须拆开看。

3.1 大模型只会说话

你让纯聊天模型“帮我改第 42 行 bug”，它会告诉你“可以改成这样”。

但它不会真的：

• 打开你的文件
• 找到第 42 行
• 改掉
• 跑测试验证

它像一个知识渊博但没有手的人。

3.2 给大模型装上手脚和眼睛

Agent 做的事，说白了就是给大模型装上眼睛和手。

• 大脑（LLM）：分析、推理、决策
• 眼睛（观察能力）：读文件、看日志、看测试输出
• 手（执行能力）：改文件、跑命令、调接口

三件东西接上之后，Agent 就从“会建议”变成了“会执行”。

3.3 Agent 的工作循环

修 bug 时，Agent 通常这样循环：

1. 看：读代码和上下文
2. 想：分析问题与策略
3. 做：修改代码
4. 再看：跑测试拿反馈
5. 再想：根据反馈继续修正

这不是一锤子买卖，而是循环。

中等复杂问题跑 5～6 轮很常见，10+ 轮也不少见。

你看着它一轮轮“读-改-测”，看到后面会有种既视感：

这不就是“看结果、比目标、调动作、再看结果”的闭环吗？

4. 那个熟悉的循环

把控制系统和 Agent 系统并排，你会发现标签可以一一对应：

• 用户需求（修 bug）= 目标
• 代码/测试结果 = 传感器反馈
• 结果未达标 = 误差
• LLM 决策 = 控制器
• 工具执行（改代码/跑命令）= 执行器
• 代码库与运行环境 = 被控对象

我第一次把这两张图放在一起时，脑子里两种声音同时响：

• “太巧了吧？”
• “这不巧，维纳 1948 年就讲过了。”

《控制论》副标题是：

关于在动物和机器中控制和通信的科学。

七十多年前的“机器”是蒸汽机、继电器、真空管；今天是会读代码、会调用工具的 Agent。外壳变了，骨架没变。

这件事真正有价值的地方是：

控制理论已经花了半个多世纪研究这类系统会怎么坏、怎么诊断、怎么治理。

Agentic Engineering 还年轻，很多坑正在重新踩。既然前人修过路，就没必要拿砍刀再去灌木丛里硬开一条。

下面就聊几个我自己最有感、最能落地的对应点。

5. 为什么 Agent 会绕圈

回到开头：A 不行改 B，B 不行改回 A，再改回 B……

这就是 Agent 最常见、也最让人抓狂的失效模式之一。

看起来很忙，日志刷很快，文件改很多，但没有推进，只有打转。

控制理论里它叫：振荡。

5.1 增益太高，或者反馈太慢

振荡常见两因：

1. 反应过度（增益太高）

   • 小 bug，本应最小改动
   • 结果它重写半个函数
   • 新问题被引入，下一轮再大改
   • 越纠越乱

2. 反馈延迟

   • 一口气改三个文件才跑测试
   • 测试失败后，定位不到是哪个文件引入问题
   • 只好三个都重改，连本来正确的也一起破坏

5.2 怎么治

控制理论药方叫“加阻尼”。翻译成智能体工程，两句话：

• 别改太猛
• 别太晚才看反馈

落地就是：

1. 每次改动尽量小（改一行验一行）
2. 每一步都验证（lint/test 过了再继续）

我后来给 Agent 配过一条很土但有效的规则：

每次编辑后必须跑验证，过了才能继续下一步。

振荡确实少了很多。

5.3 怎么判断当前状态

Agent 行为大体就三种：

• 收敛：未通过测试数稳步下降（5→3→1→0）
• 振荡：A/B 来回切，指标上下波动
• 发散：修一个引入三个，越来越糟

最实用的方法：盯一个可量化指标。

比如“还剩几个测试没过”。

• 稳步下降：继续
• 来回抖动或增大：大概率该介入

5.4 什么时候该拔电源

不是所有系统都能自恢复。

有些时候必须人工介入：

• 设最大尝试次数（例如 8 轮）
• 超限就停，人工接管
• 对删除文件、改数据库、改接口契约等高风险动作做人工确认

这就是控制系统里的：

• 安全限幅
• 安全联锁

我见过不设限地跑 30+ 轮，最后代码“亲妈不认”。还不如第 5 轮就停下来重来。

6. 积分饱和：为什么聊太久 Agent 就废了

这里讲一个我觉得很精彩的对应：PID 里的积分项（I）和长对话上下文退化。

6.1 积分是干什么的

P 盯“偏了多远”，I 盯“偏了多久”。

比如定速 120，实际总是 118。

如果只靠比例，你会永远差一点。积分会把这段“长期偏差”记账并累计，逼控制器持续补偿，最终把稳态误差抹掉。

6.2 记忆太多，也是一种病

积分有个经典毛病：积分饱和（Integral Windup）。

误差长期存在但执行器受限时，积分项会不断积累。约束解除后，积分一下子把输出推得过猛，系统过冲并振荡。

6.3 Agent 也会“饱和”

你可能也经历过：

• 前几轮很清晰
• 十几轮开始偶尔忘事
• 二三十轮后前后矛盾、把已否决方案搬回来

这和积分饱和不是数学上完全同构，但机制相通：

历史信息积累过多，反过来干扰当前决策。

上下文窗口里堆了太多“过时路径、失败方案、噪声讨论”，注意力就被稀释。

6.4 anti-windup 在 Agent 里的对应

控制里 anti-windup 的思路：限制、压缩、清零。

Agent 对应动作：

• 开新对话（硬清零）
• 做摘要（压缩有效历史）
• 选择性遗忘（只留当前相关）

这不是玄学，是系统治理。

最近半年又出现了更细腻的做法：记忆分层。

• 当前会话热状态
• 跨会话偏好与约束
• 长期项目知识

多时间尺度管理，不再把所有历史硬塞同一个窗口。

从控制论视角看，这就是“快变量与慢变量分离管理”。

7. 睁眼骑车和闭眼骑车

这一节讲一对双胞胎概念：可观性与可控性。

7.1 可观性

调试 Agent 最痛的场景：结果错了，但你不知道它为什么错。

这像闭着眼骑车：

• 只看到摔倒结果
• 看不到偏航过程

可观性就是：

能否通过输出推断内部状态。

• 只给最终结果的 Agent：可观性低
• 暴露中间日志、工具调用、思路轨迹的 Agent：可观性高

实操建议：

• 看中间思路与调用链路
• 看每一步工具输入输出
• 看命令执行日志

你看的中间状态越多，调试越稳。把眼睛睁开。

7.2 可控性

如果自行车车把锁死，你再会骑也到不了目标路径。

Agent 同理：

• 想查 DB，但没有 DB 工具
• 想部署服务，但没有 SSH 权限

这不是模型不聪明，是系统缺控制维度。

这也解释了 MCP / Function Calling 为什么关键：

它们本质是在给系统增加可控自由度。

可观但不可控，你只能“干着急”；可控但不可观，你在“盲开黑盒”。两者都要有。

随着 2025 年后 Agent 开始具备更强界面操作能力（浏览器点击、表单提交、支付流程触达），可控性上升的同时，风险半径也急剧变大。

所以“什么时候该拔电源”不再是建议，而是硬约束。

敏感动作（登录、支付、验证码）的人机切换，本质上就是安全联锁。

8. 下棋和开环

这个概念不是解释 Agent 为什么坏，而是解释 Agent 应该怎么工作。

下棋时，人不会一次性算完整盘。通常是：

• 往前推几步
• 选当前最好一步
• 对手落子后再重算

这就是“滚动规划”。

早期不少 Agent 是开环的：一口气生成大改动，中间不验证。

好的 Agent 是闭环的：

• 改一步
• 验一步
• 根据反馈重规划

这和控制里的 MPC（模型预测控制）几乎同构。

MPC 核心四字：滚动规划。

• 预测几步
• 只执行一步
• 基于新反馈再预测

预测窗口也要调：

• 太长：远期不准，易空转
• 太短：只顾眼前，易局部最优

我的体感：中等复杂任务，想 3～5 步、每次落 1 步，是比较稳的节奏。

9. 我的调参心得

前面讲了很多概念，最后落回地面，给几条我最常用的实操经验。

9.1 System Prompt 像 PID 调参

• 规则太严太多：过度阻尼，谨小慎微、效率低
• 规则太松太少：欠阻尼，风格漂移、风险增大

没有万能参数，只有按项目整定。

9.2 振荡时先加阻尼，不先换模型

让它每改一次都先验证。

很多时候比盲目换模型有效。

9.3 发散时别硬补上下文

越改越离谱时，不要执念“再补一点上下文就好”。

通常该做的是：开新对话，重置并重讲问题。

9.4 做不好先查可控性

某事反复失败，先检查它是不是缺工具/权限，而不是先怀疑你提示词措辞不够优雅。

方向盘没装上，教驾驶技巧没意义。

9.5 调试先诊断，再动手

先看中间轨迹，判断到底是：

• 理解歪了
• 推理跳步
• 工具调用参数错了

这三类问题修法完全不同。

不诊断就改，等于闭眼骑车。

---

上面五条是我最早攒下来的“战术手册”。

但到了 2026 年再回看，我越来越觉得只靠战术不够。

它们像一抽屉创可贴，每片都好用，但你不能把创可贴叫做医疗体系。

这一年 Agent 生态变化太快了，快到“只会救火”已经不够。我们需要的是系统化能力。

9.6 从 Prompt Engineering 到 Context Engineering

过去我更关注“怎么措辞 prompt”。

现在我更关注“在正确时机给 Agent 正确信息”。

因为真正驱动决策的，不只是 prompt，而是整个上下文信号流：

• 系统指令
• 历史对话
• 文件内容
• 工具返回
• 摘要信息
• 外部知识注入

控制器参数再漂亮，信号脏了、噪了、过载了，输出一样会坏。

从控制论视角，这对应的是：

• 早期只看输入输出（传递函数）
• 现代开始管理系统内部状态（状态空间）

Prompt engineering 到 context engineering，本质上也是这一步升级。

9.7 Skill 与 Rules：从个人技巧到可复用控制策略

我越来越把 Skill 看作“整定好的参数组”。

• Rules：常驻基线策略（底线约束）
• Skill：面向任务的专用流程（场景切换）

两者配合，才是一套像样的控制体系。

9.8 Skill 市场：参数共享库

社区 Skill 平台的意义，不只是“方便下载”。

它更像控制工程里的参数手册：

• 前人调好的经验可复用
• 你拿来做二次整定
• 比从零开荒更快更稳

当然，别人的参数不一定完全适配你的被控对象，但“有起点”远好于“白纸起步”。

9.9 MCP：统一接口是基础设施

没有标准接口时，接工具是胶水地狱：

• 每家接口不一样
• 每次都写适配
• 平台一换全重来

MCP 的价值在于标准化：

• 给 Agent 与工具的交互定义统一规约
• 增强可拼装性与可迁移性
• 显著降低扩展成本

它本身不让模型更聪明，但会让系统更工程化。

10. 结语

有时候我会想，如果维纳还在，看到今天这些会读代码、会跑测试、偶尔还会跟你较劲的 Agent，大概不会太惊讶。

他也许会翻开 1948 年那本书，指着副标题说：

靠反馈来调节行为的系统，骨架都差不多。

从洗澡调水温到火箭姿态控制，再到 AI 写代码，七十多年过去，有些底层规律几乎没变。

稳定性不是白来的，是设计出来的。

你看不到的东西，你管不了。

你管不了的东西，叫爱好，不叫工程。

但写这篇文章最触动我的，其实不是“控制理论能解释 Agent”。

而是另一种更私人的感受：

你以为已经与人生无关的知识，会在很多年后、一个你完全想不到的场景里重新出现。它不打招呼，也不解释自己，就这么站在你面前。

当年为了考试死记硬背的那些东西，有一天会变成你理解新世界的钥匙。

控制论这次穿上了 Agentic Engineering 的衣服。

如果你也是从别的专业转来做软件的人——机械、电气、化工、土木，或者别的——也许可以偶尔翻翻旧课本。

在这个人人都喊“全新赛道”的时代，那些旧知识未必是行李，也可能是一副只有你自己戴得上的眼镜。

透过那副眼镜，你看到的世界，至少会多一个维度。

---