Harness Engineering：用控制论看 Agent 时代的软件工程

从 Kubernetes 的声明式协调到 AI Agent 的自主编程工程系统越来越像一个需要被设计、观测和校正的闭环。这篇文章想讨论的是为什么控制论提供了一个理解 Harness Engineering 的好视角并以此得到实践上的启发。一、引言什么是 Harness Engineering2025 年下半年以来Claude Code、Codex 等 Coding Agent 迅速走红。越来越多工程师发现自己花在“亲手写代码”上的时间在减少花在“搭建一个让 Agent 稳定产出好代码的环境”上的时间在增加。OpenAI 在 2026 年初的一篇文章里用Harness Engineering来概括这种新的工程实践。Harness这个词很有意思。它的本义是“挽具”也就是套在马身上的绳索和皮带系统。挽具不替马奔跑但它负责控制方向、传递力量、施加约束。没有挽具再强壮的马也可能只是在旷野里乱跑有了挽具力量才会被引导到有用的方向上。Harness Engineering 想表达的正是这层含义我们不是替模型完成任务而是为模型设计一套“挽具”让它在真实环境中更稳定地达成目标。这套“挽具”包括什么架构文档、AGENTS.md指令文件、自动化测试、自定义 Linter、CI/CD 管道等等。它们共同构成了一个运行环境一个让 Agent 能够可靠产出正确代码的系统。但如果我们只把 Harness Engineering 理解成一组“工具链”就会错过它更深的一层含义。二、从 Prompt 到 Context 到 Harness人类角色的上移Prompt Engineering 阶段我该怎么告诉模型去做2023 年前后我们在学习如何与 LLM 对话。写好一个 Prompt就能得到一段还不错的代码。这个阶段的核心技能是“措辞”用对词、给对例子、选对格式。那时我们常常在对话框里写“你是一个资深的软件工程师现在有一个问题……”Prompt Engineering要解决的核心问题是如何写出一轮效果更好的提示词。大家关注的是各种提示技巧角色设定、few-shot、思维链、格式约束等等希望借此让模型这一轮的输出更好。这些技巧当然有价值但它们本质上是人类为了适应 AI 总结出的阶段性经验。随着模型能力不断增强AI 适应人类的速度往往比人类适应 AI 的速度更快。有些技巧在更强的模型上已经不再重要甚至会约束模型本可展现的能力——比如过度详细的 step-by-step 指令在强模型上反而会降低输出质量。更上层的概念 —— Context Engineering 开始进入人们的视野。Context Engineering 阶段我应该如何组织模型的上下文随着模型能力提升、上下文窗口扩大模型开始真正进入软件开发场景。以 2024 年爆火的 Cursor 为例它把人类、模型与 IDE 能力更紧密地组织在一起人类通过、cmd k、cmd l等交互方式主动补充上下文模型也能借助 IDE 暴露的能力比如代码检索、文件读取等按需获取解决问题所需要的信息。Context Engineering要解决的核心问题不再是”怎么把更多信息塞进窗口”而是”在某个任务、某个时刻模型到底需要看到什么”。这件事之所以难是因为上下文的两种失败模式都很致命太少模型会凭空猜测写出签名完全不兼容的代码太多模型又会淹没在噪音里输出质量反而下降。围绕这个问题行业陆续发展出 offload、retrieve、isolate、cache 等一系列最佳实践限于篇幅不展开。但 Context Engineering 解决的仍然是”单次交互中模型该看到什么”的问题。它还没有回答一个更根本的问题当 Agent 可以自主执行多步操作时如何确保整个过程持续收敛而不是越跑越偏Harness Engineering 阶段我应该如何设计反馈回路到了 Coding Agent 时代事情又继续向前推进。Prompt 没有消失Context 也没有消失但它们都开始被放进一个更大的系统里。Agent 不再只是“请求-响应”式的工具它可以自主规划、执行多步操作、运行测试、读取错误信息、修复问题从而形成一个自主循环。几乎所有长期使用 Claude Code 或 Codex 的人都会提到一个经验给 Agent 一个清晰、可验证的目标非常重要甚至可能是最重要的技巧没有之一。这也是 Harness Engineering 的核心问题如何把 Agent 放进一个可控、可验证、可恢复、可持续改进的运行系统里。OpenAI 在同一篇文章里总结过一些内部实践比如为 Agent 建设可观测性工具栈让模型可以读取日志、链路追踪和指标并根据这些信号判断任务是否完成为模型构建足够的产品上下文让 Agent 能像新加入团队的工程师一样从不同系统中获取知识将架构约束和工程品味编码进系统通过自定义 lint、结构测试等方式机械地约束 Agent 生成的代码如果把这几件事放进同一个框架里看会发现它们都指向同一个问题不是“如何让模型一次回答得更漂亮”而是“如何让系统在多轮运行中持续收敛”。这里的关系不是替代而是递进。Prompt 仍然是 Agent 接收任务和约束的入口Context 仍然决定 Agent 能否看见完成任务所需的信息Harness 则把 Prompt 和 Context 一起放进一个可观测、可验证、可纠偏的运行系统里。人类工程师发挥价值的层次也因此逐级上移先把话说清楚再把信息组织清楚最后把反馈回路设计清楚。串起这三个阶段会看到一条很清晰的上移路径人类工程师的角色并不是被替换而是在不断上移。从 Prompt Engineering 阶段的指令发出者到 Context Engineering 阶段的信息组织者再到 Harness Engineering 阶段的系统设计者人类关注的对象越来越从”眼前的一次输出”转向”支撑持续收敛的整个系统”。这个方向最终会导向一个非常鲜明的结论人类正在从”亲自做事的人”上移到”设计让事情被正确完成的系统的人”这个位置。为什么是控制论一旦工程师的工作从”亲自执行”转向”定义目标、组织观测、设计纠偏机制”问题的本质就从”求解”变成了”控制”。我们不再是一次性把答案写出来而是让一个系统在不断变化的环境中持续逼近期望状态。而研究”如何通过反馈让系统收敛”的学问正是控制论。控制论关心的不是某个组件有多聪明而是目标、观测、比较、行动和反馈如何连接成闭环。理解了这一点我们就能明白Harness Engineering 不是一组零散工具而是一种反馈控制系统的设计实践。三、一个熟悉的模式反馈控制系统从最基本的意义上说一个反馈控制系统通常包含几个元素目标状态、对现实的观测、对偏差的计算、纠偏动作以及把结果重新送回系统的反馈回路。只要一个系统依赖这种循环来维持稳定它就是控制论意义上的系统。这个抽象听起来有点理论但在现代工程里其实非常常见。Kubernetes 就是最典型的例子之一。Kubernetes 的关键价值不只是自动化而是它把基础设施管理改写成了一个闭环先定义目标再观察现实再计算偏差再执行纠偏。只要这个循环不停系统就能在节点故障、流量波动、资源漂移等扰动下持续逼近期望状态。for { desired : getDesiredState() // 读取 YAML 声明的期望状态 actual : getActualState() // 观察集群当前实际状态 diff : compare(desired, actual) if diff ! empty { reconcile(diff) // 执行动作创建/删除/更新资源 } wait(syncPeriod) // 等待然后再来一轮 }在 Kubernetes 出现之前工程师管理基础设施的方式更多是命令式的SSH 登录机器、重启进程、扩容实例、处理告警、执行脚本。系统一旦偏离预期人就必须亲自介入把它拉回正确状态。Kubernetes 改变了这件事。工程师不再需要持续地下达具体命令而是转向定义“什么是正确的状态”再由控制器通过调谐循环持续纠偏。用控制论的语言看这个循环非常标准desired state 是设定点actual state 是被观测对象的状态compare 用来计算偏差reconcile 是控制动作而 sync period 决定了系统感知和纠偏的频率。Kubernetes 之所以重要不只是因为它“自动化了运维”更是因为它把运维问题改写成了一个可持续收敛的反馈控制问题。工程师的职责也随之上移从编写运维脚本、执行具体操作逐步上移到定义目标状态、设计控制器、把领域知识编码进 Kubernetes 的 Operator。如果说 Kubernetes 控制的是容器、服务和集群资源那么 Harness Engineering 控制的就是 Agent 与任务环境之间的交互过程。人类同样不再负责每一个具体动作而是定义任务目标、验收标准和约束条件真正持续执行“观察、比较、纠偏”循环的则是由提示词、架构文档、测试、日志、CI 和审批机制共同组成的 harness。OpenAI 曾提到有内部团队借助 Codex Agent在很少的人力投入下构建出大规模代码库。工程师并不手动编写每一行代码他们更多在做的是设计架构文档、编写AGENTS.md、构建自动化测试、配置 CI 管道、校准 Linter 规则。换句话说他们主要在设计这个闭环本身。于是控制论就不只是一个修辞上的类比而是一个很有解释力的观察框架它能帮助我们理解 Harness Engineering 关心的核心问题正是如何让系统在扰动中持续逼近期望状态。四、用控制论理解 Harness Engineering有了对控制论的直觉我们就可以更具体地回到 Harness Engineering 本身。控制论由诺伯特·维纳在 1948 年系统化提出今天再看 Agent 时代的软件工程它依然提供了一套很有解释力的语言。当然这里说的不是数学意义上的同构也不是逐项一一对应。更准确地说控制论提供了一组观察坐标让我们更清楚地描述 Harness Engineering 里的目标、观测、决策、执行与反馈。下面不妨沿着这些坐标逐一展开。设定点Set Point什么是“正确”在控制论中设定点是系统的目标状态比如恒温器的目标温度、自动巡航的目标时速。在 Harness Engineering 中设定点可以理解为你对代码库的期望架构分层规则、命名约定、依赖方向、性能基准。这些期望被编码在AGENTS.md、架构文档、黄金规则之中。OpenAI 团队有一个很关键的洞察如果你不把“好”的定义外化为机器可读的形式Agent 在第一百次运行时仍然会犯第一次那样的错误。Agent 不会通过耳濡目染来学习。你脑海里的“品味”和“直觉”团队熟悉的最佳实践必须变成写下来的规则。这就是设定点的作用把模糊的“应该如何”转化为明确、可度量、可检查的标准。传感器Sensor感知偏差传感器的作用是感知系统的实际状态并将它与设定点进行比较。在传统软件工程中我们其实已经有不少接近“传感器”的机制传感器感知的属性编译器语法正确性测试套件行为正确性Linter风格一致性但这些传感器只能感知可以机械检查的属性。更高层的问题比如“这个改动是否符合系统架构”“这个抽象在代码库扩展时会不会出问题”传统上往往没有传感器只有人类判断。从控制论视角看Harness Engineering 在两个方向上扩展了传感器的覆盖范围。第一个方向是用传统工具覆盖更多可机械检查的属性。自定义 Linter 可以检查架构分层是否被违反比如 UI 层不得直接导入 Service 层结构性测试可以验证模块边界是否完整依赖方向检查可以防止循环引用。这些事情本身不需要 LLM但过去常常因为“人记着就行”而没有被编码为自动化检查。Agent 的到来反而倒逼工程师把这些隐性规则外显成机器可执行的传感器。第二个方向才是 LLM 带来的真正新能力在语义层面构建传感器。比如让 Agent 评估一个改动是否符合文档中定义的设计原则扫描代码中是否存在“AI 糟粕”机械、低质量的生成模式或者判断一段新代码是否与代码库既有风格一致。这些判断涉及自然语言理解和上下文推理传统工具难以胜任。OpenAI 团队的做法就是在这两个方向上同时推进从编译和测试到架构合规性的自动化检查再到语义层面的 AI 辅助审查。每增加一个传感器Agent 写出的代码就更有可能收敛到预期状态。控制器Controller决定如何纠偏控制器根据传感器给出的状态以及它与设定点之间的偏差决定系统下一步应该采取什么动作。在 Harness Engineering 中控制器的角色通常由两部分共同承担。一部分是确定性的编排规则CI pipeline 的条件分支比如测试失败就阻断合并重试策略比如失败后最多重跑三次审批门控比如高风险操作必须由人确认工具权限边界比如 Agent 可以读文件但不能随意编辑。这些规则不负责语义判断但它们框定了系统的决策空间。另一部分是LLM 的语义推理。当 Agent 读到一条测试失败信息它需要理解错误的含义、定位问题根因、决定该改哪段代码。这类判断很难用固定的 if/else 写死需要模型的推理能力。两者的分工是编排规则回答“什么时候该行动、能在什么边界内行动”LLM 回答“具体该怎么行动”。好的 harness 设计不是让模型承担全部决策而是先用确定性规则尽量收窄决策空间再把真正需要语义判断的部分交给模型。执行器Actuator把控制信号施加到真实世界执行器的作用是把控制器的决策真正施加到系统上。在恒温器里执行器是加热器在 Kubernetes 里执行器是负责创建、删除、更新资源的那套机制。在 Harness Engineering 中执行器可以理解为 Agent 可以驱动的那组操作接口文件编辑器、Shell、浏览器、测试命令、Git、CI/CD API甚至日志和监控系统的查询入口。它们把“下一步该做什么”的判断落实成真实动作修改代码、运行测试、读取报错、提交 PR。这样看LLM 更像是决策环节的一部分而不是执行器本身。真正的突破在于模型第一次可以基于高层语义选择合适的工具、组织合适的动作再把这些执行器组合起来作用于代码库。过去编译器能发现错误却不能修复设计问题脚本能自动执行却缺乏语义判断。今天Agent 第一次把“理解问题”和“执行修改”连接在了一起代码库也因此第一次成为一个可以被持续闭环控制的对象。反馈回路Feedback Loop让系统自我纠正控制论的核心不是任何单个组件而是这些组件形成的闭合回路传感器感知控制器比较执行器行动行动结果再被传感器重新感知。只要这个循环持续运转系统就能在扰动中保持稳定。Harness Engineering 中最典型的反馈回路是ounter(line Agent 生成代码 - 运行测试 - 发现失败 - Agent 读取错误信息 - Agent 修复代码 - 再次运行测试 - ...但更有价值的是更大尺度上的反馈回路ounter(lineounter(lineounter(lineounter(lineounter(line Agent 提交 PR - 发现架构违规 - Agent 修复 - 通过 ↓ 类似违规反复出现 ↓ 工程师更新 AGENTS.md 和 Linter 规则 - Agent 从源头避免违规这种双层反馈结构也就是 Agent 层面的短回路和人类层面的长回路正是 Harness Engineering 的精髓。短回路处理日常偏差长回路优化系统本身。一个完整的闭环把上面几个组件串起来看一个具体的例子。假设你要让 Agent 给订单服务新增取消订单接口。设定点是你在任务描述里写下的验收条件接口路径、允许取消的状态、错误码约定、审计日志要求、测试覆盖范围。传感器是编译器、单元测试、集成测试、自定义架构 lint比如Handler 层不得直接依赖 Repository。Agent 生成代码后这些传感器立刻给出信号。如果架构 lint 报错Handler 直接导入了 repository 包这个误差信号会被送回 Agent。控制器——也就是 CI 编排规则加上 Agent 自身的推理——决定下一步动作Agent 理解报错含义把数据访问逻辑移到 service 层。然后执行器文件编辑器、Shell把修改落地测试重新运行。这就是一轮短回路。如果类似的架构违规在多个 PR 里反复出现工程师会介入长回路更新AGENTS.md在任务模板里预置分层约束甚至加一条新的 lint 规则。从此Agent 在生成代码时就已经知道这条边界违规从源头被消除。整个过程里没有一个组件是孤立的设定点给出方向传感器感知偏差控制器决定纠偏策略执行器落地修改反馈回路把结果送回起点。这就是控制论视角下的 Harness Engineering。五、从认识到实践如果前面几节是在建立一个理解框架那么接下来的问题就是把这些认识落到工程实践里怎样的 harness才能让系统更稳定、更可靠、更少发散从控制论的角度看答案并不神秘。我们要做的无非是把目标定义得更清楚把观测做得更充分把误差信号设计得更可操作把动作边界控制得更稳再让整个系统拥有记忆、层次和自我清理能力。1. 明确目标值让 Agent 知道什么叫“完成”控制系统没有设定点就不可能收敛。Agent 也一样。很多失败并不是模型不会做而是任务本身没有被定义成一个可以验证的目标。不要只说“加一个取消订单接口”或“把订单状态改对”。更好的写法是把目标拆成接口行为、业务规则、兼容边界、验收条件和失败条件。比如假设你要在订单服务里新增“取消订单”能力可以这样定义新增POST /api/orders/{id}/cancel接口只允许取消PENDING_PAYMENT和PAID_PENDING_REVIEW状态的订单订单不存在时返回404状态不允许取消时返回409未登录或无权限时返回401/403取消成功后必须写入order_events审计记录并保存cancel_reason、cancelled_by、cancelled_at不得修改现有下单、支付、查询接口的响应结构必须补齐单元测试和集成测试至少覆盖成功取消、重复取消、越权取消、并发重复请求四类场景如果需要数据库迁移必须提供迁移脚本、回滚方案并说明对历史数据和索引的影响任一测试失败、出现状态机漏洞或审计日志缺失都不能算完成人类工程师过去可以在模糊目标里边做边想但 Agent 更依赖外显的完成条件。你定义得越具体系统的收敛方向就越稳定。2. 增强传感器让 Agent 真正看见系统状态没有传感器就没有反馈回路。Agent 之所以经常“自信地做错”很大程度上不是因为它不会推理而是因为它看不见足够多的现实信号。一个实用的 harness至少应该逐步把下面这些状态暴露给 Agent测试结果单元测试、集成测试、端到端测试运行时信号日志、指标、链路追踪界面状态DOM、截图、浏览器行为环境状态文件系统、配置、依赖、进程状态OpenAI 在文章里提到他们把日志、指标、链路追踪和浏览器能力直接暴露给 Codex。这样“把启动时间降到 800ms 以下”就不再是一句模糊要求而变成了 Agent 可以自行观测、自行修正的闭环任务。3. 设计更好的误差信号让反馈能直接指导下一步动作反馈不是越多越好而是越可操作越好。一个控制系统最怕的不是没有误差而是误差信号太噪、太模糊或者根本无法指导纠偏。一个坏反馈是architecture violation一个好反馈是HTTP Handler 层禁止直接依赖 repository 包。请将数据访问逻辑移动到 service/usecase 层参考 docs/architecture/layers.md并运行 golangci-lint run 与 go test ./... 重新验证。OpenAI 提到他们会在自定义 lint 的报错里直接写入修复指引。这个细节非常关键因为它等于把“发现偏差”和“提示修正路径”合并进了同一个信号里。对 Agent 来说最有价值的错误信息不是“你错了”而是“你错在哪里下一步该怎么改”。4. 限制执行器让 Agent 在边界内行动“限制执行器”听起来像一个抽象概念但在今天的 Agent 工具里它最直观的体现其实就是权限管理。以 Claude Code 和 Codex 为例它们都把“Agent 能做什么、做到哪一步需要人类确认”设计成了一等公民。Claude Code 会把工具调用放进显式的权限模式和规则系统里可以选择默认模式也可以切到只规划不执行的 plan mode并通过 allow / ask / deny 规则把权限细化到具体命令。Codex 则把执行边界直接暴露为 sandbox 和 approval policy比如 read-only、workspace-write、danger-full-access以及按需审批、对不受信任命令单独审批等策略。它们的共同点不是界面设计而是都在回答同一个问题Agent 现在到底能读什么、改什么、运行什么、联网到哪里、越界时谁来拍板。这件事之所以重要是因为 Agent 的风险从来不只来自“回答错了”更来自“做错了而且做得太快”。如果一个模型只能读代码它顶多分析失误如果它还能改文件、跑命令、访问外部系统那么同样一次误判后果就可能从“建议不靠谱”升级成“工作区被污染”“测试数据被删除”“生产资源被误操作”。所以好的 harness 不是把 Agent 一股脑放进最高权限里而是把执行能力拆成分层、分区、分审批的边界。实践上这通常意味着三件事低风险动作默认放行读文件、全文检索、查看日志、运行只读命令中风险动作放进受限环境允许在工作区内改代码、跑测试、启动本地服务但受沙箱、目录范围和网络策略约束高风险动作必须显式审批或直接禁止访问生产数据库、调用外部生产 API、批量删除、推送主分支、改密钥和凭证从控制论看这相当于不是让控制器”没有力量”而是避免它把过强的控制信号直接施加到高风险环境里。权限系统的作用不只是安全防线也是稳定性设计。很多时候好的 Harness 不是”让 Agent 什么都能做”而是”让 Agent 在安全边界内自动完成尽可能多的动作并在真正越界时把控制权交还给人类”。以上四点——目标、传感器、误差信号、执行器——关注的是单次循环内如何让闭环跑通。但真实的软件工程不会只跑一次循环。接下来三点关注的是跨循环的系统演化如何让 harness 本身越来越好。5. 代码库即记忆系统记忆系统本质上是设定点和传感器的基础设施如果系统的目标和约束没有被持久化反馈回路就没有参照物。所以记忆系统的意义不是给模型塞更多上下文而是把那些存在于代码之外、却持续影响决策的知识写进仓库。很多关键背景本来就在代码外业务规则为什么这样定、某个兼容分支是在迁移历史数据还是在满足合规要求、哪些客户承诺绝不能破坏。人类可以靠会议和经验补全这些信息Agent 不行对 Agent 来说看不见就等于不存在。这也是为什么代码库不能只保存“现在是什么”还要保存“为什么会变成这样”。业务发展会推动架构不断调整如果没有决策历史Agent 很容易把阶段性妥协当成长期原则。ADR 在这里尤其重要因为它记录的不是代码长相而是当时的选择、权衡和适用条件让后续的人和 Agent 都能理解架构演化的原因。实践上记忆系统可以分层实现用精简的AGENTS.md做导航告诉 Agent 去哪里找规则渐进式披露用docs/、产品文档、领域说明保存业务背景和长期知识用任务计划文档和 ADR 记录任务状态、关键决策和架构变更但记忆系统的关键不只是“写下来”更是“持续更新”。文档和代码的一致性一直很难靠自觉维持传统团队里文档之所以容易过时就是因为改代码有即时反馈改文档没有。到了 Agent 时代代码变化更快这个问题只会更明显。所以记忆系统必须由人和 Agent 共同维护人类负责判断什么值得记录、哪些共识已经变化Agent 负责扫描失效文档、检查交叉引用、补齐结构化更新。OpenAI 也提到过专门的文档 Agent用来周期性发现文档与真实代码行为不一致的问题并提交修复 PR。换句话说“代码库即记录系统”并不是把所有知识都塞进代码而是把会反复影响系统行为的知识版本化、可检索化并纳入持续维护的反馈回路。6. 引入多层反馈回路让系统既快又稳单一反馈回路很难支撑真实的软件工程。如果只有一层很快的反馈比如 lint、类型检查和单元测试Agent 的确能迅速修正局部错误但它也很容易学会另一件事不是把系统做对而是把眼前的检查做过。代码可以通过静态约束却仍然违背架构原则测试可以全部通过真实交互却依然出错。反过来如果只有一层很慢的反馈比如集成测试、人工评审甚至线上告警系统又会变得迟钝。错误总要等到传播得更远、代价变得更高之后才被发现。这就是为什么 Harness Engineering 必须引入多层反馈回路让不同时间尺度、不同抽象层级上的偏差都能在合适的位置被看见、被纠正短回路秒级到分钟级lint、格式化、类型检查、单元测试。负责尽快阻止低级错误扩散像控制系统的内环让 Agent 每一步都能立刻知道自己有没有偏出基本约束。中回路分钟级到小时级集成测试、端到端验证、浏览器自动化、架构检查、PR review。负责验证多个模块是否真的协同工作防止系统只对最容易测量的信号过拟合。很多 Agent 的失败恰恰不发生在语法层而发生在接口层、边界层和语义层。长回路天级到周级线上指标、用户反馈、事故复盘、架构治理、规则更新。负责回答“我们的系统是不是正在慢慢偏离目标”。从控制论的角度看多层回路的价值在于分工快回路负责即时纠偏慢回路负责整体校准内环处理局部稳定外环处理方向修正。好的 harness不只是让 Agent 在当前任务里通过测试而是让每一次偏差都能在合适的层级被吸收把问题逐层向内压缩直到它们不再反复出现。7. 抵抗熵增Agent 时代的“垃圾回收”在 Agent 时代长回路还有一个特别重要的职责做“垃圾回收”。Agent 会以极高的速度复制代码库里已经存在的模式。好的模式会被学习坏的模式也会扩散。一次错误的抽象、一个脆弱的边界、一种临时性的修复方式如果不被及时发现就会在短时间内变成整个系统的新常态。人类工程师写代码时这种扩散是缓慢的但是 Agent 写代码时一个坏模式可能在几小时内被复制到几十个文件里。所以 harness 不能只关注“这次改动对不对”还必须持续清理系统扫描架构漂移回收过期规则把反复出现的问题沉淀为新的测试和约束用小而稳定的治理性修改抵抗代码库熵增。这不是一次性的修补而是对系统稳定性的长期维护。抵抗熵增不能只靠事后清理还要把治理前移到项目初始化阶段。因为一旦一个项目从第一天起就目录混乱、边界模糊、技术选型漂移Agent 只会更快地放大这种混乱。一个能长期维护的项目至少要在一开始就把几件事固定下来功能要尽量内聚模块之间要尽量解耦目录划分要足够清晰多人协作时每个人和每个 Agent 都应该在明确的职责边界内工作而不是不断跨边界修改彼此的区域技术选型也不应该在执行任务时被临时发明出来而应该尽量收敛到团队已经验证过的技术栈上。这也是为什么团队内部的脚手架在 Agent 时代会变得格外重要。它不只是一个提高启动效率的小工具而是一种把秩序提前写进系统的方式。一行命令初始化出来的不应该只是几个空目录而应该是一个已经带着团队约束的项目骨架比如预置符合团队习惯的 DDD 目录结构默认采用团队熟悉的技术栈自动引入内部基础包再通过AGENTS.md把架构原则、模块导航和协作边界写清楚。这样AGENTS.md既是在说明架构也是在为 Agent 提供记忆入口更细的知识则可以在后续执行中按需渐进式加载。换句话说脚手架不是开发流程之外的辅助物而是团队用来对抗代码库熵增的一部分基础设施。这个类比的边界控制论提供了一个有力的思维框架但任何类比都有局限值得诚实地标注出来。首先不是所有软件工程任务都适合这个范式。控制论假设存在一个可定义的目标状态和可观测的偏差信号但探索性研究、创造性设计、早期原型验证这些任务的目标本身就是模糊的、流动的。试图为一个尚未明确的目标设计精密的反馈回路反而可能过早锁定方向。Harness Engineering 更适合目标相对清晰、可验证的工程任务而非所有软件开发活动。其次过度 harness 化本身也是一种风险。规则越多Agent 越可能退化为“面向检查编程”代码能通过所有 lint 和测试却只是在机械地满足约束而不是真正解决问题。当传感器覆盖过多维度时Agent 也可能把大量循环耗在满足相互冲突的规则上而不是推进任务本身。好的 harness 需要克制知道什么时候不检查和知道什么时候检查同样重要。最后LLM 不是经典控制论中的线性系统。恒温器的行为是可预测、连续的LLM 的输出却可能因为上下文的一点细微变化而出现显著差异。这意味着控制论中许多关于稳定性和收敛性的数学保证在 Agent 系统中并不能被严格照搬。我们借用的是控制论的结构直觉而不是它的数学确定性。也正因为如此Harness Engineering 的重点不是把软件工程生硬地套进一个理论模型而是借用控制论的视角设计一个更容易收敛的工程系统。六、总结成为系统的舵手如果说前一节讨论的是如何把一个 Agent 系统设计得更稳那么最后可以回到本文最初的问题Harness Engineering 到底改变了什么控制论Cybernetics来自希腊语 κυβερνήτης意思是“舵手”。Kubernetes 的名字来自同一个词根。Harness挽具则是另一个方向的隐喻它不是掌舵而是驾驭。但这两个意象恰好可以拼成一幅完整的画面。挽具是从执行侧看的强调如何约束和引导力量舵手是从系统侧看的强调如何把握方向、感知偏差、持续修正。一个好的 Harness Engineer既是设计挽具的人也是掌舵的人。这正是软件工程正在发生的变化。从写代码到写 Prompt到组织 Context再到设计 Harness这些能力不是彼此替代而是在不断叠加只是人类工程师的价值重心确实在向更高杠杆的位置移动。过去优秀工程师的标志是能亲自写出正确的代码今天越来越重要的能力是设计一个让 Agent 可靠产出正确代码的环境。这也是为什么用控制论来理解 Harness Engineering 会特别有帮助。它要求我们的思维从命令式的“我要做什么”转向声明式的“系统应该是什么样”再进一步转向控制论式的“系统如何在扰动中自我稳定”。你关注的不再只是一次输出而是整个系统的动态行为目标是否明确反馈是否充分约束是否清晰偏差是否能够被吸收。Kubernetes 的使用者没有回到手动重启服务的日子。今天的工程师也不会长期停留在逐行驱动 Agent 的状态。不是因为我们做不到而是因为这样做已经不再有意义。当 Agent 能以机器的速度生成和修改代码时工程的重心就会不可逆转地从执行转向设计。而这些设计所要求的东西如文档编写、自动化测试、规范化架构决策、快速反馈循环本来就是好的工程实践。Agent 只是把它们的重要性从“长期正确”放大成了“立即生效”你是否定义了正确是否暴露了足够的信号是否把经验沉淀进系统现在都会立刻体现在 Agent 的表现里。所以Harness Engineering 并不是一个关于“如何更好地使用模型”的小技巧集合。它更像是一种提醒在一个高自治的软件系统里人类最重要的价值不是比机器执行得更快而是比机器更清楚什么叫正确并把这种判断力变成系统的一部分。这正是舵手的工作。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】