关于 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]

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