Loop 的工程讨论够多了，Loop 理念的产品应该长什么样？

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 workflow，把一次复杂任务做得更闭环。 最简单的模式是，一个 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 workflow 把单次任务做闭环，外面则用目标、状态、触发和记忆，让它在一次次人类反馈和环境反馈里变得更懂这个项目。

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

文章来自于微信公众号 “Founder Park”，作者 “Founder Park”