舵手

Agentic system 的输出是两股力的合成——模型能力和你在 harness 层做的一切。正交性告诉你力该往哪使。但”使力”的具体机制是什么？你的 harness 到底在做什么类型的工作？

1948 年，一个数学家给这类工作起了名字。

Cybernetics 这个词来自希腊语 κυβερνήτης——舵手。不是哲学家，不是建筑师，是舵手。一个在风浪中实时调整航向的人。

Norbert Wiener 用这个词命名了一个学科：研究系统如何通过反馈来实现控制——无论这个系统是一台蒸汽机、一只猫，还是一个社会组织。

写过 agentic system 代码的人，读到这里应该觉得眼熟。

反馈：一个被过度使用、被过少理解的词

日常语言里的”反馈”是别人告诉你做得好不好。控制论里的反馈是一个精确的机制：系统的输出被回送为输入，影响系统的后续行为。

这个机制有两种模式。注意：这里的”正”和”负”不是”好”和”坏”的意思——正反馈往往是危险的，负反馈往往是你想要的。名字反直觉，但逻辑很清楚：

负反馈修正偏差，趋向稳态。恒温器是经典例子——温度高了就关加热器，低了就开，系统围绕设定值振荡。你的 agent 调用工具、拿到结果、据此调整下一步决策——这是负反馈在工作。

正反馈放大偏差，走向失控。麦克风靠近音箱时的啸叫就是正反馈——声音被拾取、放大、再被拾取、再放大，直到系统饱和。你的 agent 产生了一个”幻觉”（hallucination）——模型自信地输出了事实上错误的内容——这个错误信息进入上下文，模型基于错误的上下文产生更多错误。正反馈，只是失控的不是声音，是语义。

Agent 系统里两种反馈同时存在。负反馈让系统趋向目标，正反馈让系统偏离目标——而且偏得越来越快。

你已经在做控制论了

如果你写过 agent 代码，你已经在做控制论——只是可能没人告诉过你。

这些组件加在一起，就是你的 harness——包裹 LLM 的整个反馈控制系统。这个系统不需要人在每一轮介入；harness 代码自动完成闭环。人的角色在设计时，不在运行时。

Harness 是一个整体，但它内部有职责分工。控制论用三个角色来描述这种分工——Observer、Controller、Plant。

延伸阅读

• Wiener, N. (1948). Cybernetics: Or Control and Communication in the Animal and the Machine. MIT Press. — 控制论的原点；第一部分关于信息、熵、反馈的讨论，至今是理解”为什么系统需要闭环”的最清晰框架

概念与实体

本文涉及的核心概念与实体，在项目知识库中有更详细的资料：

• Harness Engineering — 本文将 harness 定义为包裹 LLM 的整个反馈控制系统，这里有更完整的工程视角
• Agentic Systems — 本文讨论的反馈机制是 agentic system 运行的核心结构
• Context Management — 文中将上下文管理类比为”信号滤波与降噪”，这里展开了具体机制
• Guardrails — 文中提到的权限系统、沙箱隔离等约束边界的详细资料

本节和念因果有向无环图的结构思考相呼应 —— 点开看它的一图流卡。

Observer-Controller-Plant

知道 harness 是一个反馈控制系统，这还不够。“整个系统”太笼统了——出了问题你不知道该往哪看。控制论把这个系统拆成三个角色。

三个角色

Plant（被控对象）——你想控制但不能直接修改内部的那个东西。在传统控制论里，它是电机、是化工反应器、是飞行器的气动面。在 agentic system 里，它是 LLM。你给它输入，它给你输出。你无法打开它的参数矩阵去手动改一个权重——你只能通过输入来影响它的输出。

Controller（控制器）——根据观测信号生成控制信号的部分。System prompt、tool definitions、编排逻辑、权限系统、上下文管理策略——这些决定了”下一轮喂给 LLM 什么”。

Observer（观察者）——感知 plant 输出的部分。Output parser、evaluator LLM（用另一个模型来检查主模型的输出）、human-in-the-loop 审批流程、日志系统——它们决定了”LLM 的输出是否达标，差距在哪”。

Controller 和 observer 都是你的 harness 代码。Plant 是唯一不属于 harness 的部分——它是你的 harness 要去控制的对象。OCP 不是在把你的系统分成三个独立的程序，而是在对 harness 内部做职责分解：同一个代码库里，哪些组件在做控制，哪些在做观测。

graph LR
  P["Plant<br>(LLM)"] -->|输出| O["Observer<br>(观测)"]
  O -->|偏差信号| C["Controller<br>(控制)"]
  C -->|控制信号| P
  style P fill:#e8f4fd,stroke:#333
  style O fill:#fff3e0,stroke:#333
  style C fill:#e8f5e9,stroke:#333

闭环与开环

如果你的 agent 只是 prompt → response、用一次就扔，你在做开环控制——发出指令但不看结果。开环控制在被控对象行为高度可预测时可以工作。

LLM 的行为不是高度可预测的——ch-01 说过，概率性是它的操作特性之一。所以几乎所有生产级 agentic system 都是闭环的。不是闭环的那些，要么是 chatbot，要么是在冒险。

闭环控制的本质很简单：观测、比较、调整、重复。 Agent loop 的 while has_tool_calls: execute → feed_back → call_again 就是这个回路的代码实现。

映射表

把控制论的术语和 agent 系统的组件对齐，整张图就清晰了：

你不需要记住这张表。你需要的是一个直觉：当你在 agent 系统里碰到一个设计问题，试着问自己——这是 plant 的问题、controller 的问题、还是 observer 的问题？仅仅是分清这一点，就能让你的排查方向精确很多。

分离原理

说白了：“让模型按格式输出”和”检查模型输出是否正确”是两件事。 前者是 controller 的事（prompt engineering、structured output、tool design），后者是 observer 的事（validation、evaluation、testing）。

混淆二者的典型症状：在 system prompt 里写一大段”请在输出中自行检查是否正确”——controller 在兼任 observer。有时候这能工作（模型的 self-correction 能力确实存在），但它把两个本可以独立优化的问题耦合在了一起。一旦耦合，你改 prompt 的时候不知道自己在调控制还是在调观测，调试就变成了碰运气。

Anthropic 在 harness 设计中采用的 generator/evaluator 分离架构，正是这条原理的工程实践——生成和评估由不同的组件负责，各自独立迭代。

三个角色、一个回路、一条分离原理——这是控制论给你的基本骨架。但这个骨架有一个麻烦：它的 plant 是一个输出空间近乎无限的语言模型。你的 controller 要怎么应对这种多样性？Ashby 在 1956 年给出了答案。

延伸阅读

• Ahn, K., Zhang, Z., & Sra, S. (2024). What’s the Magic Word? A Control Theory of LLM Prompting. arXiv:2310.04444. — 用控制论的数学框架严格分析 prompt 如何作为控制信号影响 LLM 输出，把本文的类比变成了可证明的定理

概念与实体

本文涉及的核心概念与实体，在项目知识库中有更详细的资料：

• Harness Engineering — OCP 三角色是 harness 内部的职责分解框架
• Evaluator-Optimizer — 分离原理的工程实践：generator/evaluator 分离架构
• Implicit Loop Architecture — 闭环控制回路在隐式循环架构中的具体实现
• Augmented LLM — LLM 作为 Plant 时，增强层（工具、检索）如何改变控制回路的结构
• Tool Design — tool definitions 是 controller 的核心控制信号之一

必要多样性

Observer、Controller、Plant 三个角色，一个闭环回路——骨架有了。但这个骨架有一个问题：它的 Plant 不是一台输出空间有限的电机，而是一个输出空间近乎无限的语言模型。

Ashby 定律

1956 年，W. Ross Ashby 提出了一条被后人称为”控制论第一定律”的原理：

直觉：恒温器只有一种控制手段——开关加热器。所以它只能调节温度，不能调节湿度。如果你希望同时控制温度和湿度，你需要一个至少有两种独立控制手段的系统。控制能力的上限，由控制器的多样性决定。

映射到 agentic system：你的 harness 能处理的行为种类，必须覆盖模型可能产出的行为种类。覆盖不了的部分，就是你系统的盲区——在那里，模型的输出不受控制。

LLM 是高多样性的 Plant

传统控制论的 plant 通常是低多样性的。一台电机的输出空间就是转速和扭矩。一个恒温器的输出就是温度。你可以枚举所有可能的输出状态，然后为每一种状态设计对应的控制策略。

LLM 不是这样。

LLM 的输出空间是自然语言——理论上是所有可能的 token 序列的集合。即使你把输出限制在 1000 个 token 以内，可能的输出组合也是一个天文数字。你不可能枚举所有可能的模型输出，然后为每一种输出设计一个处理分支。

Ashby 定律的工程含义很明确：既然你不可能让 harness 的多样性追上一个无穷的输出空间，那你必须从 plant 端下手，降低需要处理的多样性。

两种策略

增加 harness 的控制能力

更多工具、更复杂的编排逻辑、更多检查点、更精细的 evaluator——让你的 harness 能识别和处理更多种类的模型行为。

代价：harness 本身的复杂度上升。复杂的 harness 更难理解、更难调试、自身出 bug 的概率也更高。控制器的多样性有实际上限——它不能超过工程师能理解和维护的范围。

降低 Plant 的有效多样性

约束模型输出格式（structured output），把输出从”任意自然语言”收窄到”符合某个 JSON schema 的文本”。限制可用工具，你不是在限制模型的能力，你是在限制你需要处理的行为种类。缩窄任务范围，把一个大任务拆成多个小任务，每个小任务的输出空间更小。

OpenAI 在构建 Codex 的过程中总结了类似的经验——“give Codex a map, not a 1,000-page instruction manual”。用清晰的架构文档和约束规则来限定 agent 的行为空间，而不是用冗长的指令试图覆盖所有情况。这也是降低多样性的一种手段：不是通过代码约束输出格式，而是通过文档约束行为空间。

两种策略不是二选一。降低 plant 的有效多样性之后，harness 需要覆盖的剩余空间变小了——原本不可能的控制问题变成了可能的。先降噪，再控制。

顺便说一句——“降低 plant 的有效多样性”这件事，本身就是 ch-01 说的累积性投入。无论模型变得多强，你约束输出格式、限定工具集合、用文档框定行为空间的工作都不会被模型能力的增长所替代。它正交于模型能力。

简单 harness 为什么经常赢

Keep your agent framework simple. The sophistication should be in your tools and in your prompts, not in your agentic framework.

— Anthropic, Building Effective Agents

换成 Ashby 的话说：别试图让 harness 变得跟 plant 一样复杂。反过来——把 plant 的有效多样性降下去，简单的 harness 就够了。

但”简单”是一个微妙的词。Ashby 定律有一个推论：控制器自身也是一个系统，也有自己的多样性。如果 harness 的多样性太高——超过了工程师能理解和调试的范围——它就从控制 LLM 的工具变成了另一个需要被控制的复杂系统。控制器在控制 plant 的同时失控了。

反过来，如果 harness 的多样性太低——少到覆盖不了 plant 约束后的剩余行为空间——它就是一个盲区遍布的系统。

“简单”的含义藏在 Ashby 定律的数学里：harness 的多样性恰好覆盖它需要处理的多样性，不多也不少。

多样性约束了，结构理清了，接下来的问题是：这个被约束的系统在运行时到底长什么样？它是一个状态机——但它是非典型的。

延伸阅读

• Ashby, W. R. (1956). An Introduction to Cybernetics. Chapman & Hall. rossashby.info. — 第 11 章推导必要多样性定律的原始论证，比任何二手解读都清晰；全书免费 PDF

概念与实体

本文涉及的核心概念与实体，在项目知识库中有更详细的资料：

• Harness Engineering — harness 复杂度的上限由必要多样性定律约束
• Guardrails — 约束 Plant 有效多样性的具体机制之一
• ACI — 工具接口设计如何降低 LLM 输出的有效多样性
• Anthropic — 文中引用的 “Building Effective Agents” 的发布方

非典型状态机

多样性约束住了，harness 覆盖了剩余空间。这个被约束后的系统在运行时到底长什么样？

它是一个状态机——形式上完全符合定义。但它有几条不寻常的性质。

Agent loop 是一个 while 循环

任何 agentic system 的核心都是一个循环：

while not done:
    output = llm(context)
    if output.has_tool_calls:
        results = execute(output.tool_calls)
        context.append(results)
    else:
        done = True

当前状态（上下文）+ 输入（工具结果）→ 转移函数（LLM 推理）→ 下一个状态（更新后的上下文）。形式上，这就是一个状态机。

如果你告诉一个计算机科学家”agent loop 是一个状态机”，他会点头。但如果他试图用验证有限状态机的方法来验证你的 agent，他会发现问题。

经典 FSM vs Agent 状态机

三条非典型性质

不只是 while 循环：事件驱动

上面描述的同步循环是 agent loop 的主路径。但生产级 harness 不只跑一个 while 循环——它是一个事件循环。

主路径之外，还有异步信号在不断到达：

• Hooks：pre-tool-call、post-tool-call 钩子在主路径的特定节点触发，可以拦截、修改或中止执行。
• 外部中断：用户中止、超时信号、CI 状态变更——这些事件随时可能打断主路径。
• 事件驱动的 kickoff：agent 的启动本身就不一定是人手动触发的。外部世界的状态变更（数据到达、上游服务推送、定时调度、另一个 agent 的输出）都可以作为 agent 执行的触发条件。在生产级编排层中，事件驱动的 agent kickoff 是常见模式——状态机的第一步转移，就已经是异步的了。

经典 FSM 不需要面对这个维度——它的转移是同步的，一个输入对应一次转移。Agent 状态机的转移既有同步的（LLM 输出 → 工具执行 → 结果回注），也有异步的（外部事件随时注入）。这使得 harness 的运行时模型更接近一个事件驱动的 reactor，而不是一个简单的 while 循环。

状态空间近乎无限，转移函数非确定性，终止条件概率性，驱动方式是同步和异步的混合。这仍然是一个状态机，只是你没法用经典方法验证它。

理解了运行时的形态，还剩一个维度没拆开：这个状态机上的反馈回路不只有一层。

延伸阅读

• Weng, L. (2025). Building LLM-Powered Agents. lilianweng.github.io. — 从 agent loop 的运行时结构出发，系统梳理了状态管理、工具调用、终止控制等工程维度，与本文的非典型 FSM 视角互补

概念与实体

本文涉及的核心概念与实体，在项目知识库中有更详细的资料：

• Implicit Loop Architecture — 隐式循环是本文描述的非典型状态机的一种约束策略
• Context Management — 自然语言状态的降维手段：compaction、summarization
• Agentic Systems — agent loop 作为状态机的整体架构
• LangGraph — 文中提到的显式图约束策略的代表实现
• Claude Code — 文中提到的隐式循环约束策略的代表实现

反馈的层次

反馈是系统输出回送为输入的机制——负反馈修正偏差，正反馈放大偏差。但反馈不只发生在一个地方。把视角从一次 tool call 拉远到整个 AI 系统的生命周期，你会看到至少四层嵌套的反馈回路。

四层反馈

换一个角度看同一张图——每一层在纠正什么：

嵌套的回路

每一层都是一个完整的 Observer-Controller-Plant 回路。内层快，外层慢——但外层设定了内层运行的边界条件。

训练改变模型权重，于是每一次 token 级的概率分布都变了。你调整 system prompt，于是每一次 turn 级的模型行为都变了。慢的那一层，决定了快的那一层能做什么、不能做什么。

Harness 工程师主要在 turn 级和 session 级操作。但知道自己的控制信号在哪一层生效，知道哪些行为不是你这一层能改的——这个边界感很重要。

正反馈的危险

这也是 02 分离原理的另一个切面：为什么 evaluator 要独立于 generator。如果 generator 自己负责检查自己的输出（controller 兼任 observer），正反馈可能在 generator 的盲区里悄悄累积——它看不到自己的错误，自然无法纠正。独立的 evaluator 从外部提供负反馈，才能打破这个循环。

到这里为止，我们一直站在系统外面往里看——observer 在这边，plant 在那边，泾渭分明。但有一个问题一直没碰：你调 prompt 的时候，你自己算不算系统的一部分？

延伸阅读

• Christiano, P. et al. (2017). Deep Reinforcement Learning from Human Preferences. arXiv:1706.03741. — Alignment 级反馈回路的奠基论文；理解人类偏好信号如何经过聚合改变模型权重

概念与实体

本文涉及的核心概念与实体，在项目知识库中有更详细的资料：

• Context Rot — 正反馈导致的幻觉累积，是上下文腐烂的核心机制之一
• Generation-Verification Loop — turn 级反馈的工程实现：生成-验证循环
• Context Management — session 级反馈中上下文策略调整的具体手段
• Scaling Laws — alignment 级反馈塑造能力增长曲线方向的理论基础
• LLM Training Pipeline — alignment 级反馈在训练流水线中的位置

二阶控制论

你调 prompt 的时候在做什么？

观察模型的输出，判断离期望有多远，修改 system prompt，再观察新的输出。这个循环可能持续几个小时。你就是一个在 session 级运行的控制器。

但同时，你也是系统的一部分。你的设计决策影响系统行为，系统行为影响你的下一个设计决策。你不是站在系统外面调参数的旁观者——你在里面。

1974 年，Heinz von Foerster 给这个现象划了一条线。

一阶与二阶

一阶控制论

被观察系统的控制论。你站在系统外面，研究它怎么运作。Plant 在那边，observer 在这边，泾渭分明。前五篇的讨论——从 OCP 结构到反馈层次——都是一阶视角。

二阶控制论

观察系统的控制论。你意识到观察者本身就在系统里面，观察行为在改变被观察的系统。不是”我在看它怎么跑”，而是”我在看它怎么跑，而我的看法会改变它下一步怎么跑”。

一阶视角足以解决大部分工程问题。但有些现象只有二阶视角才能看清。

你就是那个 adaptive controller

调 prompt 的迭代过程，控制论里有一个名字：adaptive control——控制器根据被控对象的行为实时调整自身策略。

经典 adaptive control 里，控制器是一段算法。在 agentic system 的开发过程中，控制器是你——一个人类工程师，在 session 级的时间尺度上观测行为、判断效果、调整策略。你设计 harness 的过程本身就是一个反馈回路，只是闭合速度比 turn 级慢得多。

二阶控制论描述的正是这个结构：观察者和被观察系统之间没有单向箭头，只有环路。

当系统观察自己

比你调 prompt 更有意思的是：模型自己也能做类似的事。

Agent 自己生成、自己检查、自己修正——generator 和 evaluator 是同一个模型。

分离原理与二阶视角的关系

02 说过，controller 和 observer 的职责应该分离。这里又说观察者和被观察者可以合一。并不矛盾——它们在不同层次上说话。

分离原理是 harness 内部的工程原则：同一个代码库里，控制组件和观测组件各司其职，独立优化。一阶视角。

二阶视角关注的是另一件事。无论你怎么设计 harness，你自己（作为设计者）和系统之间始终构成一个环路——你的设计影响行为，行为影响你的下一个设计。这个环路无法消除，只能意识到。而意识到它的存在，就是理解为什么”把 harness 设计好”不是一个有终点的任务，而是一个持续的迭代过程。

控制论能给 agentic system 工程的视角到这里基本展开了。还剩一个问题：这些视角加在一起，画出的那条线到底在哪？

延伸阅读

• Bai, Y. et al. (2022). Constitutional AI: Harmlessness from AI Feedback. arXiv:2212.08073. — 当系统观察自己：模型用原则批评自己的输出并自我训练，是二阶控制论在 AI 安全领域最完整的工程化实践
• Anthropic. (2025). Circuit Tracing: Revealing Computational Graphs in Language Models. transformer-circuits.pub. — 模型能否可靠地”看到”自己在做什么？这篇给出了目前最精细的实证数据

概念与实体

本文涉及的核心概念与实体，在项目知识库中有更详细的资料：

• Mechanistic Interpretability — circuit tracing 所属的研究领域，追问模型内部计算的可观测性
• Evaluator-Optimizer — 分离原理在二阶视角下的张力：generator 和 evaluator 何时该分、何时可合
• Harness Engineering — 二阶视角揭示 harness 设计是一个没有终点的迭代过程
• Anthropic — Constitutional AI 和 Circuit Tracing 的研究发布方

传统软件的边界

那条线到底在哪？

三条分界线

不同的 Plant，不同的工程

三条线收拢起来：传统软件的 Plant 是确定性的、低多样性的、用类型化接口驱动的。Agentic system 的 Plant 是非确定性的、高多样性的、用自然语言驱动的。

Plant 不同，harness 的设计原则就不同。

你不会用调试编译器的方法去调一台发动机。不是因为发动机不如编译器，而是因为它们是不同的系统，有不同的失败模式。

保留什么，更新什么

工程纪律的内核不变：严谨、可重复、可验证。

变的是纪律的具体形式。“可重复”是精确重现还是统计稳定？“可验证”是断言精确值还是检验分布特征？“可观测”是追踪代码路径还是追踪推理路径？

正交性告诉你力该往哪使。控制论告诉你这股力的运作机制——一个非典型状态机上的多层反馈控制系统，而你自己也是这个系统的一部分。

机制清楚了。下一个问题：这个系统在长时间运行中会自发走向什么方向？上下文在腐烂，错误在级联，意图在漂移。

延伸阅读

• Schneier, B. & Raghavan, B. (2025). On the OODA Loop and Agentic AI. schneier.com. — 从安全研究者视角审视 agentic system 的控制回路，OODA 框架与本章的 OCP 回路形成有趣对照

概念与实体

本文涉及的核心概念与实体，在项目知识库中有更详细的资料：

• Reliability Surface — 非确定性执行带来的验证挑战，在可靠性曲面上的具体展现
• Context Rot — 文末预告的”上下文在腐烂”，下一章的核心主题
• Error Cascade — 文末预告的”错误在级联”，涌现行为不可穷举的后果之一
• Software 3.0 — 传统软件与 agentic system 的分界线在软件演化史中的位置