AI Coding 的下一阶段不是 Prompt，而是 Coding Loop
现在很多人讨论 AI 写代码，重点还停留在 Prompt。
怎么写提示词，怎么塞上下文，怎么让模型一次性多写一点，怎么让它少犯错。
这些当然重要，但我越来越觉得：AI Coding 真正进入工程阶段以后，问题不会只停留在“怎么问 AI”。
更关键的问题会变成：
怎么把多个 AI 能力组织成一个稳定、可持续、可复审的开发循环？
这就是我理解的Coding Loop。
我最近做的 LoopMarshal，就是在尝试这个方向。
https://github.com/Rainbow0328/loopMarshal
它不是一个新的 AI IDE，也不是一个多 Agent 聊天室。
它更像一个本地协作中枢：用户先和 Host 对齐目标和架构，Host 再根据当前已有的 AI IDE / CLI / Worker，自动构建一个适合当前目标的 Coding Loop。
为什么不是让一个 AI 从头写到尾？
一个 AI 从头写到尾，简单任务可以，复杂任务很快会遇到几个问题。
第一，所有上下文都堆在一个窗口里。
需求、架构、前端代码、后端代码、测试结果、review 意见、临时错误、日志输出，全塞进同一个上下文。最后模型不是不知道怎么写，而是越来越难分清什么是长期决策，什么只是一次性的临时信息。
第二，不同任务对模型能力的要求并不一样。
有的模型适合写前端，有的模型更适合做后端推理，有的模型适合长上下文分析，有的模型适合便宜快速地做重复检查。把所有任务都交给同一个模型，并不一定划算，也不一定效果最好。
第三，成本结构不一样。
不同模型的计费规则不同。长上下文、复杂推理、高质量 review，可能值得用更强的模型；但一些机械性的实现、格式调整、文档整理、重复检查，用低成本模型就够了。
如果所有任务都丢给一个高成本模型，token 很容易被浪费。
第四，工程职责本来就不同。
真实开发里，架构设计、前端实现、后端实现、测试、review、知识整理，本来就不是同一种工作。让一个 AI 长期扮演所有角色，会让上下文和职责都变得混乱。
所以我认为，AI Coding 不只是需要更强的单个模型，也需要更好的组织方式。
为什么需要多个 AI IDE / CLI 协作？
这里的重点不是“多开几个 AI 显得很酷”。
多 AI IDE / CLI 协作的真正价值，是把不同 AI 能力变成可编排的工程资源。
比如：
前端 Worker 可以常驻在更熟悉 UI 代码的 AI IDE 里。
后端 Worker 可以使用更擅长复杂逻辑和接口设计的模型。
Code Review Worker 可以使用更强但更贵的模型，只在关键节点审查。
Knowledge Keeper 可以使用一个稳定后台 Agent，专门维护项目知识。
Host 可以使用更适合规划、拆解和裁决的模型。
这带来的好处不是“AI 数量变多”，而是职责更清楚：
不同任务可以用不同模型。
不同模型可以承担不同成本等级的工作。
不同上下文可以隔离。
不同 Worker 可以长期保持自己的职责和工作记忆。
Host 可以根据已有 Worker 动态构建 loop，而不是所有事都塞给一个模型。
我把这理解为一种token 分级和能力分级。
重要的架构判断、复杂 review、高风险修改，可以交给更强模型。 普通实现、重复检查、低风险修改，可以交给更便宜的模型。 知识库维护可以交给专门角色持续做。 Host 负责把这些能力组织起来。
为什么不用 subagent？
很多人可能会问：现在一些工具已经有 subagent 了，为什么还需要多个 AI IDE / CLI 协作？
我觉得这里要区分两个东西。
subagent 很适合做一次性的子任务。
比如主 Agent 临时叫一个 subagent 去看某个文件、查一个问题、总结一段代码。这很方便。
但 subagent 通常有几个限制：
它的上下文往往是临时的。
它不一定有稳定身份和长期职责。
它的任务状态不一定被外部系统持久化。
它的工作记忆很容易随着一次调用结束而消失。
多轮任务之间，主 Agent 可能需要重复给它塞背景。
这会带来一个问题：看起来用了子任务，实际上很多上下文还是要重复传。
重复传上下文，就意味着 token 浪费。
而且如果 subagent 的状态没有持久化，那么一次复杂工程循环里的“等待、回报、复审、返工”就很难稳定追踪。
LoopMarshal 想做的不是替代 subagent。
更准确地说，它解决的是另一个层面的问题：
让不同 AI IDE / CLI / Worker 拥有稳定身份、稳定职责、持久化消息、持久化知识库和可持续等待能力。
这和临时 subagent 不一样。
在 LoopMarshal 里，Worker 不是一次性函数调用，而是一个可以持续待命、接收任务、执行、回报、再等待的协作成员。
Host 是什么？
Host 不是“更大的 Agent”。
Host 更像架构师和总负责人。
用户不是直接让多个 AI 开始写代码，而是先和 Host 对齐：
目标是什么
哪些边界不能碰
整体架构怎么定
哪些模块要拆出来
当前有哪些 Worker
哪些任务应该并行
哪些任务必须串行
什么条件下算完成
架构确定后，Host 再根据已有 Worker 构建 Coding Loop。
这点非常重要。
LoopMarshal 的核心不是“多个 AI 自动乱跑”，而是：
用户和 Host 定好架构后，Host 根据已有 Worker 自动组织工程循环。
Knowledge Keeper 是什么？
复杂任务里还有一个很容易被低估的问题：项目知识会丢。
比如：
架构决策
模块边界
接口契约
字段定义
错误码
哪些文件不能改
哪些实现只是临时方案
这些信息如果只留在聊天上下文里，很快就会被冲掉。
所以 LoopMarshal 里有 Knowledge Keeper。
你可以把它理解成项目记忆维护者。
但它是可选的。
正确流程是：
如果会话里有 Knowledge Keeper，Host 会把知识库维护任务交给它。
如果没有 Knowledge Keeper，Host 会 fallback 自己维护知识库。
无论哪种方式，Host 都要复审。
Knowledge Keeper 不替 Host 做架构决策。它只是把 Host 已经确定的架构意图，沉淀成更稳定的知识材料。
这样后续 Worker 执行任务时，不需要每次从头理解整个项目。
上下文隔离为什么重要？
上下文隔离不是为了干净，而是为了省 token、降混乱、提升稳定性。
如果前端 Worker 只关心前端，它不需要每次都带着后端所有实现细节。
如果后端 Worker 只关心接口和数据模型，它不需要长期背着前端组件细节。
如果 Review Worker 只在关键节点介入，它不需要参与每一次实现过程。
如果 Knowledge Keeper 只维护稳定知识，它不需要记录所有临时日志和调试过程。
不同角色拥有不同上下文，Host 再通过知识库和任务消息把它们连接起来。
这样比所有信息堆进一个窗口更可控。
这也是我认为 Coding Loop 有价值的地方：
它不是简单增加 Agent 数量，而是把上下文拆成不同层级。
可以粗略理解成：
Host 持有目标、架构和裁决上下文。
Knowledge Keeper 持有稳定知识上下文。
Worker 持有自己职责范围内的执行上下文。
Review Worker 持有审查上下文。
后端系统持久化消息、任务、成员和知识库。
这比单纯靠一个聊天窗口硬撑长上下文更工程化。
LoopMarshal 怎么跑一个 Coding Loop？
一个典型流程大概是：
1. 用户和 Host 对齐目标与架构 2. Host 查看当前会话有哪些 Worker 3. Host 判断是否需要维护知识库 4. 有 Knowledge Keeper：派它维护知识库 5. 没有 Knowledge Keeper：Host 自己维护知识库 6. Host 复审知识库和任务边界 7. Host 根据 Worker 职责分发任务 8. Worker 等待任务、执行任务、提交回报 9. Host 收到回报后复审 10. 需要 review 就派 Code Review Worker 11. 有问题就返工 12. 没问题就收口
注意，这里不是固定模板。
Host 会根据当前已有 Worker 构建 loop。
如果没有 review worker，就不强行 review。 如果没有 Knowledge Keeper，就 Host 自己维护知识库。 如果只有一个 Worker，loop 也可以退化成单 Worker 执行。 如果有多个专业 Worker，Host 就可以组织并行和串行。
这才是我想要的：不是预设死流程，而是 Host 根据现有能力动态组装 Coding Loop。
MCP 长等待为什么重要？
如果 Worker 不能等待任务，loop 就很难持续。
每一步都要用户手动叫醒 Worker，那还是人在控制流程。
LoopMarshal 通过 MCP 让 Worker 可以进入长等待状态。
Host 派发任务后，Worker 收到任务，执行，再回报。
如果暂时没任务，Worker 可以继续待命。
为了避免 AI IDE / CLI 在长时间等待时超时，LoopMarshal 使用 MCP Progress Notification 做保活。
这让 Worker 更像一个真正的协作成员，而不是一次性命令。
这和 Loop Engineering 的关系
最近很多 Loop Engineering 实践更偏业务 Agent，比如通过 DeepAgents 构建业务循环。
我认为这个方向是对的。
但 AI Coding 也需要自己的 Loop Engineering。
业务 loop 可能更关注：
理解业务目标 -> 调工具 -> 观察结果 -> 再行动
Coding loop 更关注：
定架构 -> 识别 Worker -> 分配任务 -> 等待回报 -> review -> 返工 -> 收口
LoopMarshal 想验证的就是这个方向：
Loop Engineering 不只适合业务 Agent，也可以用于 AI 写代码。只不过在代码场景里，核心角色不是一个万能 Agent，而是 Host 根据已有 Worker 构建 Coding Loop。
我想宣传的不是“多 AI”，而是“可组织的 AI”
如果只说“多个 AI 协作”，其实很容易被误解。
多个 AI 同时工作，不一定更好。
没有架构，没有边界，没有知识库，没有复审，多个 AI 只会更乱。
我真正想做的是：
让 Host 负责架构和裁决。
让 Worker 按职责执行。
让 Knowledge Keeper 维护稳定知识。
让 Review Worker 做独立检查。
让消息、任务、等待、回报、知识库都被持久化。
让不同模型按能力和成本分层使用。
这才是 LoopMarshal 的核心。
一句话说：
LoopMarshal 是一个面向 AI Coding 的 Loop Engineering 工具：用户和 Host 定好架构后，Host 根据已有 Worker 自动构建 Coding Loop，并持续推进实现、复审、返工和收口。
结尾
AI 写代码下一阶段，我认为不会只是 Prompt 更长，也不会只是单个模型更强。
更关键的是：能不能把不同 AI 能力组织成一个真正可运行的工程循环。
这个循环里，有架构，有分工，有等待，有回报，有复审，有记忆，也有成本分层。
这就是我理解的 Coding Loop。
也是我做 LoopMarshal 的原因。
AI Coding 的下一阶段不是 Prompt，而是 Coding Loop。