--- title: "从维纳到 Claude Code：控制论如何在 AI Agent 时代复活" author: deletexiumu pubDatetime: 2026-03-10T22:00:00+08:00 featured: false draft: false tags: - AI Agent - Claude Code description: "用控制论的三大支柱——反馈、通信、控制——作为观察框架，审视 AI Agent 的架构设计。从 1948 年维纳的经典理论到 2026 年的 Hooks、MCP、Agent Teams，理解工具为什么这样设计。" --- ## 一个 78 年前的预言 1948 年，MIT 数学教授 Norbert Wiener 出版了一本书，书名长得像论文标题：*Cybernetics: Or Control and Communication in the Animal and the Machine*（控制论：或关于在动物和机器中控制和通讯的科学）。 78 年后的 2026 年，你打开 Claude Code，让它帮你重构一个模块。它读取代码、制定计划、调用工具修改文件、自动运行 lint 检查、发现错误后自行修复、再检查——直到所有测试通过。 如果维纳看到这个场景，他大概会说：这就是我写的那本书。 **感知环境、处理信息、调整行为**——维纳在 1948 年归纳出的系统运作三要素，今天被 AI Agent 忠实地重演了一遍。控制论研究的核心问题是"系统如何通过信息交换实现目标"，而这恰恰是每个 Agent 框架在试图回答的问题。 本文要做的事情很直接：用控制论的三大支柱——**反馈、通信、控制**——作为观察框架，审视 AI Agent（以 Claude Code 为主要例证）的架构设计。不是说两者一一对应，而是看看这个 78 年前的理论框架，能否帮我们从"会用工具"跃迁到"理解工具为什么这样设计"。 --- ## 三分钟读懂控制论 先把控制论本身讲清楚。 "Cybernetics"这个词来自古希腊语 **κυβερνήτης**（kybernētēs），意思是"掌舵人"。柏拉图在《理想国》里用过这个隐喻。有趣的是，Kubernetes 也来自同一个词根——从古希腊的舵手，到 20 世纪的控制论，再到 21 世纪的容器编排，同一个隐喻跨越了两千多年。 维纳选这个词不是随意的。他研究的起点是二战期间的防空火控系统——如何让炮台自动追踪高速移动的轰炸机。核心思路是：实时获取飞机位置（感知）、计算瞄准偏差（比较）、修正炮管角度（行动）、再获取新位置（再感知）——一个不断循环的闭环。 从这个具体问题出发，维纳提炼出了适用于一切复杂系统的三大支柱： - **反馈（Feedback）**：系统行动的结果作为输入返回系统，影响后续行动。负反馈纠偏、正反馈放大。 - **通信（Communication）**：信息是控制的基础。没有可靠的信息传递，反馈回路就无法运转。 - **控制（Control）**：不是命令-服从的刚性指挥，而是"通过反馈实现目标趋近"的自适应调节。 三者形成一个闭环：**通信（感知信息）→ 反馈（比较偏差）→ 控制（修正行为）→ 通信（感知新状态）→ ...** 现在，把这个闭环画成一张通用的 Agent 控制回路图： ``` ┌─────────────────────────────────────────┐ │ │ ▼ │ ┌────────────┐ │ │ 目标设定 │ ← 用户 Prompt / UAT 标准 / SLO │ └─────┬──────┘ │ ▼ │ ┌────────────┐ │ │ 感知/上下文 │ ← MCP Resources / 文件读取 │ └─────┬──────┘ │ ▼ │ ┌────────────┐ │ │ 规划/策略 │ ← System Prompt / 工作流模板 / 记忆 │ └─────┬──────┘ │ ▼ │ ┌────────────┐ │ │ 执行/工具 │ ← MCP Tools / Bash / Edit │ └─────┬──────┘ │ ▼ │ ┌────────────┐ 偏差 → 修正 │ │ 结果评估 │ ← PostToolUse Hook / Reviewer │ └─────┬──────┘ │ ▼ │ ┌────────────┐ │ │ 记忆/约束 │ ← CLAUDE.md / 权限模型 / Hook 护栏 │ └─────┬──────┘ │ │ │ └──────────────────────────────────────────┘ ``` 后面几章要做的，就是把 Claude Code 的具体组件一个一个映射到这张图上。 --- ## 反馈——Agent 的纠偏本能 反馈是控制论的心脏。维纳最经典的例子是恒温器：温度低于设定值→加热器开启→温度升高→加热器关闭。偏差驱动修正，修正消除偏差。 AI Agent 的反馈机制，比恒温器复杂得多，但底层逻辑相同。 ### 负反馈：让系统自己纠错 Claude Code 的 Hooks 系统提供了两种截然不同的反馈机制： **PreToolUse = 前馈/联锁**。在工具调用执行前触发，相当于工业控制中的联锁保护——动作还没发生，先检查是否安全。比如，你可以写一个 Hook 拦截所有包含 `rm -rf` 的 Bash 命令： ```bash #!/bin/bash # .claude/hooks/block-rm.sh COMMAND=$(jq -r '.tool_input.command') if echo "$COMMAND" | grep -q 'rm -rf'; then jq -n '{ hookSpecificOutput: { hookEventName: "PreToolUse", permissionDecision: "deny", permissionDecisionReason: "Destructive command blocked by hook" } }' else exit 0 fi ``` 危险命令被直接阻止，永远不会执行。这是"防患于未然"。 **PostToolUse = 事后反馈/纠偏**。在工具执行成功后触发，检查结果是否符合预期。关键区别是：已经执行的操作无法撤销，这是事后纠偏而非拦截。 一个典型的反馈闭环是自动 lint 检查： ```json { "hooks": { "PostToolUse": [ { "matcher": "Edit|Write", "hooks": [ { "type": "command", "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/auto-lint.sh" } ] } ] } } ``` 闭环是这样转起来的：Claude 编辑文件 → 触发 PostToolUse → Hook 运行 lint → 发现错误并反馈给 Claude → Claude 自动修复 → 再次编辑 → 再次触发 lint → 直到零错误。偏差被检测、反馈、修正，系统趋向目标状态——这就是教科书级的负反馈。 更宏观地看，Claude Code 的核心工作流本身就是一个反馈循环：**Plan → Execute → Review → Revise**。在 Agent Teams 中，这个循环变成了多角色版本：Writer 输出代码 → Reviewer 检查并反馈问题 → Writer 修改 → Reviewer 再审。Reviewer 在构建过程中捕获 bug 并委派修复，整个过程无需人工介入——一个闭环纠错系统。 ### 正反馈：放大与失控 负反馈让系统稳定，正反馈让变化放大。在 Agent 系统中，正反馈往往不是有意设计的，而是失控的信号： - **错误记忆放大**：Agent 将一个错误结论写入 Auto Memory → 后续会话基于这个错误前提做决策 → 产生更多错误 → 错误进一步被"固化"。偏差不是在缩小，而是在滚雪球。 - **幻觉通过工具写回系统**：Agent 产生幻觉 → 通过工具将幻觉内容写入数据库或文件 → 幻觉被"固化"为事实 → 后续查询返回被污染的数据。 - **Agent 间错误传播**：多 Agent 协作中，一个 Agent 的错误输出成为另一个的输入，错误在链路中逐级放大。 正反馈失控是 Agent 安全的核心挑战之一。多项 Agent 安全研究（包括 Stellar Cyber 和 Microsoft Security Blog 的分析）表明，Agent 不仅会记住被植入的虚假信息，在被人类质疑时还会为这些错误信念辩护——错误被"内化"后，负反馈（人类纠正）反而遭到抵抗。控制论告诉我们：任何缺乏负反馈约束的正反馈，最终都会走向失控。 --- ## 通信——Agent 的标准化 I/O 边界 维纳有一个核心命题：**信息是控制的基础**。没有可靠的通信，反馈回路就是断路的。 ### MCP：Agent 与外部世界的接口标准 MCP（Model Context Protocol）是 Anthropic 于 2024 年 11 月推出的开放标准，目标是把 Agent 与外部工具、数据源的集成从 N×M 的定制连接器问题，变成即插即用的标准化接口。 用控制论的视角看，MCP 不只是一个"传感器接口"——它是 Agent 完整的 I/O 边界，同时涵盖了感知和执行： | MCP 原语 | 控制论角色 | 功能 | |----------|-----------|------| | **Resources** | 传感器 | Agent 从外部世界获取信息（读数据库、读文件、获取 API 状态） | | **Tools** | 执行器 | Agent 对外部世界施加影响（写文件、调接口、执行命令） | | **Prompts** | 预制交互模板 | 标准化的信息交换格式 | 一个 MCP Host 可以并行连接多个 MCP Server，每个 Server 由独立的 Client 管理——相当于控制系统中的多传感器融合架构。Agent 通过 Resources 感知环境状态，通过 Tools 输出控制动作，信息在标准化通道中流动。 MCP 的生态采纳速度很快。OpenAI 在 2025 年 5 月的 Responses API、6 月的 ChatGPT connectors 中相继支持 MCP。Google DeepMind、Zed、Sourcegraph 等也相继接入。MCP 正在成为 Agent 生态事实上的通信标准。 ### Agent Teams：多回路之间的通信总线 如果说 MCP 解决的是 Agent 与外部工具之间的通信，Agent Teams 的 SendMessage 机制解决的是 Agent 与 Agent 之间的通信。 Agent Teams 的通信基于文件系统上的邮箱机制：每个 Agent 有一个 inbox 文件，SendMessage 通过向目标 Agent 的 inbox 追加 JSON 来传递消息。没有共享内存，全靠消息传递——这和控制论中的神经信号传递如出一辙：独立的处理单元通过标准化信号进行协调。 Team Lead 是"上位控制器"，负责全局目标分解和任务分配；各 Teammate 是独立的控制回路，在各自的 context window 中运行，通过 SendMessage 报告状态、请求协调。 ### 协议层次：从现场总线到控制网络 2026 年，Agent 通信协议正在形成清晰的层次结构： | 协议 | 定位 | 控制论类比 | |------|------|-----------| | **MCP** | Agent ↔ Tool | 现场总线（控制器与传感器/执行器的接口） | | **A2A**（Google 发起，现归 Linux Foundation） | Agent ↔ Agent | 控制网络（控制器之间的协调通信） | | **ACP**（IBM BeeAI 发起，已于 2025 年 8 月并入 A2A 体系） | 轻量级 Agent 消息 | 局部总线（已与 A2A 合流） | 这种层次化通信架构是大规模分布式控制系统（DCS）的标准范式。AI Agent 生态正在自发地重现控制工程积累了数十年的架构经验——这大概不是因为 Agent 开发者在读控制工程教材，而是因为当系统复杂度到达一定程度时，通信分层往往是最自然的解法。 --- ## 控制——目标、策略、约束三层架构 控制论的"控制"不是命令式的强制指挥，而是"目标导向的行为调节"。维纳的掌舵人隐喻最贴切：舵手不断根据风浪调整方向，目标是到达目的地。 在 AI Agent 中，控制机制可以分为三层： ### 第一层：目标（Setpoint / 设定值） 控制系统追求的期望状态。对 Agent 来说，就是任务目标——用户的 prompt、UAT 验收标准、SLO 指标。 Agent 的任务描述就是它的 setpoint：你说"把这个函数重构成异步的"，这就是 Agent 要趋近的目标状态。没有明确目标的 Agent 就像没有设定值的恒温器——运转着，但不知道为了什么。 ### 第二层：策略（Controller Policy / 控制策略） 决定如何从当前状态走向目标状态。在 Claude Code 中，策略层有两个核心载体： - **System Prompt**：Agent 的默认行为策略，定义了它的"出厂设置"。 - **可复用工作流**（如通过插件系统定义的工作流模板）：预定义的行为规范和工作流模板，相当于控制系统中的"预设控制程序"。Claude Code 的插件生态允许用户封装常用工作流，Agent 在需要时按需加载——避免上下文被无关策略淹没。在控制论术语中，这叫"按需调度控制程序"。 ### 第三层：约束（Constraints / 边界条件） 系统的安全边界。到达边界就自动停止，无论目标和策略如何指示。 Claude Code 的权限模型提供了一个清晰的"自主性频谱"： | 权限模式 | 自主性 | 控制论类比 | |---------|--------|-----------| | `plan` | 最低——先输出计划，等人类批准 | 手动控制（人类操纵每一步） | | `default` | 中等——每步操作需确认 | 半自动（人在回路中） | | `acceptEdits` | 较高——自动批准文件操作 | 监督控制（human-on-the-loop） | | `bypassPermissions` | 最高——禁用所有权限检查 | 全自动（仅限隔离环境） | 关键设计：**Hooks 在所有权限模式下都生效**，包括 `bypassPermissions`。这是"安全联锁"——无论运行模式怎么切换，硬性约束始终存在。你可以把自动驾驶的级别调到最高，但碰撞预警不会因此关闭。 这三层架构——目标、策略、约束——在维纳的控制论中都有对应物。目标是设定值，策略是控制器，约束是限位器和安全阀。理解这层映射，能帮你在设计 Agent 系统时问对问题：我的 Agent 有明确的 setpoint 吗？它的控制策略是什么？安全边界在哪里？ --- ## 高阶映射：控制论的更多回响 前面三章覆盖了反馈、通信、控制的直接映射。但控制论还有几个高阶概念，在 AI Agent 时代以不同形式"复活"了。 ### 黑箱方法 → Prompt Engineering 1956 年，W. Ross Ashby 在《控制论导论》中形式化了"黑箱方法"：面对一个不了解内部机制的系统，通过反复施加输入、观察输出、记录模式，建立行为预测模型——即使完全不知道箱子里装的是什么。 Ashby 的论点很激进：**"真实对象事实上都是黑箱"**，因为对任何系统内部机制的完全了解都是不可能的。 这不就是我们每天在做的事情吗？LLM 是典型的黑箱：没人能完全解释模型的内部权重如何工作。但通过调整 prompt（输入）、观察 response（输出）、迭代优化，我们已经积累了大量有效的使用模式。Prompt engineering 的本质，就是 Ashby 黑箱方法的当代实践——70 年后换了个名字。 而 Agent 框架做的事情更进一步：在黑箱外层套了一个控制论的反馈闭环。LLM 本身是黑箱，但 Agent 通过 Plan → Execute → Review → Revise 的循环，用负反馈来约束黑箱的输出质量。 ### 弱形式适应 → 记忆与配置系统 CLAUDE.md 和 Auto Memory 是一种有趣的机制：Agent 在工作过程中自动记录经验（构建命令、调试洞察、代码风格偏好），在后续会话中读取并据此调整行为。 需要谨慎的是，这**不是**真正的"二阶控制论"。二阶控制论（von Foerster 定义为"控制的控制"）指的是系统修改自身的控制规则——观察者嵌入系统内部，系统对自身进行反思和调节。CLAUDE.md 更接近一种**外置配置的经验持久化**，是弱形式的适应机制：经验积累写入磁盘 → 下次会话读取 → 行为微调 → 减少重复错误。 但这种"弱适应"已经产生了实际价值。Auto Memory 的三层结构（人工规则 → 结构化知识库 → 自动学习笔记）实现了从"完全由人类定义行为"到"Agent 部分自主积累经验"的渐进过渡。 真正接近二阶控制论的，是 LLM 的 RLHF/RLAIF 训练过程——模型通过人类反馈真正修改了自己的"控制规则"（权重参数）。但这发生在训练阶段，不在推理阶段。 ### 稳态与动态平衡 → 成本-质量-速度调节 控制论的 homeostasis（稳态）指系统在扰动中维持平衡。恒温器维持温度，人体维持体温，生态系统维持种群平衡——共同点是有**被维持的状态变量**和**反馈调节机制**。 AI Agent 系统也有需要维持的稳态，只是状态变量不同： - **预算上限**：Token 消耗超阈值 → 自动切换到更小/更便宜的模型。 - **延迟阈值**：响应时间超标 → 降级到更快的模型或启用缓存策略。 - **质量通过率**：输出不达标 → 触发重试或升级到更强的模型。 多模型编排（我在[《AI Agent 多模型编排》](/posts/ai-agent-multi-model-orchestration/)中讨论过）本质上就是一种基于多变量的稳态维持系统：在成本、速度、质量三个约束之间动态寻找平衡点。系统不追求某个变量的最优，而是追求多变量在可接受范围内的**动态平衡**——这正是 homeostasis 的定义。 ### 这个框架的边界 走到这里，有必要正面回答本文的核心问题：控制论作为 AI Agent 的观察框架，是否成立？ 我的判断是：**有效，但有明确的边界**。 控制论假设系统有明确的设定值（setpoint）和可测量的偏差。恒温器的设定值是 25°C，偏差是当前温度与 25°C 的差值——清晰、可量化。但 AI Agent 的"目标"往往是模糊的自然语言（"帮我重构这段代码，让它更清晰"），"偏差"难以用数值衡量（什么叫"更清晰"？）。控制论的数学框架在这里失去了精确性，只剩下定性的启发。 其次，经典控制论处理的是连续、可预测的系统。LLM 的输出具有内在的随机性——同样的输入可能产生不同的输出。这和恒温器、火控系统的确定性行为有本质区别。Agent 框架通过外层的反馈循环来约束这种随机性，但约束的效果取决于评估函数的质量，而评估函数本身往往也依赖 LLM——一个黑箱在评估另一个黑箱。 最后，控制论的映射更适合描述 Agent 的**机制**（怎么做），而非**能力**（能做什么）。它能解释为什么 Hook 系统这样设计、为什么需要权限分层，但无法预测一个 Agent 在具体任务上能做到什么程度。 理解边界不是为了否定框架的价值。恰恰相反——知道一个工具在哪里失效，才能更好地使用它。控制论提供的是一套**结构化的思考方式**，让你在设计 Agent 系统时不至于遗漏关键环节。但它不是万能钥匙，不能替代对具体技术的深入理解。 --- ## 反思：维纳的遗产与我们的行动 1950 年，维纳出版了《控制论》的通俗版《人有人的用处》（*The Human Use of Human Beings*）。在书末他写道： > "如果我们不提出正确的问题，就永远得不到正确的答案……时间已经很晚了，善与恶的选择正在叩门。" 76 年后，这段话读起来不像历史文献，更像是写给 2026 年的备忘录。 Brian Christian 在 2025 年新版导言中称维纳为"当代 AI 安全话语的先驱"。这个评价并不夸张。维纳预见了自动化将消除大量工作岗位，警告智能机器"可能不会总是以人类能预见或希望的方式做决策"，主张技术应该增强人类而非控制人类。 2026 年的现实正在映照这些警告： - Agent 越来越自主。Gartner 预测到 2026 年，40% 的企业应用将嵌入任务特定 Agent。但同时，MIT 研究发现许多 Agent 工具缺乏基本监控和可靠的停止控制。 - 认知卸载的风险浮现。研究表明频繁 AI 使用与批判性思维能力呈负相关。Gartner 预测到 2026 年，50% 的组织将要求"无 AI 技能评估"以对抗技能萎缩。 - 治理框架快速成型。新加坡发布了全球首个针对 Agentic AI 的综合治理框架，核心思路是"风险限定设计"——通过控制 Agent 的工具访问、权限和操作范围来限制其行为。EU AI Act 于 2024 年 8 月生效，分阶段适用：禁用做法和 AI 素养义务自 2025 年 2 月起适用，通用 AI 义务自 2025 年 8 月起适用，大多数高风险系统义务将于 2026 年 8 月适用。 用控制论的语言说：**行业正在争论反馈回路中"人"的位置**。从 human-in-the-loop（人在回路中，每步确认）到 human-on-the-loop（人在回路上，监督审查）再到 human-out-of-the-loop（人在回路外，全自主）——我们正处于这条频谱的中段，而维纳 76 年前就在提醒我们：别急着把人移出去。 ### 用控制论审视你的 Agent 系统：5 个问题 下次你设计、评估或调试一个 Agent 系统时，用这五个问题做 checklist： 1. **目标是什么？** 你的 Agent 有明确的 setpoint 吗？还是在漫无目的地执行？目标模糊的系统无法评估偏差。 2. **反馈从哪来？** 执行结果如何回传？谁在评估"偏差"？如果 Agent 做错了事，系统能在多久之内发现？ 3. **噪声在哪里？** 幻觉、错误记忆、模型不确定性、上下文丢失——你识别了这些噪声源吗？有隔离措施吗？ 4. **谁有停机权？** 当系统失控时，谁能拉下"急停按钮"？这个机制是否在所有运行模式下都生效？ 5. **边界在哪？** 成本、风险、质量——系统如何在多个约束的交集内稳定运行？你的安全阀设在哪里？ 这五个问题不是发明的，而是从控制论的基本原理推导出来的。任何控制系统的设计者都需要回答它们——无论是设计恒温器、飞行控制器，还是 AI Agent。 --- 理解控制论不是为了怀旧。1948 年维纳写的那本书之所以今天还有价值，不是因为他预测了 AI——他没有。而是因为他抓住了一个更底层的东西：**任何需要实现目标的系统，都离不开反馈、通信和控制**。工具会迭代，框架会更替，但这个底层逻辑不会变。 掌舵人换了，但航海术没有变。 --- ## 相关阅读 - [AI Agent 多模型编排：让 Claude、ChatGPT、Gemini 各干各的活](/posts/ai-agent-multi-model-orchestration/) — 本文提到的多模型稳态维持系统，在这篇中有完整的实战案例 - [认知卸载到技能提升：AI 时代的学习悖论](/posts/cognitive-offloading-to-skill-upgrade/) — 控制论视角下"人是否还在反馈回路中"的深入讨论 - [同样的话跟 Claude Code 说了八遍，是时候让它自己记住了](/posts/claude-code-memory-rules/) — 本文"弱形式适应"部分的实操指南