最近阅读了一批 Agent 设计与开发相关文章。综合来看，业内实践大致可以归纳为四个演进阶段：Prompt 工程、Context 工程、Harness 工程、Loop 工程。
当前 Agent 开发的工程方法论仍处在持续发展阶段，落地过程中一定会碰到缺少成熟通用方案的疑难问题。想要妥善应对这类问题，做到知其所以然至关重要。因此在持续阅读与思考中，我整理形成本文，记录现阶段的认知。
1. Agent到底要解决什么问题
首先需要厘清：Agent 的核心目标是什么。
过往计算机系统的核心优势，来自远超人类的高速确定性计算；PC 互联网、移动互联网，本质都是持续扩大算力的触达范围。2022 年 ChatGPT 爆发，让大家看到大语言模型这种全新计算载体的潜力。LLM 底层依旧依靠高速确定性计算，但对外呈现出前所未有的通用智能能力，和传统程序有着本质区别。
对话机器人只是通用智能最初步的应用，顺着这条思路自然延伸：既然 LLM 具备思考、语言表达能力，能否指挥各类工具完成现实任务？这就是 Agent 诞生的初衷：打造一套集思考、表达、工具执行于一体的系统。
更进一步，我们不仅希望 Agent 可以调用工具执行任务，还要求推理正确、执行可靠，同时控制 Token、调用资源，维持较低运行成本。
一句话总结：Agent 旨在充分利用 LLM 的通用智能，解决传统确定性程序难以胜任的、带有模糊智能需求的任务；而 Agent 开发工程方法论，就是实践、提炼一套指导方案，用来构建高可靠、低成本的智能执行体。
类比角度，可以把LLM当做一批大体掌握人类目前所有公开知识、会思考、但存在较多不足（一些不足已经明确，大概率还有一些不足尚未被发现）的“新人脑”，Agent工程考虑的就是如何让这个“新人脑”能够更好的完成任务。说是一批，是因为虽然训练模式大体相同，但是各个大模型提供厂商有各自独特的一些判断、方法，使用的数据集也并非完全相同，并且这两个因素即便在同一家大模型厂商，也是在不断变化的，由此产生的“新人脑”虽然大体相同，却仍然存在较为明显的不同。
2. Prompt工程的出现和瓶颈
LLM的智能输出外在表现形式是接收一段文本、输出一段文本，这段输入的文本，就叫做Prompt提示词。人们发现，同样的一个问题，给LLM不同的提示词输入，响应的质量可能差别很大，由此出现Prompt工程来指导如何更好的编写提示词，使得LLM能够产生更高质量的响应。
Prompt的产出更多的是一些tips，例如声明角色（你是一个某某某专家）、末尾再次强调、重要的话说两遍、引导模型逐步推理（CoT）、根据任务类型设置恰当的温度等参数、样本提示等等。这些tips本身当然有价值，原因很好理解，LLM的智能基础来自于对人类海量文本的处理，有逻辑、有样例、结构化的输入+一些语言技巧，当然能够更适配LLM，使得其产生质量更高的输出。但是不足也十分明显，当通用的提示词tips把响应质量提高到一个相对较好的程度后，继续优化会是模型绑定的，即针对A家的版本1模型的提示词优化，到B家的模型不一定管用，甚至到A家的版本2模型也不一定管用(Anthropic的提示词最佳实践即一个具体的例子，不同的版本都有一些不同的方法）。总结来说，提示词工程有价值，但适用范围有限（例如单轮对话改写、信息提取等），不适合中长程任务。
同时，提示词工程解决不了私有化知识的利用的问题。大模型所掌握的知识来自公开可获得文本，而实际更有价值的问答（也是对非大模型厂商类型的企业更有价值的商业路径），除大模型已掌握的公共知识外，问题相关的、业务相关的私有化知识必不可少，因此出现了RAG检索增强注入：在构建提示词时，先通过外部检索来获得问题相关的私有知识，加入到提示词中一起输入给大模型。
很明显，如何检索到语义相关的私有知识是这种解决方案的关键问题，向量检索因为具有语义相似检索的能力而大行其道，甚至某种程度上成了RAG本身的代名词，但是当前阶段，RAG检索一般会基于向量检索融合关键词检索(后续升级的还有图检索、适用于代码的方式、LLMWiki，以及向量检索技术的自身进化）等其他方案，只有这样，才能够在各种情况下把相关的私有知识检索完全。我感觉先检索后注入模式的RAG也是提示词工程的一部分，因为它还是在考虑与大模型的单轮输入输出下如何优化提示词以获得更好的响应质量。
RAG增强的提示词工程在单轮对话的前提下较好的提升了大模型的输出质量。但是：
- 即便只考虑对话类应用，更多的业务场景是多轮对话，这种场景下，仅有RAG增强的提示词工程无法解决大模型输出质量随对话轮数增加而下降的问题。这背后的原因，其一是多轮对话下需要保证对话连续性，势必需要把历史对话记录（含历史对话中检索增强的信息）全部给到大模型，而大模型本身的上下文窗口限制以及长上下文下注意力漂移等不足，使得其准确注意到当前重点的能力大幅下降，其二是多轮对话中用户的意图本身就有可能产生漂移，这种偏移更进一步加剧了大模型响应质量的下降。
- 如果考虑Agent，Agent会有迭代的推理、工具调用（参考单Agent架构演进），每次推理都会产生新的推理输出，每次工具调用都会产生工具调用结果，所有的这些都应当作为输入进入大模型下轮迭代的推理环节，输入长度过程一般远长于多轮对话的输入，由此会引起大模型推理能力的显著下降。
这使得人们意识到，更重要的并不仅仅是如何组织人类输入的原始提示词，而是如何管理一个会话（即用户与大模型的一连串的对话，或者完成一个任务）的所有上下文，在合适的时机将合适的信息以合适的结构给到大模型，这就是上下文工程了。
3. Context工程的出现和瓶颈
按照Anthropic的定义，上下文工程是：Context refers to the set of tokens included when sampling from a large-language model (LLM). The engineering problem at hand is optimizing the utility of those tokens against the inherent constraints of LLMs in order to consistently achieve a desired outcome，上下文Context其实是考虑Agent场景时，输入给大模型的输入序列的新的叫法，在大模型应用与对话尤其是单轮对话时，输入给大模型的只有人类写的文本，那个时候管它叫提示词prompt，但是扩展到Agent应用时，为了让大模型更好的完成任务，输入给大模型的除了人类用户给的文本外，还包括可用工具、与任务相关的约束、规则、方法，以及（也是长度一般最长的）智能体迭代过程中产生的中间推理输出+工具调用输出，为了区分二者，所以就给了个新的名字叫上下文Context。按我理解，Context工程事实上是包括了Prompt工程的。
Context工程的目标很清楚，但是要做好并不简单，事实上，虽然Context工程这4个都叫工程，但是离理想的工程化还有显著的距离，更多的是概念的定义以及有限场景（例如CodeAgent或其他单个领域Agent）思路方法级别的总结。
某种意义上，RAG也可以算做是Context的在单轮对话场景下的一个很有价值、有意义的尝试，因为它在为模型更好的推理补足上下文。但是如果考虑Agent场景下的Context工程会复杂很多，因为Context的范围显著变大了。一个合理的方式，是对Context分类，然后分而治之；另外，前文所述的三个合适，显然是跟Agent执行的任务的当前状态有关系的，如何判断合适，单靠传统的计算机系统基于规则的方式显然不足，因此引入大模型的智能能力来来增强Context管理（注意是增强而不是替代）是一个显而易见的想法。
Agent按照架构分，可以分为单Agent和多Agent，先考虑单Agent场景且完成一个任务（即只有一次用户输入任务），此时，Context大致可以分为以下几类：
- 任务目标：需要长久保持在上下文中，避免目标偏离
- 任务执行的规则和约束：需要长久保持在上下文中，避免方法、规则偏离，Claude Code的claude.md即是例证；而skills则是提供了个性化的规则、约束的注入和管理方式。
- 任务规划：如果采用了Plan-And-Execute类的方式，则任务规划是路线图，需要长久保持
- 任务可使用的外部能力集合即工具集合：最理想的是按需披露，即只给模型看到当前需要的工具列表的详细数据，在工具集很多的时候，无非是层次化给与即按照层次组织工具，先披露最上层索引，并提供一个“工具检索”的元工具，由大模型按照当前任务执行阶段来检索所需要的工具，考虑现在用户体感最多的Skills，Skills中包含工具，而支持Skills的各类工具，都支持渐进式披露，这就是工具层次化组织并层次化披露的一个绝佳实践。另外一个可同时使用的解法，是控制工具的数量，这自然而然就引入了多Agent架构的必要性之一了。
- 任务完成所需要的外部知识：应当按需加入和退出上下文，按需是确保“内容合适”的题中应有之义；关键点在于如何按需？
- RAG的早期的“先检索后一股脑给到大模型”方式的不足之处就在于没有办法很好的来满足“按需”的要求，因为这种方式隐含了一个假设“模型解决当前问题的需要的外部知识，是跟用户输入问题语义相似的知识片段”，但是实际情况可能复杂很多，知识库相关的探索和技巧，大致都是在解决这个问题
- 例如查询改写是为了解决“用户问题处于问题域，而回答问题所需知识一般处于解答域”不匹配的问题，给向量数据库增加chunk父子、兄弟关系，是在基于语义相似片段扩展解决问题可能需要的关联知识，基于外部知识层级关系组织成Wiki，然后使用目录来检索得到最终给到大模型的外部知识，是更进一步的借鉴人类书本的知识组织方式。
- 我们考虑人脑完成任务利用外部知识的过程，一般是先看下任务，大致检索阅读一些背景知识，然后开始探索任务解法，在解决问题过程，判断当前是否需要增加外部知识的查阅，这个边做边检索的过程与ReAct的过程十分相似，只要把根据需要检索外部知识也理解为一个Action即可，即把检索能力封装为可供使用的工具。在Anthropic的文章中，明确提到"just in time"的检索方式，只不过在他们的Claude Code的实践中，外部工具使用工具是head/grep/tail之类的工具，并且使用文件目录等方式为这些工具提供了统一的工具描述（告知大模型这些工具可以大致检索出什么信息）。而在非Code Agent场景中，则需要适配产生合适的工具，例如如果需要进行向量检索，则封装向量检索工具，如果需要进行图检索，则封装图检索工具等。
- 退出上下文，仍然类比人类处理问题的方式，人类在按需读取外部知识后，实际上实时进行了一个“过滤-记忆”的处理，后续继续完成任务，是基于过滤后加入记忆的知识进行的，这自然而然就引入了对记忆管理的需求，即：外部知识检索后，需要进行一个过滤，判断是否有价值，如果有价值，则进一步提炼出最核心的知识存入记忆系统，而下一步迭代，是基于记忆系统中关于这次任务的记忆来进行的，也即从逻辑统一的角度上说，每一迭代处理完毕，进行一次记忆的更新，每一迭代的开始，从记忆系统中加载该迭代所需的上下文，实际实现的时候，从性能等考虑会优化这个逻辑，但是总体框架基本如此。从简化抽象的角度，外部知识库也可纳入记忆管理的统一范围来。
- 上一条的方式在一定程度上解决了外部知识退出的问题，进一步的退出，在两种情况下有必要触发，一种是记忆系统中关于该会话的部分记忆不再需要，一种是记忆系统中关于该会话的部分记忆相互冲突，这二者同样需要借助大模型的智能推理能力进行处理。
- 任务执行过程产生的中间数据：
- 这里专指ReAct模式中迭代产生的中间数据，在上一步中，已经推理出外部知识的加入上下文和退出上下文，应当按照工具调用的方式来实现，而任务执行过程，产生的中间数据可分为两大类，第一类是Reasoning阶段的产出，第二类是Action的产出。
- Reasoning阶段的产出，大部分时候应当保留，尤其注意的是被判定为错误探索、无效探索的部分，也需保留以利于后续推理避免反复尝试错误路径；其问题在于如果存在长期的推理，这部分也有可能较长，仍然是要依赖记忆系统来解决，但是额外对记忆系统提出了新的“分层”要求，即在合适的时候，需要压缩只保留较为宏观的思考过程记录，但是同时要保持根据宏观思考记录按需从记忆系统中抽取对应微观详情的能力；
- Action产出也可分为两类，查询类工具（例如搜索）返回的本质是外部知识，同上一步中关于外部知识点的讨论（事实上，ReWOO就是在试图管控这部分上下文，因为Obs这部分经常很大）；另一类为修改类操作的结果，例如编码类Agent编译代码产生的结果、修改业务数据库产生的返回值，这一类信息如何管理，需要根据工具和任务来智能化处理。但是，不论是前面所述的外部知识，还是这里提到的执行结果，对于大模型而言，事实上都是一种外部状态，也就是说，从逻辑推理的角度，应该统一为一个外部状态管理，包含了现有记忆管理的所有功能。
- 任务执行的经验数据：仍以人类比，一个人做同一类任务达到一定次数后，会自然而然形成经验，下次遇到相同类任务时，能够自动调用这些经验。事实上，前面提到的规则和约束，是人根据Agent要完成的任务注入的经验，而基于Agent观测数据经过人类处理后的经验规则，也可通过外部知识+检索工具的方式，走前面外部知识的路径自动的按需注入上下文。更进一步的，Agent自我进化逻辑下产生的经验，也可采用相同的方式进行使用，难点在于这些经验的生成，不过超出了上下文管理的讨论范围。
总结起来，上下文管理要管理的上下文可分为两大类：
- 需要长久保持的：任务目标、规则与约束、任务规划、小规模的工具集合，这些上下文最为重要，应当确保在上下文窗口的高注意力区间中并在整个会话中保持。
- 按需注入的：大规模的工具集合、外部知识、执行过程数据、以某种方式产生的经验数据。整体上采用“工具化封装为能力+Agent按需检索+基于分层分类的外部状态管理系统”的方式。
单Agent单任务的Context工程清楚后，扩展到单Agent的连续任务，多出来的问题是历史任务处理记录如何管理以及用户任务目标变化；用户目标任务变化比较简单，直接替换Context中的任务目标即可，而历史任务处理的记录，与任务执行的中间数据并无本质区别，可以考虑采用按需注入方式Context的方式进行管理。
多Agent事实上简化了Context的管理，因为每个Agent一般具有聚焦的职责边界，这意味着工具集合变小、处理过程变短，因此简化了上下文管理，与单Agent不同的在于，多Agent尤其是编排-执行模式的多Agent，额外多出来一个宏观的任务规划，以及一个宏观的一般经过精简处理的任务执行路径来作为上下文。
理想情况下，给了大模型Context管理后的最佳上下文，大模型就应当能够正确推理了，但是实际情况并非如此，一方面由于大模型本质上是概率性的（甚至也可以说智能本身就具有不确定性），缺乏传统软件系统的因果必然性，另一方面，在实际工程落地的时候，受限于响应时长、Token消耗等约束，并不能做到最佳上下文。
由此Harness工程出现。
3. Harness工程
Prompt工程和Context工程，实质上在做的是如何适配大模型这个新的计算单元的输入，Prompt聚焦于单轮对话场景，Context聚焦于Agent场景。但是即便尽量优化了输入，大模型的表现仍然具有不确定性，在单轮对话应用为主的阶段，大模型出错影响相对较小，但是Agent应用为主的阶段，大模型的推理结果是要影响实际业务的，其出错的影响显著放大，因此这种不确定性需要被更强的管控，如何做好这个管控，就是Harness工程要做的事。
Harness于2026年2月被Mitchell Hashimoto提出，这个作者是个软件工程师，他其实是总结如何自身更好的用好CodeAgent的经验，明确提出一个新的规则“anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again”，他称之为Harness enginerring。并提出两种实现Harness的方法，一种为“Better implicit prompting”，一种为“Actual, programmed tools”。
随后同样在2月份，OpenAI发了一篇文章，宣称他们5个月内使用自家的Codex编写了包含100万行代码，构建交付了一个内部beta版，其中所有代码均是Codex写的，估计消耗的时间是手工编写代码的1/10。该文章在代码编写这个应用场景下，总结了一组如何实现“人类掌舵，智能体执行”的方法思路，例如工程师工作重点调整为系统、架构和杠杆作用，提高应用程序（也即这个Beta系统）对于Agent的可读性，把代码仓库（Agent的产出）设为记录系统（这个本质也是在提高产出物对于Agent的可读性），规范架构与品位（这其实也是以Codex可读的方式为其提供更多的必要的信息），让Codex直接具有仓库合并代码的权限，编码“黄金原则”到代码仓库中并定期使用Codex运行代码质量提升的任务（这实际上就是在让Codex做明确原则指导下的重构）。读下来，我感觉到这篇讨论的最大重点是就是在软件开发这个场景，如何把执行软件开发的各类信息变得对Agent可读，由此使得Agent单次行动成功率提升，即便不成功，也可根据Agent可读的行动结果来判断是否成功、以及指导重试。
2026年4月，Martin Fowler的站点发了一篇文章Harness engineering for coding agent users，总结了如何“在较少的人类干预下，找到方法提升代码Agent产出的可信任度”，拆分出Harness的两个目标，其一为尽量让Agent第一次就成功，其二为提供一种反馈机制，使得Agent能够意识到自身的失败并执行纠正错误，对应的提出两种方式，即前馈类型FeedForwrd的Guides和反馈类型FeedBack的Sensors，然后从另外一个角度，拆分出计算性和推理性的两种手段，计算性是利用传统计算机的确定性计算能力，例如编译通过，推理性则是利用大模型的推理能力，例如语义分析。
从上面Harness的几篇重要文章，可以明显的看出来，Harness是包含了Context的，Harness中的“尽量让Agent一次性成功”或者“使得任务执行的前置外部信息对于Agent可读”，都是在上下文管理，所以提出Agent=LLM+Harness。它的主要新贡献有三：
- 提出了“反馈回路”，考虑如何降低大模型犯错的影响，以及如何为它提供支持，使得它可以认识到自身的错误并纠错，其背后的思路变化是允许LLM犯错，这个思路变化是一个最重要的思维层面的升级。这是Harness最重要的贡献。
- 在Context工程之上，强化了“使模型一次执行正确”的方式，不再局限于控制输入上下文的方式：这个使得Harness在逻辑上完备了，但是Context工程之外，提高一次性执行正确的尝试，原本就存在，例如Plan-And-Execute等先规划后执行的流程设计本身就已经超出Context工程的范围。
- 明确提出充分利用确定性计算来补足大模型推理性计算天然的不稳定性的劣势。
理解了这个，随Harness工程而来的各类常见的具体方法变得易于理解：
- 错误永久固化：Agent出现错误，即提出解决方案，使得它不再犯这错误，这种解决方案优先采用Agent运行环境改造的方式。这是反馈回路，并且充分利用确定性计算的优势提高后续Agen一次执行成功率。
- 沙箱权限管用：限制Agent可调用工具、可读写路径、危险操作拦截。这一方面在使用确定性计算提高Agent一次执行成功率，一方面也降低犯错的影响范围。
- 标准化工具契约：所有输入输出强Schema，并且通过Harness强制校验。使用确定性计算提高Agent一次执行成功率。
- 任务环境基础设施标准化：这是OpenAI实践经验，把所有隐性业务知识版本化固化到可访问仓库，统一唯一可信数据源；构建标准化启动脚本、会话初始化钩子。提高外部信息全面性和可读性，来提高Agent一次执行成功率。
- 执行结果计算性校验和重试：在CodeAgent中，使用语法检查、编译测试、单元测试等各种手段，在其他场景中则使用其他基于确定性计算的方式检查LLM的输出，在失败时以LLM可读的方式返回给LLM，要求其重试当前步骤。基于确定性计算的校验+反馈回路，使得Agent认识自身错误并纠错。
- 执行结果推理性校验和重试：使用独立的LLM进行评审，产出结构化评审意见（这个结构化也要使用确定性计算来进行可信校验）送入Agent迭代循环。基于推理性计算的校验+反馈回路，使得Agent认识自身错误并纠错。这个其实跟单Agent架构中的Reflection架构思路是一致的。
- 执行状态持久化、断点续跑：这个严格来说，我理解并非Harness的主要点，这是一个提升任务效率、降低token消耗的显然工程手段，在Plan-And-Execute等架构提出时，就已经在解决这个问题了，Harness只不过是把它纳入到统一框架中来了。
- 工具调用限流、超时控制等并以规格化方式返回给Agent执行迭代：基于确定性计算的校验+反馈回路，使得Agent认识自身错误并纠错。
- 观测体系+基于观测体系的持续迭代改进：改进可以分为两条分支，其一为改进确定性计算部分，即Agent运行环境也即Harness，这是在大规模收集Agent错误并采用确定性计算提高后续任务的一次性正确率；其二为改进推理性部分，例如人工或自动（自动当前阶段还比较难）改进提示词，这是在大规模收集Agent错误并采用推理性计算提高后续任务的一次性正确率。
- 多Agent架构以及边界隔离：多Agent一方面通过职责划分，降低了单个Agent的潜在上下文空间，从而提升了一次性执行成功率；另一方面，Agent之间一般采用基于Schema的通信约束，这是在通过确定性计算提高一次性成功率和必要尽早失败率。
考虑到实际落地的时候，Harness最有效、最稳定的部分是在利用确定性计算，所以它必然是一个与场景关联紧密的工程，按我现在的认知，无非就是问3个问题：
- 在我的Agent场景下，有没有更多基于确定性计算的方式来提高Agent一次性执行成功率的方法？如果没有，那有没有基于推理性计算的方式？
- Agent会犯错，对于可能的出现的错误，是否有什么方法降低其影响并尽早发现？
- 是否能够有更好的方法收集到Agent的所有错误，针对这些错误，合适的改进方法是什么？
其实到Harness工程，如何构建一个好的Agent的思路已经比较完备了，难点在于这个思路的内在其实是在充分利用确定性计算来强化或者叫管控LLM带来的推理性计算，但是不见得所有Agent场景都有CodeAgent场景一样丰富的基础设施（例如编译、自动化测试等）来做确定性计算。
4 Loop工程
Loop工程是更新的东西，2026年6月Addy Osmani提出，概念，其定义为“Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead”，仍然是站在代码开发的场景提的。2026年7月，Dzone出了一个综述“Loop Engineering: The Layer After Prompt, Context, and Harness Engineering”，这个综述的逻辑更完善一些，尤其给出的一个表格十分好：
Loop工程考虑的问题不同了，它其实更多的是在考虑如何让有了Harness加持的更可靠的Agent如何来更好的发挥价值，给出的答案就是“给Agent职责，让他主动发现任务，主动完成任务”，完全是把Agent当一个具有主动性的人来用了。上面这个表十分明确的说明了它的适用范围：需要有一个十分明确的目标，并且为这个目标而完成的任务都需要有十分明确的验收标准（我理解也就是最好能够使用Harness里面的计算性方式来验证，而非推理性方式来验证的标准）。感觉这个更多的是在探索新的使用方式，如果Harness工程足够好，已经能够很好的完成单个的较大的较复杂的任务，那Loop工程的难度并不会太高。Loop的讨论，其实就超出了本文的“如何构建一个更好的Agent”的方位了。这个概念太新，我现在完全没有任何实践，也没有办法给出更多的分析，但是其思路倒是比较明确的。
5 总结
整个梳理下来，发现其实这四个工程，尤其是Context工程、Harness工程、Loop工程的提出的直接动因，并非为了前述Agent的目标“充分利用 LLM 的通用智能，解决传统确定性程序难以胜任的、带有模糊智能需求的任务，而是顶尖程序员群体在如何利用LLM通用智能，利用CodeAgent充分提高软件构建这个事情的效率上产生的一系列经验总结，只是这些经验总结提炼也适用于其他领域。
而为何顶尖程序员群体如此热衷于提高CodeAgent的提升，结合Anthropic、OpenAI的各种工程文章，以及最近流出的梁圣投资人交流录音，他们的目标可能更远大，是在尝试基于CodeAgent跑通LLM自进化逻辑，因为LLM形式上也是一个软件构建问题，一旦CodeAgent可以自行优化一般软件，就可以尝试让CodeAgent自行优化LLM，一旦CodeAgent可以自行优化LLM，基于CodeAgent解决问题的速度远超人类的特性，则自家LLM的进化进入指数增长阶段，一骑绝尘。而有了自行进化能力的LLM，只要LLM架构决定的本身的上限足够，由此产生的商业竞争优势乃至国家实力优势，会产生何种影响简直不可想象。
回归本篇的初始目标，这4个工程，解决的问题也并非完全一致。Prompt、Context以及Harness工程是在解决如何构建一个更好的Agent这个问题，最抽象的切法如下表：
| 单轮对话 | 多轮对话或非对话类任务 | |
|---|---|---|
| 优化输入 | Prompt工程 | Context工程 |
| 优化反馈处理 | Harness工程 |
上面这个表格，表达的是各个工程锚定的场景和“最主要的新的解法（而非它完整的解法）”，在概念上，Context工程是包含Prompt工程的，Harness工程是包含Context工程的。
而Loop工程事实上是在考虑如何利用LLM+Harness构建的Agent这个新的能力（已经不再是纯的大模型能力了），其思路是“从完成任务到承担职责”，Loop工程的一旦成熟，则给Agent一个职责“持续优化你所使用的LLM”，就可以尝试LLM自进化了。
