Loop Engineering循环工程关注的不是“写出一个更聪明的提示词”而是围绕 Agent 设计一组相互嵌套的反馈循环使行动、验证、业务触发与系统改进成为同一套可观察的机制。模型是其中的推理引擎决定系统是否可靠的是承载模型的 harness上下文、工具、状态、评测、记忆、权限与反馈通道。图用户提供的 LangChain Loop Engineering 示意图。由内到外依次是 Agent、verification、event 与 hill-climbing 四层循环最外层并非简单重复执行而是借由 trace 分析反向改进内层 harness。1. 从“单次生成”到“反馈系统”传统 LLM 应用常被理解为一个函数输入 prompt返回 output。Agent 则至少包含两种交替发生的行为模型根据上下文决定动作工具执行后把 observation 返回给模型。LangChain 将这称为最基本的agent loopmodel call → tool execution → observation → model call直至任务结束。LangChain 的 context engineering 文档强调Agent 的失败通常不只是模型能力不足更常见的是模型在某个时刻没有获得正确的上下文、工具或生命周期约束。Loop Engineering 的转变在于关注对象从“一次回答是否漂亮”转为“系统能否反复产出可接受结果”质量的来源从模型自我声明转为外部可检验的证据失败不再只是一次运行的损失而成为评测、诊断与下一轮改进的输入优化对象不局限于 prompt还包括工具描述、路由、状态、检索、记忆、评测器与权限边界。这是一种控制论式的理解Agent 的输出经过测量测量结果形成误差信号误差信号再影响下一次决策或下一版本 harness。没有评价标准与反馈通道的“循环”只是重复能改变系统行为的闭环才是工程意义上的 loop。2. 四层嵌套循环LangChain 在 The Art of Loop Engineering 中把生产级 Agent 概括为四层循环。它们不是四个彼此独立的功能而是由内到外包裹外层以更慢的频率观察与改变内层。层级闭环核心问题产生的信号Loop 1Agent loop怎样完成一次任务动作、观察、结果Loop 2Verification loop结果是否满足要求分数、断言、失败原因Loop 3Event-driven loopAgent 如何进入真实业务世界事件、状态变更、业务结果Loop 4Hill-climbing loop系统怎样从运行中变好Trace、失败模式、评测集、候选变更2.1 Loop 1Agent loop——行动与观察Agent loop 是工具使用的最小结构。模型不直接拥有世界状态它通过工具读取信息、执行动作并根据 observation 修正后续判断。因此轨迹trajectory与最终回复同等重要一个看似正确的答案可能来自错误的工具、越权的数据访问或不稳定的偶然路径。LangChain 将可控上下文区分为三类模型上下文model context系统指令、消息、可用工具、模型与输出格式它决定模型在单次调用中“看见什么”。工具上下文tool context工具可访问和可写入的 state、store 与运行时信息它决定动作可以影响什么。生命周期上下文life-cycle context模型调用与工具调用之间的摘要、护栏、日志、跳转等机制它决定循环怎样延续、暂停或改道。这三层上下文解释了为什么“模型很强却依然不可靠”是常态可靠性并不只由权重决定而是由模型在每个决策点可见的信息、可调用能力与运行约束共同决定。2.2 Loop 2Verification loop——结果与证据之间的闭环Verification loop 在 Agent 得到候选结果后引入独立的grader。grader 将结果映射到 rubric评价准则返回通过、失败及可解释的反馈失败反馈成为下一次尝试的上下文。LangChain 将这层关联到RubricMiddleware或after_agenthook在其文档 Agent 示例里链接解析、CI、变更范围都是验证证据而不是模型的主观自评。来源verification 的本质不是“再问一个 LLM 是否正确”而是建立证据的层级确定性证据格式、类型、约束、单元测试、策略规则、数学或数据库断言。这类证据可重复、边界清楚。语义性证据事实覆盖、解释完整性、风格与受众匹配。它们常由 LLM-as-a-judge 或人工判断必须依附明确 rubric。业务性证据真实动作是否带来目标状态例如工单是否正确更新、代码是否通过 CI、用户是否接受结果。这里有一个关键区别自我反思self-reflection是生成策略验证verification是质量证据。前者可能帮助 Agent 发现问题后者才决定结果是否可信。把同一模型、同一上下文中的“我觉得没问题”当作验收会把同源偏差伪装成质量信号。2.3 Loop 3Event-driven loop——Agent 进入系统而非停留在聊天框事件循环把 Agent 置于真实生态中新文档、消息、工单、告警、定时信号或 webhook 都可以成为 event trigger。此时 Agent 不再只在用户发问时存在而是成为业务事件的订阅者。事件循环的意义不仅是自动化频率更高而是引入了新的真实性信号真实输入分布、真实工具异常、真实用户纠正和真实业务结果。也正因为如此第三层是第四层的素材来源。没有事件与生产轨迹持续改进只能在静态样例上进行没有校验与权限事件循环又会放大错误的影响范围。LangChain 还强调 human-in-the-loop 并没有被自动化取代敏感或不可逆的操作需要人类批准人类也可以处于 grader、业务提交和 harness 变更审查的位置。来源2.4 Loop 4Hill-climbing loop——改进的是 harness而非只改一次输出Hill-climbing loop爬山式持续改进以 production trace 为输入。trace 包含模型做了什么、调用了哪些工具、工具观察是什么、grader 如何评分、花费了多少时间与 token以及最终是否达成业务结果。分析 Agent 从大量 trace 中发现重复失败模式诊断根因并产出针对 harness 的候选改变。这层的关键思想是返回箭头“伸入”内层循环。被改变的可能是prompt 与上下文选择工具描述、参数约束或工具路由记忆与检索到的辅助上下文grader 的 rubric 与覆盖范围模型、策略或代码。LangSmith Engine 将这一闭环产品化为检测反复出现的问题、结合 trace 与代码诊断根因、提出修复、生成 evaluator 与离线 ground-truth 示例并在同类问题复发时重新打开问题。LangSmith Engine 文档 这表明一个“改进 Agent”的价值不在于标记单条异常而在于能否把原始轨迹压缩成可路由、可验证、可复用的工程问题。3. Eval 在 Loop Engineering 中的地位Eval 并非部署前的一次考试而是闭环中的测量装置。它至少承担三种不同职责Eval 类型观察对象回答的问题离线评测offline eval固定、带标签或带断言的样本新版本是否优于基线在线评测online eval生产运行的抽样或规则命中 trace系统在真实分布下是否退化人工评测human review高歧义、高风险或主观质量场景rubric 是否表达了真正的业务判断对复杂 Agent 而言eval 不能只看 final answer。LangChain 对 Deep Agents 的总结把可评估对象分为三类trajectory调用了哪些工具、参数是否正确、动作序列是否合理final response最终回复是否正确、完整、符合任务other state / artifacts文件、记忆、数据库状态或其他产物是否真的满足要求。这个区分非常重要。对话 Agent 的终局可能是一段文本编码 Agent 的终局可能是可通过测试的文件系统状态具有记忆的 Agent 的终局也包括持久化记忆是否被正确写入。将所有 Agent 都压缩成“回答文本得分”会遗漏最容易造成生产事故的轨迹和状态错误。LangChain 的 Deep Agents Eval 总结4. 从 ReviewBench 到 IssueBench名称澄清与评测思想这里需要做一个事实澄清在公开检索到的 LangChain 官方资料中团队发布和介绍的是IssueBench不是ReviewBench。ReviewBench是学术界用于评估论文评审文本的一类基准名称LangChain 的对应工作是用于评估 LangSmith Engine 的IssueBench。两者都关心“review 的质量”但任务对象不同前者评价文本评审后者评价 Agent 对运行轨迹进行问题发现与归并的能力。IssueBench 恰好为 Loop Engineering 中的 eval 提供了一个更高阶的范式它评测的不是业务 Agent 本身而是负责诊断和改善业务 Agent 的分析 Agent。于是评测对象也从“答案对不对”上升为“是否把复杂的失败迹象组织成真正可行动的问题”。4.1 IssueBench 的任务定义LangChain 为 Engine 构建的内部 benchmark 由15 个任务构成。每个任务包含一批 Agent trace 和一组已有 issuetrace 中混有干净轨迹以及已知、已标注的注入式失败。Engine 需要完成四类工作识别哪些 trace 存在问题给问题分配正确的 failure category将相同根因的 trace 关联到正确的已有 issue将新的失败聚成新的 issue card。该基准采用合成环境来同时获得可控的 ground truth 与近似真实的 Agent 行为当前覆盖 SRE 日志分析、软件工程、客户支持三类场景同一失败范畴跨领域出现用来区分“理解抽象失败模式”与“记住某一业务表象”。任务在 Harbor 中隔离运行并对隐藏 ground truth 评分。IssueBench 官方文章4.2 为什么“问题归并”本身需要评测逐 trace 标记异常不等于问题诊断。若十条同根因失败被创建成十张 issue 卡团队会被噪声淹没若不同失败被错误合并到一张宽泛卡片又会失去定位修复的能力。IssueBench 正是在这一层评分评分维度衡量的能力典型坏结果分类classification区分 issue trace 与 clean trace把正常轨迹误报为问题或漏掉真实问题失败类别issue category给失败归入正确故障类型将 silent tool error 归为 hallucination已有问题关联把重复症状接到正确 issue忽略已有根因重复建卡新问题归组将新型同根因症状形成合适的 issue一条 trace 一张卡或把无关问题强行合并官方给出的 failure taxonomy 有 15 类PII 泄露、幻觉、系统提示漂移、错误工具、能力缺口、错误恢复失败、工具参数错误、Agent 循环、上下文膨胀、护栏绕过、响应截断、静默工具错误、错误计划、任务逃避、能力认知缺失。这个 taxonomy 的价值不只是标签它把“用户体验不好”分解成指向不同根因、不同责任边界和不同验证方式的工程语言。4.3 IssueBench 对 eval 观念的三个启发第一clean / no-issue 类与失败类同样重要。如果“看起来正常”的轨迹中混入隐藏问题误报率会失真模型或版本的比较就不可信。Eval 不是只收集坏例子负例质量决定了分数是否具有区分力。第二评测必须贴近产物的真实用途。Engine 面向团队交付的是 issue 集合而非逐条异常概率所以 IssueBench 评分 issue 分类、既有卡关联与新卡归并。一个 eval 若只测容易量化的代理指标可能会奖励一个对真实工作没有帮助的系统。第三基准也会反向暴露定义的含混。Engine 误分类并不总是模型能力问题它也可能说明类别边界模糊、issue 描述不足或评分规则与实际 triage 判断不一致。因而 eval 既评估系统也校准团队对“好”的定义。5. Verification、Evaluation 与 Analysis三个容易混淆的层次概念发生时机粒度核心产物Verification单次运行内或结果提交前单个任务pass/fail、反馈、可提交结果Evaluation版本比较或线上监测样本集 / trace 集分数、回归、能力画像Analysis观察到重复模式之后问题簇 / 系统层面根因假设、issue、改进候选三者共同构成 Loop Engineering 的质量基础verification 保护一次行动evaluation 判断某个版本是否变好analysis 从大量运行中解释“为什么会坏、坏在哪里”。把 verification 当成 eval会得到很多局部检查却不知道版本是否提升把 eval 当成 analysis会得到分数却没有根因把 analysis 当成自动修复则会忽略候选变更本身也需要被验证。6. 对“持续改进”的边界理解Hill-climbing 是一种局部改进隐喻不意味着自动化一定单调向好。它至少面对四种认识论风险指标代理化Goodhart系统可能学会取悦 grader而非改善真实质量。数据分布偏移生产样本偏向常见任务罕见但关键的场景会在优化中被牺牲。因果误判trace 的共同表象不必然说明同一根因一次修复的相关性也不等于因果收益。局部最优只围绕当前错误做小修补可能阻碍架构级改进或掩盖能力缺口。因此Loop Engineering 的成熟形态不是“自动改 prompt”而是让系统拥有可观察性、可比较性、可解释的评价准则与受控的学习记忆。LangChain 所说的 loop 是一种通用模式可优化的对象可以是提示词、工具、grader、memory、retrieved skills甚至模型本身真正不可替代的是从行动到证据再到改进的闭环结构。7. 关键结论Agent 的竞争力不只来自模型而来自包围模型的循环与 harness。验证是输出是否可信的证据链评测是版本是否更好的比较机制分析是将失败变成工程问题的过程。复杂 Agent 的 eval 必须同时观察轨迹、最终回复和外部状态。IssueBench 展示了 meta-evaluation连“负责发现并归类失败的 Agent”也需要自己的 ground truth、负例、归并质量和跨域泛化评测。最外层的学习循环只有在内层行动、验证与观测足够清晰时才有价值否则它只会把噪声自动化。参考资料Sydney Runkle, The Art of Loop Engineering, LangChain, 2026-06-16。LangChain Webinar, The Art of Loop Engineering: How to Build Agents That Improve Over Time。LangChain Docs, Context engineering in agents。Nick Bray Arjun Nargolwala, IssueBench — How We Evaluate Engine, LangChain, 2026-07-20。LangChain, Evaluating Deep Agents: Our Learnings, 2025-12-03。LangChain Docs, Find and fix your agents issues with LangSmith Engine。 Loop Engineering：以评测闭环为核心的 Agent 系统观
Loop Engineering循环工程关注的不是“写出一个更聪明的提示词”而是围绕 Agent 设计一组相互嵌套的反馈循环使行动、验证、业务触发与系统改进成为同一套可观察的机制。模型是其中的推理引擎决定系统是否可靠的是承载模型的 harness上下文、工具、状态、评测、记忆、权限与反馈通道。图用户提供的 LangChain Loop Engineering 示意图。由内到外依次是 Agent、verification、event 与 hill-climbing 四层循环最外层并非简单重复执行而是借由 trace 分析反向改进内层 harness。1. 从“单次生成”到“反馈系统”传统 LLM 应用常被理解为一个函数输入 prompt返回 output。Agent 则至少包含两种交替发生的行为模型根据上下文决定动作工具执行后把 observation 返回给模型。LangChain 将这称为最基本的agent loopmodel call → tool execution → observation → model call直至任务结束。LangChain 的 context engineering 文档强调Agent 的失败通常不只是模型能力不足更常见的是模型在某个时刻没有获得正确的上下文、工具或生命周期约束。Loop Engineering 的转变在于关注对象从“一次回答是否漂亮”转为“系统能否反复产出可接受结果”质量的来源从模型自我声明转为外部可检验的证据失败不再只是一次运行的损失而成为评测、诊断与下一轮改进的输入优化对象不局限于 prompt还包括工具描述、路由、状态、检索、记忆、评测器与权限边界。这是一种控制论式的理解Agent 的输出经过测量测量结果形成误差信号误差信号再影响下一次决策或下一版本 harness。没有评价标准与反馈通道的“循环”只是重复能改变系统行为的闭环才是工程意义上的 loop。2. 四层嵌套循环LangChain 在 The Art of Loop Engineering 中把生产级 Agent 概括为四层循环。它们不是四个彼此独立的功能而是由内到外包裹外层以更慢的频率观察与改变内层。层级闭环核心问题产生的信号Loop 1Agent loop怎样完成一次任务动作、观察、结果Loop 2Verification loop结果是否满足要求分数、断言、失败原因Loop 3Event-driven loopAgent 如何进入真实业务世界事件、状态变更、业务结果Loop 4Hill-climbing loop系统怎样从运行中变好Trace、失败模式、评测集、候选变更2.1 Loop 1Agent loop——行动与观察Agent loop 是工具使用的最小结构。模型不直接拥有世界状态它通过工具读取信息、执行动作并根据 observation 修正后续判断。因此轨迹trajectory与最终回复同等重要一个看似正确的答案可能来自错误的工具、越权的数据访问或不稳定的偶然路径。LangChain 将可控上下文区分为三类模型上下文model context系统指令、消息、可用工具、模型与输出格式它决定模型在单次调用中“看见什么”。工具上下文tool context工具可访问和可写入的 state、store 与运行时信息它决定动作可以影响什么。生命周期上下文life-cycle context模型调用与工具调用之间的摘要、护栏、日志、跳转等机制它决定循环怎样延续、暂停或改道。这三层上下文解释了为什么“模型很强却依然不可靠”是常态可靠性并不只由权重决定而是由模型在每个决策点可见的信息、可调用能力与运行约束共同决定。2.2 Loop 2Verification loop——结果与证据之间的闭环Verification loop 在 Agent 得到候选结果后引入独立的grader。grader 将结果映射到 rubric评价准则返回通过、失败及可解释的反馈失败反馈成为下一次尝试的上下文。LangChain 将这层关联到RubricMiddleware或after_agenthook在其文档 Agent 示例里链接解析、CI、变更范围都是验证证据而不是模型的主观自评。来源verification 的本质不是“再问一个 LLM 是否正确”而是建立证据的层级确定性证据格式、类型、约束、单元测试、策略规则、数学或数据库断言。这类证据可重复、边界清楚。语义性证据事实覆盖、解释完整性、风格与受众匹配。它们常由 LLM-as-a-judge 或人工判断必须依附明确 rubric。业务性证据真实动作是否带来目标状态例如工单是否正确更新、代码是否通过 CI、用户是否接受结果。这里有一个关键区别自我反思self-reflection是生成策略验证verification是质量证据。前者可能帮助 Agent 发现问题后者才决定结果是否可信。把同一模型、同一上下文中的“我觉得没问题”当作验收会把同源偏差伪装成质量信号。2.3 Loop 3Event-driven loop——Agent 进入系统而非停留在聊天框事件循环把 Agent 置于真实生态中新文档、消息、工单、告警、定时信号或 webhook 都可以成为 event trigger。此时 Agent 不再只在用户发问时存在而是成为业务事件的订阅者。事件循环的意义不仅是自动化频率更高而是引入了新的真实性信号真实输入分布、真实工具异常、真实用户纠正和真实业务结果。也正因为如此第三层是第四层的素材来源。没有事件与生产轨迹持续改进只能在静态样例上进行没有校验与权限事件循环又会放大错误的影响范围。LangChain 还强调 human-in-the-loop 并没有被自动化取代敏感或不可逆的操作需要人类批准人类也可以处于 grader、业务提交和 harness 变更审查的位置。来源2.4 Loop 4Hill-climbing loop——改进的是 harness而非只改一次输出Hill-climbing loop爬山式持续改进以 production trace 为输入。trace 包含模型做了什么、调用了哪些工具、工具观察是什么、grader 如何评分、花费了多少时间与 token以及最终是否达成业务结果。分析 Agent 从大量 trace 中发现重复失败模式诊断根因并产出针对 harness 的候选改变。这层的关键思想是返回箭头“伸入”内层循环。被改变的可能是prompt 与上下文选择工具描述、参数约束或工具路由记忆与检索到的辅助上下文grader 的 rubric 与覆盖范围模型、策略或代码。LangSmith Engine 将这一闭环产品化为检测反复出现的问题、结合 trace 与代码诊断根因、提出修复、生成 evaluator 与离线 ground-truth 示例并在同类问题复发时重新打开问题。LangSmith Engine 文档 这表明一个“改进 Agent”的价值不在于标记单条异常而在于能否把原始轨迹压缩成可路由、可验证、可复用的工程问题。3. Eval 在 Loop Engineering 中的地位Eval 并非部署前的一次考试而是闭环中的测量装置。它至少承担三种不同职责Eval 类型观察对象回答的问题离线评测offline eval固定、带标签或带断言的样本新版本是否优于基线在线评测online eval生产运行的抽样或规则命中 trace系统在真实分布下是否退化人工评测human review高歧义、高风险或主观质量场景rubric 是否表达了真正的业务判断对复杂 Agent 而言eval 不能只看 final answer。LangChain 对 Deep Agents 的总结把可评估对象分为三类trajectory调用了哪些工具、参数是否正确、动作序列是否合理final response最终回复是否正确、完整、符合任务other state / artifacts文件、记忆、数据库状态或其他产物是否真的满足要求。这个区分非常重要。对话 Agent 的终局可能是一段文本编码 Agent 的终局可能是可通过测试的文件系统状态具有记忆的 Agent 的终局也包括持久化记忆是否被正确写入。将所有 Agent 都压缩成“回答文本得分”会遗漏最容易造成生产事故的轨迹和状态错误。LangChain 的 Deep Agents Eval 总结4. 从 ReviewBench 到 IssueBench名称澄清与评测思想这里需要做一个事实澄清在公开检索到的 LangChain 官方资料中团队发布和介绍的是IssueBench不是ReviewBench。ReviewBench是学术界用于评估论文评审文本的一类基准名称LangChain 的对应工作是用于评估 LangSmith Engine 的IssueBench。两者都关心“review 的质量”但任务对象不同前者评价文本评审后者评价 Agent 对运行轨迹进行问题发现与归并的能力。IssueBench 恰好为 Loop Engineering 中的 eval 提供了一个更高阶的范式它评测的不是业务 Agent 本身而是负责诊断和改善业务 Agent 的分析 Agent。于是评测对象也从“答案对不对”上升为“是否把复杂的失败迹象组织成真正可行动的问题”。4.1 IssueBench 的任务定义LangChain 为 Engine 构建的内部 benchmark 由15 个任务构成。每个任务包含一批 Agent trace 和一组已有 issuetrace 中混有干净轨迹以及已知、已标注的注入式失败。Engine 需要完成四类工作识别哪些 trace 存在问题给问题分配正确的 failure category将相同根因的 trace 关联到正确的已有 issue将新的失败聚成新的 issue card。该基准采用合成环境来同时获得可控的 ground truth 与近似真实的 Agent 行为当前覆盖 SRE 日志分析、软件工程、客户支持三类场景同一失败范畴跨领域出现用来区分“理解抽象失败模式”与“记住某一业务表象”。任务在 Harbor 中隔离运行并对隐藏 ground truth 评分。IssueBench 官方文章4.2 为什么“问题归并”本身需要评测逐 trace 标记异常不等于问题诊断。若十条同根因失败被创建成十张 issue 卡团队会被噪声淹没若不同失败被错误合并到一张宽泛卡片又会失去定位修复的能力。IssueBench 正是在这一层评分评分维度衡量的能力典型坏结果分类classification区分 issue trace 与 clean trace把正常轨迹误报为问题或漏掉真实问题失败类别issue category给失败归入正确故障类型将 silent tool error 归为 hallucination已有问题关联把重复症状接到正确 issue忽略已有根因重复建卡新问题归组将新型同根因症状形成合适的 issue一条 trace 一张卡或把无关问题强行合并官方给出的 failure taxonomy 有 15 类PII 泄露、幻觉、系统提示漂移、错误工具、能力缺口、错误恢复失败、工具参数错误、Agent 循环、上下文膨胀、护栏绕过、响应截断、静默工具错误、错误计划、任务逃避、能力认知缺失。这个 taxonomy 的价值不只是标签它把“用户体验不好”分解成指向不同根因、不同责任边界和不同验证方式的工程语言。4.3 IssueBench 对 eval 观念的三个启发第一clean / no-issue 类与失败类同样重要。如果“看起来正常”的轨迹中混入隐藏问题误报率会失真模型或版本的比较就不可信。Eval 不是只收集坏例子负例质量决定了分数是否具有区分力。第二评测必须贴近产物的真实用途。Engine 面向团队交付的是 issue 集合而非逐条异常概率所以 IssueBench 评分 issue 分类、既有卡关联与新卡归并。一个 eval 若只测容易量化的代理指标可能会奖励一个对真实工作没有帮助的系统。第三基准也会反向暴露定义的含混。Engine 误分类并不总是模型能力问题它也可能说明类别边界模糊、issue 描述不足或评分规则与实际 triage 判断不一致。因而 eval 既评估系统也校准团队对“好”的定义。5. Verification、Evaluation 与 Analysis三个容易混淆的层次概念发生时机粒度核心产物Verification单次运行内或结果提交前单个任务pass/fail、反馈、可提交结果Evaluation版本比较或线上监测样本集 / trace 集分数、回归、能力画像Analysis观察到重复模式之后问题簇 / 系统层面根因假设、issue、改进候选三者共同构成 Loop Engineering 的质量基础verification 保护一次行动evaluation 判断某个版本是否变好analysis 从大量运行中解释“为什么会坏、坏在哪里”。把 verification 当成 eval会得到很多局部检查却不知道版本是否提升把 eval 当成 analysis会得到分数却没有根因把 analysis 当成自动修复则会忽略候选变更本身也需要被验证。6. 对“持续改进”的边界理解Hill-climbing 是一种局部改进隐喻不意味着自动化一定单调向好。它至少面对四种认识论风险指标代理化Goodhart系统可能学会取悦 grader而非改善真实质量。数据分布偏移生产样本偏向常见任务罕见但关键的场景会在优化中被牺牲。因果误判trace 的共同表象不必然说明同一根因一次修复的相关性也不等于因果收益。局部最优只围绕当前错误做小修补可能阻碍架构级改进或掩盖能力缺口。因此Loop Engineering 的成熟形态不是“自动改 prompt”而是让系统拥有可观察性、可比较性、可解释的评价准则与受控的学习记忆。LangChain 所说的 loop 是一种通用模式可优化的对象可以是提示词、工具、grader、memory、retrieved skills甚至模型本身真正不可替代的是从行动到证据再到改进的闭环结构。7. 关键结论Agent 的竞争力不只来自模型而来自包围模型的循环与 harness。验证是输出是否可信的证据链评测是版本是否更好的比较机制分析是将失败变成工程问题的过程。复杂 Agent 的 eval 必须同时观察轨迹、最终回复和外部状态。IssueBench 展示了 meta-evaluation连“负责发现并归类失败的 Agent”也需要自己的 ground truth、负例、归并质量和跨域泛化评测。最外层的学习循环只有在内层行动、验证与观测足够清晰时才有价值否则它只会把噪声自动化。参考资料Sydney Runkle, The Art of Loop Engineering, LangChain, 2026-06-16。LangChain Webinar, The Art of Loop Engineering: How to Build Agents That Improve Over Time。LangChain Docs, Context engineering in agents。Nick Bray Arjun Nargolwala, IssueBench — How We Evaluate Engine, LangChain, 2026-07-20。LangChain, Evaluating Deep Agents: Our Learnings, 2025-12-03。LangChain Docs, Find and fix your agents issues with LangSmith Engine。