企业官网建设流程全解析

1. 从单兵作战到团队协同：Loop Engineering 到底在解决什么问题

第一次接触 Loop Engineering 这个概念是在去年做一个自动化内容审核系统的项目。当时团队里三个人各自维护一套脚本，A 负责抓取，B 负责清洗，C 负责分类，中间靠共享文件夹和定时任务串起来。跑了两周就崩了——A 改了字段名没通知 B，B 的输出格式变了 C 直接报错，排查一圈下来半天没了。那时候我就在想，能不能让这些环节像一支训练有素的团队一样，自己知道该干什么、干完了通知谁、出错了怎么补救。Loop Engineering 要解决的，正是这个问题。

简单来说，Loop Engineering 是一套围绕多智能体协作架构的工程化方法论。它不单单是写几个 Agent 然后让它们互相调用，而是把“循环”作为核心抽象——每个智能体在循环中感知状态、执行动作、评估结果、决定下一步，多个智能体之间通过明确的协议和共享上下文形成协作闭环。它能做到的事情包括：把复杂任务拆解成多个可独立执行的子任务、让不同专长的智能体各司其职、在运行过程中动态调整策略、以及在某个环节失败时自动触发重试或降级。

这套东西适合谁？如果你正在做以下任何一件事，Loop Engineering 的思路都值得参考：搭建自动化工作流但发现线性管道不够用、想让多个模型或工具协同完成一个任务、需要处理长链路任务中的不确定性和异常、或者单纯对多智能体系统的工程落地感兴趣。哪怕你只是用单个智能体做代码生成，理解循环机制也能帮你设计出更稳定的提示词策略。

我写这篇东西的出发点很简单：网上讲多智能体概念的文章很多，但真正从工程角度讲清楚“怎么搭、为什么这么搭、踩过哪些坑”的内容太少。接下来我会从架构设计、核心机制、实操落地、问题排查几个维度，把 Loop Engineering 这套东西拆开揉碎讲一遍。内容基于我在实际项目中的实践和观察，涉及具体参数和步骤的地方会给出可复现的方案。

2. 多智能体协作架构的核心设计思路

2.1 为什么是“循环”而不是“管道”

传统的自动化流程大多采用管道模式：步骤 A 完成输出给步骤 B，B 完成给 C，像工厂流水线一样。这种模式在任务确定、环境稳定的场景下效率很高。但一旦引入大模型这类具有不确定性的组件，管道模式就会暴露三个致命问题。

第一个问题是错误传播。管道中任何一个环节出错，后面的环节要么直接崩溃，要么基于错误输入产生更离谱的输出。我见过一个案例：摘要智能体把原文的关键数据漏掉了，后面的分析智能体基于残缺摘要生成了一份看起来合理但完全偏离事实的报告，最后人工审核才发现问题。第二个问题是缺乏反馈。管道是单向的，后面的环节无法告诉前面的环节“你给的东西不对，重新来”。第三个问题是无法动态调整。任务执行到一半发现需要额外信息，管道模式没法回头去补充。

循环模式的核心区别在于：每个智能体在执行完动作后，会评估当前状态与目标的差距，然后决定是继续、重试、还是请求其他智能体介入。这个“评估-决策-执行”的循环可以跑多轮，直到满足终止条件。用生活化的类比来说，管道模式像接力赛，棒子交出去就跟你没关系了；循环模式像篮球队，球传出去之后你还要跑位、接应、根据场上情况调整战术。

2.2 智能体角色的划分逻辑

多智能体系统设计的第一步是角色划分。我见过两种极端：一种是所有事情都塞给一个“全能智能体”，结果提示词长得像论文，效果反而不好；另一种是拆得太细，十几个智能体互相调用，调试的时候根本不知道问题出在哪个环节。

我的经验是遵循“单一职责+最小接口”原则。每个智能体只负责一类明确的动作，对外暴露的输入输出格式尽量简单。以一个技术文档生成系统为例，我划分了四个角色：

• 规划智能体：接收用户需求，输出任务分解和每个子任务的验收标准。它不执行具体操作，只负责“想清楚要做什么”。
• 执行智能体：根据规划结果调用工具或生成内容。可以有多个执行智能体，分别擅长不同领域。
• 评审智能体：检查执行结果是否满足验收标准，输出通过或不通过以及具体原因。
• 协调智能体：管理循环流程，决定下一步调用哪个智能体，处理异常和超时。

这里的关键是评审智能体和执行智能体必须分离。如果让执行智能体自己评审自己，它倾向于认为自己做的是对的，这是模型自评的固有偏差。我试过让同一个模型先执行再评审，通过率虚高，实际质量很差。分离之后，评审智能体用不同的提示词和评估维度，能发现很多执行智能体忽略的问题。

2.3 通信协议与共享上下文的设计

多智能体之间怎么传递信息，直接决定了系统的稳定性和可调试性。常见的做法有三种：直接消息传递、共享内存、以及黑板模式。我推荐的是“结构化消息+共享状态存储”的混合方案。

结构化消息指的是智能体之间传递的数据有明确的 schema，比如 JSON 格式，包含发送者、接收者、消息类型、负载、时间戳等字段。这样做的好处是可以在协调层做统一的路由和日志记录，出问题的时候能快速定位是哪条消息导致的。共享状态存储则是一个中心化的键值存储，所有智能体都可以读写，用来保存任务进度、中间结果、全局配置等。

注意：共享状态存储一定要设计好并发控制。多个智能体同时写同一个 key 会导致数据覆盖。我的做法是给每个写入操作加上版本号，写入时检查版本是否匹配，不匹配就重试或报冲突。

通信协议的设计还要考虑超时和重试。智能体 A 给智能体 B 发消息后，不能无限等待。一般设置 30 秒到 2 分钟的超时，超时后触发重试或降级。重试次数建议不超过 3 次，超过后应该上报给协调智能体做人工介入或任务终止。

2.4 循环终止条件的设定

循环不能无限跑下去，必须设定明确的终止条件。常见的终止条件包括：评审智能体连续 N 次通过、达到最大循环次数、总耗时超过阈值、或者累计成本超过预算。

我一般会同时设置多个条件，以先满足的为准。最大循环次数通常设为 5 到 8 次，再多的话要么是任务本身有问题，要么是评审标准太苛刻。耗时阈值根据任务复杂度来定，简单的文档生成给 3 分钟，复杂的代码生成给 10 分钟。成本预算这个容易被忽略，但实际项目中很重要——有一次一个循环跑了 47 轮，账单出来的时候我差点没站稳。

终止后的处理也要设计好。正常终止就输出结果，异常终止要输出当前状态和失败原因，方便后续排查。我习惯在终止时生成一份执行报告，包含每轮循环的输入输出摘要、耗时、消耗的 token 数，这份报告对优化系统非常有价值。

3. 核心机制拆解与关键参数解析

3.1 循环控制器的实现要点

循环控制器是整个系统的心脏，它决定了每一轮循环调用哪个智能体、传递什么参数、以及何时终止。实现方式可以很简单，也可以很复杂，取决于任务的不确定性程度。

最简单的实现是一个状态机：定义几个状态（规划中、执行中、评审中、已完成、已失败），根据当前状态和评审结果决定下一个状态。这种实现适合流程相对固定的场景。复杂一点的可以用基于规则的路由，比如根据任务类型、历史成功率、当前负载来动态选择执行智能体。

我在实际项目中用的是“状态机+优先级队列”的混合方案。状态机负责主流程控制，优先级队列负责管理待执行的任务。每个任务有优先级、依赖关系、超时时间等属性。控制器每轮从队列中取出优先级最高的可执行任务，分配给对应的智能体。

关键参数方面，有几个需要特别注意：

这些参数不是拍脑袋定的，而是根据实际运行数据调出来的。比如最大循环轮次，我一开始设了 10 次，后来发现大部分任务在 3 到 4 轮就收敛了，设太高只是浪费资源。评审通过阈值也是，0.8 是在准确率和召回率之间取的平衡点，设 0.9 会漏掉一些可接受的输出，设 0.7 又会放过太多低质量结果。

3.2 上下文管理与记忆机制

多智能体协作中，上下文管理是最容易被低估的环节。每个智能体在执行时都需要知道“之前发生了什么”，但把所有历史信息都塞进提示词会导致 token 爆炸，而且模型对长上下文的注意力会分散。

我的做法是分层管理上下文。第一层是全局状态，包含任务目标、当前进度、关键决策记录，这部分始终保留。第二层是近期交互，保留最近 3 到 5 轮的完整消息，让智能体了解最近的动态。第三层是历史摘要，更早的交互压缩成简短摘要，只保留结论性信息。

摘要的生成也有讲究。不能让执行智能体自己摘要，因为它可能遗漏重要信息。我专门用一个摘要智能体来做这件事，提示词里明确要求保留：决策依据、未解决的问题、被否决的方案及原因。这样后续智能体在需要回溯时，能快速定位到关键节点。

实操心得：上下文压缩的时机很重要。不要等到快满了才压缩，那样容易丢信息。我一般在上下文使用率达到 70% 时就触发压缩，留出足够的缓冲空间。

3.3 评审智能体的评估维度设计

评审智能体是保证输出质量的关键。如果评审标准太模糊，它就会变成橡皮图章，什么都给通过。如果太严格，循环次数会飙升，成本失控。

我通常从四个维度设计评审标准：完整性、准确性、一致性和格式合规性。完整性检查是否覆盖了所有要求点，准确性检查事实和数据是否正确，一致性检查前后逻辑是否自洽，格式合规性检查是否符合输出规范。每个维度给出 0 到 1 的评分，加权平均后得到总分。

权重的分配根据任务类型调整。技术文档生成中，准确性权重最高，占 0.4；内容创作中，完整性和一致性更重要，各占 0.35。评审智能体的提示词里要给出具体的评分标准和示例，让它知道什么算 0.9 分，什么算 0.5 分。

还有一个技巧是让评审智能体输出具体的改进建议，而不只是分数。这样执行智能体在下一轮循环中能明确知道该改哪里。我试过只给分数的版本，执行智能体经常在无关紧要的地方反复修改，真正的问题却没动。

3.4 异常处理与降级策略

多智能体系统运行中遇到异常是常态，关键是怎么处理。我把异常分为三类：可重试异常、可降级异常和致命异常。

可重试异常包括网络超时、模型返回格式错误、临时性资源不足等。这类异常直接触发重试，重试时可以调整参数，比如降低温度值让输出更稳定。可降级异常包括某个智能体持续失败、评审一直不通过等。这时候可以切换到备用方案，比如换一个模型、简化任务要求、或者跳过非关键步骤。致命异常包括配置错误、依赖服务完全不可用等，这时候只能终止任务并报警。

降级策略要提前设计好，不能等出问题了再想。我一般会为每个关键智能体准备一个备用实现，主实现失败时自动切换。备用实现可以简单一些，比如用规则引擎代替模型推理，虽然效果差一点但能保证流程继续。

4. 从零搭建一个多智能体协作系统的实操记录

4.1 环境准备与基础框架选型

动手之前先想清楚技术栈。多智能体系统的核心组件包括：智能体运行时、消息队列、状态存储、日志系统。运行时可以用现成的框架，也可以自己写。我评估过几个主流框架，各有优劣。

自己从零写的好处是可控性最强，每个环节都能按需定制。坏处是工作量大，光是消息路由和状态管理就要写不少代码。用框架的好处是开箱即用，坏处是遇到框架的坑时排查成本高。我的建议是：如果只是做原型验证，用框架快速搭起来；如果要上生产，核心的循环控制器和状态管理最好自己实现，外围组件可以用现成的。

基础环境方面，Python 生态比较成熟，异步用 asyncio，消息队列用 Redis 的 Stream 或者 RabbitMQ，状态存储用 Redis 或 PostgreSQL。日志用结构化日志，每条日志包含 trace_id，方便串联一次完整循环的所有事件。

# 一个简化的循环控制器骨架 import asyncio from dataclasses import dataclass, field from typing import Any @dataclass class LoopState: task_id: str goal: str current_round: int = 0 max_rounds: int = 6 history: list = field(default_factory=list) status: str = "running" class LoopController: def __init__(self, agents: dict, state_store): self.agents = agents self.state_store = state_store async def run(self, task_id: str, goal: str): state = LoopState(task_id=task_id, goal=goal) while state.current_round < state.max_rounds: state.current_round += 1 plan = await self.agents["planner"].execute(state) result = await self.agents["executor"].execute(plan) review = await self.agents["reviewer"].execute(result) state.history.append({ "round": state.current_round, "plan": plan, "result": result, "review": review }) if review["score"] >= 0.8: state.status = "completed" break state.goal = self._refine_goal(state.goal, review["feedback"]) return state

这段代码只是骨架，实际项目中还要处理超时、重试、并发、持久化等。但核心逻辑就是这么简单：规划、执行、评审、根据评审结果决定继续还是终止。

4.2 智能体提示词的设计与调优

提示词的质量直接决定智能体的表现。我设计提示词时遵循几个原则：角色定义要具体、任务描述要清晰、输出格式要明确、边界条件要说明。

以评审智能体为例，差的提示词是“请评估以下内容的质量并打分”。好的提示词会写成：“你是一名严格的技术文档评审专家。请从完整性、准确性、一致性、格式合规性四个维度评估以下文档。每个维度给出 0 到 1 的分数，并列出具体问题和改进建议。评分标准：0.9 以上表示可以直接发布，0.7 到 0.9 表示需要小修，0.5 到 0.7 表示需要大修，0.5 以下表示需要重写。”

调优提示词的方法论是：先写一版，跑 20 到 30 个测试用例，看哪些地方不符合预期，针对性修改，再跑测试。不要凭感觉改，要有数据支撑。我一般会维护一个测试集，包含各种边界情况，每次改提示词都跑一遍回归测试。

还有一个容易被忽略的点是提示词的版本管理。多智能体系统中提示词是核心资产，改了什么、为什么改、效果如何，都要记录。我用 Git 管理提示词文件，每次修改都写 commit message，方便回溯。

4.3 消息路由与状态同步的实现

消息路由决定了智能体之间怎么找到对方。最简单的做法是硬编码，A 要调用 B 就直接写 B 的地址。但这样扩展性差，加一个新智能体就要改多处代码。更好的做法是用注册中心，每个智能体启动时注册自己的能力和地址，路由层根据能力匹配来转发消息。

状态同步的挑战在于一致性。多个智能体可能同时读写共享状态，需要保证不会出现脏读或丢失更新。我的方案是用乐观锁：每次读取状态时拿到版本号，写入时检查版本号是否变化，变了就重试。对于高频写入的场景，可以用消息队列串行化写操作。

# 乐观锁更新示例 async def update_state(key: str, new_value: Any, expected_version: int): current = await state_store.get(key) if current["version"] != expected_version: raise VersionConflictError(f"Expected {expected_version}, got {current['version']}") await state_store.set(key, { "value": new_value, "version": expected_version + 1 })

实际运行中，版本冲突的概率不高，但一旦发生没有处理好，会导致数据不一致。我建议在关键路径上都加上版本检查，非关键路径可以放宽。

4.4 完整运行流程演示

以一个“生成产品需求文档”的任务为例，走一遍完整流程。

用户输入：“为我们的新功能——智能日程推荐——写一份产品需求文档，包含背景、目标用户、功能描述、优先级、验收标准。”

第一轮：规划智能体接收需求，输出任务分解：1）调研同类产品；2）定义目标用户画像；3）描述核心功能；4）排定优先级；5）编写验收标准。每个子任务附带验收标准。

执行智能体依次执行五个子任务，生成初稿。评审智能体检查后发现：目标用户画像缺少数据支撑，功能描述没有覆盖边界情况，验收标准不够可量化。总分 0.62，不通过。

第二轮：规划智能体根据评审反馈调整任务，增加“补充用户调研数据”和“明确异常流程”两个子任务。执行智能体重新生成相关章节。评审智能体再次检查，总分 0.81，通过。

协调智能体汇总最终文档，生成执行报告，任务完成。整个过程耗时约 4 分钟，消耗 token 约 15000 个。

这个流程看起来简单，但实际跑的时候会遇到各种问题：规划智能体有时会漏掉子任务，执行智能体有时会偏离规划，评审智能体有时会给出矛盾的反馈。这些都需要通过提示词调优和流程设计来逐步解决。

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

5.1 循环不收敛的排查思路

循环不收敛是最常见的问题，表现为评审一直不通过，循环次数用尽后输出质量仍然很差。排查时按以下顺序检查：

先看评审标准是否合理。如果评审智能体给出的分数一直在 0.6 到 0.7 之间徘徊，但具体问题描述很模糊，说明评审标准不够明确。解决方法是细化评分标准，给出正例和反例。

再看执行智能体是否理解了评审反馈。有时候评审说“第三段逻辑不清晰”，执行智能体却去改了第五段。这是因为反馈信息在传递过程中丢失了上下文。解决方法是在传递反馈时附上原始内容和评审的具体位置引用。

最后看任务本身是否可完成。有些任务在给定约束下就是无法达到评审标准的，比如要求“用 100 字说清楚一个复杂技术方案”。这时候需要调整任务目标或放宽评审标准。

5.2 智能体“互相甩锅”的解决

多智能体系统中经常出现的一种情况是：执行智能体说“我按规划做的”，规划智能体说“我按需求规划的”，评审智能体说“我按标准评审的”，但最终结果就是不对。这种“甩锅”现象的根本原因是职责边界模糊。

解决方法是在每个环节都定义明确的输入输出契约。规划智能体的输出必须包含可验证的验收标准，执行智能体的输出必须逐条对应验收标准，评审智能体的评审必须引用具体的验收标准条目。这样出了问题就能精确定位是哪个环节的契约没有满足。

我还会在协调层加一个“一致性检查”步骤，在每轮循环开始前检查上一轮的输出是否符合契约。不符合就立即中断，而不是等到评审阶段才发现。

5.3 成本失控的预防与止损

多智能体系统的成本比单智能体高得多，因为每轮循环都要调用多次模型。成本失控通常有几个信号：循环轮次频繁达到上限、单个任务消耗 token 超过预算、重试次数异常增多。

预防措施包括：设置每轮和每任务的 token 预算，超预算时触发告警或降级；监控循环轮次的分布，如果大部分任务都要跑满最大轮次，说明规划或评审环节有问题；定期分析成本构成，找出消耗最大的环节进行优化。

止损措施包括：设置硬性成本上限，达到后强制终止；对于持续超预算的任务类型，降低模型规格或简化流程；建立成本看板，让团队每个人都看到实时消耗。

踩过的坑：有一次一个批量任务跑了 200 多个循环，原因是评审智能体的一个边界条件写错了，导致所有输出都被判为不通过。等发现的时候已经消耗了大量资源。后来我加了“连续不通过次数”监控，超过 5 次就自动暂停并报警。

5.4 常见问题速查表

5.5 独家避坑经验分享

第一个经验是关于提示词中的“禁止项”。很多人写提示词只写“要做什么”，不写“不要做什么”。但在多智能体场景下，智能体很容易越界。比如执行智能体不应该修改规划，评审智能体不应该直接改内容。在提示词里明确写出禁止项，能减少很多意外行为。

第二个经验是关于日志的粒度。日志太粗，出问题查不到原因；日志太细，关键信息被淹没。我的做法是分层记录：协调层记录每轮循环的摘要，智能体层记录每次调用的输入输出，工具层记录具体操作的参数和结果。排查时从协调层往下逐层深入。

第三个经验是关于测试集的建设。多智能体系统的行为空间很大，靠手动测试覆盖不全。我建议从第一天就开始积累测试用例，包括正常流程、边界情况、异常场景。每次修改提示词或流程后，跑一遍回归测试，确保没有引入新的问题。

第四个经验是关于人工介入的时机。不要等到系统完全跑不通才人工介入。我设置了一个“置信度阈值”，当评审智能体的置信度低于某个值时，自动转人工审核。这样既保证了效率，又避免了低质量输出直接流向用户。

6. 多智能体协作架构的扩展与优化方向

6.1 从固定流程到动态编排

目前大部分多智能体系统采用固定流程：规划、执行、评审、循环。这种流程在任务类型相对固定的场景下够用，但面对多样化任务时显得僵化。下一步的优化方向是动态编排：根据任务特征自动选择最合适的智能体组合和流程。

实现动态编排的关键是建立一个“任务特征到流程模板”的映射。任务特征可以包括：复杂度、领域、输出格式要求、时效性要求等。流程模板则定义了智能体的调用顺序、循环条件、评审标准。系统在接收任务后，先做特征提取，然后匹配最合适的模板。

我目前在做的一个实验是让规划智能体不仅输出任务分解，还输出推荐的执行策略。比如对于创意类任务，推荐“多轮发散-收敛”模式；对于技术类任务，推荐“规划-执行-验证”模式。这样系统就有了一定的自适应能力。

6.2 智能体能力的持续进化

多智能体系统运行一段时间后，会积累大量的执行记录和评审记录。这些数据是宝贵的资产，可以用来持续优化智能体的表现。

一个方向是用历史数据微调模型。把高质量的执行记录作为正例，低质量的作为反例，训练一个更擅长特定任务的模型。另一个方向是用历史数据优化提示词。分析评审不通过的案例，找出提示词中缺失的约束或模糊的表述，针对性改进。

还有一个方向是建立智能体能力画像。记录每个智能体在不同任务类型上的成功率、平均耗时、平均成本，形成能力矩阵。调度时根据能力矩阵选择最合适的智能体，而不是固定分配。

6.3 人机协作的边界设计

完全自动化的多智能体系统在可预见的未来仍然不现实。关键决策、高风险操作、创意性工作，都需要人的参与。设计好人机协作的边界，比追求全自动化更有价值。

我的做法是设置三个介入点：任务启动前，人工确认任务目标和约束条件；循环过程中，当置信度低于阈值或触发特定规则时，转人工审核；任务完成后，人工做最终验收。这样既发挥了系统的效率优势，又保证了关键环节的质量可控。

介入点的设计要根据任务风险等级调整。低风险任务可以放宽介入条件，高风险任务则要增加介入频率。我一般会为每类任务定义一个风险等级，然后根据等级自动配置介入策略。

6.4 性能优化的几个实用技巧

多智能体系统的性能瓶颈通常在模型调用上。优化方向包括：减少不必要的调用、并行化可并行的调用、缓存可复用的结果。

减少调用方面，可以在评审前加一个轻量级的预检，用规则或小模型快速过滤明显不合格的输出，避免浪费评审智能体的调用。并行化方面，规划智能体分解出的子任务如果没有依赖关系，可以并行执行。缓存方面，相同或相似的输入可以复用之前的输出，特别是对于常见问题或标准格式的内容。

还有一个技巧是分级模型策略。不是所有环节都需要用最强的模型。规划环节可以用强模型保证质量，执行环节可以用中等模型控制成本，评审环节可以用专门微调过的小模型提高速度。根据实际测试，这种分级策略能在保证质量的前提下降低 40% 到 60% 的成本。

7. 一些个人体会

写到这里，我想分享一个最深的体会：多智能体协作系统的难点不在技术，而在设计。技术上的问题，比如消息传递、状态同步、异常处理，都有成熟的解决方案。但设计上的问题，比如角色怎么划分、评审标准怎么定、循环条件怎么设，没有标准答案，需要根据具体场景反复试验和调整。

我见过很多团队一上来就追求复杂的架构，结果调试成本高得吓人，最后还不如一个精心设计的单智能体系统。我的建议是：从最简单的循环开始，一个执行智能体加一个评审智能体，跑通了再逐步增加角色和复杂度。每增加一个组件，都要问自己：它解决了什么具体问题？没有它行不行？

另外，不要低估提示词工程的重要性。在多智能体系统中，提示词就是代码，而且是比普通代码更脆弱的代码。模型的一点微小变化都可能导致行为漂移。建立完善的测试和监控体系，比追求架构的先进性更重要。

最后，保持对成本的敏感。多智能体系统的成本是指数级增长的，每增加一轮循环、每增加一个智能体，消耗都会显著上升。在设计阶段就把成本纳入考量，比事后优化要有效得多。