别写Prompt了，现在流行给AI写循环

过去一年多里大部分人用大模型的方式基本没怎么变过写一段prompt发过去拿到回复不满意就改prompt重来满意了就复制结果走人。这个模式在问答、写作辅助、代码片段生成这类一次性任务上够用但一旦任务变复杂需要多步骤执行、需要根据中间结果调整策略、需要验收打回再改单轮prompt的短板就暴露得很明显。prompt写得再长再精细也只是一个静态指令模型执行过程中遇到意外情况没法自己回头修正输出质量全靠人在回路外盯着出错了还是得人手动打断重来。最近几个月行业里开始频繁讨论AI Loop这个概念核心思路说起来不复杂就是把一次性的prompt调用变成一个有状态的循环模型执行一步检查结果根据反馈决定下一步是继续、修正还是结束整个过程由程序控制而不是靠人盯着刷新页面。这个想法本身不新传统软件工程里的控制循环、REPL、甚至编译器的多轮优化pass本质上都是循环结构只不过之前循环里跑的是确定性代码现在循环里跑的是大模型推理不确定性高得多反馈信号的设计也远比传统程序复杂。传统prompt工程的局限在真实生产环境里体现得很具体一个写文档的任务人给了prompt和素材模型第一版输出往往结构有问题或者措辞不对人要指出具体哪里不行模型改一版可能还有问题再改来回三四轮是常态。如果这个流程靠人手动复制粘贴完成每一轮人都要读全文找问题写反馈效率极低而且反馈质量不稳定。更麻烦的是多步骤任务比如让Agent去操作GUI完成一个跨多个应用的工作流中间某一步点错了按钮或者页面加载出了异常单轮prompt没有能力感知错误并回退只能整轮重来。Loop模式要解决的就是这层问题把执行-检查-反馈-修正这个回路本身程序化模型在一个受控的循环里反复运行直到产出满足验收标准或者达到预设的迭代上限。这里面有几个工程上的关键设计。第一是状态管理每一轮迭代的输入输出、中间决策、错误信息都需要被记录下来后续迭代可以参考完整的执行历史而不是只看原始prompt这跟编译器需要AST和符号表是一个道理没有状态的循环只是重复调用。第二是反馈信号的设计反馈不能只是好/不好这种二元判断需要具体到哪里不好、期望改成什么样最好是结构化的模型在下一轮能直接消费而不是再去理解一段自然语言吐槽。第三是终止条件循环不能无限跑下去需要明确的验收标准和步数上限否则模型在错误方向上死循环是迟早的事。第四是经验沉淀多轮验收打回产生的反馈数据如果只是用完就扔太浪费了把这些反馈提炼成可复用的偏好或规则下次类似任务直接作为上下文注入模型从一开始就少走弯路。这几个点说起来容易做起来难状态管理涉及到上下文窗口的限制执行历史太长了塞不进模型窗口需要做摘要或选择性保留。反馈信号的质量取决于验收环节的设计自动验收需要一个可靠的evaluator要么用另一个模型做评判要么用程序化的断言检查特定条件但模型评判本身有不稳定性程序化断言又覆盖不了语义层面的质量判断。终止条件设得太松浪费token设得太紧可能还没收敛就被截断了。经验沉淀更难反馈数据是噪声很大的自然语言怎么提炼成结构化的、可检索的、真正有用的经验条目而不是一堆互相矛盾的批注这本身就是一个需要单独解决的问题。我们在做Octo的时候把这套Loop模式作为产品的核心抽象任务单元直接就叫回路Loop从对话中自然创建不需要先填表单指定一个智能体作为负责人后就进入执行循环。智能体接到任务开始干活产出物挂在回路上发起人审核通过就关单不通过就打回带具体批注打回的批注被系统记录为Preference经验条目智能体在下一轮迭代时自动参考这些经验修正产出。整个执行-验收-打回-修正的循环由平台管理不需要人手动复制粘贴或反复开新对话。Preference经验系统是Octo跟普通任务管理工具差异比较大的部分每次打回不是简单地在评论区留一句话就完事系统会把反馈提炼成可复用的经验条目挂在对应智能体的经验库上下次这个智能体执行类似任务时在推理阶段就自动检索相关历史经验作为上下文注入。如果一个写文档的智能体反复收到段首不要放总结句避免总分结构这类反馈几次之后它在生成时就会自动避开这些写法不需要人每次重复提。团队的偏好和做事标准用这种方式沉淀下来不会因为人员变动或者模型升级丢失新加入的智能体挂载经验库之后直接继承团队积累的偏好。在多智能体协作场景下Loop模式的价值更明显单个智能体在一个循环里执行任务已经能解决不少问题但复杂业务流程往往需要多个智能体分工配合有的写代码有的审文档有的做测试这时候编排层控制的不只是单个循环的迭代还有多个循环之间的依赖和流转。Octo内置了六种协作模式Solo是单智能体单循环Roundtable是多智能体在共享上下文里讨论收敛Critic把执行和审核拆成两个独立循环互相看不见对方身份Pipeline按顺序串联多个循环做阶段流转Split把任务拆成多个并行循环最后合并Swarm启动多个并行循环解同一题选最优解。这些模式本质上都是在Loop这个基本单元之上做编排跟并发编程里future/promise和各种并发模式的关系类似基本单元确定之后上层编排才有意义。执行层基础设施目前在Octo里已经上线的包括回路工作台的列表和看板视图、子任务树、迭代记录、评审打回状态流转、计划图可视化项目分组功能可以把相关回路归堆管理挂常驻成员和智能体自动化流水线支持定时和事件触发两种模式跑固定流程跨回路搜索可用。智能体管理模块包括指令配置、技能挂载、运行时绑定和统计在V1开发中运行时注册与健康检查也在开发第一版支持自带机器智能体跑在自己的CLI daemon上平台做注册监控和任务分发工作区组队功能允许从通讯录拉人拉智能体组建团队。技能市场和A2A智能路由在规划阶段等执行闭环稳定后推进。端侧覆盖上Web和桌面端提供完整工作台移动端处理通知和快速验收浏览器插件可以在任意网页旁呼出自动带入上下文CLI是智能体原生接口通过命令行收发任务IM端保持群聊界面一句就能创建回路。从Prompt工程到Loop工程的转变本质上是把AI从一个问答工具变成一个可以被编排的执行单元。Prompt是一次函数调用Loop是一个带状态的控制循环有检查点有回滚有反馈有终止条件。这个方向上的工程实践还在很早期反馈信号怎么设计得更可靠、经验怎么提炼得更准确、多循环编排怎么做才不会在复杂场景下失控这些问题都还没有标准答案但趋势已经很清楚了生产环境里跑的Agent系统早晚都会走到Loop架构上单轮prompt再怎么优化也撑不起真正的自动化。Octo的回路工作台、项目分组、自动化流水线都已经可用智能体管理和运行时注册本月内陆续开放代码在GitHub上。https://github.com/Mininglamp-OSS/octo-web