Loop Engineering：为什么智能体运行时是新的中间件

本文建立在 长时间运行智能体模式：让智能体跨越数小时和数天保持存活 之上，后者映射了在数小时至数天范围内出现的三种失败模式（轨迹级偏差、压缩侵蚀、自进化）以及捕获它们的三层强制机制。这里我们关注一个互补的发展：运行时层本身正在成为一种受管理的、可检查的中间件——TrueFoundry 称之为 loop engineering，发布于 2026 年 8 月 23 日。

关键要点

• LangGraph 拥有 3450 万月度 PyPI 下载量和约 400 个企业部署，包括 Klarna、Uber 和 BlackRock — 模型周围的运行时层是生产差异化积累的地方，而非模型选择（uvik.net 生产比较）
• TrueFoundry 的 loop engineering 模式命名了五个从 prompt 转向运行时的操作决策：审批检查点、会话持久化、凭证隔离、上下文压缩和按需能力加载 — 每个都是运行时属性，而非 prompt 指令（TrueFoundry）
• 图工程治理循环之间的边：谁在行动、什么跨越边界、花费多少以及什么证据留存 — "评估节点，治理边"原则使权限、数据流动和支出在拓扑层可执行（TrueFoundry）
• 单个智能体在 64% 的基准测试任务中达到或超过多智能体系统，成本仅为 2 倍 — 第一个架构决策是你是否需要多个智能体，而循环是执行该决策的地方（Princeton NLP）

每个企业软件时代都会发展出一个看似次要的层，直到操作决策在那里积累。在客户端-服务器时代是应用服务器。在云时代是容器编排器。在数据时代是管道调度器。对于 AI 智能体，这个层有一个名字：包裹模型并将其转变为可靠、长时间运行智能体的运行时。仅 LangGraph 就有 3450 万月度 PyPI 下载量和约 400 个企业部署——运行时不是次要层。TrueFoundry 的文档将 agent harness 明确定义为"围绕 LLM 的运行时层，将其转变为可靠的长时间运行智能体。"本文映射了 loop engineering 模式——循环中介了什么、为什么它表现得像中间件以及图工程治理层添加了什么——并解释了为什么循环而非模型是 B2B 部署可靠性决定的地方。

问题：操作判断存在于循环中，而非 prompt 中

Prompt 工程问的是对模型说什么。上下文工程问的是给它看什么。循环工程问的是系统在模型调用之间做什么。这个问题属于平台和安全工程的程度不亚于 prompt 作者，因为循环是机构操作决策变得可执行的地方。

当列出循环在每个回路中中介的内容时，这个区别变得具体。配置的工具调用是写入生产系统还是暂停等待人工。会话状态是否在重连和重启后存活。生成的代码是否能看到 harness 凭证。长任务是否裁剪或卸载上下文。委托的子任务是否返回最终结果而非整个工作记录。这些都无法仅靠模型行为可靠地强制执行。每一个都是组织可能希望一致应用的操作决策——这就是为什么循环开始看起来像中间件。

翻译表让模式变得可见：

操作判断	作为 prompt，它是...	在循环中，它变成...
写入/破坏性操作等待人工	建议	强制检查点
工作在重连/重启后恢复	尽力而为	持久会话
凭证远离执行中的代码	希望	架构式隔离
长任务管理上下文	无限历史	受管理压缩
能力按需到达	载荷膨胀	按需发现

循环决策与 prompt 指令的组合方式不同，因为运行时策略可以确定性地中介每一轮。改变压缩发生的位置，使用该运行时的每个长任务都继承了这一改变。添加审批边界，一类风险操作现在需要明确授权而非仅依赖行为纪律。这个机制在中间件中很常见——定义一次控制，一致应用——它解释了为什么高级工程注意力正在转向运行时。

这个模式直接连接到父文档记录的三种失败模式。基于压缩的侵蚀（治理衰减）是循环问题：丢弃安全规则的摘要器存在于循环的上下文管理步骤中。轨迹级偏差是循环问题：逐操作门控看到一系列通过的 tool 调用，而属于循环的轨迹级监控看到了偏差。自进化是循环问题：编辑自身约束的智能体在编辑循环管理的状态。循环是所有三种失败模式出现或被抑制的基底。

循环作为中间件：历史解读

跨技术时代的重复模式并不是中间件不可避免地成为开源。企业应用服务器仍然包括与开放标准并存的主要专有产品。容器编排强烈收敛到开源 Kubernetes 周围。工作流调度有影响力的开源系统（Apache Airflow）与托管替代方案并存。教训更窄：一旦操作层变得战略重要，企业就重视可检查性、可移植性以及按自己条件运行或替换该层的能力。

时代	被赞颂的组件	决定结果的层	最终去向
客户端-服务器	数据库	应用服务器	混合：专有加开放标准
云	虚拟机	容器编排器	开源 Kubernetes 成为主导
数据	数据仓库	管道调度器	开源调度器与托管服务共存
智能体	模型	循环	正在决定中

智能体循环可能遵循这条弧的一部分。开放的理由是具体的：源代码可用性使实现级审计成为可能（它不证明部署的二进制文件是可信的，但使审计成为可能）。支持自托管的运行时可以将执行层放在你的边界内。可扩展的开放实现让团队更改压缩、检查点或集成行为而无需等待供应商路线图。TrueFoundry 以 MIT 许可发布了其 harness TrueForge，支持本地和托管运行，将模型、MCP 服务器和沙箱提供者视为连接的依赖项。

战略总结：执行你判断的层应该是你可以判断的层。

向你的循环提出什么问题

如果循环是操作判断所在的地方，采购问题是你的运行时是否可检查和可移植。六个问题构成审问框架：

1. 工作能在重启后存活吗？会话持久化是运行时属性。一个必须在每次中断后从头开始的智能体不是长时间运行的智能体——它是一个不断被重启的短命智能体。
2. 代码执行环境能看到什么？沙箱设计将 harness 凭证保持在模型触达范围之外。如果模型能读取提供自身计算的 API 密钥，隔离是 prompt 而非边界。
3. 哪些操作为人工暂停——由运行时还是由希望？工具审批是强制检查点和建议之间的区别。循环使其确定化。
4. 能力是按需加载还是在每轮都携带？延迟的工具和技能减少载荷膨胀。在每次回路中发送每个工具描述的循环浪费了智能体推理所需的上下文窗口。
5. 运行可以从其痕迹重建吗？仅追加的会话日志模式——由 DeepSeek Harness 和 Meta Muse Code 独立收敛——是回放、回滚和审计的基底。父文章详细记录了这一收敛。
6. 如果你明天离开运行时供应商，你会失去什么？真正的可移植性取决于数据格式、集成和操作实践，而不仅仅是源代码可用性。但实现无法检查的运行时使深度审计、自托管、修改和退出规划更加困难。

从循环到图：治理连接

具有持久循环的单个智能体解决了执行问题。但生产系统很少运行单个智能体。从智能体到循环到图的进阶——在每一步添加不同的系统问题。TrueFoundry 的 From Agent to Loop to Graph 架构文章框架了升级：第一个可工作的智能体引入能力和工具使用问题。持久循环添加状态、恢复、上下文和审批关注。图添加拓扑、协调和委托。自修改引发验证、隔离和推广问题。编排将组合系统转变为操作问题。

关键区别是图不替代循环——它组织循环和其他节点。生产图可能包含智能体、确定性函数、路由器、连接、队列、人工检查点、评估器、数据库写入和普通服务。只有智能体节点需要自己的本地执行循环。图拥有如下问题：下一个运行哪个节点、分支是否并行执行、哪个结果解锁连接、一个分支失败时会发生什么以及哪条路径需要人工检查点。智能体节点内的循环拥有一组不同的问题：智能体看到什么上下文、选择哪个工具、如何处理观察、何时重试以及本地工作何时完成。

第二个区别很重要：图编排不是知识图谱。知识图谱结构化信息——实体和关系。智能体执行图结构化执行——参与者、计算节点、转换、依赖和工作状态。一个可以喂养另一个，但它们回答不同的问题。如果研究智能体查询知识图谱然后委托验证给第二个智能体，知识图谱是系统所知的一部分；执行图描述系统所做之事。

TrueFoundry 用七个词压缩的治理原则：评估节点，治理边。你仍然评估节点行为——模型评估不会消失。但仅靠评估无法使生产数据库拒绝写入、执行预算或要求在破坏性操作前审批。运行时、网关和下游授权边界在相关流量通过时执行这些约束。每个有后果的边应回答五个问题：

问题	为什么重要	可能的负责方
谁或什么在行动？	归因、最小权限、审计	身份/注册表
此节点能到达什么？	发现不是授权	编排器+网关+下游策略
什么可以跨越边？	数据最小化、prompt 注入防御	应用策略+网关护栏
可以花费或扇出多少？	图乘以重试、分支和模型调用	编排器+网关预算
什么证据留存？	设计图和执行图会偏离	编排器+harness+记录系统

框架格局：loop engineering 的位置

Loop engineering 是运行时级模式，不是框架选择。截至 2026 年 8 月框架格局稳定：

• LangGraph — 3450 万月度 PyPI 下载量，约 400 个企业部署包括 Klarna、Uber、LinkedIn、BlackRock 和 JPMorgan。有状态智能体的生产标准，具备检查点、时间旅行调试和原生 MCP 支持。LangSmith 用于可观测性。
• CrewAI — 超过 44,600 GitHub 星标，平台上每月超过 10M 智能体执行，约 60% 的 Fortune 500 在探索。简单任务的 token 开销比 LangGraph 高达 3 倍。
• Microsoft Agent Framework — 2026 年 4 月 3 日发布 1.0 GA，替代 AutoGen（现处于维护模式）。原生 MCP 支持；A2A 通过单独适配器（测试版）。
• OpenAI Agents SDK — 约 19,000 GitHub 星标，1030 万月度下载量。
• Google ADK — Gemini 原生，A2A 优先。
• DeepSeek Harness — MIT 许可，超过 33K GitHub 星标，仅追加会话日志。

Princeton NLP 的发现锚定了第一个架构决策：单个智能体在 64% 的基准任务中达到或超过多智能体系统，成本仅为 2 倍。在选择多智能体图之前，先问任务是否值得协调开销。循环是执行该决策的地方——一个工程良好的循环，具备检查点/恢复、审批门控和上下文管理，可以做多智能体图以更高成本和更多故障面才能做的工作。

Loop engineering 与所有这些框架兼容。该模式关注运行时中介了什么，而非你在哪个框架上构建。LangGraph 的检查点和时间旅行调试是 loop engineering 原语。DeepSeek Harness 的仅追加会话日志是 loop engineering 原语。TrueForge 的工具审批和沙箱隔离是 loop engineering 原语。收敛就是信号：当多个独立运行时实现同一组操作控制时，这些控制就是结构要求，而非供应商选择。

Loop engineering 模式——在模型和业务系统之间的执行循环中积累的运行时决策：

相关阅读

• 长时间运行智能体模式：让智能体跨越数小时和数天保持存活 — 父文章映射了三种失败模式（轨迹级偏差、治理衰减、自进化）和三层强制机制（推理前、运行时、回滚），loop engineering 将其操作化
• Kill Switch by Design：智能体治理架构 — 三层强制模型（推理前钩子、运行时断路器、事后回滚），循环在运行时层实现
• AI 智能体可观测性：你看不到的会伤害你 — 四层遥测栈，使 loop engineering 智能体可查询而非可 grep

一个运行 NetSuite 和 BigCommerce 的中型经销商部署了一个智能体，24/7 监控采购收件箱、检查供应商目录、应用商业规则并起草报价。该智能体运行数小时而非数分钟。Loop engineering 模式是让它保持在边界内的关键：在写入 NetSuite 前暂停的审批检查点、在供应商 API 超时后恢复智能体的会话持久化、将 NetSuite OAuth 令牌保持在模型上下文之外的凭证隔离，以及裁剪旧 RFQ 历史而不丢弃治理定价的商业规则的上下文压缩。构建是一个范围明确的参与：RFQ 引擎、MCP 连接器模块、带检查点/恢复和审批门控的循环运行时，以及治理报价智能体、合规智能体和 NetSuite 回写之间边的图层。

一周发现。您获得系统清单、工作流映射和固定范围——whether or not you build with us.