Cybernetics Agent——人工智能应用的新范式

一次性的 prompt，是一个把反馈控制留在系统之外的范式

我刚开始使用 LLM 的时候，几乎是把大模型当做一个”更聪明的函数”来用的：写一段 prompt，扔进去，拿回一段输出，检查，不满意就改 prompt，再扔一次。这个过程有一个人尽皆知的名字——”调 prompt”。

不过，这个阶段很快过去了。和那个时代的很多同行一样，我们很自然地开始尝试管理消息队列，搭建工作循环。回头看，我才逐渐意识到最初那种调 prompt 范式的结构性缺陷：它通常把反馈控制留在了系统之外。

这里需要澄清一点：一次性 prompt 并不意味着整个工作过程没有反馈。用户检查输出、修改 prompt、重新发起调用，本身就形成了一个由人参与的反馈回路。真正的问题在于，这个回路主要依赖人的记忆、判断和手工操作，没有被系统化地实现为一个持久、可追踪、可自动运行的控制机制。

系统本身没有持久化的目标状态，没有独立的验收机制，也没有基于验收结果自动校准下一轮行动的工作协议。每一次调用都是一次局部求解：目标主要活在当前这条 prompt 里，测量的责任在人，修正的手段是人重新写 prompt。人承担了整个控制循环，而模型只负责其中一次执行。

这在简单任务上问题不大。但当任务变成”在这个仓库里完成一次可靠的重构”、”写一篇所有技术细节都有据可查的深度文章”时，一次性 prompt 就露馅了：模型说”应该可以了”，而你无法独立验证；它跑偏了，你只能整段重来；它忘了最初的目标，因为目标从来没有被作为一个独立的状态持续跟踪过。

更深一层看，一次性 prompt 把本应持续进行的控制问题，简化成了一次性的求解问题。单次调用关注的是：在当前给定的上下文中，模型能否生成一个足够好的结果。控制关注的则是：当环境持续变化、行动产生新结果、需求不断澄清时，系统能否通过反复观测与调整，持续逼近目标。

两者并不矛盾。优化可以服务于控制，最优控制本身就是控制理论的重要分支；但一次求解的质量，并不能代替整个闭环的可靠性。写好一段 prompt 并将它打磨到极致，是对单次求解过程的优化；让系统能在扰动下持续观察、调整和验证，才是闭环控制要解决的问题。实际系统两者都需要，但传统的 prompt 工作流把后者的大部分责任交还给了人。

有意思的是，这些问题在工程史上早就有了实践性的答案。早在控制论成为一门学科之前，反馈控制就已在机械调速等装置中发挥作用。18 世纪末，博尔顿与瓦特将离心调速器应用于蒸汽机，使机器能够根据转速变化自动调节蒸汽供给。

二战期间，维纳参与研究防空火力控制中的预测问题，思考如何根据目标运动的信息不断修正瞄准。1948 年，他出版《控制论：或动物和机器中的控制与通信》，尝试把控制、通信与反馈的共同原理系统地联系起来。

反馈实践早于控制论作为统一学科的形成；而控制论的重要贡献之一，就是把这些分散的实践和思想纳入更广泛的理论框架。

控制论中最直观的一类调节机制，是负反馈：设定目标（setpoint），采取行动，测量输出与目标的偏差，再利用偏差修正下一次行动。反馈的关键，是系统利用行动的实际结果反过来修正自己的行动。

从感知机的误差修正，到反向传播驱动的参数优化，再到 RLHF 引入的人类偏好反馈，现代人工智能的许多关键技术都体现了利用反馈改进系统行为的思想。但这些机制在数学结构和作用层次上并不相同。真正值得追问的，是如何把反馈从模型训练阶段扩展到应用运行阶段，让整个 Agent 系统也能持续测量、修正和验证自己的行为。

于是有了 dsh-cybernetics——一个我集中两天时间写出来的实验性项目，构建在 DeepSeek Harness（DSH）之上，作为一套控制论工作协议插件。

它想回答的问题是：如果把 LLM Agent 编排明确设计成一个反馈控制回路，会得到什么？

核心思想：把 Agent 编排做成一个闭环

dsh-cybernetics 的工作回路包含四个环节：

1. 目标（setpoint）：一份持久化的 goal，包含目标文本（objective）、当前子目标（subgoal）和一份完整的工作委托书（brief）——背景、路径、约束、验收标准，详细到执行者无需任何对话历史即可开工。
2. 行动（act）：task agent——一个不继承用户对话历史的独立 sub agent——面向委托书实际执行，产出结构化交付报告。
3. 测量（measure）：verify agent 独立验收。它把总目标拆成可逐条判定的方面，产出结构化 verdict：{met, criteria:[{criterion, pass, evidence}], gaps, goalItselfQuestionable}。
4. 校准（calibrate）：triage agent 对 verdict 暴露的后续线索进行四分拣：auto（自动迭代）/ defer / reject / human（回对话找用户）。

在这个回路里，角色分工是严格定义的：session agent 是编排者，也就是控制器——它识别用户输入、维护 goal 板、启动和收取轮次、向用户转述，但从不亲自执行任务；task agent 是承担具体任务的执行子系统，通过工具作用于实际工作对象；verify agent 是独立的测量与验收环节；而用户是目标层面的监督者与校准者——目标层面的修订需要用户确认，完成也需要用户点头，controller 从不自宣完成。

把这套角色系统性地列出来，就是工作循环里的三份角色定义：

• session agent 是主工作循环：它负责和人交互，同时调度下级的 sub agents。它把用户的输入整理为 goal，分配给具体的 task agent 去完成任务；task agent 完成工作后，verify agent 负责验收，session agent 再根据验证结果决定是否进一步校准。
• task agent 是执行子系统：面向委托书独立完成工作，不继承用户与 session agent 的完整对话历史。它可以调用工具，对代码、数据、文件或外部服务等实际工作对象产生影响。
• verify agent 是验收者：对 task agent 的交付做独立测量，其结论是 session agent 校准决策的核心依据。验收不仅检查执行者提交的报告，还要尽可能核验实际交付物与证据。

这套循环还有一个我一开始没有预料到、后来却觉得最关键的属性：session agent 处于非阻塞的双工状态。

用户不必等任务结束才能交流——任务在后台运行的时候，你随时可以继续和 session agent 讨论任务本身，这些讨论可能直接带来 goal 的修正。也就是说，外环的校准随时在线，不必等内环转完一圈。

这既是因为我在过去的工作中反复有过打断正在思考的 AI、插入新想法的需求，更是因为从控制论的角度看，外环对目标的校准不应该受制于内环任务的执行周期。任务的执行可以持续推进，但对目标的校准必须始终保持开放。

这并不是说所有控制系统都必须允许随时介入，而是说，在这个 Agent 协议里，我有意消除了一个不必要的时序依赖：用户不应该被迫站在闸门口等待结果，他应该始终坐在控制台旁边。

这就是一个具有双环结构的控制系统：

• 内环：task → verify → triage → 下一轮 subgoal 修正。在当前 goal 不变的前提下，系统自动迭代，每轮有连续迭代上限兜底。
• 外环：用户 ↔ session agent。它始终保持开放，既可以响应用户在执行期间主动提出的目标修订，也可以在验收反馈显示目标本身可能存在问题时，要求用户介入重新校准。

verdict 里专门有一个字段 goalItselfQuestionable——当验证者怀疑”这个目标本身就不对”时，回路被禁止自动迭代，必须回对话重新校准。这个字段是我最喜欢的细节之一：它把”方向错了”和”执行得不好”在结构上区分开了。

需要说明的是，goalItselfQuestionable 是协议定义的一个目标层面升级信号，而不是控制论规定的标准机制。除此之外，工具权限不足、证据互相矛盾、自动修正多轮无效等情况，也可以通过 human 分拣升级给用户。前者专门处理目标本身可能有问题的情况，后者处理更广泛的人工介入需求。

从控制论的角度理解这四个环节，可以得到一个更精确的对应关系：

• goal 是参考值（reference）及其显式版本记录；
• session agent 是控制器，负责状态管理、轮次调度与校准决策；
• subgoal 和 brief 是控制策略在当前轮次的具体表达；
• task agent 是执行子系统；
• task agent 调用的工具是执行器的一部分；
• 代码仓库、知识库、文件和外部服务等是实际工作对象；
• verify agent 负责测量与验收；
• verdict 是反馈信号；
• 环境变化、工具故障、需求漂移等则构成扰动。

triage 分拣里的 human 类目，本质上是控制器为”不可自动处理的扰动”预留的升级路径：当问题超出了内环的调节能力，或者现有证据不足以支持安全可靠的自动决策时，它不被强行吞下，而是被升级到系统的最高决策者手里。

而每轮连续迭代上限，则是对自动反馈回路的一道工程护栏。它首先限制无界迭代与资源消耗；更重要的是，当测量结果不可靠、修正策略失效，或者系统陷入重复试错时，它能够阻止回路无限运行。

当然，迭代上限并不等于稳定性保证。一个 Agent 即使只允许三轮，也可能连续做出三次错误修正。要真正减少振荡与反复失败，还需要可靠的验收信号、合理的修正策略，以及对重复失败的识别。

负反馈纠偏，正反馈放大，正与负描述的是作用方向而非价值判断。一个没有刹车机制的自动迭代，可能从纠偏滑向错误的持续放大。上限不是不信任回路，而是为自动化设定一个明确的停止边界。

四个关键设计

1. 双层修正回路，目标版本只追加、不原地改写

内环修正的是 subgoal——本轮怎么干，session agent 根据 verdict 自动调整，每轮记账。外环修正的是 goal 本身。

这里我做了一个重要的设计决策：目标版本不可原地改写，修订通过创建新版本表达（append-only goals）。

修订目标时，系统不是原地改写 objective，而是创建一个带 parentGoalId 的新 goal 并立即启动它的第一轮，旧 goal 置为 superseded 状态、记录 supersededBy。revise 是唯一的改目标动词，reason 必填，每次修订追加一行审计日志 {from, to, reason, at}。被取代的 goal 再次 revise 会被拒绝，以免谱系分叉。

为什么这么较真？

因为目标被悄悄改写，会摧毁 goal 跟踪的全部价值。如果一个 agent 可以在多轮迭代中不知不觉地漂移目标，那你在页签上看到的那个目标就不再是你当初设定的目标——跟踪失去了意义。

身份与历史由 goal 链来表达，而不是由一个可变字段的最新值来表达。这个设计与 Git 用不可变 commit 保留历史的思想相似：重要状态的变化不应该只留下一个被覆盖的最新值，而应该留下可追溯的演化记录。

控制论本身并不要求目标必须采用 append-only 存储。但对于需要审计和人工校准的 Agent 系统，显式记录每次目标修订，可以让控制过程本身也成为可检查的对象。

外环的存在还让我联想到二阶控制论的一个重要主题：观察者并不总是一个完全独立于被观察系统的外部角色。

在这套协议里，用户既是目标的设定者，也是任务执行过程的观察者和干预者；他的判断会改变 goal，而新的 goal 又会改变系统接下来的行动。这里不是说这套协议就等同于二阶控制论，而是说它体现了一个相似的思想：目标、观察与干预之间的关系，也应成为系统设计中明确处理的对象。

append-only 的 goal 链记录的正是这个”观察—干预—再观察”的历史：每一次修订都是一次干预的证据。

2. 上下文不变量：上下文是被配给的，不是无条件继承的

这可能是整个协议里最核心的一条不变量：所有二级上下文都必须受到显式边界约束，不能无条件继承上层会话历史。

• task agent 只拿委托书；
• verify agent 只拿 goal、任务交付物和可独立核验的证据；
• triage agent 只拿 verdict 及协议明确允许的决策信息。

为什么 verify 不能直接接受执行者对自身工作的叙述作为验收依据？

因为那样验证就可能被污染：执行者会把”我做了什么、为什么这样做”讲得头头是道，验收者会被叙述带着走，最后变成”检查执行者的自述是否自洽”，而不是”检查事实是否满足目标”。

这里需要区分两件事：verify agent 可以检查 task agent 提交的结构化交付报告，但不能把执行者对自身表现的解释当作通过验收的依据。验收结论必须尽可能建立在实际交付物和可核验事实之上。

测量仪器应当尽可能独立于被测对象。但上下文独立不等于证据独立：如果证据全部由 task agent 自己生成，verify agent 即使使用完全独立的上下文，也仍然可能受到证据质量的限制。

因此，独立验收不仅要隔离叙述，还要尽可能核验真实的交付物、测试结果和外部事实。

整个协议里还明确禁止 context: 'fork'（继承对话历史的子代理）参与回路——持久的是身份和 goal 边界，不是用户会话的完整历史。

这条不变量在实机验证中表现出了意想不到的收益：fresh 上下文加详细委托书，不但没有让执行者变笨，反而让它在一次知识库分析中自发发现了委托书都没要求的数据质量问题（PII 混入正文、markdown 与 JSON 格式漂移、异常空值维度）。

这只是一次工程观察，并不意味着 fresh context 在所有任务中都优于持久上下文。但它至少说明，没有历史包袱的执行者可以带着”白纸的怀疑”去看事实，而不必完全沿用前序会话已经形成的判断。

当然，持久执行者也有价值。迭代型、多轮分析任务可能需要复用已有发现，避免重复探索。这里真正重要的不是禁止一切状态继承，而是让记忆的边界与 goal 的边界重合。

对于需要跨轮次积累工作的 persistent executor，可以保留执行者自身的任务状态，但其记忆必须限制在对应 goal 的范围内。用户对话历史、执行者内部记忆和持久化 goal 是不同的状态来源，不能不加区分地混在一起。

3. 硬门：思考与行动在结构上分离

协议早期版本里，”session agent 不亲自执行任务”只是系统提示里的一句劝告——模型心情好就遵守，看到琐碎任务就忍不住内联干完。劝告是不够的。

于是有了硬门（hard gate）：插件在系统提示装配期，直接把执行类工具（bash/edit/write）从顶层 session agent 的工具清单中物理移除。模型根本看不见这些工具，自然无法调用。

后来实机又暴露了 denylist 的覆盖缺口——变更类工具是长尾（服务管理、看板写入、定时任务……），逐名封堵永远补不完——于是进一步反转成 allowlist 模式：顶层编排者只保留读、对话、展示和 goal/编排动词。

语义随之变得极其清晰：

只读问答无需 goal 直接回答；任何”改变世界”的请求——无论多小——都是委派信号。

task agent 和 verify agent 不受硬门影响，执行能力只属于被编排的执行者。

这就是”思考与行动分离”的结构化实现：编排者的全部产出是 goal 和 brief（信息），执行者的全部产出是对实际工作对象的改变（行动），测量者独立于两者。人透过 goal 和审计日志观察这一切——可解释性不再只依赖事后阅读对话记录，而是回路的原生产物。

回头再看，硬门体现的是一种与控制论相容的工程原则：让信息可见性、决策职责和行动权限彼此匹配。

编排者能够读取 goal 板、审计日志和 agent 状态，却不直接拥有执行类工具；执行者负责改变实际工作对象；验收者独立检查结果。这样的职责与权限分离，使系统更容易被监督、审计和纠错，也降低了对模型自觉遵守指令的依赖。

这里涉及几个相互关联、但并不等同的概念：

• 可观测性：系统能否通过可获得的信息推断关键状态；
• 可控性：系统能否通过可用的控制输入到达所需状态；
• 权限隔离：不同角色被允许执行哪些操作；
• 可审计性：系统能否留下足够的信息，供人追踪和检查决策过程。

在经典控制理论中，可观测性与可控性有明确的数学定义，不能简单地等同于”能否读取工具”和”能否调用工具”。硬门本身也不自动保证系统具有数学意义上的可观测性或可控性。

但它确实能够通过明确的角色边界，让整个 Agent 系统更容易被监督和约束。

这里有一条我越来越确信的判断：单纯换更强的模型并不能解决结构性问题——关键是让信息、决策能力和行动权限相互匹配。

模型再强，如果它的可见范围、决策边界和它被允许做的事不互相咬合，系统整体的可靠性不会因为模型变聪明而自动提高。硬门做的事，就是让这种匹配不再依赖模型的自觉。

4. 分级的轮次与执行者基质

工程上不能让所有任务都付全价，所以有两套正交的分级。

轮次深度（depth）：琐碎只读问答直接答，不建 goal；轻量分析走 quick——单 task agent 一轮出结果，跳过 verify/triage，成本更低；复杂分析与一切变更走 full——完整的工作→验证→分诊循环，验收通过才交付。协议里明令禁止用 quick 轮抄近路做变更。

在目前的实测配置中，quick 路径的模型调用成本约为 full 路径的三分之一。这个比例取决于任务复杂度、模型选择和验收流程，不应被理解为普遍适用的性能保证。

执行者基质（executor）：一次性或变更类 goal 用 ephemeral（临时 workflow agent，最省、已验证）；迭代型、多轮的分析型 goal 用 persistent（持久 teammate，首轮投生，后续轮只投递”委托书修订”——新增约束、验收标准变化、范围收窄，禁止开放式对话）。

第 0 步实验里，持久执行者在第二轮直接复用了第一轮自己的结论，墙钟约减半。这是一次具体的实验观察，而不是对所有任务的普遍保证。

记忆是特性，但记忆的边界必须与 goal 的边界重合。

配套的还有审计与可视化：每轮结构化结果落 round-<goalId>-<N>.json，goal 板整值快照落盘、宿主重启后可恢复；客户端的「目标」页签实时展示每个 goal 的状态徽标、轮次和当前 subgoal，「控制」页签递归展示全部 agent 的运行状态。你随时能看到回路此刻转到了哪一环。

roles 配置允许按角色为不同的 sub agent 指定模型：

- id: dsh-cybernetics
  config:
    roles:
      default: { provider: zai-coding-cn, model: glm-5.3 }
      verify:  { provider: zai-coding-cn, model: glm-5.3 }
      writer:  { provider: zai-coding-cn, model: glm-5-turbo }

roles 这套角色化分工，让我想起 Ashby 的必要多样性定律（Law of Requisite Variety）。

它给了我一个有启发性的视角：控制系统需要具备足够的有效调节能力，才能应对环境中的多样扰动。代码修改、数据分析、内容撰写和独立验收具有不同的失败模式，因此把它们分配给职责、工具和评估标准各异的角色，可能比让一个通用角色承担全部工作更容易建立有效的调节机制。

但角色数量本身并不保证多样性。多个角色可能共享相同的盲点，使用不同模型也不意味着它们必然具有互补能力。关键在于它们是否具备真正不同的应对策略，以及整个系统能否根据实际反馈选择合适的应对方式。

Ashby 的思想还有另一面：控制器不必穷举每一种情况，抽象、分类和缓冲本身就能降低调节问题的复杂度。

这正是为什么这套协议选择分层——编排者、执行者、验证者各司其职——而不是往系统提示里堆规则：把庞大的扰动空间分类路由给不同的角色，让每个角色只在自己的职责范围内处理问题，再由整个回路根据测量结果决定下一步行动。

这种设计的目标，不是用更多角色简单堆叠智能，而是让有限的角色组合能够更有效地应对多样的任务与失败模式。

Dogfooding：这个范式本身就是在回路上造出来的

这个项目最有自指意味的一点是：它自己的开发过程，就是在”目标—测量—校准”回路上跑出来的。

README 里有一节叫”实测修正”，老实记录了从 v0.2 到 v0.7 每一版是怎么被现实打回来又校准的。挑几件有代表性的。

v0.2 的时候，端到端回路根本没跑通过。

README 里白纸黑字写着”workflow 轮脚本、页签挂载均待首次真实验证”。2026-11-02 第一次实跑，隐式提示注入和工具注册都成功了，执行却在读取编排引擎服务的地方直接抛错——宿主的依赖注入框架对未注入服务的属性访问是零容忍的，异常把 goal 护栏整个打断。

改成静态注入后，插件又卡在启动 pending：原来那个服务是在另一个插件组的隔离环境里提供的，顶层根本拿不到。第三种方案按组 id 注入 patch，dump 配置才发现那个组压根不在顶层索引里，而是嵌在 preset 的 config 对象深处。

最终方案是让插件回到顶层行，运行时经由官方的 root-realm 访问器去读服务——四次实测修正，才换来一次成功的启动。

页签渲染的两连修更像悬疑剧。

页签死活不出现，浏览器里逐步排查：先是手动传入的翻译函数 t 遮蔽了宿主按命名空间注入的正确翻译函数，字典注册前被解析成了空串；修掉之后文本还是全部丢失，最后对照官方插件的编译产物才发现，宿主的 JSX 变体会忽略 jsx(type, props, children) 的第三个参数——children 必须放进 props.children，否则所有文本静默消失、元素塌缩成空胶囊。

两次修复后，两个页签才完整渲染出来。

改个包名也能炸出一条不变量。

包从 dsh-cybernetics 改名成 @mars.liu/dsh-cybernetics 后，客户端 boot 直接报 “loaded without registering”。排查结论：客户端模块图以 package.json 的 name 为行键，注册 id 必须等于包全名；短名只用于 loader 行。这条不变量现在有离线测试断言锁死。

还有 v0.7.4 那次配置面板的实机验证。

我发现开关的保存请求被宿主静默拒绝——profile 文件没变、RPC 错误不上控制台、此前的代码还把失败吞掉了，第一次点击甚至把 promise 挂死在”保存中”。

这一轮的修复是先把失败可见化：写入被拒或超时立即显示”保存未生效”并还原到宿主确认的快照值；宿主侧的根因留待带日志的复现。

看不到的失败等于不存在——至少对于一个试图自动调节自身行为的系统来说，如果关键失败既没有被观察到，也没有反馈给后续决策，那么这个失败就无法成为有效的校准信号。

这些坑没有一个是能靠”想清楚”避开的。每一个都是：设定目标 → 实机运行 → 测量到偏差 → 校准方案 → 再跑。

一个关于反馈回路的系统，用反馈回路开发出来。

Dogfooding 在这里不是营销词，而是这个范式可行性的工程证据：设计假设必须接受实际运行的检验，发现的偏差必须能够改变下一轮实现。不过，这些成功案例证明的是回路在真实开发过程中的实用价值，并不意味着整个协议已经得到形式化的稳定性或收敛性证明。

AI Agent 新范式

回到开头。

最朴素的 LLM 应用范式的典型形状是：人写 prompt，模型一次输出。人是主要的控制者，模型是局部执行者，反馈回路如果存在，也主要存在于人的脑子里和手上——难以审计、难以累积、难以扩展。

而现代主流 Agent 早已不是这样。它们的基本运行方式是一个由多个相互关联的层次组成的循环：会话存储（Conversation Store）保存会话的完整历史，包括消息、工具事件、摘要与执行记录；上下文构建器（Context Builder）决定本次模型调用实际看到什么——从历史中选择相关内容，注入指令与工具定义，再做摘要、裁剪与组装；接着是模型推理（LLM Inference），生成文本、工具调用或结构化输出；然后执行运行时（Agent Runtime）负责执行工具、检查结果、更新状态、判断是否结束。运行时把新事件追加回会话存储、更新任务状态，继续循环，直到完成、失败、被取消或达到执行限制。值得注意的是，这个循环已经包含了”行动-检查-继续”的反馈雏形——但它追踪的仍然是执行状态，还不是目标层面的校准。

Cybernetics Agent 的形状是：人设定目标，一个经反馈回路持续校准的 Agent 系统去逼近它。

目标成了系统里一等公民的持久状态；测量由独立于执行者的 verify agent 承担；校准分成了结构上清晰的两层——内环自动修正执行，外环由人确认目标修订；思考与行动在工具清单的层面被物理分离；每一次行动和每一次判定都尽可能落进可追溯的审计记录。

在这个范式里，人的角色不再局限于逐条 prompt 的作者，而是转向目标的设定者与外环的校准者。人的介入频率可以下降，但目标定义、关键判断和必要的人工授权仍然保留在人手中。

你不再逐句指挥，而是定义什么叫做”对”，然后让回路去逼近，在它拿不准的地方（human 分拣）和它怀疑目标本身的地方（goalItselfQuestionable）介入。这更接近管理者与系统工程师的工作，而不是打字员的工作。

这里需要明确一个边界：把 Agent 编排设计成反馈回路，不等于已经证明这个回路具有经典控制理论意义上的稳定性或收敛性。

LLM 的行为具有不确定性，验收器也可能犯错，环境甚至可能在任务执行期间发生变化。独立验收、显式状态、迭代上限和人工升级机制，都是为了让这个回路更可控、更可审计；至于如何形式化地定义和验证它的收敛性、鲁棒性与稳定性，仍然是后续需要研究的问题。

七十八年前，维纳在《控制论》里系统讨论的反馈、控制与通信思想，参与塑造了此后的自动控制和多个相关研究领域，也为理解生物与机器中的调节机制提供了重要框架。

今天，LLM 让通用的语言推理与任务执行能力变得越来越容易获得，但如何围绕这些能力建立可靠的目标管理、反馈、验收和权限控制机制，仍然是 Agent 应用工程中的核心问题。

Cybernetics Agent 不是又一个 Agent 框架，而是对”Agent 系统该如何被驾驭”这件事的一次重新回答。

当然，这只是开始。

多 goal 的 super-agent 编排、更细的测量维度、回路自身的在线调参——”控制回路能不能控制控制回路”，这个问题与二阶控制论所关注的观察者、系统描述和调节之间的关系存在有趣的联系。

观察者可以成为自己观察对象的一部分，回路的上方也可以继续构建更高层的回路。但每往上增加一层，都需要重新回答几个问题：这一层的观测从哪里来？它依据什么判断偏差？校准由谁执行？它又如何避免把自己的错误判断无限放大？

这些问题不可能只靠增加一个更聪明的模型解决。

但方向我是确定的：下一代 AI 应用竞争的主战场，不在模型的权重里，而在回路的拓扑里。

参考资料：从蒸汽机调速器到维纳的防空火控研究

蒸汽机调速器：反馈思想的工程实践

18 世纪末，博尔顿与瓦特将离心调速机构应用于旋转式蒸汽机，使机器能够根据自身转速的变化自动调节蒸汽供给。现存于英国科学博物馆集团的一台 1788 年博尔顿与瓦特旋转式蒸汽机（Lap engine），是最早安装离心调速器的机器之一，当年用于驱动伯明翰 Soho Manufactory 的金属抛光设备。伯明翰档案馆的 Boulton and Watt Collection 中，还保存有 1788 年调速器与节流阀连接关系的图纸。需要说明的是，瓦特式离心调速器虽然历史悠久，但它并不是离心调节原理的凭空发明，而是既有机械调节思想在蒸汽机上的应用与发展。

机器上的调速器早已有之，而对调速器行为的数学分析则要等到近一个世纪之后。1868 年，麦克斯韦发表《On Governors》，将调速器定义为使机器在驱动力或阻力发生变化时仍能维持近似恒定速度的装置，并进一步研究调速器的动态行为——从真实工程装置出发建立数学模型、讨论扰动与稳定性，这是一篇典型的一手文献。机械反馈实践与控制理论之间，由此出现了清晰的历史连接。当然，麦克斯韦的这篇论文并非建立了现代控制理论的全部基础，它是这一发展史上的重要里程碑。

相关史料：

• 博尔顿与瓦特 1788 年旋转式蒸汽机（英国科学博物馆集团馆藏记录）：collection.sciencemuseumgroup.org.uk
• 伯明翰档案馆 Boulton and Watt Collection 中 1788 年调速器与节流阀连接图纸：calmview.birmingham.gov.uk
• 麦克斯韦《On Governors》（1868）原文：en.wikisource.org

维纳与防空火控：预测、噪声与控制

二战期间，维纳参与了防空火控相关研究。与蒸汽机调速不同，这类问题不仅需要根据观测结果采取行动，还要在观测带有噪声、目标持续运动的情况下预测目标的未来状态。维纳将随机过程与预测理论用于这一领域；美国国家科学院的维纳学术传记明确将其二战期间的防空火控研究与预测理论联系起来，介绍了随机过程理论的应用，并指出他在战后把这些思想发展为跨越数学、工程、生物学与通信的研究纲领。Tufts 大学数学系对维纳的介绍同样提到，他在二战期间研究火炮瞄准（gunfire control）中打击运动目标的问题，推动了平稳时间序列预测理论的发展，所涉及的技术问题包括目标运动、观测误差与未来位置预测。

关于措辞的一个边界：说维纳”参与了防空火控相关研究”是较为稳妥的表述——不宜把维纳描述成独自发明了投入实战的自动防空系统，也不宜把控制论的起源归于某一个军事项目。战后，维纳把控制与通信的思想扩展为一个跨学科框架，1948 年出版的《Cybernetics》是他系统阐述控制与通信思想的代表作，应作为理解控制论整体思想的一手阅读材料。

相关史料：

• 美国国家科学院维纳学术传记（网页版）：nationalacademies.org；PDF：biographicalmemoirs.org
• Tufts 大学数学系维纳介绍：math.tufts.edu
• 维纳《Cybernetics》（1948），Wellcome Collection 馆藏记录：wellcomecollection.org；Internet Archive 扫描本：archive.org

史料与 dsh-cybernetics 的联系

这些是工程设计上的启发与类比，不是已经证明的理论等价关系。控制论史料能够解释这种架构为何值得探索，但不能替代对具体 Agent 系统的实验验证。

项目定位

dsh-cybernetics 的定位是 Cybernetics-inspired Agent architecture——一种受控制论启发的 Agent 架构：尝试将目标管理、任务执行、独立验证、反馈校准和人工监督组织成显式闭环。它目前仍处于早期工程探索阶段，其可靠性、稳定性与适用边界需要通过后续实现和实验来检验。

下一步

这个项目刚刚开始，还远远说不上完整，我还有很多工作要做。目标显示还只是简单的罗列markdown；控制页现在还只是显示agents的状态，并没有像better sidebar的任务状态一样可以跟踪subagent的内部；配置页也还只是有个雏形，连基本的功能都还谈不上。这个设计的有效性，也还没有经过考验，它到底有没有更快、更节省资源的解决问题，有没有帮助使用者解决更复杂更困难的问题，有没有精确的度量；甚至说，这个想法是否经得起实践验证，一切还刚刚开始。