企业官网建设流程全解析

近两年我接手了不少多智能体项目，也拆过一些团队的协作架构，发现一个很有意思的现象：真正把系统跑稳跑久的团队，几乎都围绕着同一个关键词在做文章——Loop Engineering。这个词落到实践层面，核心就一个字：“循环”。多智能体系统从来不是一次性编排，而是一套靠反馈驱动、自我修正、持续收敛的工程机制。这篇文章我不想讲炫技的原型Demo，只聊架构设计里的内幕和工程化落地时真正有用的最佳实践，把多智能体协作架构那些文档里不写的坑，一次说清楚。

1. Loop Engineering到底是什么：先把“循环”这件事想明白

很多团队搭Agent原型很容易，A模型调用B模型再调用C模型，一次跑通就觉得大功告成。但真正往生产上推，问题一个接一个来：智能体各说各话、任务做到一半跑偏、输出质量忽高忽低、模型幻觉没人发现。这些问题的根源，往往不是单个模型不够聪明，而是系统整体上缺少反馈和迭代机制。Loop Engineering解决的就是这件事——它不是某个具体算法，而是一套关于“如何让多智能体系统在循环中不断逼近正确目标”的工程方法论。

1.1 我理解的Loop Engineering

我做过多智能体系统之后有一个很深的体会：搞多智能体不是在搭积木，而是在建一条带质量闭环的流水线。传统软件工程里没人相信“一次写对”这回事，代码要Review、测试要反复跑、发布要灰度。Loop Engineering就是把这种“没有一次做对，但通过循环收敛到正确状态”的工程哲学，固化到多智能体系统的架构里。它的核心命题不是“你的Agent能不能回答”，而是“你的Agent系统有没有自我修正的能力”。

这里有个特别直观的对比，能说明单次编排和循环系统之间的本质差异：

这张表基本概括了Loop Engineering和“搭积木式”多智能体开发的本质区别。理解了这个区别，你再看那些动辄十几个Agent互相调用的系统，就会明白它们为什么往往撑不过一周——因为看起来热闹，实际上没有形成“执行—评估—修正”的闭环回路。

1.2 为什么多智能体架构“离不开循环”

这个话题要从大模型本身的不确定性说起。同一套Prompt，就算把温度调到接近0，模型每次输出也可能有差异。当系统里串联了多个模型，每个环节的误差都会叠加，这和工厂流水线一模一样——每个工位的微小偏差累积到最后，出来的可能就是废品。多智能体系统的信息传递过程里还有另一层损耗：下游Agent接收到的其实是上游Agent输出文本的“压缩”，这种压缩天然会丢失细节和上下文。

生活里最容易理解这个问题的类比是装修。再漂亮的设计图纸，也不可能一次施工到位，必须有“设计—施工—监理—验收—整改”的完整闭环，最后才有可能交付一个住着舒服的房子。多智能体系统也完全一样：生成环节必须和评估环节组成闭环，黑不提白不提地指望模型一轮到位，最后就是在给线上事故攒经验。

1.3 循环的四种基本形态

做Loop Engineering之前，建议先识别自己的业务里到底存在哪一种循环。我从实践里总结，常见的是四种形态：

• 任务执行循环：执行→检查→修正→再执行。典型场景是代码生成、报告撰写、数据处理。
• 多轮对话循环：提问→澄清→追问→回答收敛。典型场景是客服机器人、咨询分析助手。
• 记忆演变循环：写入→检索→更新→淘汰。典型场景是用户画像、长期记忆、知识库沉淀。
• 人机协同循环：机器执行→人工反馈→策略调整→再执行。典型场景是内容审核、代码Review、高影响决策。

这四种形态很少孤立存在。一个实际的多智能体系统，往往是任务循环、对话循环、记忆循环、人机循环交织在一起。所以Loop Engineering真正的架构洞察是：系统设计的关键不是把Agent的角色表填得多漂亮，而是把循环织成一张网——每条循环回路都要有反馈、有终止条件、有失控时的升级机制。

2. 多智能体协作架构的核心拆解：角色、模式与回路

这一章把多智能体架构拆开来看。理解了角色怎么分工、模式怎么选择、回路怎么闭合，你才能动手设计一套真正能循环起来的系统，而不是停留在“让两个大模型聊天”的层面。

2.1 核心角色体系：一个可运转的最小班子

我在项目里常用的角色体系包含五个部分，其中前四个都是软件系统里的角色，最后一个是人。

这套体系里最容易被忽略的是Critic。很多团队拿着一个模型反复又是生成又是评估，结果评出来的分数虚高。我后面会专门讲评估环节怎么设计，这里先记住一句话：评估者和生成者一定要解耦，至少要保证评估的“立场”独立。最小的可运转闭环其实只需要两个角色——Generator和Critic。先跑通这个最小循环，再慢慢加Worker和Planner，这条路最稳。

2.2 常见的协作模式与选择依据

多智能体之间的协作模式，决定了循环怎么组织。常见的四种模式我用一张表说清楚：

我踩过最大的坑是“看到什么新潮就用什么”。有一段时间团队里流行议会式，我们也在一个不合适的场景里硬上了七个Agent互相辩论，结果就是问题没变简单，成本和延迟倒是实打实翻了好几倍。后来我们沉淀出一个选择原则：能简单就不要复杂。百分之八十的业务场景用“编排式加一个Critic”就足够，复杂系统不是角色越多越好，而是回路越清晰越好。

2.3 一个完整的循环是怎样转起来的

拿一个我们经常写的场景举例：系统要生成一份“行业趋势分析报告”。整个Loop是这样转的：

1. Planner接收原始任务，拆解为资料收集、数据整理、初稿撰写、逻辑审查四个环节。
2. Researcher类型的Worker去检索行业资料并整理成结构化素材。
3. Writer类型的Worker基于素材撰写初稿。
4. Critic从结构完整性、数据准确性、结论支撑度三个维度给初稿打分，附加修改意见。
5. Planner查看Critic的反馈，结合全局任务状态做路由决策：如果评分低于阈值，把任务连同反馈一起送回Writer返工；如果返工超过最大次数，升级给人处理。
6. 每次循环结束时，Memory记录一条关键经验：任务类型、常见缺陷、有效的修改策略，后续同类任务直接复用。
7. 循环终止条件有三个：评分达标、达到最大迭代次数、人工提前中断。

这个例子里最关键的细节在第五步——“Planner查看Critic反馈再决定路由”。很多失败系统的反馈回路是断的：Critic提了意见，但没有人把它转化成下一步的行动指令，Worker根本不知道该改什么。Loop Engineering不只是要有Critic，更要有“反馈升级为行动”的路由机制，这个机制通常放在Planner里。

3. 实操落地：搭建带反馈闭环的多智能体系统

理论聊完，进入动手环节。这一章从技术选型开始，到代码实现，再到验证循环和可观测性设计，完整走一遍带反馈闭环的多智能体系统搭建过程。

3.1 技术选型：先别急着写代码

市面上的多智能体框架已经不少，选型很关键。我简单梳理一下几个主流方向的差异：

我个人建议：如果你是第一次做多智能体系统，优先从LangGraph这类“状态图驱动、循环显式化”的框架切入。理由很简单——循环是这个系统的灵魂，你需要先看得见循环的轨迹，才能理解怎么控制它。AutoGen做实验很爽，但到了线上环境，你会发现自己需要一套更严格的状态和路由控制。

3.2 核心代码示例：最小可运行的“Planner-Worker-Critic循环”

下面这个例子是用LangGraph风格写的，它实现了上一章描述的最小闭环。先定义系统的AgentState，所有节点共享这一个状态对象：

from typing import Annotated, TypedDict, Literal import operator class AgentState(TypedDict): task: str # 原始任务描述（始终不覆盖） messages: Annotated[list, operator.add] # 全部交互消息 draft: str # Worker生成的当前草稿 feedback: str # Critic的评估反馈 iteration: int # 当前循环轮数 max_iterations: int # 最大循环轮数

然后是三个核心节点。Planner负责拆任务和产生调度信息，Worker负责干活，Critic负责评估：

def planner_node(state: AgentState): # 实际项目里这里要让LLM做任务拆解，这里简化为固定逻辑 plan = ( f"任务已接收：{state['task']}。" "计划：先由Worker执行初稿，再由Critic评估，不达标则返工。" ) return {"messages": [{"role": "assistant", "content": plan}]} def worker_node(state: AgentState): # 实际项目里这里是LLM调用： # draft = llm.invoke(build_worker_prompt(state["task"], state["feedback"])) draft = f"这是第 {state['iteration']} 轮生成的内容草稿，涉及{state['task']}。" return {"draft": draft} def critic_node(state: AgentState): # 实际项目里这里应该用一个独立的评估模型： # score, feedback = evaluator_llm.invoke(build_critic_prompt(state["draft"], state["task"])) score = 0.6 if state["iteration"] < 2 else 0.85 feedback = "结构不够清晰，需要补充数据支撑和结论导向。" return {"feedback": feedback, "iteration": state["iteration"] + 1}

最关键的是条件路由函数。循环不是写死的“永远跑N轮”，而是由评估结果动态决定去Worker返工还是结束：

def route_after_critic(state: AgentState): # 实际系统中这里会综合评分和全局任务状态 if state["iteration"] >= state["max_iterations"]: return "end" if state["feedback"] and ("补充" in state["feedback"] or "改进" in state["feedback"]): return "worker" return "end"

最后用StateGraph把节点和边装配起来：

from langgraph.graph import StateGraph, END graph = StateGraph(AgentState) graph.add_node("planner", planner_node) graph.add_node("worker", worker_node) graph.add_node("critic", critic_node) graph.set_entry_point("planner") graph.add_edge("planner", "worker") graph.add_edge("worker", "critic") graph.add_conditional_edges( "critic", route_after_critic, {"worker": "worker", "end": END} ) app = graph.compile() # 运行一次任务 result = app.invoke({ "task": "分析2025年智能硬件行业趋势", "messages": [], "draft": "", "feedback": "", "iteration": 0, "max_iterations": 3, })

这段代码的逻辑很直白：Planner拆任务，Worker写初稿，Critic评估，评估结果决定下一跳是回Worker还是结束。把这个最小闭环跑通后，你再往里加真实的LLM Prompt、加并行Worker、加记忆模块，都是在已经“会循环”的骨架上做增量，而不是推倒重来。

3.3 验证循环的设计：别只靠LLM打分数

有段时间我们天真地相信“让GPT给GPT打分”就够了，后来发现不设防的同模型评估会出现明显的互相迁就现象——评估者倾向于给生成者宽松的评价，分数普遍虚高。真实的工程化系统里，验证循环至少要叠加三层校验：

第一层是规则校验。所有结构化输出必须做Schema校验，JSON字段缺失、格式错误、必填字段为空，这些不需要模型判断，直接规则拦截。第二层是模型评估。Critic模型和生成模型要解耦，可以选不同的模型供应商，或者用同样的模型但加完全不同的Prompt模板、不同的温度参数。第三层是人工抽检。高影响输出，比如直接面向客户的内容、自动生成的合同文本，必须保留人工审核节点。

这里还有一个经验：Critic的Prompt绝对不要写成“你觉得这篇写得好不好”，这种开放式提问只会得到模糊答案。要拆成可打分的维度，比如结构完整性、逻辑一致性、数据准确性、格式规范性，每个维度给出具体标准和分值区间。说到底，评估质量决定了循环收敛的质量，评估器不行，整个Loop都是空转。

3.4 可观测性：让循环过程透明可见

多智能体系统最让人头疼的是它的不可观测性。你拿到最终结果，很难知道中间经历了什么：哪一步返工了？哪个Agent最容易被Critic打回？哪类任务总是跑满最大轮数？没有这些数据，你后面做任何优化都是拍脑袋。

我们的做法是引入一个全局trace_id贯穿任务全程，每个节点运行都输出一条结构化日志，记录节点名、输入摘要、输出摘要、耗时、token数量、成本、评分、下一跳路由结果。所有日志落到统一存储，在排查的时候按trace_id一条链路拉出来看：

import json import time import logging def log_node(trace_id: str, node_name: str, payload: dict): logging.info(json.dumps({ "trace_id": trace_id, "node": node_name, "feedback": payload.get("feedback", ""), "iteration": payload.get("iteration", 0), "cost_usd": round(payload.get("cost_usd", 0.0), 6), "ts": time.time(), }))

可观测性还能帮我们做一些主动告警。比如单次任务循环轮数超过N次、某个Agent节点在短时间内被路由命中超过M次、成本飙升，都应该触发告警。没有这些，Loop Engineering就永远是“只可意会”，出了问题你连复现都难。

4. 工程化最佳实践：多智能体系统上生产的8条经验

这一章我总结了自己在多智能体系统上走过生产环境后沉淀下来的八条经验。每一条都对应一个真实的教训，希望能帮你少踩坑。

4.1 状态管理：给系统找一个“单一事实源”

多智能体项目一开始最容易犯的错，是让每个Agent自己记自己那点状态，Agent跟Agent之间靠对话传话，越传越乱。后来我们统一改成全局State对象——所有Agent的输入输出都挂在一个数据结构上，中间结果、反馈、路由信息全部显示声明。这里说的State要包含原始任务、当前草稿、最新反馈、迭代轮数、各节点关键输出。这样做的好处是一次任务的全貌都在一个地方，重试和恢复执行都变得简单明确。没有单一事实源的系统，连回滚都做不了。

4.2 上下文与记忆管理：别让Agent背着全部历史

我见过最夸张的一次，有个Agent的上下文里塞了十几轮完整对话记录，一轮Prompt的token费用就抵得上别人几十次调用。多智能体的循环机制会让历史消息成倍膨胀，所以必须把短期记忆和长期记忆分开管理。短期记忆只保留最近两轮消息以及当轮的关键结构化产出，更早的内容切割成摘要或者是干脆丢弃。长期记忆放到向量库，按需检索，而且检索结果要控制数量——宁可少给关键几条，也不要一次塞进五十条让模型自己挑。记忆条目还要带时间戳和置信度，旧信息要被新信息覆盖，不然Agent会被过期知识带偏。

4.3 防死循环：给循环装上“熔断器”

循环系统最大的工程风险就是掉进死循环。我们做过的线上排查里，死循环大多不是代码bug，而是路由条件永远无法满足。比如Critic的评分阈值设得太高，模型无论怎么改都达不到，于是任务就在Worker和Critic之间无限往返。真正防死循环要装三层熔断：第一层是最大迭代次数，一次任务默认上限建议3到5轮；第二层是反馈相似度检测，如果Critic连续两次返回几乎相同的反馈，说明系统已经震荡，必须中断并转人工；第三层是全局超时看门狗，无论跑到哪里，总耗时超时就强制退出。记住一个原则：循环系统必须有明确的终止条件，必须有失控时打断循环的开关。

4.4 成本控制：循环是一把双刃剑

循环带来质量上限，也带来成本成倍增长。一个任务平均循环2.5轮，token成本可能达到单次生成的4到6倍，如果某个环节还做多Agent并行评审，成本会更高。我的经验是用分级模型策略：初稿和简单任务用便宜的小模型，Critic评估用更强一点的模型，只有高难度返工或者人工介入之前才动用最强的模型。同时给每次任务预先设置成本上限，一旦超过上限就必须中断循环进入人工兜底流程，绝不允许无上限地跑下去。

4.5 评估与回归：循环质量的度量衡

多智能体系统改了Prompt、换了模型、调了路由策略，你怎么知道变好了还是变坏了？必须建立一套离线评估集。我们内部保留了至少50条覆盖典型场景的评估任务，每条任务都有标准答案和预期的执行路径。每次改动上线前跑一遍，重点看四个指标：任务完成率、平均循环轮数、人工干预率、单任务成本。尤其是Critic评分和人工评分的一致性，如果自动评分从标准差上就偏离人工，多半是Critic的评估Prompt出了问题，要优先处理。

4.6 角色定力：稳定System Prompt与记忆隔离

多智能体系统里每个Agent都要有稳定的“人设”。同一类角色换一个System Prompt，整个系统的行为就可能大变样。还有一条容易被忽视的经验——Agent之间的记忆隔离。不要让一个Agent看到系统里所有Agent的完整对话历史，那会造成观点污染。比如Critic看到Writer所有底层思考之后，就很容易“理解”对方的难处从而降低评估标准。我们现在的做法是每个Agent只接收结构化产出和必要的元数据，完全不把其他Agent的原始对话塞过去，角色定力明显稳了很多。

4.7 人工兜底：永远给人留一个“红色按钮”

无论循环设计得多完美，迭代上限、成本上限、反馈相似度检测，这些机制最终都会指向同一个出口：人工接管。所以在系统架构里一定要预留人工节点。置信度低于阈值自动转人工，连续返工达到上限转人工，用户主动触发转人工。我在实际使用中最深的感受是，Loop Engineering不是“无人驾驶”，而是“人机共驾”。人工兜底不是系统的失败态，而是系统安全的另一半。

4.8 渐进式发布：先影子模式再灰度放量

多智能体系统本质上仍是概率系统，不要指望它上线就稳。我们的上线流程分四步：第一步影子模式，系统在后台完整跑任务但结果不对外，只记录行为日志；第二步小流量灰度，放1%真实流量，所有结果都经过人工审核；第三步半量放量，放30%左右，重点看人工干预率和成本；第四步全量。每一步都设立回滚条件，比如人工干预率超过15%就自动切回上一阶段。这套流程很保守，但保住了我们好几次因为Prompt迭代引发的线上事故的回退空间。

我把这八条经验汇总成一张落地清单，方便你对照检查：

5. 常见问题与排查技巧实录

再分享几个线上排查的典型问题。每个问题都是我们真实踩过的坑，白纸黑字写出来，希望你能直接拿去用。

5.1 智能体陷入“死循环”

现象很直接：任务执行轮次一直增加，日志里同一个节点被反复进入，token成本快速上升，但输出没有实质变化。我们的排查套路是这样：先看路由日志确认卡在哪个环节，再对比这个节点连续几轮的输出反馈，如果反馈文本高度重复，说明系统在震荡。解决方案主要三个方向：一是调低Critic的阈值或者放宽评估标准，让任务有机会达标；二是打开反馈相似度检测，一旦发现重复反馈直接中断转人工；三是检查路由函数本身有没有覆盖到“评估结果达标”的分支。死循环最怕硬扛，熔断一定比硬扛省钱。

5.2 输出质量越迭代越差

质量越改越差，这是循环系统里最打击人的问题。原因往往是Critic反馈太笼统，Worker不知道具体改什么，结果为了改而改。解决方案是把反馈结构化：问题清单、修改建议、优先级三个字段分开。每次返工只要求Worker处理最高优先级的前两个问题，改完立刻对比评分。我们后来还加了一个快照机制——每次迭代都保存上一版内容，如果新版本评分低于上一版，自动回滚到上一版。循环必须允许“回退”，不能像没头苍蝇一样往前冲。

5.3 上下文膨胀导致成本爆炸

上下文太长，是循环系统必然面对的问题。原因在于每轮循环都会产生新的消息，随着轮数增加，输入给模型的上下文越来越长，成本指数级上升。我们的处理办法是固定窗口截断加摘要压缩：模型只读取最近两轮完整消息加上全局任务摘要，更早的消息无论多重要都不进了，需要细节时通过向量检索。还有一个容易忽略的点：不要把所有Agent的历史消息都塞给同一个模型。每个模型只看自己需要的输入和输出，这个筛选逻辑要写死在状态管理里。

5.4 多智能体对任务理解不一致

Planner拆解出来的任务，到了Worker手里经常走样，原因是没有一份两方都认的“任务规格书”。我们后来规定，任务拆解的输出必须是结构化的：目标、背景、输入、输出格式、完成标准、约束条件六个字段全齐，缺一不可。而且在任务正式开始前加了一个对齐检查点——让Worker先用一句话复述自己的任务，Planner比对通过后才正式开工。这个小小的复述步骤，能把理解偏差从根源上减少一大半。

5.5 任务目标漂移

多轮循环后Agent越走越偏，离原始目标越来越远。这是循环系统的天然风险，因为每轮返工都会引入新的上下文，模型被中间反馈带着跑，原问题反而淡化了。我们的解法是把原始任务定义设为一个不可变字段，每轮循环开始前强制注入当前Agent的Prompt，让模型始终知道“我们原本要干什么”。同时Planner在每次路由时都要对照原始任务检查全局进度，而不是只看Critic对局部产出的评分。

我把这五类问题整理成速查表，方便排查时对照：

6. 写在最后：我对Loop Engineering的几点体会

这些年做多智能体项目，我个人最大的体会是：循环本身往往比模型更重要。刚入坑的时候我也迷信“Agent越多越强”，结果做了一个八个角色互相调用的系统，跑起来热闹得跟菜市场一样，产出质量反而不如后来精简成“Planner加Worker加Critic”的紧凑循环。踩过几次坑之后，我给自己定了几条简单直白的原则：先画循环图再写代码；先跑通两个Agent再加角色；不要信任任何Agent的输出，只信任验证结果。

最后再分享一个小技巧，也是我们团队内部用得最多的一个方法：每次迭代都保存一份包含输入、草稿、反馈、路由结果在内的完整快照。这个快照比任何你精心设计的测试用例都管用，因为在多智能体系统里，所谓“调试”，很多时候就是把某一次循环的完整路径拉出来，一行行看每一个决策是在哪里偏离的。

如果你正在搭自己的多智能体系统，我强烈建议你从Loop Engineering的视角重新审视一遍架构：你的系统有没有反馈回路？反馈回路有没有熔断机制？熔断之后有没有人工能接管？这三个问题都能给出清晰答案的时候，这套多智能体系统才算真正具备了上生产的资格。