Loop Engineering是2026年人工智能圈最火爆的核心概念，它指的是设计、运营和持续改进反馈循环（Feedback Loops）的AI工程化实践。NVIDIA 首席执行官黄仁勋将其形容为定义2026下半年AI发展的重大转变为：**现在没人写提示词了，大家都在编写和管理循环（Loops）**。它的核心思想是让你从一个**向AI发送指令的人**，变成一个**设计自动运转系统，让AIAgen

Handoff（交接模式）允许Agent根据上下文或用户请求相互转移控制权。每个Agent都可以将对话“交接”给具有相应专业知识的其他Agent，确保任务的每个环节都由合适的Agent处理。这在客户支持、专家系统或任何需要动态委派任务的场景中尤为有用。

本文介绍了如何利用OpenTelemetryAgent中间件实现LLM（大语言模型）调用的链路跟踪和性能监控。通过搭建本地Jaeger（链路跟踪）、Prometheus（指标收集）和Grafana（数据可视化）的Docker环境，结合OpenTelemetry框架，开发者可以轻松监控Agent调用链和性能指标。文章提供了一个C#示例程序，展示了如何配置TracerProvider（输出到Jaege

在前文中，我们详细介绍了MAF的Workflow框架中的Checkpointing机制，并且通过一个示例程序演示了如何利用Checkpointing来实现Agent的状态持久化和恢复功能。其中提到一个关于FanInEdge的bug，我认为这是一个非常严重的bug，它会导致只要涉及到FanInEdge的Checkpointing功能就无法正常工作。我为此在github上提交了一个Issue,我们现在

`AIFunction`通过绑定一个方法实现了在Agent本地执行工具，当时更多的情况下，我们会利用一个MCP服务来为一个或者多个Agent提供工具。这种情况下，我们就需要利用`McpClientTool`来远程调用MCP服务提供的工具。`McpClientTool`自身是一个`AIFunction`，它通过MCP协议来调用远程的MCP服务提供的工具。在正式介绍`McpClientTool`之前，

Pregel由Node和Channel这两个核心部件组成，Channel不仅维护了整个图的状态，还是驱动Node执行的 “原力” 。

除了我们显式声明的用于存储业务数据或驱动信号的Channel之外，Pregel自身也会维护一些系统Channel，其中最重要的莫过于一个名为“__pregel_tasks”的Channel，是它成就了基于“PUSH”的节点任务执行方式。

一个Pregel由Node和Channel构建而成，后者保持状态并以Pub/Sub的方式驱动Node执行，Pregel中的Node是一个PregelNode对象，是一个完全无状态的功能节点。

当我们在调用Pregel对象的`invoke`方法的时候，可以利用参数（durability）指定采用的持久化模式，它决定了在Superstep N成功结束之后，针对Checkpoint的持久化与开始Superstep N+1之间的关系。

到目前为止，我们已经大体了解Pregel的`invoke/ainvoke`方法在背后都做了什么。接下来我们分两种情况简单梳理一下Pregel对象的执行的大体流程，这也是我们创建的Agent的执行流程。具体执行场景分两种， 一种是指定输入从头开始的常规调用，另一种是针对某个Checkpoint的恢复调用。