控制论与智能体编码中的”人在环上（Human-on-the-Loop）”

作者：Dirk Lässig

自 20 世纪 50 年代以来，软件开发的一大瓶颈始终是人类在终端前敲击代码的速度。而今天，这一限制正在悄然消退。随着能够自主生成、测试和重构代码的 AI 智能体（Agents）的崛起，我们似乎即将彻底攻克这一历史性的效率瓶颈。

然而，这也带来了全新的挑战：如今，AI 产出代码的速度极其惊人，以至于人类进行传统逐行手动代码审查的能力，反而成了新的瓶颈。

在软件开发中，人类的引导和塑造依然不可或缺，因为最终的产出必须由人来负责 —— 并且理所应当，我们仍希望保持主导权。换句话说，我们需要有切身利益相关（skin in the game）的人参与到流程中，以确保 AI 智能体忠实地实现我们的意图。但是，如果我们坚持对每一个微小的代码改动都做”人在环中（Human-in-the-loop, HITL）“式的微观审查，我们不仅会限制系统的吞吐量，更会成为整个研发流程的”断裂点（fracture point）”。

这意味着我们要么选择限制智能体的速度，要么沦为”无脑盖章（rubber-stamping）“的工具人，去批准那些我们并未真正理解的代码。

像管理组织一样，领导基于智能体的软件开发

要突破这一”断裂点”，关键在于理解基于大语言模型（LLM）的智能体具有”非确定性（non-deterministic）“。这种非确定性意味着我们不能盲目信任 AI 会把每一件事都做对。但这同样折射出了一个关于人类团队的基本事实：人也同样会犯错。然而，作为由”会犯错的人”组成的复杂交互集合体，企业组织却往往能够实现卓越的业绩并交付极其稳定的成果。他们是如何做到的？正是通过领导层所建立、管理层所执行与引导的结构、流程、能力和行为。

优秀的管理者不会去审查员工所做的每一件事，但他们掌控着整个系统。他们设计组织架构、进行目标管理、在出现异常时予以干预，并设定规则边界，从而让富有成效的自组织结构自然涌现。

领导一个基于智能体的软件开发生命周期（SDLC）面临着极为相似的挑战。如果我们想更上一步、高效地领导 AI 智能体，我们就必须在 SDLC 中承担起全新的”引导和掌舵（Steering）“角色，而不是试图去检查每一行代码。

我相信，要实现成功的掌舵，我们可以从”管理这门手艺（management craft）“中汲取灵感。编排和控制智能体，与管理者领导一个组织有着极多的异曲同工之妙。

💡 示例：由开发者扮演”AI 团队主管（Head of AI Workforce）“的角色。由他们定义成功的衡量标准（例如：将 API 延迟降低 20%），并建立团队结构和流程（例如：让一个智能体编写代码，而让另一个 QA 智能体独立进行验证）。只有当仪表盘提示目标偏离或智能体之间出现分歧时，开发者才会介入。

引入控制论：连接开发与管理的桥梁

对于许多软件工程师来说，将管理视为一门”手艺”甚至”科学”可能会感到有些疏离，甚至有些怀疑。将管理实践应用到软件工程中也并非显而易见。然而，“控制论（Cybernetics）“可以作为二者之间必不可少的桥梁。

这一概念由诺伯特·维纳（Norbert Wiener）于 20 世纪 40 年代提出。控制论是研究复杂系统中的通信与控制的科学，它认为生物体、社会组织和机器都遵循着相同的反馈与调节这一普遍规律。

20 世纪 70 年代，斯塔福德·比尔（Stafford Beer）开发了”可生存系统模型（Viable System Model, VSM）“，将控制论与管理学科紧密连接起来。到了 20 世纪 80 年代，弗里德蒙德·马利克（Fredmund Malik）开始将 VSM 融入其著作《复杂系统管理战略》中，这帮助构成了以控制论为导向的”圣加仑管理学派（St. Gallen School of Management）“的中坚力量。

这一庞大的知识库提供了丰富的科学思想体系，能够帮助软件工程师不再把 AI 智能体系统仅仅看作一个”黑匣子”，而是将其视为一个功能完备、可控、可调节的控制论系统。而且，由于控制论作为一门科学，不仅适用于社会组织，同样适用于技术系统，因此它能极好地作为桥梁，帮我们解决智能体 SDLC 中由于人类试图保持”人在环中”而带来的重重摩擦。

💡 示例：设想一个由智能体驱动的自愈式基础设施。工程师设计了这样一套机制：监控智能体一旦检测到内存泄漏，就会立即触发编码智能体自动修复并打上补丁。在工程师眼中，随之而来的并非几个孤立脚本的简单堆砌，而是一个经典的控制论反馈环 —— 智能体之间的通信通过反馈受到动态调节，从而确保整个基础设施在面临压力时，依然能够保持高可用与稳定运行。

跃升至元维度的”控制”

为了理解人类如何有效引导智能体，我们必须审视控制论的基石之一 —— 罗斯·阿什比（Ross Ashby）的”必要多样性定律（Law of Requisite Variety）”：

“唯有多样性可以吸收多样性（Only variety can absorb variety）。”

多样性缺陷是衡量复杂性的指标，代表了系统不同状态的数量。在 SDLC 的语境下，智能体系统的”多样性”表现为在机器速度下产生的海量代码变更、架构决策和缺陷修复。为了控制这一点，人类必须具备”必要的多样性”（即同等或更多的状态处理能力），但这往往超出了人类的认知极限。

如果人类试图在具体的代码执行层，通过”人在环中（In-the-loop）“来死磕这种多样性，那么必然会以失败告终或导致流程大幅放缓，从而反而降低了多样性，并最终削弱了智能体系统的速度与能力。

自然地，人类必须跳出”问题-解决（Problem-Solution）“层面，移动到更高的抽象维度：元维度（meta level）。弗里德盟德·马利克将其称为元系统控制（meta-systemic steering）。这就是处于”人在环上（Human-on-the-loop）“的真正含义。这是通过塑造智能体系统、设计并配置它以实现期望目标、并加入适当的机制来引导智能体向这些目标迈进而实现的。

跳出系统：人类设计与配置智能体系统

上述的控制机制使智能体系统的多样性与人类的能力（多样性）达到一种内稳态（homeostasis）—— 这是一种动态平衡，在此状态下双方都能保持稳定且方向一致。

因此，为了跳出”问题-解决”层并在元维度进行控制，我们必须拥有正确的传感器（Sensors）和指南（Guides）。

人在环上（Human on the loop）终极控制模型

这便完整构建了我们的”人在环上”模式：智能体系统自主运行其内部的反馈闭环，而身处外部的人类则在系统层面上进行领航。

在设计支持人类控制智能体的机制时，我们应该从控制论的两个核心手段中汲取灵感：

1. 衰减（Attenuation）

通过过滤或聚合，来衰减来自智能体系统侧的超高多样性，避免让人类侧过载。

例如：

• 将高频输出物聚合为浓缩的标准化报告或仪表盘（如：代码质量趋势、智能体任务成功率指标）。
• 仅基于预设的阈值向上级升级”异常情况”（Exception Handling）。
• 促进智能体系统内部的自我管理（就像一个成熟的敏捷团队能够在没有管理层日常介入的情况下，自行解决更复杂的局部问题）。

💡 示例：开发者不再去阅读 QA 智能体每天生成的 200 个冗长日志，而是配置一个仪表盘，仅在测试成功率指标跌破 98% 时才向人类发出警报。这有效地过滤掉了噪音（衰减了多样性），使其在人类有限的认知带宽内变得可控。

2. 放大（Amplification）

放大来自人类侧的多样性，以更高效、规模化地影响 AI 智能体。

例如：

• 将架构和准入决策规则编码进智能体全局策略中（例如通过项目根目录下的 AGENTS.md）。
• 为智能体提供包含特定业务领域或核心技术规范的统一知识库。
• 将控制权分散给多个人类角色或整个平台工程团队。
• 通过培训和先进的思维模型，深化人类对系统整体状态的理解。

💡 示例：开发者编写了一份详尽的 DESIGN_PRINCIPLES.md 文件，其中包含明确的安全规范和编码风格标准。通过将这份指南注入所有智能体的上下文（Context）中，他们将自身作为个体的技术影响力，成百倍地放大到了整个代码库中。

针对这种衰减与放大，业界最近提出了一个新词 —— 安全套件工程（Harness Engineering）。它的意思是为智能体系统内部的高多样性构建一个稳固的”安全套件（Harness）”。

寻找合适的衰减与放大方法，要求管理侧对智能体系统拥有足够精确的模型。这就是康南特-阿什比定理（Conant-Ashby Theorem）：

“系统的任何优秀调节者都必须是该系统的模型（Every good regulator of a system must be a model of that system）。”

这一理论表明，想要控制智能体系统的人类必须深刻理解系统本应如何运行。通过为 SDLC 设计和配置智能体，人类将形成一个初始的”思维模型”。但在现实中，实际运行的技术系统可能会与该模型产生偏差（例如发生模型漂移，或在某些未预料到的极端情况下失败）。这就是为什么我们需要引入最后一个元素，来促成”人在环上”模式的最终闭环。

在智能体系统中践行”现地现物（Go See）”

为了使整幅控制论图景更加完整，我想引入另一项来自精益（Lean）管理的成功实践。如果说元维度（Meta level）是我们实施全局控制的地方，那么 Gemba（现场/源头）就是我们验证控制是否真正与现实相连的地方。在软件开发中，Gemba 指的就是创造价值的实际场所 —— 也就是智能体与代码、仓库打交道的微观世界。

在精益管理中，“现地现物”（Go See，或称 Genchi Genbutsu）是指管理者离开高高在上的象牙塔，亲自深入到生产第一线去。对于基于智能体 SDLC 的工程师而言，这意味着尽管他们主要承担着智能体系统管理者的角色，但他们不能完全只依赖仪表盘传感器和指南策略来领导。

工程师必须定期、偶尔地”降维”回到微观的”问题-解决”层面。

将”现地现物”反馈环融合进”人在环上”模型

结构上，“现地现物”的回归是绝对必不可少的，因为它能保持工程师用于控制的思维模型处于最新、最准确的状态。

大语言模型可以生成看起来极其精美、能顺利通过单元测试并满足表面需求的代码，但它同样可能悄悄引入代码退化（Code Decay），或包含自动化传感器无法轻易标记的隐性”幻觉（Hallucinations）”。

传感器通过聚合和过滤来”衰减”多样性，而”现地现物”则刻意逆转了这一过程 —— 让人类重新直面繁杂的微观现实。凭借自身的工程专业技能和在软件工程中沉淀的实战经验，人类能够敏锐地识别出未知的失败模式、检测出潜在的代码坏味道（Code Smells），并感知智能体是否在以正确的方式做正确的事。

通过对特定代码模块进行手动的、随机的抽样检查（Spot-checks），工程师将人类的技术直觉转化为了整个控制论系统中最顶级的感知输入。

💡 示例：某位开发者平时主要通过仪表盘关注质量指标，并不断优化智能体的全局 Prompt 策略。然而，每周五下午，他们会进行一次”现地现物” session：随机挑选由编码智能体生成的 3 个复杂 PR（Pull Request），并开展深度的手动代码审查。在审查中，他们可能会惊喜地发现，尽管代码通过了所有的自动化测试，但智能体却使用了一种非常低效的数据结构，这在未来高并发流量下会引发严重的扩展性（Scaling）问题。

此时，开发者就需要重新修正他们对系统能力的模型评估，并改进安全套件（Harness），以便在未来引导智能体选用更合适的数据结构。同时，他们也可能会调整智能体流水线设计，以期在未来更早地自动检测出此类可扩展性问题。

这种对控制行为的阶段性校准，能够确保外部的传感器没有过滤掉残酷的真相，并且制定的指南在真实的代码世界中切实产生了预期效果。“现地现物”是一种修正机制；它应当成为”人在环上”系统中固定的、不可或缺的次级反馈闭环。在组织学习理论中，这实际上正是双环学习（Double-loop Learning）的经典应用。

结语

从”人在环中（Human-in-the-loop）“向”人在环上（Human-on-the-loop）“的范式转变，正是软件工程这一职业在 AI 时代的进化史。

探索控制论与管理艺术，为我们在这场变革中提供了坚实的学科底层支撑。它科学地解释了该如何塑造全新的智能体协作系统，使其既能享有机器带来的极致速度，又不会失控，从而持续创造出可靠且一致的业务价值。

在这一背景下，未来的软件工程师和系统架构师实质上正在转变为”控制论系统设计师（Cybernetic System Designers）“。如果他们能做到以下几点，就必将在智能体时代大放异彩：

• 应用控制论（Applying Cybernetics）：深刻理解并善用控制论概念，在人机的演进中精准平衡系统多样性。
• 学会控制与掌舵（Learn Steering）：积极采纳先进的管理学实践，将 AI 智能体作为高产出的团队组织来编排和管理。
• 践行”现地现物”（Practicing “Go See”）：拒绝只看 KPI 报告，定期深入编码一线，用人类直觉和经验不断更新技术思维模型。

这也向我们揭示了一个硬币的两面：在未来，单靠抽象的管理和控制技能是不够的。“现地现物”的有效性依然深度依赖于人类扎实的技术专家经验和对代码的敏锐直觉。因此，留给整个行业思索的终极问题依然存在：当大部分代码都由 AI 代劳时，我们又该如何为下一代人类开发者保持并培养这些至关重要的、核心的技术直觉与工程硬实力？