{
"summary": "视频深入解析了AI工程领域的新范式——Harness Engineering，指出其作为继Prompt Engineering和Context Engineering之后的第三次重心迁移，核心在于构建一个能持续稳定运行、具备自我约束与恢复能力的AI系统。通过真实案例与一线公司实践，揭示了Harness如何解决模型在复杂任务中执行不稳、状态失控等问题，强调其对AI落地的关键作用。",
"timeline": [
{
"time": "00:00:00",
"point": "引出主题：介绍Harness Engineering概念，并以个人调优Agent的成功案例说明其重要性"
},
{
"time": "00:00:15",
"point": "阐述AI工程三阶段演进：从Prompt Engineering到Context Engineering，再到Harness Engineering"
},
{
"time": "00:02:15",
"point": "解释Harness Engineering的核心目标：让模型‘别跑偏、跑得稳、出错能拉回’"
},
{
"time": "00:04:30",
"point": "提出Harness的六层构成：上下文管理、工具系统、执行编排、记忆与状态、评估与观测、约束与恢复"
},
{
"time": "00:08:45",
"point": "分析Anthropic的两个典型实践：context reflect（上下文反射）和生产验收分离"
},
{
"time": "00:11:20",
"point": "介绍OpenAI的实践：工程师不再写代码，而是设计环境；以及Agent自主验证的能力"
},
{
"time": "00:14:10",
"point": "总结三者关系：Harness不是取代前两者，而是在更大系统边界上包含它们"
},
{
"time": "00:16:50",
"point": "点明AI落地的核心挑战已从‘让模型更聪明’转向‘让模型在真实世界里稳定工作’"
}
],
"chapters": [
{
"title": "从提示词到运行系统的范式迁移",
"start_time": "00:00:00",
"end_time": "00:02:15",
"summary": "视频开篇引入Harness Engineering概念，通过真实案例引出问题：为何同样模型表现差异巨大？进而提出AI工程经历了从Prompt、Context到Harness的三次演进，揭示了系统稳定性依赖于外部运行机制而非仅模型本身。"
},
{
"title": "Harness的六大核心构成",
"start_time": "00:02:15",
"end_time": "00:08:45",
"summary": "系统性拆解成熟Harness Engineering的六个关键层级：第一层是确保模型在正确信息边界内思考；第二层是管理工具调用；第三层是规划执行流程；第四层是维护状态；第五层是建立独立的评估与观测机制；第六层是实现失败后的约束、检查与恢复。"
},
{
"title": "一线公司的实战洞察",
"start_time": "00:08:45",
"end_time": "00:14:10",
"summary": "以Anthropic和OpenAI为例，展示顶级公司如何应用Harness。Anthropic采用‘上下文反射’应对长任务中的信息过载，以及将‘干活’与‘验收’分离以保证质量；OpenAI则让Agent自主验证结果，并将资深工程师经验固化为可执行的系统规则。"
},
{
"title": "Harness的本质与未来意义",
"start_time": "00:14:10",
"end_time": "00:18:30",
"summary": "总结Harness并非取代Prompt或Context，而是在更大的系统层面整合二者。它标志着AI落地的核心挑战已从‘让模型看起来聪明’转变为‘让模型在真实世界里稳定工作’，是决定产品能否成功的关键。"
}
],
"quotes": [
{
"text": "Harness engineering 解决的是怎么让模型在真实的执行中持续作对。",
"time": "00:17:20"
},
{
"text": "真正的决定能不能落地 能不能稳定交付的就是Harness。",
"time": "00:17:45"
},
{
"text": "当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的。",
"time": "00:17:55"
},
{
"text": "修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力。",
"time": "00:12:30"
},
{
"text": "生产验收必须分离 只要评估者足够独立 系统就能形成一个真正有效的循环。",
"time": "00:10:15"
},
{
"text": "Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来。",
"time": "00:17:00"
}
],
"key_points": [
"Harness Engineering是AI工程的第三次重心迁移，核心是构建一个能持续稳定运行的系统。",
"一个成熟的Harness包括六层：上下文管理、工具系统、执行编排、记忆与状态、评估与观测、约束与恢复。",
"成功的Harness实践强调‘生产验收分离’和‘渐进式披露’，避免信息过载。",
"一线公司如Anthropic和OpenAI已将Harness深度融入产品体系，实现高效自动化。",
"Harness决定了AI系统能否真正落地，是超越模型本身的关键因素。",
"AI落地的核心挑战已从‘让模型更聪明’转向‘让模型在真实世界里稳定工作’。"
],
"terms": [
{
"term": "Harness Engineering",
"meaning": "指对AI Agent运行系统的工程化，涵盖上下文管理、工具调用、执行编排、状态维护、评估观测和故障恢复等，旨在确保模型在复杂任务中持续稳定地输出正确结果。"
},
{
"term": "Prompt Engineering",
"meaning": "通过优化提示词（Prompt）来引导大模型生成期望输出，解决的是‘模型有没有听懂你’的问题，核心是语言设计。"
},
{
"term": "Context Engineering",
"meaning": "在模型运行时动态提供正确的上下文信息，解决的是‘模型有没有拿到足够且正确的信息’的问题，核心是信息供给。"
},
{
"term": "Context Reflect",
"meaning": "一种高级的上下文管理策略，当原始上下文过载时，不是压缩，而是启动一个全新的、干净的Agent来接手任务，类似于重启进程恢复状态。"
},
{
"term": "渐进式披露",
"meaning": "一种信息暴露策略，不一次性将所有工具能力或规范塞给模型，而是根据任务需要，在关键时刻才动态加载相关部分，避免上下文窗口浪费。"
},
{
"term": "生产验收分离",
"meaning": "将任务的执行者（干活的人）与最终的验证者（验收的人）分开，由独立的、具备真实环境操作能力的实体进行审查，以确保结果真实可靠。"
}
],
"provider": "qwen",
"model": "qwen-flash",
"text_length": 7718,
"generated_at": "2026-05-13T21:47:54.437398",
"corrected_text": "今天我们来聊一个最近在AI圈特别火，但很多人还没真正弄懂的词——Harness Engineering。如果你最近也在做Agent，或者关注AI应用的落地，或多或少都可能遇到这样的问题：为什么同样的模型，别人做出来的Agent可以连续跑很久，成功率很高，到了自己手里就总是差强人意？\n\n很多人可能会想，是不是模型不够强？是不是提示词没调好？是不是上下文（context）没调明白？当然，这些都有影响。但越来越多的团队发现，真正决定我们的系统能不能稳定跑起来的，往往不是模型本身，而是模型外面那套运行的系统。这套东西，现在有了一个统一的名字，就叫Harness。\n\n大家好，欢迎来到代码秘密花园，我是欢迎老师。为什么想聊这个话题呢？因为年初的时候，有个朋友找我帮他们调一个Agent。他们团队之前已经做了很多努力，换上了最好的极箭模型，提示词改了上百版，各种参数也调得不少，但真实成绩的效果依然不稳定。有的时候很聪明，有的时候莫名其妙就跑偏，任务的成功率不到70%。\n\n后来我去看了一下，最后改动最大的地方，反而是模型和提示词之外的部分。我的改进点在于任务是怎么拆的，状态是怎么管的，关键步骤要怎么校验，失败之后要怎么恢复。结果新版本上线之后，还是同样的模型，同样的提示词，成功率直接拉到了95%以上。\n\n当时那个朋友问我：“你到底改了什么呢？”说实话，那时候我没有一个特别准确的词来形容。直到最近，Harness and Niren这个概念越来越火，我才意识到，我当时改的这些东西，本质上就是Harness。\n\n所以今天这期视频，我想彻底把这个概念跟大家讲清楚。我们主要分三个部分：Harness是怎么一步步演进出来的；一个成熟的Harness到底包括哪些部分；以及OpenAI、Anthropic、Lunchin这些公司，真实到底是怎么做的。\n\n过去两年，AI工程其实经历了三次很明显的范式迁移：从Prompt Engineering，到Context Engineering，再到最近的Harness Engineering。表面上看，好像只是换了几个新的名词，但如果你只是把它理解成流行史，那就完全低估它们了。\n\n这三个词分别对应了现在AI系统发展的三个阶段性问题：模型有没有听懂你在说什么？模型有没有拿到足够而且正确的信息？模型在真实的执行里，能不能持续地作对？你会发现，这些问题是一层一层往外扩张的。\n\n在大模型刚活起来的时候，大家最直观的感受就是：同一个模型，你换一种说法，结果可能差很多。比如你说一句“帮我总结一下这篇文章”，他可能只会给你一个很平的总结；但如果你换一种说法，效果马上就会不一样。\n\n所以那个阶段，大家都相信一件事：模型不是不会，而是你没有把问题说明白。于是大家开始疯狂研究提示词，什么角色设定、约束条件、输出格式、分步引导等等。\n\n那为什么这些东西有效呢？因为大模型本质上是一个对上下文非常敏感的概率生成系统。你给它什么身份，它很容易沿着那个身份去回答；你给它什么样的样例，它很容易沿着那个范式去补全；你强调什么样的约束，它就很容易把那一部分当成重点。\n\n所以提示词工程的本质，不是秘密模型，而是塑造一个局部的概率空间。\n\n那这个阶段最重要的能力，不是系统的设计，而是语言的设计。\n\n但提示词工程很快就遇到了天花板。因为很多任务不是你说清楚就行，而是你真的得知道。比如你让模型分析一份公司的财报文档，回答一个产品的最新配置，按照一套非常长的规范去编写代码，在多个工具之间完成复杂的任务。\n\n这个时候你会发现，提示词写得再漂亮，也替代不了事实本身。所以提示词擅长的是长期任务约束输出，激发模型的已有能力；但它不擅长填补缺失的支持，管理大量动态的信息，处理长链任务里的状态。\n\n说白了，提示词解决的是表达的问题，而不是信息的问题。\n\n于是第二阶段开始了。当大家还只是做聊天机器人的时候，提示词的作用很大，因为任务短、链路短、状态少，很多问题确实靠把话说明白就可以解决了。\n\n但后来Agent开始火了。模型不只是要回答问题，而是要进入真实的环境里面做事。它要多轮对话、调浏览器、调工具、输入数据、生成报告，还要在多个步骤之间传递中间结果，根据Web反馈不断修正计划。\n\n这个时候问题就变了。系统面对的已经不是一次回答对不对，而是整条链路的任务能不能跑通。\n\n比如，如果你不是简单地说“帮我总结一下这篇文章”，而是让它做一个更真实的任务，比如说“帮我分析这份需求文档，找出潜在风险，结合历史评审意见，给出修改建议，再生成一版发给产品经理的返稿”，你会发现，这已经完全不是一句提示词就能解决的问题了。\n\n它至少要拿到当前的需求文档、历史的评审记录，先回顾当前目标，分析出中间结论，输出的对象是谁，语气应该怎么调，等等等等。\n\n所以Context Engineering的核心，就变成一句话：模型未必是知道的，系统必须在合适的时机把正确的信息送进去。\n\n这里的context也不只是几段背景资料。在工程的意义上，它代表了所有影响模型当前决策的信息的总和，包括用户的输入、历史对话、检索结果、工具返回、当前任务的状态、中间产物、系统规则、安全约束，以及其他Agent传过来的结果。\n\n所以你会看到，prompt其实只是context的一部分。也正因为如此，针对上下文的攻击机制是非常重要的。\n\n说到context engineering，我觉得IG也算是一个比较典型的实践。IG的价值是很直接的：模型参数里没有指示，怎么在运行时补进去呢？做法大家都知道：先检索，再把相关的内容塞到上下文。\n\n但真正成熟的context engineering，关注的肯定不只是检索。它关注的是整体完整的链路，比如文档怎么切块，结果怎么排序，上下文怎么压缩，历史对话什么时候要保留，什么时候要摘除，工具返回要不要全部暴露给模型，多个Agent之间到底传原文还是结果摘要。\n\n包括最近很火的Agent Skills，我觉得本质上也是上下文工程的高级实践。因为它解决了一个特别现实的问题：如果你把十几个不同的工具、工具的说明、所有的参数定义，全部一上来就塞给模型，理论上模型会知道得更多，但实践往往会更糟糕。\n\n为什么呢？因为上下文的窗口是非常稀缺的资源。信息一多，注意力就分散。所以Skill采用的是一个非常典型的思路，叫渐进式披露：不是一开始就把能力全部给模型看，而是只给它看最少量的原始信息，等它真正要触发某些能力的时候，再把那部分的SOP、详细的参考信息、脚本，动态地加进来。\n\n这个思路非常重要，因为它告诉我们：上下文的优化，不只是给得更多，而是按需给、分层给、在正确的时间给。\n\n但上下文工程其实也不只是终点。因为后来大家又发现了一个更麻烦的问题：就算信息给对了，模型也不一定能稳定地执行正确。它可能计划做得很好，但执行跑偏了，调错了工具，误解了返回结果，在一个很长的链路里慢慢偏行了，但系统却没有发现。\n\n这个时候我们发现，提示词和上下文主要解决的都是输入端的问题：提示词优化意图的表达，上下文优化的是信息的供给。但在复杂的任务里，还有一个更难的问题：当模型开始连续行动的时候，谁来监督它、约束它、纠偏它呢？\n\n这个时候，第三阶段来了。\n\nHarness这个词，原本的意思是缰绳、马具、约束装置。放到AI系统里，就是在提醒我们一件非常普遍的事情：当模型从回答问题走向执行任务，系统不仅要有能力驾驭它，还要能够驾驭整个过程。\n\n这就是Harness and Niren的出发点。如果说前两代工程关注的是“怎么让模型更会想”，那Harness更关注的就是“怎么让模型别跑偏、跑得稳，出了错还能拉回来”。\n\n这里我用一个比较通俗的例子来解释这三个概念。假设你要派一个新人去完成一次很重要的客户拜访工作。\n\nPrompt Engineering就是你要告诉他：先把任务讲清楚，比如见面先自我介绍，再介绍方案，再问需求，最后推动下一步。这其实就是prompt，重点是把话说明白。\n\nContext Engineering是啥？你要告诉他：把资料准备齐全，比如客户的背景、过往的沟通记录、产品的报价、竞品的情况，这次会议的目标。这些都是context的重点，是把信息给对。\n\n但如果这个会议真的很重要，你还会继续做很多事情：让他带着checklist去，让他在关键节点做汇报，会后何时整理录音，如果发现偏差马上纠正，最后按照明确的标准去验收结果。这些就是Harness。\n\n重点已经不是说清楚和资料齐不齐全，而是有没有一套持续观测、持续纠偏、最终验收结果的机制。\n\n所以这三者也不是替代关系，而是包含关系：prompt是对指令的工程化，context是对输入环境的工程化，Harness就是对整个运行系统的工程化。它们的边界是一层比一层大的。\n\nLunchin的工程师给Harness下了一个很典型的定义：agent等于model加harness。Harness就等于agent minus model。\n\n翻译成人话就是：在一个Agent的系统里面，除了模型本身以外，几乎所有能决定它能不能稳定交付的东西，都可以算作Harness。\n\n那如果拆开来看呢？我自己会把一个成熟的Harness Engineering分成六层。\n\n第一层，是我们重新站在Harness的视角去看Context。模型能不能稳定发挥，很多时候不仅取决于它聪不聪明，而取决于它看到了什么。所以Harness的第一职责，就是让模型能够在正确的信息边界内思考。\n\n这一层通常包括三件事情：首先，角色的目标和定义——模型要知道自己是谁，任务是什么，成功标准是什么；其次，信息的检索和选择——上下文不是越多越好，而是越相关越好；第三，结构化的组织——固定的规则放在哪儿，待办任务放在哪儿，任务运行的状态放在哪儿，外部的证据又放在哪儿？最好分层清楚。因为信息一旦乱掉，模型就很容易漏重点、忘约束，甚至自我污染。\n\n第二层，工具系统。没有工具，大模型本质上还是一个文本处理器，会解释、会总结，但它接触不到真实世界。一旦连上工具，模型才可以真正做事，比如查网页、读文档、写代码、调API等等。\n\n但Harness在这里做的，不只是简单地把工具挂上去，而是要解决三个问题：第一，给它什么工具？工具太少，能力不够；工具太多，模型又会乱用。第二，什么时候该调用工具？本来不需要查的时候别乱查，该查证的时候也别硬答。第三，工具结果怎么重新呈现给模型？几十条返回结果，不应该原封不动地塞回去，而要提炼、筛选，保持与任务的相关性。\n\n第三层，执行编排。这一层解决的核心问题是：模型下一步该做什么？\n\n很多AZ的问题，不是某一步不会，而是不会把所有步骤串起来。它会搜索，也会总结，也会写代码，但整个过程想到哪做到哪，最后交付一堆半成品。\n\n所以一个完整的任务，通常需要有这样的轨道：首先理解目标，然后判断信息够不够，不够就继续补充；接着生成结果，继续分析；然后输出，检查输出；如果不满足要求，就重新修正或重试。\n\n这个时候你会发现，这已经非常接近人在工作了。区别在于，人靠经验，Agent靠Harness这套环境。\n\n第四层，记忆和状态。没有状态的Agent，每一轮都会像失忆一样，不知道自己刚做了什么，也不知道哪些结论已经确认了，哪些问题还没解决。\n\n所以Harness还必须管理状态。这里我们要至少让它分清三类东西：当前任务的状态、中间结果、长期的记忆和用户偏好。这三类如果混在一起，系统会越来越乱。看清楚之后，Agent才会像一个稳定的协作者。\n\n第五层，评估和观测。这一层往往是很多团队最容易忽视的部分。很多系统其实不是生成不出来，而是生成完了之后，根本不知道自己做得好不好。\n\n如果没有独立的评估和观测能力，Agent就会长期停留在自我感觉良好的状态。这一层通常包括输出和验收、环境的验证、自动测试、日志和指标、错误的归因等等。\n\n也就是说，系统不仅是要运作，还要知道自己有没有真的作对。\n\n第六层，约束、校验、失败和恢复。最后一层往往才是真正决定这个系统能不能上线的关键环节。因为在真实环境里，失败不是例外，而是常态。可能搜索不准，可能API超时，也可能文档混乱，或者模型误解了任务。\n\n如果没有恢复机制，Agent每次出错就只能从头再来。所以一个成熟的Harness，一定要包括三件事：约束哪些能做，哪些不能做；校验，比如输出之前、输出之后要怎么检查；恢复，失败之后怎么回滚，切换到稳定状态。\n\n接下来，我们来看最有参考价值的部分：一线公司的真实实践。因为Harness这个词最近之所以突然火起来，不是大家在空谈方法论，而是很多公司都已经把它做进了产品和工程体系里。\n\n比如，Lunchin在底层模型完全不变的情况下，只通过改造和部署Harness，就把它自家的智能体业务，从一个排名30开外的水平，直接杀到了前五。\n\nOpenAI依靠一个只有几名人类工程师的团队，用Agent从零构建了一个超百万行代码的生产级应用，100%的代码都是由Agent编写的，耗时只有纯人工开发的十分之一。\n\nAnthropic也构建了一个可以完全自主编码的系统，仅凭一句自然语言的需求，就能在无需人类干预的情况下，连续运行几个小时，最后做出完整的游戏、完整的数字音频工作站。\n\n我们先看看Anthropic的实践。首先，他们在长期自主任务上总结了两个特别典型的问题。\n\n第一个问题，我自己把它翻译成“上下文膨胀”。时间一长，上下文越来越满，模型就开始丢细节、丢重点，甚至会出现一种很有意思的现象：它好像知道自己快装不下了，于是开始着急地收尾。\n\n很多系统面对这种问题，都会做context compression，也就是把前面的历史上下文压缩一下再继续跑。但Anthropic发现，对一些模型来说，这还是不够。因为压缩只是变短了，不代表那种负担感真的消失了。\n\n所以他们做了一件更积极的事：叫context reflect。不是在原上下文里继续压缩，而是换了一个非常干净的新Agent，把工作交接给它。这个思路很像什么呢？特别像工程里遇到内存泄漏之后，不是继续缓存，而是直接重启整个进程，恢复状态。\n\n这其实就是一种非常典型的Harness设计。\n\nAnthropic解决的第二个问题，是自评偏差。首先让模型自己干活，再让它自己给自己打分，往往结果会偏乐观，尤其是在设计、体验、产品完整度这类没有标准答案的问题上，偏差更明显。\n\n所以他们采用了一个非常关键的思路：把干活的人和验收的人分开。他们是这样分工的：Planner负责把模糊的需求转化为完整的规格，Executor负责逐步实现，Evaluator负责像QA一样去真实测试。\n\n更关键的是，这个Evaluator不只是看代码，而是会真实操作页面，检查具体的交互，验证实际结果。也就是说，这不是一个抽象的审查，而是一个带具体环境的验证。\n\n这件事非常重要，因为它背后是一个明确的工程原则：生产验收必须分离。只要评估者足够独立，系统就能形成一个真正有效的循环——生成、检查、修复、再检查。\n\n再看OpenAI在这方面的感觉，是他们重新定义了工程师在Agent时代的工作。他们有一个非常有意思的思路：人类在这个环境里不需要写一行代码。\n\n人类只需要负责设计环境。具体来说，工程师的工作变成三件事：第一，把产品目标拆解成Agent能力阶的小任务；第二，Agent失败的时候，不是让它更努力一点，而是问：环境里缺了什么能力？第三，建立反馈链路，让Agent真正能够看到自己的工作结果。\n\n这句话我是非常认同的。当Agent出了问题，修复方案几乎从来不是要它更努力一点，而是确定它缺了什么样的结构性能力。这其实也是典型的Harness思维。\n\n我们还有一个特别典型的事件，也是见于“渐进式披露”。他们早期犯过一个很多团队都会犯的错误：写了一个巨大的Agent 4.md，把所有的规范、框架、约定全部塞进去了。结果Agent更糊涂了，因为上下文窗口是稀缺资源，塞得太满，其实等于什么都没说。\n\n后来他们怎么改的？把Agent 4.md变成一个目录页，页面只保留核心索引，更详细的内容则拆到架构文档、设计文档、执行计划、执行评分、安全规则等具体文档里去了。Agent先看目录，需要的时候再钻进去。\n\n这个时候我们会发现，这和我们前面说的Skills，本质上是一个道理：不是一次性全给，而是按需暴露。\n\n还有一点实践是：OpenAI不只是让Agent写代码，还让Agent看见整个应用。因为产业速度一旦上来，静态的“写”其实就不再是重点，而是“验”了。\n\n人类根本是验不过来的。所以他们让Agent自己去验。怎么验？首先，接浏览器，能截图、点页面；能模拟用户的真实操作；然后接入日志系统和指标系统，让Agent能查LOG、查监控。\n\n最后，每个任务都在独立隔离的环境中运行，互不影响。结果就是，Agent不再是“写完代码就说写完了”，而是真正可以跑起来看结果，发现Bug、修Bug、再验证。\n\n这其实就是Harness里非常完整的一套：工具系统、执行编排、评估和观测、约束和恢复。\n\n还有一点需要注意的是，OpenAI不只会靠人类在最后的Code Review环节去兜底质量。因为Agent的提交速度太快，人类是盯不过来的。所以他们把很多资深工程师的经验，直接写成了系统规则。\n\n比如模块怎么分层，哪一层不能依赖哪一层，什么情况下必须拦截，发现问题之后应该怎么修。重点是，这些规则不只是负责报错，而是会把“怎么修”也一起返回给Agent，进入下一轮的迭代。\n\n你会发现，这已经不是传统意义上的代码规范了，而是一套可持续运行的自动智力系统。这也是Harness的典型形态。\n\n最后我们总结一下：Prompt Engineering解决的是怎么把任务讲清楚；Context Engineering解决的是怎么把信息都给对；Harness Engineering解决的是怎么让模型在真实执行中持续作对。\n\n所以Harness不是在取代Prompt，也不是在取代Context，它是在更大的系统边界上，把前两者都包含进来。\n\n当任务还是简单的单轮生成时，Prompt很重要；当任务开始依赖Web支持去运行信息时，Context就很关键了；当模型真的进入了长链路、可执行、低容错的真实场景，Harness几乎就是不可避免的。\n\n这就是为什么同样的模型，在不同的产品里表现差距会这么大。因为真正决定上线的可能是模型，但真正决定能不能落地、能不能稳定交付的，是Harness。\n\n到了这个阶段，我们也看清了一个现实：AI落地的核心挑战，正在从“让模型看起来更聪明”，转向“让模型在真实世界里稳定工作”。\n\n如果你最近也在做Agent，我觉得这件事情非常值得你趁早想明白。\n\n本期教程的内容就是这么多。如果本期对你有所帮助，希望得到一个免费的三连和关注。感谢大家，我们下期见。"
}