Harness闭环工程
在上下文工程之上加入 Loop 校验、安全围栏、MCP 工具能力和工程交付约束，把 LLM 从“能生成回答”推进到“能稳定进入生产系统”的闭环落地方法。
简介
Harness闭环工程是 LLM 应用从演示走向生产时需要补上的工程层。它不是单纯“写更好的 Prompt”，也不是只把业务资料塞进上下文，而是围绕模型输出建立一整套可校验、可重试、可约束、可接入业务系统的运行框架。来自 2026-07-05-juejin-context-engineering-harness 的表述是：成熟企业 AI 数字化标准方案应从“用户简易 Prompt”开始，经由“LLM 自动优化提示词 + 注入上下文 + 加载 MCP 技能”，再到“模型生成内容”，最后进入“Loop 循环校验 + 安全围栏 Harness 约束 + 标准化工程落地”。
这个概念与 Agent Harness 相邻，但关注点略有不同：Agent Harness 更像管理多个 Agent、工具、规则和审计的系统框架；Harness闭环工程更强调单个或多个 LLM 应用上线时的闭环机制——输出格式能否被程序解析、成本和合规能否被约束、失败后能否自动重试、工具调用能否标准化、结果能否进入真实业务流程。换句话说，它回答的是“AI 生成之后，如何保证可用、可控、可上线”。
在企业场景中，这一层尤其关键。没有 Harness，AI 输出常常停留在“看起来不错”：文案好看但格式不可解析，建议合理但超出成本约束，问答流畅但引用了不存在的业务规则，工具调用成功但权限和审计缺失。Harness闭环工程把这些风险变成系统性门禁：机器先验收格式，程序先校验约束，循环负责修复，安全围栏负责阻断，MCP/工具层负责把能力接入业务系统。
关键信息
- 类型：LLM 应用工程化方法 / 闭环落地层
- 核心问题：模型输出如何从“可能有用”变成“可被系统稳定消费”
- 上游依赖：提示词工程、上下文工程、RAG 知识库
- 关键机制：Loop Engineering、安全围栏、格式校验、成本校验、合规校验、MCP 模型上下文协议
- 适用场景：企业 AI 系统、智能客服、数据分析 Agent、内容生成后台、业务审批助手、知识图谱问答、Agent 工具链
核心特性
1. 从一次生成变成闭环运行
传统 Prompt 或上下文工程的默认模式是“一次请求 → 一次回答”。Harness闭环工程不把这次回答当成终点，而是把它当作候选输出。候选输出必须经过校验：JSON 是否能解析，字段是否完整，数值是否满足成本约束，引用是否来自可信资料，是否触犯安全/合规边界。如果不通过，系统进入修复或重试，而不是把错误直接传给用户或后台。
这个变化看似只是加几层代码，实质上改变了 LLM 应用的产品性质。没有闭环时，模型是一个聊天对象；有闭环后，模型才可能成为业务流程中的执行节点。前者可以“说得差不多”，后者必须“交付可消费对象”。
2. 校验器必须独立于生成器
Harness闭环工程吸收了 Loop Engineering 的核心原则：执行者和验证者必须分开。模型负责生成饮品方案、SQL、报告、摘要或策略；校验器可以是确定性代码、规则引擎、JSON Schema、权限系统、单元测试、成本计算器，也可以是另一个受约束的评估 Agent。关键是不能只让同一个生成模型自称“我已经符合要求”。
2026-07-05-juejin-context-engineering-harness 的奶茶店示例展示了最小版本：模型输出后先 JSON.parse，解析失败就提示“需开启 Loop 循环重生成”。这只是闭环的第一层。企业系统还需要继续校验成本、库存、合规、权限和业务口径。
3. 安全围栏把业务边界写进系统，而不是写进愿望
提示词里写“不要违规”“成本控制在 8 元以内”属于软约束，模型可能遵守，也可能因为幻觉、上下文冲突或格式漂移而失守。Harness闭环工程要求把关键边界系统化：成本字段超过阈值就拒绝入库，权限不足就不调用工具，敏感内容命中规则就拦截，输出缺少来源就不进入下一步。
这与 企业AI落地 中“先诊断、后派单”的系统级强绑定同构：真正可靠的 AI 流程不是培训用户或提醒模型“请遵守”，而是让系统在关键节点强制执行边界。AI 可以辅助判断，但放行机制必须可追踪、可审计、可回滚。
4. MCP 和工具层让闭环结果进入业务现场
Harness闭环工程不是只在模型外面套一层检查器。检查通过之后，结果还要能进入业务系统：写入数据库、调用 CRM、查询库存、生成报表、创建工单、触发审批、调用知识图谱服务。MCP 模型上下文协议 在这里提供标准化工具调用和数据接入能力，让不同 Agent 能复用同一套工具和可信知识能力，而不是各自临时拼 API。
这也是 Harness 与普通“脚本后处理”的区别。脚本后处理解决格式问题；Harness闭环工程解决“LLM 如何成为业务工作流的一部分”。MCP、RAG、权限、审计、日志和失败处理共同构成这条链路。
5. FDE 或工程交付把闭环嵌入真实系统
文章把“标准化工程落地 FDE”放在链路末端，说明最终价值不在 Demo，而在上线后的业务可用性。FDE 不是神化岗位，而是代表一类现场工程工作：理解客户流程、接入真实系统、定义验收指标、处理异常数据、补上权限和审计、让 AI 结果被业务人员真正采用。
因此 Harness闭环工程既是技术层，也是产品/交付层。它要求产品经理、工程师、业务架构师共同定义“什么算可用”“什么情况下必须拒绝”“失败后谁负责”“日志怎么追溯”。
与 Prompt / Context / Loop 的关系
| 层级 | 解决的问题 | 典型形态 | 主要风险 |
|---|---|---|---|
| 提示词工程 | 单次任务怎么说清楚 | 角色、任务、格式、示例、负向约束 | 长提示难维护、幻觉仍存在 |
| 上下文工程 | 模型应该看见哪些业务资料 | background/constraints/outputRequirements、RAG、代码库、规则库 | 缺少闭环验收，输出不一定可用 |
| Loop Engineering | 失败后如何自动重试/修复 | 生成器 + 评估器 + 预算 + 停止条件 | 目标不清会空转，预算失控 |
| Harness闭环工程 | 如何进入生产系统 | 校验、围栏、工具调用、审计、FDE 落地 | 设计成本更高，需要真实业务边界 |
这个表说明，Harness闭环工程不是替代前几层，而是把它们组合成生产链路。Prompt 负责表达任务，Context 负责供给业务资料，Loop 负责失败修复，Harness 负责约束和上线。
不同素材中的观点
-
2026-07-11-woshipm-knowledge-base-engineering-practice：@Sean 把个人知识库的”三层防线”明确称为”我知识库自己的 Harness”，是 Harness闭环工程在个人知识管理场景的落地样本。三层分别是：脚本层守格式（validate_notes + batch_fix_notes，机器能查的不靠人眼）、Skill 层守结构（card-govern 治理孤儿卡/重复卡/结构失衡）、Dataview 层守全局（各主题分布、缺字段清单、未挂载主题页清单）。核心主张与本词条一致——CLAUDE.md 只解决”AI 知道该怎么做”，但”知道怎么做”和”真的做对了”是两件事，需要一套独立于生成器的机制守执行质量。作者还提出与”校验器独立于生成器”同构的 准入准出条件：在流程节点间加检查点，拦住 LLM 的执行漂移。方法论上强调三层防线”不是先规划好再动手，而是每遇到一类新问题就补一层，逐渐培养出 Harness 的意识和手感”。
-
2026-07-05-juejin-context-engineering-harness：提出 Prompt → Context → Harness 的三阶段演进。文章认为单纯写 Prompt 已经跟不上大模型迭代，上下文工程可以通过结构化注入业务背景、硬性约束和静态资料降低幻觉，但企业线上 AI 系统还必须搭配 Loop 循环校验、安全围栏和 MCP 标准化技能。奶茶店饮品研发示例展示了最小闭环：结构化 context + 系统提示词拼接 + JSON 解析校验 + 网络异常捕获。
实用信息
最小落地清单
- 结构化上下文：把业务背景、硬性约束、输出格式拆成独立字段，不混在一段话里。
- 机器可验收输出：优先要求 JSON、表格、固定字段、状态码等可解析格式。
- 格式校验：用
JSON.parse、JSON Schema、类型检查或字段完整性检查拦住不可消费输出。 - 业务约束校验：成本、权限、合规、库存、时间范围、额度等不能只靠提示词约束。
- Loop 修复机制：校验失败后自动带错误信息重试，设置最大次数和预算上限。
- 工具标准化：通过 MCP/API/内部服务让 AI 调用真实数据和业务动作。
- 日志与审计：记录输入、上下文版本、模型输出、校验结果、工具调用和人工接管点。
- 人工升级路径：超出边界、无法判断、连续失败或高风险动作必须交给人。
常见误区
- 把 Harness 误解成“更复杂的 Prompt”：Harness 的核心是校验、约束和接入，不是把提示词再写长。
- 只做格式校验，不做业务校验：JSON 能解析不代表饮品成本真的小于 8 元，也不代表客服回答符合退款政策。
- 没有预算控制的 Loop：重试机制如果没有最大次数、时间和费用限制，会把错误变成持续烧钱。
- 工具调用缺少权限边界：AI 能查数据不等于能改数据，能生成建议不等于能自动执行高风险动作。
- 缺少日志：生产事故后无法追溯模型看了什么、为什么调用某个工具、哪一层校验放行，就无法运营和改进。