关于 Loop Engineering 的实践与反思

[yunshangzhou]

循环工程 这个思想主要是几个知名的大模型团队成员同一时间提出来的

说白话就是，把开发分为 4 个阶段，

1. 发现问题 ->
2. 开辟几个 git worktree 并行解决开发防止同文件代码污染 ->
3. 新开一个 agnent 做功能验证，防止 yes 幻觉 ->
4. 把上下文内容和核心主旨通过 MCP 存到 linear 、notion 上。在下一次的发现问题中，从 MCP 对应的 issues ID / docs ID 回显上下文。

然后再开/loop 以此往复，直到 agent 发现不了新的问题。

这个工程实践真的能落地么？离开人类的监督范畴，很多没考虑到的边界问题，agent 能够帮忙兜底吗？ 国内对应 linear 、notion 的，甚至可以是 github issues/wiki 、feishu CLI 、feishu MCP 以及语雀。尽量靠近团队生态，甚至在敏捷开发的团队里，都不需要把存储上行到这些第三方服务，而是直接在本地开一个 md 文件存储即可。

现在 agent 范式搞不出什么新东西了，本质都是围绕着提示词转悠，重复性地搞出不同的术语来表达同一件事。但这也只是我个人观点，水友们你们怎么看？

[zizon]

自从 ChatGPT 发明了 prompt 用自然语言生成各种东西之后,人类就彻底抛弃 DSL 了.

往好处想想,这叫不做容易的事.

[webcape233]

升级了一圈 还是 prompt

[levn]

真正的下一步应该是世界模型，或者说中介模型。步子有点大。

[YanSeven]

什么 loop 工程，就是个噱头。扯那么多虚头巴脑的玩意儿的，除了 llm 训练能力本身，普通人搞不定。

只要把 llm 的 api 部署上去放出来，说明手册往那边一摆。

所有基于 prompt 和 context 做 llm 应用的各种技巧和噱头概念上的，你往那儿栓条狗，用着用着，这些工程上的技巧性的概念也就自然而然的出来的，那帮人天天搁那咋咋呼呼的，跟神经病一样。

就很自然的开发小技巧，老是要包装成什么石破天惊的定律和理念一样的。

[l84]

看看 openclaw 的 issue 数量就懂了，loop 噱头太重

[hahiru]

自从我用 superpowers 搭配 codex ，我就知道什么叫边界。
原本的小项目经过 AI 的多 agent 循环验证+审阅之后就发现 codex 把一个小项目左右脑互博之后变成了分布式负载多租户项目。
一条命令就能榨干限额。

[Solix]

认真你就输了，这就是美国硅谷那几个老登玩不出新花样提出来的，本质就是提示词，没啥区别

[tars13344]

@YanSeven #4 真的是 什么 skill 什么 mcp 连 openclaw 那种 cron 定时调 API 都能让大家群体高超 有时候怀疑是不是 99.999%的人都没认真看过这个 api

[Azure99]

任务的设计并不只是"玩玩提示词"，像#6 提到的，如果不在任务中定义清楚偏好和边界（比如 日抛脚本/自用小项目/大型原型/线上老屎山），让 Agent 按自己理解发挥，做重了/做简单了，都是很正常的。
功能验证也一样，Agent 静态改代码/跑跑单测和 lint/端到端验证，可靠性完全不一样。所谓 Harness 搭的完善程度，也直接决定了 Agent 能把产出验证到什么程度。假设你让人（ Agent ）来改 css ，但是不给浏览器（ playwright+截图）、只能对着代码瞪眼，不是一样完成不好么？

[Retas]

边界是人类和 AI 一起探索出来的，肯定不是 All in AI 。
AI Agent 的功能和概念迭代快，可以理解为一个工具或者 work flow ，根据项目自己按需使用就行。
从实践中找到了大致的规律，基本能快速上手 AI 领域新出的东西，踩一脚没必要。

[heroisuseless]

并不能成功。

这么 loop 并不能解决核心架构腐坏问题，补丁越来越多，最终结果就是 bug 越来越难解，直到完全解决不了。

估计接下来就是 Mermaid Engineering ，人来把控整个流程图，然后让 AI 来填空。