1. 多智能体协作架构到底在解决什么问题第一次接触“Loop Engineering”这个词很多人会以为是某种循环语句的工程化封装或者跟事件循环、消息循环沾边。实际上它描述的是一套让多个智能体在同一个任务闭环里反复协作、互相校验、逐步收敛的架构方法论。核心不在“循环”本身而在于把一次性的任务执行改造成一个可迭代、可观测、可回滚的协作回路。我最早接触多智能体协作是在做自动化内容生产流水线的时候。单个智能体写出来的东西质量波动极大同一个提示词跑十次能出十种水平。后来把任务拆成“规划—执行—评审—修正”四个角色让它们在一个回路里互相拉扯输出质量才稳定下来。这就是 Loop Engineering 最朴素的样子不是让一个智能体变强而是让一组智能体在循环中互相补位。它适合谁如果你正在做以下任何一件事这套东西就跟你有关用多个模型或同一模型的多角色完成复杂任务代码生成、报告撰写、数据分析需要任务结果有自检和修正能力而不是“一次成型听天由命”想把智能体协作从“演示 demo”推进到“工程可用”团队里已经有人在喊“多智能体”但实际跑起来就是几个 prompt 串在一起这篇文章我会按真实项目落地的顺序来讲先拆架构设计的取舍逻辑再讲每个核心环节的实现细节然后是完整实操流程和参数选择最后把我踩过的坑和排查方法整理出来。全程按“能直接抄作业”的标准写不搞概念堆砌。2. 协作架构的整体设计与选型逻辑2.1 为什么是“回路”而不是“流水线”最常见的多智能体实现是流水线A 做完交给 BB 做完交给 C结束。这种结构实现简单但有个致命问题——错误会沿着流水线一路传递且没有任何环节负责回头。A 输出里有个事实错误B 基于它继续加工C 再润色一遍最后交付的东西错得很精致。Loop Engineering 的核心改动是引入回边。评审环节发现问题的不是打个分就完事而是把问题结构化地退回给执行环节执行环节带着反馈重新生成再进入评审。这个回路可以跑固定轮数也可以跑到评审通过为止。我用一个实际对比说明差异。做代码生成任务时结构首次通过率平均修正轮数最终可用率单智能体直出约 40%040%流水线生成→格式化→输出约 45%045%回路生成→评审→修正约 40%1.882%回路多角色评审约 38%2.191%数据是我自己项目里统计的样本量几百次任务不追求绝对精确但趋势很清楚回路结构牺牲了首次通过率因为评审会挑刺换来了最终可用率的大幅提升。这就是选它的理由。2.2 角色划分的三种主流方案角色怎么分直接决定架构复杂度。我试过三种各有适用场景。方案一三角色最小回路规划者、执行者、评审者这是我最推荐的起步方案。规划者负责把模糊需求拆成可执行步骤执行者按步骤产出评审者对照原始需求检查产出。三个角色可以用同一个模型加不同系统提示词实现成本低调试直观。方案二五角色扩展回路增加协调者和记忆管理者当任务步骤超过 10 步、需要跨轮次记住上下文时加一个协调者负责调度加一个记忆管理者负责压缩和检索历史信息。这个方案适合长周期任务但调试难度明显上升角色之间的通信开销也大。方案三动态角色按任务类型临时生成角色让一个元智能体根据任务描述动态决定需要哪些角色。灵活但不可控我只在探索性任务里用过生产环境不敢上。提示新手直接上五角色大概率会陷入“角色之间互相甩锅”的困境。先用三角色跑通一个完整回路再按需扩展。2.3 通信机制共享状态还是消息传递角色之间怎么交换信息是架构里第二个关键决策。共享状态是指所有角色读写同一个结构化对象比如一个 JSON每个角色只修改自己负责的字段。优点是实现简单、状态可追溯缺点是并发写容易冲突且角色容易“越界”改别人的字段。消息传递是指角色之间通过显式的消息队列通信每条消息有发送者、接收者、类型和载荷。优点是解耦彻底、可审计缺点是需要设计消息协议前期投入大。我的实际选择是混合模式主状态用共享对象关键决策用消息传递留痕。具体来说任务状态、当前轮次、评审结果这些放共享对象评审意见、修正指令这些走消息方便回溯“谁在什么时候说了什么”。# 共享状态的最小结构示例 task_state { task_id: t-001, round: 0, max_rounds: 5, plan: None, artifact: None, review: {passed: False, issues: []}, history: [] # 每轮的消息摘要 }这个结构看着简单但每个字段都有讲究。round和max_rounds是回路的刹车防止无限循环review.issues必须是结构化的列表而不是一段文字否则执行者没法精准修正history只存摘要不存全文控制上下文长度。3. 核心环节的实现细节与实操要点3.1 规划环节把模糊需求变成可执行步骤规划者的输出质量决定了整个回路的天花板。我见过太多项目在这里偷懒直接让规划者“列个步骤”结果执行者拿到一堆没法落地的空话。好的规划输出应该满足三个条件步骤可独立执行、步骤之间有明确依赖、每步有可验证的完成标准。我通常要求规划者输出这样的结构{ steps: [ { id: 1, action: 提取需求中的核心功能点, depends_on: [], done_criteria: 列出不少于3个功能点每个有明确输入输出 }, { id: 2, action: 为每个功能点设计接口, depends_on: [1], done_criteria: 每个接口有参数列表和返回结构 } ] }done_criteria这个字段是精髓。没有它评审者只能凭感觉判断“做完了没”有了它评审可以逐条对照把主观判断变成客观检查。实操心得规划者的系统提示词里一定要加一句“如果需求信息不足以规划先输出需要澄清的问题不要臆测”。我吃过亏规划者自作主张补全需求结果整个回路都在为一个错误假设服务。3.2 执行环节带着反馈重新生成执行者最容易被低估。很多人以为执行就是“把步骤翻译成结果”实际上执行者要处理的是带约束的生成——既要完成当前步骤又要吸收上一轮的评审意见还不能破坏已经通过的部分。我的做法是给执行者三段式输入原始需求、当前步骤定义、上一轮评审意见如果有。评审意见必须转成“问题—位置—建议”的结构而不是一段自然语言吐槽。def build_executor_prompt(requirement, step, last_review): prompt f原始需求{requirement}\n prompt f当前步骤{step[action]}\n prompt f完成标准{step[done_criteria]}\n if last_review and not last_review[passed]: prompt 上一轮评审发现以下问题请针对性修正\n for issue in last_review[issues]: prompt f- 位置{issue[location]}问题{issue[problem]}建议{issue[suggestion]}\n return prompt这里有个细节只把未通过的问题传给执行者已通过的部分不要重复提。否则执行者会过度修正把本来对的地方改坏。我早期没注意这点导致回路震荡——这轮改好 A 弄坏 B下轮改好 B 又弄坏 A。3.3 评审环节从“打分”升级为“定位”评审者是整个回路的守门人。最差的评审是“给个分数”好一点的评审是“列出问题”最好的评审是“定位问题并给出可执行的修正方向”。我要求评审者输出固定结构字段含义示例passed是否通过falsescore0-100 分72issues问题列表见下issues[].location问题位置第2步的接口定义issues[].problem问题描述缺少错误返回结构issues[].suggestion修正建议补充 error 字段及错误码location字段是关键。没有它执行者要自己猜“你说的问题在哪”猜错就白跑一轮。有了它修正可以精准打击。注意评审者的标准要跟规划者的done_criteria对齐。我见过评审者用自己的一套标准挑刺结果执行者按评审改完规划者那关又过不了来回扯皮。解决办法是评审提示词里明确写“以每步的 done_criteria 为唯一通过标准”。3.4 回路控制什么时候停什么时候退回路不能无限跑。我设三道刹车最大轮数一般设 3-5 轮。超过 5 轮还没通过说明任务定义或角色能力有问题继续跑是浪费。分数阈值评审分数连续两轮不升反降立即停止标记为“需要人工介入”。震荡检测如果同一组问题在相邻两轮反复出现说明执行者改不动停止并输出诊断信息。def should_stop(state): if state[round] state[max_rounds]: return True, 达到最大轮数 scores [h[score] for h in state[history] if score in h] if len(scores) 2 and scores[-1] scores[-2]: return True, 分数下降疑似震荡 return False, 震荡检测这个逻辑是我被坑了好几次之后加的。有一次回路跑了 8 轮每轮评审都说“接口定义不完整”执行者每轮都改但改的地方都不是评审真正在意的纯属无效循环。加了震荡检测后这种情况会在第 2 轮就被拦下来。4. 完整实操流程与关键参数选择4.1 从零搭一个三角色回路下面是我实际项目里的搭建顺序按这个走能少走弯路。第一步定义任务状态结构。先把task_state定下来所有角色都围绕它工作。字段宁少勿多后面按需加。第二步写三个角色的系统提示词。每个提示词只干一件事不要试图让一个提示词兼顾多个角色。规划者提示词的核心是“拆解可验证”执行者核心是“按步骤吸收反馈”评审者核心是“对照标准定位问题”。第三步实现回路主循环。伪代码逻辑如下def run_loop(requirement, max_rounds5): state init_state(requirement, max_rounds) state[plan] planner(requirement) while True: state[artifact] executor(requirement, state[plan], state[review]) state[review] reviewer(requirement, state[plan], state[artifact]) state[round] 1 state[history].append(summarize(state)) stop, reason should_stop(state) if state[review][passed] or stop: state[stop_reason] reason break return state第四步加日志和可观测性。每轮把输入输出完整落盘包括提示词、模型返回、耗时、token 消耗。没有这些出问题只能靠猜。第五步小样本调优。先拿 10 个任务跑看通过率和轮数分布再决定要不要调提示词或加角色。4.2 参数选择轮数、温度、模型搭配这几个参数我调了很久直接给结论。最大轮数3-5 轮是甜点区。设 2 轮太紧很多任务需要两轮修正设 8 轮以上边际收益极低还容易震荡。我现在的默认值是 4。温度设置规划者和评审者用低温度0.1-0.3保证输出稳定执行者可以用稍高温度0.5-0.7保留一定创造性。但如果是代码生成这类严谨任务执行者也压到 0.2。模型搭配不一定要用同一个模型。我的常用搭配是规划者和评审者用推理能力强的模型执行者用生成速度快、成本低的模型。这样整体成本能降三到四成质量损失很小。角色温度模型倾向理由规划者0.2强推理拆解质量决定上限执行者0.5快且便宜要跑多轮成本敏感评审者0.1强推理判断要稳定一致4.3 上下文管理别让历史撑爆窗口回路跑起来后历史信息会快速累积。第 4 轮的时候如果把前 3 轮的完整内容都塞进提示词token 消耗会爆炸而且模型注意力会被稀释。我的做法是分层压缩当前轮完整保留上一轮保留评审意见和修正点更早的轮次只保留一行摘要“第1轮接口定义不完整已修正”。这样上下文长度基本恒定不会随轮数增长。def build_context(state, current_round): ctx [] for h in state[history]: if h[round] current_round - 1: ctx.append(f上一轮评审{h[review_summary]}) elif h[round] current_round - 1: ctx.append(f第{h[round]}轮摘要{h[one_line]}) return \n.join(ctx)这个压缩策略实测下来4 轮任务的总 token 消耗比全量保留低 60% 以上质量没有可感知的下降。5. 常见问题与排查技巧实录5.1 回路震荡改了又好像没改现象评审每轮都提类似的问题执行者每轮都改但问题依旧。排查思路先看评审意见是否具体到位置。如果评审只说“质量不高”执行者根本不知道改哪。再看执行者是否真的理解了意见有时候是提示词里反馈信息被淹没在长上下文里。解决把评审意见单独成段加粗标注限制每轮只修最多 3 个问题避免执行者顾此失彼如果连续两轮同一问题直接停止并输出诊断。5.2 评审放水什么都通过现象评审通过率异常高但人工检查发现明显问题。排查思路检查评审提示词是否给了“通过”的默认倾向。很多提示词写“如果基本满足就通过”模型会倾向于放水。解决改成“必须逐条对照 done_criteria任何一条不满足即不通过”给评审者加一个“找出至少一个可改进点”的强制要求哪怕通过也要提改进建议。5.3 执行者过度修正现象这轮改好了 A下轮把 A 又改坏了。排查思路看是否把已通过的部分也传给了执行者。执行者看到“已通过”的内容有时会手痒去动。解决只传未通过的问题在提示词里明确“已通过部分不要改动”。5.4 常见问题速查表问题可能原因快速处理回路不收敛任务定义模糊让规划者先输出澄清问题评审标准漂移评审提示词未对齐 done_criteria统一以 done_criteria 为准token 消耗过高历史全量保留启用分层压缩角色互相甩锅职责边界不清每个角色只改自己负责的字段首轮通过率低评审过严检查 done_criteria 是否合理执行者输出格式乱缺少输出结构约束提示词里给 JSON schema5.5 几个我踩过的坑坑一角色用同一个提示词模板。我一开始图省事三个角色共用一个模板只改角色名结果规划者开始执行、执行者开始评审乱成一锅粥。每个角色的提示词必须独立写职责描述要具体到“你只做 X不做 Y”。坑二忽略失败案例的归档。回路跑失败的任务比成功的更有价值。我后来专门建了一个失败案例库每次震荡或超轮数都归档定期复盘提示词优化全靠它。坑三过早追求多模型。一开始就想用不同厂商的模型搭配结果接口适配、格式差异、超时处理耗掉大半精力。先用同一个模型把回路跑通再考虑模型搭配降本。坑四没有人工兜底。回路不是万能的有些任务就是需要人。我在流程里加了一个“人工介入”出口当回路停止且未通过时自动生成一份诊断报告推给人而不是硬跑。6. 从能跑到好用几个进阶优化方向回路跑通之后想让它真正好用还有几件事值得做。评审者分级。我后来把评审拆成两级一级评审做快速筛查只判断“有没有明显硬伤”二级评审做深度检查对照 done_criteria 逐条过。一级不通过直接退回不浪费二级评审的算力。这样整体成本降了约三成。执行者缓存。相同步骤定义加相同反馈执行者的输出可以缓存复用。在批量任务场景下命中率能到 20% 左右省下的调用很可观。回路指标监控。我盯三个指标首轮通过率、平均修正轮数、震荡率。首轮通过率突然下降通常是任务类型变了或提示词被改坏了平均轮数上升可能是评审变严了震荡率上升说明执行者能力跟不上了。这三个指标比任何日志都直观。任务类型路由。不是所有任务都值得跑回路。简单任务格式化、翻译单次调用就够跑回路纯属浪费。我加了一个前置判断根据任务复杂度决定走单次还是走回路整体效率提升明显。这套东西我从最初的三角色回路迭代到现在带分级评审和任务路由的版本前后改了十几版。核心体会就一句多智能体协作的难点从来不在“多”而在“协作”——让每个角色清楚自己该干什么、不该干什么让回路有明确的收敛条件和退出机制比堆角色数量重要得多。 多智能体协作架构实战：Loop Engineering回路设计与工程落地
1. 多智能体协作架构到底在解决什么问题第一次接触“Loop Engineering”这个词很多人会以为是某种循环语句的工程化封装或者跟事件循环、消息循环沾边。实际上它描述的是一套让多个智能体在同一个任务闭环里反复协作、互相校验、逐步收敛的架构方法论。核心不在“循环”本身而在于把一次性的任务执行改造成一个可迭代、可观测、可回滚的协作回路。我最早接触多智能体协作是在做自动化内容生产流水线的时候。单个智能体写出来的东西质量波动极大同一个提示词跑十次能出十种水平。后来把任务拆成“规划—执行—评审—修正”四个角色让它们在一个回路里互相拉扯输出质量才稳定下来。这就是 Loop Engineering 最朴素的样子不是让一个智能体变强而是让一组智能体在循环中互相补位。它适合谁如果你正在做以下任何一件事这套东西就跟你有关用多个模型或同一模型的多角色完成复杂任务代码生成、报告撰写、数据分析需要任务结果有自检和修正能力而不是“一次成型听天由命”想把智能体协作从“演示 demo”推进到“工程可用”团队里已经有人在喊“多智能体”但实际跑起来就是几个 prompt 串在一起这篇文章我会按真实项目落地的顺序来讲先拆架构设计的取舍逻辑再讲每个核心环节的实现细节然后是完整实操流程和参数选择最后把我踩过的坑和排查方法整理出来。全程按“能直接抄作业”的标准写不搞概念堆砌。2. 协作架构的整体设计与选型逻辑2.1 为什么是“回路”而不是“流水线”最常见的多智能体实现是流水线A 做完交给 BB 做完交给 C结束。这种结构实现简单但有个致命问题——错误会沿着流水线一路传递且没有任何环节负责回头。A 输出里有个事实错误B 基于它继续加工C 再润色一遍最后交付的东西错得很精致。Loop Engineering 的核心改动是引入回边。评审环节发现问题的不是打个分就完事而是把问题结构化地退回给执行环节执行环节带着反馈重新生成再进入评审。这个回路可以跑固定轮数也可以跑到评审通过为止。我用一个实际对比说明差异。做代码生成任务时结构首次通过率平均修正轮数最终可用率单智能体直出约 40%040%流水线生成→格式化→输出约 45%045%回路生成→评审→修正约 40%1.882%回路多角色评审约 38%2.191%数据是我自己项目里统计的样本量几百次任务不追求绝对精确但趋势很清楚回路结构牺牲了首次通过率因为评审会挑刺换来了最终可用率的大幅提升。这就是选它的理由。2.2 角色划分的三种主流方案角色怎么分直接决定架构复杂度。我试过三种各有适用场景。方案一三角色最小回路规划者、执行者、评审者这是我最推荐的起步方案。规划者负责把模糊需求拆成可执行步骤执行者按步骤产出评审者对照原始需求检查产出。三个角色可以用同一个模型加不同系统提示词实现成本低调试直观。方案二五角色扩展回路增加协调者和记忆管理者当任务步骤超过 10 步、需要跨轮次记住上下文时加一个协调者负责调度加一个记忆管理者负责压缩和检索历史信息。这个方案适合长周期任务但调试难度明显上升角色之间的通信开销也大。方案三动态角色按任务类型临时生成角色让一个元智能体根据任务描述动态决定需要哪些角色。灵活但不可控我只在探索性任务里用过生产环境不敢上。提示新手直接上五角色大概率会陷入“角色之间互相甩锅”的困境。先用三角色跑通一个完整回路再按需扩展。2.3 通信机制共享状态还是消息传递角色之间怎么交换信息是架构里第二个关键决策。共享状态是指所有角色读写同一个结构化对象比如一个 JSON每个角色只修改自己负责的字段。优点是实现简单、状态可追溯缺点是并发写容易冲突且角色容易“越界”改别人的字段。消息传递是指角色之间通过显式的消息队列通信每条消息有发送者、接收者、类型和载荷。优点是解耦彻底、可审计缺点是需要设计消息协议前期投入大。我的实际选择是混合模式主状态用共享对象关键决策用消息传递留痕。具体来说任务状态、当前轮次、评审结果这些放共享对象评审意见、修正指令这些走消息方便回溯“谁在什么时候说了什么”。# 共享状态的最小结构示例 task_state { task_id: t-001, round: 0, max_rounds: 5, plan: None, artifact: None, review: {passed: False, issues: []}, history: [] # 每轮的消息摘要 }这个结构看着简单但每个字段都有讲究。round和max_rounds是回路的刹车防止无限循环review.issues必须是结构化的列表而不是一段文字否则执行者没法精准修正history只存摘要不存全文控制上下文长度。3. 核心环节的实现细节与实操要点3.1 规划环节把模糊需求变成可执行步骤规划者的输出质量决定了整个回路的天花板。我见过太多项目在这里偷懒直接让规划者“列个步骤”结果执行者拿到一堆没法落地的空话。好的规划输出应该满足三个条件步骤可独立执行、步骤之间有明确依赖、每步有可验证的完成标准。我通常要求规划者输出这样的结构{ steps: [ { id: 1, action: 提取需求中的核心功能点, depends_on: [], done_criteria: 列出不少于3个功能点每个有明确输入输出 }, { id: 2, action: 为每个功能点设计接口, depends_on: [1], done_criteria: 每个接口有参数列表和返回结构 } ] }done_criteria这个字段是精髓。没有它评审者只能凭感觉判断“做完了没”有了它评审可以逐条对照把主观判断变成客观检查。实操心得规划者的系统提示词里一定要加一句“如果需求信息不足以规划先输出需要澄清的问题不要臆测”。我吃过亏规划者自作主张补全需求结果整个回路都在为一个错误假设服务。3.2 执行环节带着反馈重新生成执行者最容易被低估。很多人以为执行就是“把步骤翻译成结果”实际上执行者要处理的是带约束的生成——既要完成当前步骤又要吸收上一轮的评审意见还不能破坏已经通过的部分。我的做法是给执行者三段式输入原始需求、当前步骤定义、上一轮评审意见如果有。评审意见必须转成“问题—位置—建议”的结构而不是一段自然语言吐槽。def build_executor_prompt(requirement, step, last_review): prompt f原始需求{requirement}\n prompt f当前步骤{step[action]}\n prompt f完成标准{step[done_criteria]}\n if last_review and not last_review[passed]: prompt 上一轮评审发现以下问题请针对性修正\n for issue in last_review[issues]: prompt f- 位置{issue[location]}问题{issue[problem]}建议{issue[suggestion]}\n return prompt这里有个细节只把未通过的问题传给执行者已通过的部分不要重复提。否则执行者会过度修正把本来对的地方改坏。我早期没注意这点导致回路震荡——这轮改好 A 弄坏 B下轮改好 B 又弄坏 A。3.3 评审环节从“打分”升级为“定位”评审者是整个回路的守门人。最差的评审是“给个分数”好一点的评审是“列出问题”最好的评审是“定位问题并给出可执行的修正方向”。我要求评审者输出固定结构字段含义示例passed是否通过falsescore0-100 分72issues问题列表见下issues[].location问题位置第2步的接口定义issues[].problem问题描述缺少错误返回结构issues[].suggestion修正建议补充 error 字段及错误码location字段是关键。没有它执行者要自己猜“你说的问题在哪”猜错就白跑一轮。有了它修正可以精准打击。注意评审者的标准要跟规划者的done_criteria对齐。我见过评审者用自己的一套标准挑刺结果执行者按评审改完规划者那关又过不了来回扯皮。解决办法是评审提示词里明确写“以每步的 done_criteria 为唯一通过标准”。3.4 回路控制什么时候停什么时候退回路不能无限跑。我设三道刹车最大轮数一般设 3-5 轮。超过 5 轮还没通过说明任务定义或角色能力有问题继续跑是浪费。分数阈值评审分数连续两轮不升反降立即停止标记为“需要人工介入”。震荡检测如果同一组问题在相邻两轮反复出现说明执行者改不动停止并输出诊断信息。def should_stop(state): if state[round] state[max_rounds]: return True, 达到最大轮数 scores [h[score] for h in state[history] if score in h] if len(scores) 2 and scores[-1] scores[-2]: return True, 分数下降疑似震荡 return False, 震荡检测这个逻辑是我被坑了好几次之后加的。有一次回路跑了 8 轮每轮评审都说“接口定义不完整”执行者每轮都改但改的地方都不是评审真正在意的纯属无效循环。加了震荡检测后这种情况会在第 2 轮就被拦下来。4. 完整实操流程与关键参数选择4.1 从零搭一个三角色回路下面是我实际项目里的搭建顺序按这个走能少走弯路。第一步定义任务状态结构。先把task_state定下来所有角色都围绕它工作。字段宁少勿多后面按需加。第二步写三个角色的系统提示词。每个提示词只干一件事不要试图让一个提示词兼顾多个角色。规划者提示词的核心是“拆解可验证”执行者核心是“按步骤吸收反馈”评审者核心是“对照标准定位问题”。第三步实现回路主循环。伪代码逻辑如下def run_loop(requirement, max_rounds5): state init_state(requirement, max_rounds) state[plan] planner(requirement) while True: state[artifact] executor(requirement, state[plan], state[review]) state[review] reviewer(requirement, state[plan], state[artifact]) state[round] 1 state[history].append(summarize(state)) stop, reason should_stop(state) if state[review][passed] or stop: state[stop_reason] reason break return state第四步加日志和可观测性。每轮把输入输出完整落盘包括提示词、模型返回、耗时、token 消耗。没有这些出问题只能靠猜。第五步小样本调优。先拿 10 个任务跑看通过率和轮数分布再决定要不要调提示词或加角色。4.2 参数选择轮数、温度、模型搭配这几个参数我调了很久直接给结论。最大轮数3-5 轮是甜点区。设 2 轮太紧很多任务需要两轮修正设 8 轮以上边际收益极低还容易震荡。我现在的默认值是 4。温度设置规划者和评审者用低温度0.1-0.3保证输出稳定执行者可以用稍高温度0.5-0.7保留一定创造性。但如果是代码生成这类严谨任务执行者也压到 0.2。模型搭配不一定要用同一个模型。我的常用搭配是规划者和评审者用推理能力强的模型执行者用生成速度快、成本低的模型。这样整体成本能降三到四成质量损失很小。角色温度模型倾向理由规划者0.2强推理拆解质量决定上限执行者0.5快且便宜要跑多轮成本敏感评审者0.1强推理判断要稳定一致4.3 上下文管理别让历史撑爆窗口回路跑起来后历史信息会快速累积。第 4 轮的时候如果把前 3 轮的完整内容都塞进提示词token 消耗会爆炸而且模型注意力会被稀释。我的做法是分层压缩当前轮完整保留上一轮保留评审意见和修正点更早的轮次只保留一行摘要“第1轮接口定义不完整已修正”。这样上下文长度基本恒定不会随轮数增长。def build_context(state, current_round): ctx [] for h in state[history]: if h[round] current_round - 1: ctx.append(f上一轮评审{h[review_summary]}) elif h[round] current_round - 1: ctx.append(f第{h[round]}轮摘要{h[one_line]}) return \n.join(ctx)这个压缩策略实测下来4 轮任务的总 token 消耗比全量保留低 60% 以上质量没有可感知的下降。5. 常见问题与排查技巧实录5.1 回路震荡改了又好像没改现象评审每轮都提类似的问题执行者每轮都改但问题依旧。排查思路先看评审意见是否具体到位置。如果评审只说“质量不高”执行者根本不知道改哪。再看执行者是否真的理解了意见有时候是提示词里反馈信息被淹没在长上下文里。解决把评审意见单独成段加粗标注限制每轮只修最多 3 个问题避免执行者顾此失彼如果连续两轮同一问题直接停止并输出诊断。5.2 评审放水什么都通过现象评审通过率异常高但人工检查发现明显问题。排查思路检查评审提示词是否给了“通过”的默认倾向。很多提示词写“如果基本满足就通过”模型会倾向于放水。解决改成“必须逐条对照 done_criteria任何一条不满足即不通过”给评审者加一个“找出至少一个可改进点”的强制要求哪怕通过也要提改进建议。5.3 执行者过度修正现象这轮改好了 A下轮把 A 又改坏了。排查思路看是否把已通过的部分也传给了执行者。执行者看到“已通过”的内容有时会手痒去动。解决只传未通过的问题在提示词里明确“已通过部分不要改动”。5.4 常见问题速查表问题可能原因快速处理回路不收敛任务定义模糊让规划者先输出澄清问题评审标准漂移评审提示词未对齐 done_criteria统一以 done_criteria 为准token 消耗过高历史全量保留启用分层压缩角色互相甩锅职责边界不清每个角色只改自己负责的字段首轮通过率低评审过严检查 done_criteria 是否合理执行者输出格式乱缺少输出结构约束提示词里给 JSON schema5.5 几个我踩过的坑坑一角色用同一个提示词模板。我一开始图省事三个角色共用一个模板只改角色名结果规划者开始执行、执行者开始评审乱成一锅粥。每个角色的提示词必须独立写职责描述要具体到“你只做 X不做 Y”。坑二忽略失败案例的归档。回路跑失败的任务比成功的更有价值。我后来专门建了一个失败案例库每次震荡或超轮数都归档定期复盘提示词优化全靠它。坑三过早追求多模型。一开始就想用不同厂商的模型搭配结果接口适配、格式差异、超时处理耗掉大半精力。先用同一个模型把回路跑通再考虑模型搭配降本。坑四没有人工兜底。回路不是万能的有些任务就是需要人。我在流程里加了一个“人工介入”出口当回路停止且未通过时自动生成一份诊断报告推给人而不是硬跑。6. 从能跑到好用几个进阶优化方向回路跑通之后想让它真正好用还有几件事值得做。评审者分级。我后来把评审拆成两级一级评审做快速筛查只判断“有没有明显硬伤”二级评审做深度检查对照 done_criteria 逐条过。一级不通过直接退回不浪费二级评审的算力。这样整体成本降了约三成。执行者缓存。相同步骤定义加相同反馈执行者的输出可以缓存复用。在批量任务场景下命中率能到 20% 左右省下的调用很可观。回路指标监控。我盯三个指标首轮通过率、平均修正轮数、震荡率。首轮通过率突然下降通常是任务类型变了或提示词被改坏了平均轮数上升可能是评审变严了震荡率上升说明执行者能力跟不上了。这三个指标比任何日志都直观。任务类型路由。不是所有任务都值得跑回路。简单任务格式化、翻译单次调用就够跑回路纯属浪费。我加了一个前置判断根据任务复杂度决定走单次还是走回路整体效率提升明显。这套东西我从最初的三角色回路迭代到现在带分级评审和任务路由的版本前后改了十几版。核心体会就一句多智能体协作的难点从来不在“多”而在“协作”——让每个角色清楚自己该干什么、不该干什么让回路有明确的收敛条件和退出机制比堆角色数量重要得多。