2026年6月初，在由知名商业播客Acquired联合开发工具平台WorkOS举办的Acquired Unplugged开发者大会上，Claude Code的开发者Boris Cherny说了一句话，随后在技术社区迅速传开："我不再给Claude写提示词了。我写好一个个运行着的循环，让循环去提示Claude并让它自己搞清楚该做什么。我的工作就是写循环。"
这段演讲片段上传到X平台后，不到24小时获得近70万次播放，并在Reddit等技术社区引发大量讨论。"Loop Engineering"（循环工程）由此成为AI开发圈的热词。
从写提示词，到设计循环
Loop Engineering的核心主张并不复杂：与其反复手工调试提示词，不如设计一套让Agent自主迭代的循环系统。这套系统通常包含五个要素：明确的目标、上下文管理、可调用的工具、对产出的评估，以及判断何时停止的标准。五者组合起来，Agent就不再只是"接收指令、输出结果"的单次调用，而能形成自我迭代、自我修正的闭环。
从"人写提示词、Agent执行一次"到"人设计循环、Agent自主迭代多轮"，这一转变在效率上的提升是实质性的，也解释了为什么这个概念能在短时间内引发广泛共鸣。
但目前行业讨论的Loop Engineering，基本停留在单个Agent的层面——一个更聪明的Agent，配上更精巧的循环设计，在自己的沙箱里反复迭代。这解决的是"一个人怎么把活干得更快"的问题。而现实世界的工作往往不是一个Agent能独立闭环的：一个产品需求的落地，需要产品经理定义目标、设计师输出方案、工程师实现代码、测试团队验证质量、运营反馈数据。这不是一个循环，是循环的嵌套与协作。
Octo：把循环工程推向组织层面
这正是明略科技（2718.HK）试图解决的问题。这家被外界称为“Agentic AI第一股”的港股上市企业，目前正在推进一套名为Octo的多Agent协作平台。
从架构设计上看，Octo与Loop Engineering的五个要素之间有不少相似性。编排调度（Orchestration）负责任务拆解与目标分配，对应循环中的"目标"设定；跨Agent的上下文流转（Context）对应上下文管理；开放的工具生态（Open）对应工具接入；而"品鉴"机制（Taste）则同时承担评估和停止条件两个角色——由人来判断产出"够好了"还是"方向偏了"。
据公开资料显示，明略科技目前有1400余名员工与超过2900个AI Agent在日常业务中协同运作。当数千个Agent同时运行，彼此之间需要交换上下文、传递产出、相互触发，单Agent层面的循环设计已经不够用，必须在网络层面解决协作问题。
"品鉴者"：一个被低估的角色
在Loop Engineering的各要素中，"评估"环节在实践中常被简化处理——跑一个测试、算一个分数、对比外部基准。但在组织级协作中，很多判断并不适合完全交给算法：一个营销方案好不好、一个产品决策对不对方向、一个策略该不该调整，这些都需要人的判断介入。
Octo将这个角色称为"品鉴者"。品鉴者不参与Agent的具体执行过程，而是在关键节点做方向性判断：循环在正轨上就放行，偏了就纠偏，达到标准就叫停。明略将其定位为有别于传统"审批人"的角色——审批解决的是合不合规的二元问题，品鉴解决的是好不好、对不对方向的价值判断。
"Human-in-the-loop"（人在循环中）是AI行业喊了很久的概念，但在很多产品里，它要么变成了人工审核的另一种说法，要么演变为对用户的频繁打扰。明略的品鉴者机制是否真正解决了这个问题，还有待更多外部观察，但至少在架构设计上，它试图给这个角色一个更清晰的产品定义。
Scaling Out，而不只是Scaling Up
明略科技创始人吴明辉曾多次公开表达一个判断：Scaling Out（横向扩展）比Scaling Up（纵向增强）更重要。在Loop Engineering的语境下，这个区分有了更具体的含义。
Scaling Up是把单个Agent做得更强、让单个循环跑得更快更准，其上限在于模型本身的能力边界。Scaling Out是让更多Agent进入协作网络、让循环之间能够嵌套联动，挑战的是组织协作的效率上限。明略的逻辑是：当一组Agent能像一个协调良好的团队一样运作，能够处理的问题复杂度就会上一个台阶。
据明略介绍，在其内部协作网络中，Agent A的产出会流入Agent B的上下文，Agent B的迭代结果经品鉴者评估后触发Agent C的新循环，整个网络的产出能力超过各Agent独立运行的简单加总。这一说法目前来自明略自身披露，尚无第三方独立验证。
时间维度：先有实践，后有命名
值得注意的是，当Loop Engineering这个概念在2026年初开始被广泛讨论时，明略的Octo网络据称已经在生产环境中运行了相当一段时间，2900多个Agent每天处理真实业务。
这并不意味着明略"预判"了这个概念——Loop Engineering的命名和传播是社区自发形成的。但这个时间差说明，至少有一些团队已经在实践层面触碰到了单Agent循环无法解决的问题，并摸索出了自己的应对方式，只是彼时还没有一个统一的名字来描述它。
Loop Engineering的三个层次
如果对Loop Engineering做一个简单的分层，大致可以分成三级。第一层是单Agent内部的迭代循环，这是目前社区讨论的主要焦点，也是Boris Cherny那段话所描述的场景。第二层是多Agent之间的协作循环，A的输出是B的输入，B的反馈触发A的修正，这需要上下文管理和任务编排来支撑。第三层是人与Agent网络共同构成的组织级循环，品鉴者在关键节点做判断，整个网络在目标、执行、评估的大循环中持续调整。
目前行业讨论集中在第一层，一些技术团队在探索第二层，而明略科技的Octo或许已经在第三层的生产环境中运行。
Loop Engineering作为一个概念，准确捕捉到了AI工程从"手工调参"到"系统设计"的方向性转变。但从单Agent的循环到组织级的协作网络，中间还有相当长的工程路要走。明略的实践提供了一个值得关注的样本，但其经验能否被更广泛地复制，仍是一个开放的问题。
