夜雨聆风AI 圈造了个新词：Loop Engineering。它说的是围绕 Agent 搭建一个“思考—调用工具—检查结果—继续或停止”的闭环系统。相比早期只聊 Prompt Engineering，这个词更强调任务分解、工具调用、状态保存、人工审批、错误恢复和持续验证。有人觉得这是 AI 应用从聊天机器人变成真正生产力工具的关键标志。
但也有人点破：所谓循环工程，本质上就是软件工程——尤其是过去二十年逐步成熟的事件驱动、可观测、有状态的分布式系统。
一个词，掩盖了三十年的工程积累
AI 圈讲 Agent 时，喜欢把“模型不断调用工具直到任务完成”包装成全新的“代理循环”。从后端系统看，这不过是一个消息队列消费者：系统接任务，拆成步骤；工作进程取任务，做一次模型或工具调用；结果写回持久化存储；下一步进队列；直到流程完成、失败或超时。
Agent 的“思考—行动循环”，在工程上就是一个带状态的异步工作流。
这类问题，传统软件系统早就处理过：订单系统支付成功后触发库存扣减、物流创建、通知发送；风控系统在异常交易时调用多个外部服务；数据平台让任务失败重试、超时终止、重复提交时保持幂等。Agent 系统今天遇到的难题，几乎都能在这些老场景里找到对应物。
| AI 圈的新词 | 软件工程里的老名字 |
|---|---|
| Agent Loop（代理循环） | 消息队列消费者 + 持久化执行 |
| Verification Loop 的停止条件 | 预算、超时、失败阈值、熔断机制 |
| Sub-agents（子代理） | 彼此隔离的会话、队列、权限域 |
| Human Oversight（人工监督） | 中间件链、拦截器、审批节点 |
| Agent Memory（代理记忆） | 数据库、键值存储、缓存 |
这些对应关系不是在说 AI 没有新问题，而是提醒：别把基础设施问题误认成概念创新。
“连接器”最容易制造幻觉
“连接器”这个词特别容易让人以为这是 Agent 时代特有的能力。
实际上，只要一个智能体能调用外部系统——发邮件、创建工单、提交采购申请、触发设备控制指令——它就立刻进入了分布式系统最经典的风险区：网络超时、重复调用、部分成功、状态不一致、权限越界。
举个例子：Agent 请求创建一笔采购订单，接口返回超时。
系统该重试，还是停止？
如果订单其实已经创建成功，只是响应包丢了，重试会不会造成重复下单？
如果 Agent 执行了前两步，第三步失败，前两步要不要回滚？
这些问题不属于提示词工程，也不属于模型能力本身。它们的真实名字是幂等性、事务边界、补偿机制、故障恢复——分布式系统教材第一章就会讲的内容。
从 Prompt Engineering 到 Loop Engineering：重心的真实迁移
早期的大模型应用，注意力几乎全在 prompt 上：怎么写更长，怎么加角色设定，怎么塞 few-shot 示例，怎么让模型“更听话”。那个阶段这么做合理，因为系统简单，模型输出就是产品主体。
但当 Agent 进入生产环境，prompt 很快不够用了。
一个能接入企业系统、调用数据库、修改文档、提交表单、触发工作流的 Agent，不能只靠“请仔细思考”“不要犯错”这类自然语言约束来保证可靠性。它需要明确的状态机、任务队列、失败重试、权限隔离、审计日志、人工审批、回放能力，以及出错后能定位到是哪一步、哪一次调用、哪个上下文导致的问题。
这正是 AI 开发重新撞上软件工程硬约束的地方。
但“换汤不换药”也不完全对：真正的新变量是什么
把 Loop Engineering 简化成“全是老东西”，也不准确。
传统分布式系统里的工作进程，执行的大多是确定性程序逻辑：输入满足条件，输出通常可预期；失败模式也比较清楚，主要集中在网络、服务、资源和数据一致性。
Agent 不一样。它的核心执行单元是概率模型。
同一个任务、同一组工具、相近的上下文，模型可能走出不同的行动路径；可能误读工具返回结果，也可能在上下文变长后逐渐偏离目标；它会把不确定的信息说得很确定，也可能在看似正确的局部推理里，把任务带向错误方向。
传统系统的“错误”往往意味着 bug、异常或宕机。Agent 系统的程序可能完全没有报错，接口也全部调用成功，但整个任务在语义层面已经做错了。
这才是 Agent 工程真正的新难点——而且传统软件工程教材里确实没有。
概念坐标系：循环工程到底“新”在哪里
把上面的讨论整理成一张图，会更清楚：
│
├── 老问题（分布式系统已解决的部分）
│ ├── 状态管理 → 数据库 / 键值存储
│ ├── 任务调度 → 消息队列 / 工作流引擎
│ ├── 失败恢复 → 重试机制 / 幂等性设计
│ ├── 权限隔离 → 中间件 / 拦截器 / 审批节点
│ └── 外部调用风险 → 事务边界 / 补偿机制
│
└── 新问题（执行主体是概率模型带来的）
├── 语义正确性判断（任务“做完”≠“做对”）
├── 模型对工具结果的误读
├── 长上下文下的目标漂移
├── 高置信度表达的错误结论
└── 在错误目标上的“高效重复”
Loop Engineering 这个词的新意，不在于“循环”——因为循环、状态、重试、持久化早就是软件工程的基本语法。它真正的新意，在于循环中的执行主体变成了一个非确定性的语言模型。
这才是当前 AI 工程最值得警惕的地方：行业把全部注意力放在“循环”这个壳子上，却很容易忽略壳子里那个真正的新变量。
为什么这个混乱值得认真对待
有人会说，叫什么名字无所谓，能落地就行。
这个态度在工程实践里同样危险。
如果团队把“循环工程”理解为一门全新的学科，会倾向于从零造轮子，重新发明消息队列、重试机制、幂等设计——而这些正是分布式系统领域已经被验证了二十年的成熟方案。结果往往是花大量时间踩别人早就踩过的坑，却把真正的新问题（语义正确性、模型漂移）留在表面应付。
反过来，如果团队完全否认 Agent 系统的新颠覆性，把它当成普通的异步任务系统来设计，又会低估“执行主体是概率模型”这个变量带来的连锁后果——可靠性工程需要补的不只是熔断器，还需要把传统机制与模型评测、上下文管理、策略约束、工具权限重新耦合起来。
系统不仅要判断“任务有没有执行完”，还要判断“它是不是在正确地执行”；不仅要保证调用没有重复，还要保证模型没有在错误目标上高效地重复。
AI 没有取消软件工程，只是把边界往前推了一步
太阳底下未必没有新鲜事。只是很多所谓的新鲜事，最终都要先学会如何不重复下单、不无限循环、不丢失状态、不越权操作，也不把一次模型幻觉变成一次真实世界的事故。
过去，软件工程师主要在管理确定性的程序；现在，他们还要管理一个会猜、会变、会跑偏、却又越来越能干的概率模型。这个变化确实重要，但不意味着传统工程经验可以被抛弃——恰恰相反，Agent 越深入企业流程，越需要回到那些并不时髦、却经受过长期验证的基本原则上。
