Loop Engineering 在人工智能圈已持续引发关注近一个月，但大多数讨论仍聚焦于工程细节：如何构建循环、如何压缩长上下文、如何完成验证。一个更具宏观视野、也更值得深入思考的问题却鲜有人提及：当 Loop 真正进入成熟运行阶段后，人与项目之间的关系将发生怎样的演变？

前阶跃 Agent 产品负责人钟十六近日发表的一篇文章，尝试从产品视角给出解答。他描绘了 Loop 成熟后的未来图景：Agent 将成为自主运转的项目中心，人类只需在关键时刻做出决策。在他看来，Loop 的核心价值不在于重复执行任务，而在于它会带着你的每一次判断持续成长，在一次次迭代中逐渐演变为更懂你的系统，最终沉淀为可以长期运转的资产。

基于这一理念，钟十六开发了一款开源 Codex 插件项目：Dittos Loop For Codex。目前为第一版，附上地址供大家体验感受：https://github.com/502399493zjw-lgtm/dittosloop-for-codex

文章授权转载自「016 数据」。

作者介绍：钟十六，前阶跃 Agent 产品负责人，曾主导阶跃 AI 桌面伙伴的研发。Founder Park 在年初曾与他进行过一次深度对话，分享了他对基模公司打造 Agent 产品背后的思考逻辑与实践探索。

01

Agent 越深入，

人越能放手

用一句话来概括，就是——项目中心，将从人转变为 Agent 系统。

我先解释清楚这句话的含义，因为它代表了我过去半年来的认知转变。

目前我们与 Agent 的合作方式，仍然依赖人类在其中不断协调：我发出指令，它执行；我检查结果，我再发出指令。我就像这台机器的发动机，一旦我停下来，整个流程就随即停滞。

但随着 Agent 能够独立完成的任务单元越来越长，我越来越清晰地意识到：应该将"项目中心"的位置，从人转移到 Agent。

一个系统能够自主运转，遇到不确定的情况时，回头向我请求一个判断，我给出方向，它继续执行。发动机不再是我，而是这个 Agent 系统。

更重要的是，它不会执行完就遗忘。我给出的每一个判断，它都会吸收、记忆，并在下一次自主应用——它会随着我的引导，逐步变得更加了解这个项目。

就像带一个刚入职的新员工，他越熟练，你越能放手，到后来很多事务他自己就能完成闭环。

因此大家所讨论的 Loop，并非仅仅是一个工作流或定时任务，其核心价值体现在两个层面：

第一层在内部：它能够利用多 Agent 工作流，将一次复杂任务完成得更具闭环性。 最简单的模式是：一个 Agent 负责执行，另一个负责验证，将"做了"转变为"做到、验过、能交付"。

第二层在外部：它具备目标、状态、触发和记忆功能。 它清楚自己为什么要做、当前进展到哪一步、何时需要返回、哪些反馈需要记住、哪些人类判断可以转化为默认规则。

普通的定时任务只是到点重复执行，而 Loop 会带着人和环境的反馈，在一轮轮迭代中不断变强，也越来越贴合用户的偏好。

02

一个设想：

Agent 运行半小时，

人仅需三次决策

光讲理论还是太抽象，我举一个具体的应用场景。

Codex插件参考视频

设想一个人，经营着定制刻字项链的小生意。他拥有自己的下单网站，同时在多个 Discord 用户群里聚集了大量买家。

某个清晨，群里的消息开始不断涌现。第一条附带一张报错截图：「付款一直转圈，钱扣了，订单却没生成。」九点五十一分，阿 May 又跟了一条：「刻字预览整页空白，什么都看不到，换了 Safari 和 Chrome 都一样。」

紧接着桃子说「想下单前先看到刻字效果再决定」，半夏也「+1」。到第十条消息时，群里已经乱成一团。

这是每个管理事务的人都熟悉的处境：信号每天都在冒，却没有一个地方能把这些信息整合成"接下来该做什么"。你能做的，往往就是自己一条条爬楼、一条条回复、再一条条记下来回头处理。

那天下午两点，店主没有打开任何后台，也没有填写任何表单。他只是像跟一个同事交代工作那样，给 DittosLoop 发了一段话：

帮我盯着群里的问题反馈，做适当的回复和记录。记录的问题给我分类——哪些是你能直接修了提 PR 的，哪些需要我二次确认和再开发的。回复也分一下：哪些等我拍板，哪些你自己就能回。

Agent 思考了三分多钟，没有急于动手，而是先回复了他一份计划——它打算怎么做。

如何分类、如何校验、整个流程如何推进，都写得清清楚楚，最后还说明，这件事它会拆解执行，派出多个分身各自负责一段。

一个专门负责扫群归类，一个验证疑似 Bug，一个负责修改网站代码，一个起草回复。"你看一眼，没问题我就开始。"

他回了三个字："可以的。"

在接下来的半个多小时里，这件事自己一轮一轮向前推进：

• 先是扫群的分身把最近十条消息全部扫描了一遍，完成分类：两条疑似 Bug、三条功能请求、四条咨询、一条闲聊。
• 接着其他几个分身依次跟进：验证 Bug 的去复现报错，改代码的去修改网站，起草回复的把咨询一条条准备好草稿。
• 中间刻字预览那个 Bug，第一版没有修干净、Safari 上仍然显示空白——但它没有把半成品提交上来：改代码的分身说"修好了"不算数，必须另一个分身验证通过才放行；

这就是 loop 与普通 Agent 任务的第一个本质区别：它不是一个 Agent 从头干到尾，然后把结果丢回来让人检查；

它把一件事拆解成多个角色，让执行、验证、反驳和修正彼此咬合。复杂任务之所以能够形成闭环，靠的不是"多跑几遍"，而是每一轮都包含检查和回路。

三十二分钟后，一份完整的汇报回到了群里：

• 能直接修的，它都修了，提了 PR 等他合并：结账页付款卡死（测试 14/14 通过）、刻字预览空白（补充了 Safari 的兜底方案，测试 9/9）、尺寸表错位（附了改动前后的截图）。
• 需要再开发的，它整理成了立项方案，等他拍板是否要做：字体实时预览（两位客人在催，还关联到本周另外三条反馈）、礼物包装（一个人提，它建议先确认供应商）。
• 十四条该回复的消息，它自己回复了九条；剩下五条涉及退款、加急、折扣，它没有擅自做主，整理成一张表等店主定调——其中一条它拟的是九折，还特意在旁边标注了"超出现行价格政策"。

店主看完，回了一段话：

501、502 合并；503 我晚点自己看。字体预览立项，礼物包装先放着。回复按你拟的发；不过那条九折的，可以给到 85 折。

它逐条照办，逐条回执：PR 合并了，立项进了需求池，回复发了出去，那条折扣改成了 85 折。"这一单的事，清完了。"

回看这半小时会发现：真正需要这个人出现的时刻，只有那么几个——确认要不要合并、要不要立项、那条折扣给到几折。

其余所有的爬楼、分类、复现、改代码、跑测试、发回复，都不需要他在场。他不再是那个一条条处理的人，他成了在关键路口被请来拍板的那个人。

03

Loop 会记住你的判断，

定时任务不会

那天的事处理完毕，店主又补了一句：

把这套盯群的活留着。以后每 30 分钟跑一次，或者群里攒满 30 条新反馈就触发；碰上丢钱、影响下单这类紧急情况，别等，直接进群找我。

同一个 loop，从此开始自主运行。他没创建任何新东西，只是让它别走了——信号攒够了，它就启动，无需人再去发起。一件原本要他天天爬楼的活，从此常驻在那儿，自己盯着。

但它真正特别的地方，仍然不是"会重复跑"。

你可能会想，这不就是个定时任务吗？

差别不在时间，而在于它外面那层东西：目标、状态、触发、记忆、反馈。定时任务只是到点执行一次；

Live Loop 清楚自己负责什么、上次处理到哪、哪些事已经问过人、哪些判断可以沉淀下来、什么情况必须再把人叫回来。

它会从环境里学习，也会从人那里学习。

头一回有客人在群里询问一笔 20 件批量购买的折扣，它拿不准，把这条整理出来问店主；

他说"给到 85 折"。过了几天又有人问，它还是先来确认，他还是那句"85 折"。第三次，又是同样的判断。

到了第四回，它没有直接自作主张，而是在简报里多问了一句：

过去三次，20 件左右的批量购买你都给到了 85 折。要不要将"这类批量购买默认给到 85 折"设为这个 loop 里的规则？以后我可以直接按这个处理，并在简报里标出来。

店主回了"可以"。从那以后，它才开始自动照这个规则处理。再遇到类似情况，它会自己回复，回完在简报里附一句："这类我按已确认规则处理了。"

一件店主来回拍过几次的标准，从此被记住了。他没有提前配置一堆复杂规则，只是照常做了几次判断；

系统观察到这些判断，提出一个规则候选，让他确认，然后将其沉淀为往后能用的上下文。

它学习每一条规矩，都应该是这样：同一种判断重复出现，它先意识到这里可能存在规律，再让人确认这是否成为规则。

什么算"丢钱的急事"、价格的红线在哪、哪类咨询可以放心直接回……这些都不是你一开始填进表单的，是你一次次拍板，它在旁边一点点看会的。

而每学会一条，它就更像你一点，也更少需要你一点。

这就回到我前面说的那个新员工——一周前还什么都得问你，一周后，大半的事他自己就闭环了。

一个 loop 的价值，不仅在于它第一次跑得多漂亮，还在于你让它常驻下来后，它会带着你的判断，在一轮轮迭代中长成一个越来越靠得住的"自己人"。

04

一群 Loop 共享同一套经验，

撑起整个项目

但一个 Loop，只能盯好一块事务。一个真正在运转的项目，是由很多模块组成的。

一条 loop 把"用户反馈"这一摊管好；可一个真正在运转的项目，背后是一群这样的 loop，各盯一摊、连成一套自主运转的系统。

于是店主开始往这个项目里，一条条地添加新的。

先是那天晚上——他被一条漏看的物流投诉弄得有点窝火，客人下单五天没发货，闹到群里他才知道。

他没去找谁，只在对话框里敲了句："以后帮我盯着物流，超过三天没发的，挑出来给我。"于是这个项目里，又多了一条专盯物流的 loop。

再往后，加进来的越来越多样：

一条盯着小红书和抖音评论区、顺手把写得好的好评挑出来、还能到点替他把上新预告发出去的 loop；

一条守着网站、一旦报错或者下单流程哪步挂了就第一时间报警的 loop；

一条每周替他把最集中的几个抱怨汇总成一页的 loop……

他从没"配置"过什么，只是想起一件就说一句，这个项目里就多一条自己跑的 loop。

慢慢地，这家店的客服、运营、监控、周报，背后各有一条 loop 在盯。Live Loop 里这个项目越来越长，像他一个人，悄悄带起了一支不用盯着的队伍。

更关键的是，这些 loop 不是分散的。它们共享同一个项目里的判断、规则、状态和历史：

客服 loop 学到的高频问题，会影响周报 loop；

网站监控 loop 发现的下单故障，会进入反馈 loop 的回复口径；

物流 loop 反复捞出来的延期，会变成客服 loop 安抚用户时要主动说明的背景。

一个项目的经验开始在这些 loop 之间流动。

到这时候，他和这家店的关系，已经彻底变了：他不再是那个什么都得亲手干的人，而是站在一支队伍上方的人。

大事他定，剩下的，交给这支队伍运行。项目的中心，真的从他，转移到了这群 Loop 身上。

我觉得这才是整件事里最动人的地方。他从头到尾都以为自己在"用 AI 干点活"，可回过神来才发现，他其实是在为一个自己真正在意的项目，一点一点养出了一整套会自主运转、还会不断进化的系统

他的判断没有一次是白费的，全部沉淀了下来，长成一个往后能一直替他干、也能原样交给别人接着用的东西。

我后来才意识到这背后的逻辑：它替你干的那些活，做完就做完了；真正留下来、还会利滚利地变厚的，是它跟着你一次次判断攒出来的那套经验。

这也正是微软 CEO 纳德拉最近反复在讲的——人和 AI 之间这种会产生复利的学习，才是最关键的。

我们总担心 AI 会让人的经验越来越不值钱。可我在这件事里看到的，恰恰相反——它第一次让一个普通人琢磨出来的那点门道，能被真正地记住、攒起来、传下去。

不止于此，在未来，你甚至可以把当前正在运转的项目文件库、想要开始做的大目标，直接丢给它。

它能基于更强的模型能力，帮你自动构建这套 Project OS，带着你往前走。

05

AGI 可能就是你身边

一群自主运行的任务系统

当看到这些时，我心中的 AGI 变得更清晰了。

它未必首先以一个无所不知的超级大脑出现。它可能更像你身边站着一批自主运转的任务系统，围绕不同的项目，各管一摊事——你可以有电商的项目、投资研究的项目，也可以有健身的项目、家庭管理的项目。

它们自己醒来、自己干活、自己纠错、自己积累，只在需要你来判断的那一刻，才回头请求你。

而人，终于从那个停不下来的中心里走出来，站到这些系统的上方，做那个只在关键路口出现的决策者。

行业现在埋头讨论的"怎么写好一个循环"，是这一切的地基。而地基之上真正立起来的东西是：

AGI 可能以"无数个自主运转、围绕目标持续进化的任务系统"的形态，悄无声息地、一件事一件事地，渗进每个人的日常工作里。

这一天，我觉得没那么远。

06

让 Loop 变得

普通人友好

所以回到 Dittos Loop，我现在做的事，其实是围绕 Loop 这个中心，重新设计一套让普通人更容易理解、创建、运行 Loop 的方式。

很多产品会把能力拆成一堆命令：goal、workflow、schedule、trigger、memory。它们在工程上都对，但放到用户面前，就变成了新的负担。

用户真正想说的，往往只是："这件事你帮我做到好"、"以后这类事你帮我看着"、"别每次都让我重新交代"。

当前，你只需要在 Codex 上，安装这个插件，就可以在原有的工作习惯下，实现更无感的 Project OS。

围绕这个中心，我们当前做了两层设计。

第一层叫 loopable：Agent 要能自己看出来，一件事是不是适合变成 Loop。

比如它发现用户在反复做同一种判断、在等一个条件发生、在盯一批反馈，或者在处理一种以后还会不断出现的工作，它就应该自然地问一句："这件事要不要我以后持续帮你盯着？"

第二层是把用户的一句话，编译成一个真正能跑的 Loop。

它知道目标是什么、每轮做什么、怎么验证、什么时候问人、什么该记住、什么时候停。

里面可以用多 Agent 工作流把单次任务做闭环，外面则用目标、状态、触发和记忆，让它在一次次人类反馈和环境反馈里变得更懂这个项目。

所以我们最终想做的，不止是一个个 Loop，还是一个普通人将大目标和项目给出来，就可以自动构建出的 Project OS。