看到“ Harness 其实就是控制论”这个说法，我觉得有道理，但还可以再往下走一步。
如果只说 AI 圈又把 80 年前的东西包装成新词，这个判断当然痛快，也有一点真实。但它会把事情说小。更准确的地方在于，AI agent 正在把工程师重新带回一组很老的问题：一个系统怎样观察环境，怎样接收反馈，怎样限制动作，怎样校正偏差，怎样验证结果，怎样分配人与机器之间的责任。
这些问题过去一直存在，只是没有那么尖锐。模型只负责回答问题的时候，错误大多停在文本里。回答错了，可以重问；总结偏了，可以重写。到了 agent 阶段，模型开始调用工具、读写文件、修改代码、发请求、触发流程，错误会进入环境，留下后果。于是工程重心自然变化。问题不再只是在于它会不会回答，而在于它能不能被约束、观测、回滚和验证。
过去几年，AI 工程的词换得很快。最早大家谈 Prompt Engineering，研究怎样把任务说清楚，怎样给示例，怎样让模型少误解。后来 Context Engineering 变得重要，因为复杂任务的质量，经常取决于模型看到了什么材料，系统如何检索、压缩、排序和更新这些材料。
现在又轮到 Harness Engineering。
这里的 Harness，大致可以理解为模型周围的一整套运行脚手架：上下文选择、工具接入、权限、记忆、任务状态、可观测性、反馈、验证、人工介入记录。它关心的不再是一段输入写得好不好，而是一个模型被接入真实流程以后，系统怎样让它稳定工作。
这不是单纯的赶时髦。它反映的是工程重心从单次输入，转向系统闭环。模型只负责生成一段文本时，prompt 是主要界面；模型要长期处理任务时，context 变得关键；模型开始行动以后，harness 就成了必要条件。
一个没有 Harness 的 agent 系统，就像把一个能力很强但状态不透明的执行者直接接进生产环境。它可能知道目标，却未必知道边界；可能能调用工具，却未必知道什么时候停手；可能能改代码，却未必能判断改动有没有破坏其他模块。
Harness 处理的也不是“让模型更聪明”这一件事。它处理的是一个行动系统怎样可靠运行。模型周围需要传感器，知道任务进行到哪里；需要权限边界，知道哪些动作可以做，哪些动作必须请示；需要日志和轨迹，能回看判断链路和外部动作；需要验证机制，让结果接受测试、审查或人工确认；需要介入机制，让人类能在关键点接管、纠偏或终止。
这就和 Norbert Wiener 在 1948 年《Cybernetics: Or Control and Communication in the Animal and the Machine》里讨论的“控制与通信”接上了。控制论关心的不是某个部件是否聪明，而是一个系统怎样通过信息流、反馈和调节，在变化环境里维持目标导向的行为。
今天的 agent 系统同样有目标、传感器、执行器、反馈回路和环境扰动。用户给出任务，系统收集上下文，模型生成计划，工具执行动作，日志记录结果，验证器检查输出，人类在必要处介入。所有这些看起来很现代，底层问题却相当古老：一个会行动的系统，怎样在不确定环境里维持可接受的行为。
控制论重新变得有用，不是为了给 AI 工程找一个经典祖先。真正的原因是，agent 让“控制与通信”从理论语言重新变成工程日常。只要模型开始改变外部状态，反馈就不能只是装饰；只要任务持续时间变长，状态管理就不能只是附属功能；只要错误会扩散，约束、验证和责任分配就必须进入设计中心。
Ross Ashby 的 requisite variety，也可以放到这里理解。环境越复杂，控制系统本身就越需要足够多样的状态、传感器、行动手段和反馈通道。控制系统的复杂度如果低于环境复杂度，系统迟早会被环境压垮。
这对 AI agent 很直观。让 agent 处理一个单步写作任务，所需的 variety 很低：输入、输出、修改即可。让 agent 处理一个跨仓库代码任务，环境复杂度立刻上升：文件结构、依赖关系、测试结果、已有改动、权限边界、用户偏好、外部 API、失败恢复路径，都会影响结果。
如果 Harness 只给模型一段很长的 prompt，却不给它可靠的状态表示、工具反馈、测试入口和权限控制，就等于让一个单薄的控制结构去应对高复杂度环境。结果通常不会表现为一次性崩溃，而会以更隐蔽的方式失控：重复尝试、误判成功、覆盖他人改动、调用错误工具、在错误前提上继续推进。
好的 Harness 会增加系统的有效 variety。它让 agent 能看到任务状态，而不是只看到聊天记录；能区分可逆动作和高风险动作；能在执行后获得真实反馈，而不是只靠语言自评；能根据测试、日志、审查结果调整下一步；能在不确定性过高时请求人类判断。
这里的复杂度不是堆料。更多规则、更多 prompt、更多工具，未必带来更好的控制。规则太多会让系统僵硬，工具太多会放大误用，prompt 太长会制造新的歧义。真正有用的 Harness，是让系统拥有足够多的观察和调节能力，同时把风险限制在可承受的范围里。
所以，一个好的 Harness 首先要让状态可见。agent 不应该只在一长串对话里迷路，它需要明确知道当前目标、已完成步骤、待验证事项、外部环境变化和失败记录。状态一旦可见，系统才有可能判断下一步是否合理。
其次是权限分层。读文件、写文件、发网络请求、改生产配置、触发支付或发布内容，风险完全不同。一个成熟系统会把动作按风险分级，低风险动作自动执行，高风险动作需要确认，关键动作保留审计链路。权限不是不信任模型，它是让信任可以持续的结构。
第三是反馈真实。很多 agent 失败，并不是模型完全不会做，而是它没有收到足够清晰的环境反馈。代码改完要跑测试，内容生成后要做事实检查，流程触发后要确认外部状态。验证应当靠系统信号，而不能只靠模型说“已完成”。
第四是错误可恢复。行动系统一定会错，工程上真正要关心的是错误发生后能否定位、能否回滚、能否把损害限制在小范围。日志、版本、沙箱、事务、人工接管点，都是 Harness 的一部分。能承认错误并管理错误的系统，比假装永远正确的系统更可靠。
最后是责任可分配。agent 做了什么，工具返回了什么，人类在哪一步批准，系统在哪一步放行，这些都要留下记录。责任分配不是为了事后甩锅，而是为了让组织敢于把 agent 放进真实流程。没有责任边界，自动化越强，采用阻力越大。
Harness Engineering 这个词也许会流行，也许会被下一个词替代。词本身没有那么重要。重要的是，AI 工程已经从“如何让模型说出更好的答案”，走向“如何管理一个会行动的系统”。
控制论提供了一种冷静的视角。它提醒我们，智能一旦进入环境，就必须讨论观察、反馈、约束、校正和验证。Ashby 的 requisite variety 又进一步说明，复杂环境不能靠单薄控制结构硬撑，系统自身必须拥有足够丰富的状态、感知和调节能力。
所以，说 Harness 其实就是控制论，有道理。但更值得写下来的，不是新概念和旧理论谁赢了，而是 AI agent 正在把工程师带回一组无法绕开的老问题。
AI 工程越往后走，可能越像一门古老的工程学：管理一个会行动、会出错、会在环境里留下后果的系统。
资料参考：Norbert Wiener, Cybernetics: Or Control and Communication in the Animal and the Machine；W. Ross Ashby, An Introduction to Cybernetics。