循环工程：让大语言模型多轮调用稳定可控的设计实践

1. 整体设计与思路拆解

1.1 从“写循环”到“设计循环工程”

第一次听到 Loop Engineering 这个词的人，大概率会把它理解成“写循环代码”。我在实际项目中摸爬滚打之后才发现，这个词说的完全不是那么回事。它真正关注的是：当大语言模型（LLM）被放到一个可能会反复调用工具、多次拆解任务的流程里时，你怎么设计这个“循环”，才能让它稳定、可控、不跑偏。

打个不那么严谨的比方。你让实习生去整理仓库，如果他只知道“反复搬箱子”这个动作，那他可能把同一箱货搬来搬去搬十遍，也可能把易碎品压到底下，甚至搬到一半开始发呆。Loop Engineering 研究的就是三件事：第一，让实习生知道每一趟该搬哪个箱子（循环的每一步走什么分支）；第二，让他知道什么时候算搬完、可以停下来（循环的退出条件）；第三，在他搬错的时候，怎么通过指令把他拉回正轨（反馈与修正机制）。这三件事合起来，才叫“循环工程”。

我最早接触这个领域，是在做智能客服机器人项目的时候。最初的版本是一个简单的“用户提问 → 调大模型 → 返回答案”的单轮结构。跑起来之后发现，稍微复杂一点的用户需求，比如“帮我查一下订单，如果发货了就把物流单号发我，如果还没发货就帮我催一下”，单轮结构根本应付不来。它需要先查订单状态，根据状态决定下一步动作，动作完成之后再决定要不要结束对话。这就逼着我去设计一个真正带状态的循环结构。 Loop Engineering 在这一刻从概念变成了刚需。

1.2 为什么用“循环工程”而不是“写个循环”

有读者可能会说：这不就是 while 循环 + if 判断吗，用 Python 写不就行了。理论上是这样，但实际落地的时候，难点全在“判断条件”上。

传统编程里，判断条件非常明确——订单状态是“已发货”，那就是已发货，布尔值不会撒谎。但在 LLM 场景里，“理解用户意图”和“判断工具返回结果”这两件事，本质上都是概率行为。模型觉得“用户应该是在问订单状态”，可它不一定对；模型看到“物流信息不存在”，它有可能会推断成“还没发货”，也有可能会推断成“查询失败”，还有可能觉得“用户没给订单号，需要反问”。同一个事实，在不同模型的眼里可能得出不同结论，甚至同一个模型在不同温度设置下结论也不一样。

所以 Loop Engineering 的真正难点，不是“循环怎么写”，而是“循环每一步的决策怎么设计”。这包括：

• 如何用 Prompt 约束模型，告诉它每一步根据什么信号做出什么决定；
• 如何在上下文里保留足够的状态信息，让模型记住自己走到哪一步了；
• 如何区分“任务完成”和“任务失败”，避免循环无限空转；
• 如何从失败中恢复，比如某一步解析出错时，是重试、修正还是跳出。

这些问题的答案，构成了整个循环工程的核心方法论。简单地写一个 for 循环，完全覆盖不了这些设计层面的事情。

1.3 适合谁来学、能解决什么问题

这个教程对三类人最有用：第一类是正在做 Agent 应用开发的工程师，尤其是遇到了“模型单轮回答够用，但一接工具/API 就乱套”这种情况的人；第二类是产品经理和技术负责人，他们不一定写代码，但需要理解为什么 Agent 项目的复杂度比传统后端项目高一个量级，以及怎么拆分需求才能让开发更顺利；第三类是想转型 AI 应用开发的传统后端工程师，他们把这一套东西吃透之后，会发现之前积累的工程化经验完全能迁移过来，并不是非得懂模型训练才能做 AI 应用。

至于它能解决什么问题，我挑几个典型的：多轮工具调用的状态管理混乱，模型的中间判断不可靠导致流程走错，工单处理、客服对话、数据分析这类需要“多步操作 + 条件跳转”的任务不知道怎么拆解，以及测试时看着单轮都通过、一跑全链路就翻车这类非常扎心的场景。

下面我结合一个完整的实战项目，把这套方法论一步步拆开讲。你跟着走一遍，就能理解它到底是怎么在真实业务里发挥作用的。

2. 核心细节解析与实操要点

2.1 状态设计的核心思想：让每个循环节点都有明确的“输入信号”

我见过不少刚开始做 Agent 的人，一上来就铺了很多节点，什么“分析意图节点”“生成回答节点”“调用工具节点”“记忆更新节点”，看起来流程很完整，但模型在实际跑的时候根本不听指挥，到处乱跳。问题出在哪里？出在状态节点的定义不够明确。

在循环工程里，每一个状态节点都必须回答三个问题：当前这个节点是干什么的？它依赖上一步的什么输出？它下一步可以跳转到哪几个节点？以我那个智能客服项目为例，我设计了四个核心状态：意图确认、工具调用、结果分析、回复生成。

意图确认节点的输入信号是用户的原始消息，它输出的是一个结构化的 JSON，比如 {"intent": "query_order", "entities": {"order_id": "12345"}}，那下一步就只能去工具调用节点；如果输出的是 {"intent": "clarify", "question": "请问你的订单号是多少？"}，那下一步就直接去回复生成节点。这里面的关键点在于，下一步跳转不由代码硬编码决定，而是由模型输出的 intent 字段来决定，所以你对模型输出格式的控制能力，直接决定了整个循环能不能跑得起来。

我做一个具体展示。假设你的意图确认节点 Prompt 是这么写的：

你是订单客服助手。请分析用户消息，输出 JSON： {"intent": "query_order" | "clarify" | "chat", "entities": {...}, "question": "需要反问时的问题"} 规则： - query_order：用户提供了订单号或可识别的订单特征 - clarify：缺关键参数，需要反问用户 - chat：非订单相关的闲聊

用户输入“帮我看看我的快递到哪了”，模型输出 {"intent": "clarify", "question": "请提供你的订单号"}，那程序就跳到回复生成节点，把这句话发给用户。用户接着输入“订单号是 888888”，模型输出 {"intent": "query_order", "entities": {"order_id": "888888"}}，程序就跳到工具调用节点去查物流接口。这样每个循环都走得很清晰，模型永远知道自己在哪个状态、下一步做什么。

2.2 工具调用的上下文窗口设计：该保留什么、该丢掉什么

Loop Engineering 里另一个特别容易踩坑的地方是上下文管理。很多教程会告诉你“要把完整对话历史都传给模型”，我实测下来这是个坑。上下文越长，模型对当前步骤的专注度越低，而且 token 成本成倍上涨。更麻烦的是，如果前面的某个中间结果有误，它会带着错误继续往后跑，后面每一步都想把前面的错误“圆回来”，越走越偏。

我的做法是给每一个节点定义独立的“瞬时上下文”。比如工具调用节点，它只需要拿到上一步确认的意图和提取出来的实体，加上对应工具的说明文档就够了，不需要把用户两轮之前的闲聊都塞进去。但这不等于完全不保留历史，你需要在全局维护一份“会话摘要”，每轮循环结束后，用一小段文本把当前进展浓缩进去，比如“订单 12345 已发货，物流单号 SF1234567890，当前在运输中”，然后把这份摘要作为下一轮循环的起点。

说一个实操细节。摘要不是简单地把每轮的输出拼起来，而是要主动淘汰掉已经没用的信息。还是客服机器人那个例子，用户第一轮只给了手机号，第二轮给了订单号，那“手机号”这个信息在订单查完之后就没用了，摘要里就不用再留它。如果留着，模型反而可能在下一次判断中被这个冗余信息干扰。这种对上下文做“裁剪”的操作，是循环工程里非常吃功夫的一点。

2.3 步骤分类：不是所有循环都一样

在真正的项目里，你会遇到很多种不同形态的循环，我得先说清楚再讲实战，否则你会觉得我的实现方式怎么跟你在别处看到的不一样。

第一种是“决策循环”，每一步根据当前条件决定下一步往哪走，走过的路径不回头，典型场景是工单处理流程：判断工单类型 → 分配优先级 → 匹配处理小组 → 生成回复。第二种是“重试循环”，调用工具失败或者模型输出不合法时，在当前步骤内部做有限次数的修正，典型场景是 JSON 解析失败时让模型重新输出。第三种是“反思循环”，模型根据执行结果反思自己哪里做得不好，然后调整策略再来一轮，典型场景是代码修复、文本改写这类任务，模型写完一版，自己检查一遍发现问题，再写第二版。

这三种循环在工程上的实现方式差别很大。决策循环追求的是“路径可控”，每一步走完就固化下来，不要前面走到第三步了，后面又回头去改第一步。重试循环追求的是“次数有限”，一定要设置最大重试次数，否则模型可能永远修正不对，把 token 烧光。反思循环追求的是“有效反思”，你给它的评价标准必须具体，说“请检查代码是否正确”等于没说，说“请检查是否有变量未定义、是否有数组越界、是否有类型不匹配”才能真正引导它发现问题。

我见过最典型的翻车现场，是有人把反思循环设计成“如果用户不满意，就重新回答一次”，没有任何标准，结果模型对自己生成的内容有天然惰性，它每次都微调几个词再返回，用户满意度不升反降。这就是典型的循环设计没有约束导致的失控。

2.4 约束系统设计：把选择权留给模型，把边界划给系统

Loop Engineering 听起来很灵活，好像是在给模型自主权，但实际落地时你会发现，它其实是一门“怎么在灵活性里加护栏”的学问。这里的护栏，就是我说的约束系统。

约束分为三层次。第一层是输出格式约束，强制模型输出合法 JSON，并且字段名、类型都是预先定义好的，这样你的代码才能稳定解析。第二层是动作空间约束，就是要明确告诉模型“你现在只能从这几个动作里选，不要自由发挥”，比如工具调用节点只允许选择调用物流查询接口或订单接口，不允许模型自己编一个“检查库存”的动作出来。第三层是业务规则约束，比如客服机器人不允许对用户做任何承诺、不允许虚构物流状态、不确定时必须回复“帮您转人工”，这些规则在 Prompt 里必须是硬性的，不能用“一般来说”“通常”这种模糊措辞。

我自己有个习惯，会专门维护一个“约束清单”文档，每加一条约束就在文档里登记一条，标注这条约束是用来解决什么问题的。因为 Loop Engineering 越到后期，Prompt 越长，约束越多，你很可能忘了哪条规则是为哪个事故加的，结果后面优化的时候把它删掉，老问题就复发了。这个清单文档在排障的时候也能帮你快速缩小排查范围。

3. 实操过程与核心环节实现

3.1 实战项目背景：多轮工单处理助手

说一个我做过比较典型的项目，背景是帮一个中型电商团队做智能售后工单助手。这个团队的售后流程是这样的：用户提交工单，系统先判断工单类型（退货、换货、退款、维修、投诉），然后根据类型走不同分支，有的分支需要查订单、有的需要补材料、有的需要人工介入，最后生成一个完整回复，并在回复中给用户一个明确的下一步指引。

这个项目可以说是 Loop Engineering 的标准演习场。它有多步骤、有分支跳转、有工具调用、有失败重试、有中间状态、有退出条件，而且业务上容错率很低——如果循环出了错，给用户回了错误信息，售后问题会被放大。我们做的时候分了几个版本来迭代，我挑关键部分拆解给你看。

3.2 版本一：定义工单状态机与跳转逻辑

我先定义了一套状态机。这一步是整个项目的地基，后面所有 Prompt 和代码都是围着这套状态机转的。

状态定义如下：

• TICKET_CLASSIFY：工单分类，输出工单类型和关键实体
• ORDER_CHECK：订单核查，需要调用订单系统，获取订单状态、商品信息、支付信息等
• POLICY_MATCH：策略匹配，根据工单类型和订单信息，对售后策略表里的规则
• RESPONSE_GENERATE：回复生成，生成一段有温度、有指引的用户回复
• HUMAN_HANDOFF：人工介入，标记需要人工处理

跳转规则是：TICKET_CLASSIFY 总是起始状态；如果分类不明确或者缺必要信息，跳转到 RESPONSE_GENERATE 生成反问；如果分类明确，跳到 ORDER_CHECK；如果没有对应订单，跳到 HUMAN_HANDOFF；ORDER_CHECK 之后跳到 POLICY_MATCH，策略匹配之后跳到 RESPONSE_GENERATE；HUMAN_HANDOFF 是终态，RESPONSE_GENERATE 也是终态，但 RESPONSE_GENERATE 之后根据用户反馈可能回到 TICKET_CLASSIFY 重新走一轮。

我不把 HUMAN_HANDOFF 后面的流程写成自动的，因为人工介入之后动作不可控，循环就断了。有一点需要特别指出：循环工程里有一条原则，凡是流程边界没有明确定义的地方，后面必然出问题。人工介入之后系统还会不会自动发消息，发了消息又走哪条分支，这些都要提前定义清楚，哪怕你的定义是“人工介入后冻结自动回复”，那也是一种定义。

3.3 版本二：为每个节点编写约束 Prompt

状态机定好之后，我开始为每个状态编写 Prompt。这里有一个心得，每个节点的 Prompt 都要包含三段式：角色定义、任务说明、输出约束。我给 POLICY_MATCH 节点举个例子，这个节点是整个项目里最容易出错的地方。

你是售后策略匹配引擎。你的任务：根据工单信息和订单信息，匹配适合的售后方案。 可选方案： - full_refund：全额退款（仅限未发货订单或质量问题退货） - partial_refund：部分退款（仅限补偿性售后，如运费争议） - replacement：换货（仅限质量问题且订单在质保期内） - repair：维修（仅限质量问题且超出退换期） - return_only：仅退货退款，不换货 - manual_review：无法自动匹配，需人工审核 输出格式：{"solution": "方案名", "reason": "一句话理由", "confidence": 0到1的置信度} 硬性规则： 1. 订单状态为“已发货”时，优先考虑 replacement 或 repair，不得直接给 full_refund。 2. 退款金额涉及支付渠道手续费的，一律转 manual_review。 3. confidence 低于 0.7 时，solution 必须设为 manual_review。 4. 如果你不确定，永远选择 manual_review，不要猜。

这套 Prompt 跑下来，效果比初版好很多。初版的问题是让模型自己“自由发挥”出方案，结果它经常提出一些存在但业务上不成立的组合，比如订单已经发货了还全额退款。把可选方案枚举出来之后，模型的准确率从 62% 提到了 89%，大部分跳转错误其实都是因为模型不知道边界在哪，而不是模型能力不行。给模型的自由越少，它的表现越稳定，这在循环工程里是铁律。

RESPONSE_GENERATE 节点也值得说。这个节点最容易出现的 bug 是模型会用模板语气回复，被用户一眼识破是机器人。我后来在 Prompt 里加了一条：“以资深售后专员的口吻回复，不要使用‘亲爱的用户’开头的模板式语言，直接说明处理结果和下一步操作。如果处理结果是 manual_review，要主动告诉用户会有专员在 24 小时内跟进，不要只丢一句‘已转人工’。”加完之后，用户的回复率降了不少——这里“回复率降低”反而是好事，说明用户不需要再追问“然后呢”，一次就看明白了。

3.4 版本三：Python 实现带状态跟踪的循环主体

代码层面，我写了一个简化版本，但保留了核心逻辑。目标是让你看清“状态跟踪”在代码里是怎么实现的，以及为什么说 Loop Engineering 的难点在状态而不在循环本身。

from dataclasses import dataclass, field from typing import Optional, Dict, Any import json @dataclass class TicketState: current_state: str = "TICKET_CLASSIFY" ticket_type: Optional[str] = None order_info: Optional[Dict[str, Any]] = None solution: Optional[str] = None confidence: Optional[float] = None retry_count: int = 0 max_retries: int = 3 conversation_history: list = field(default_factory=list) def call_llm(prompt: str) -> str: # 实际项目中替换为你的模型调用 # 这里刻意留空，不同模型有不同的调用方式 pass def extract_json(raw: str) -> Optional[Dict[str, Any]]: # 从模型输出中提取 JSON，兼容各种异常格式 try: return json.loads(raw) except json.JSONDecodeError: # 二次尝试：提取被 Markdown 代码块包裹的 JSON try: start = raw.index("{") end = raw.rindex("}") + 1 return json.loads(raw[start:end]) except (ValueError, json.JSONDecodeError): return None def classify_ticket(user_msg: str) -> Dict[str, Any]: prompt = f"""你是工单分类引擎。分析用户消息并输出 JSON： {{ "ticket_type": "return" | "exchange" | "refund" | "repair" | "complaint", "order_ref": "提取到的订单号或空字符串", "issue_desc": "一句话描述用户问题" }} 用户消息：{user_msg}""" raw = call_llm(prompt) result = extract_json(raw) if result is None: return {"ticket_type": "unknown", "order_ref": "", "issue_desc": "解析失败"} return result def check_order(order_ref: str) -> Optional[Dict[str, Any]]: # 模拟调用订单系统 return {"order_status": "shipped", "product": "无线鼠标", "days_since_purchase": 25} def match_policy(ticket_type: str, order_info: Dict[str, Any]) -> Dict[str, Any]: prompt = f"""你是售后策略匹配引擎。根据信息选择方案。 可选方案：full_refund, partial_refund, replacement, repair, return_only, manual_review 工单类型：{ticket_type} 订单信息：{json.dumps(order_info, ensure_ascii=False)} 输出 JSON：{{"solution": "...", "reason": "...", "confidence": 0.0-1.0}} 硬性规则：订单已发货不得直接 full_refund；不确定时必须 manual_review。""" raw = call_llm(prompt) result = extract_json(raw) if result is None or "solution" not in result: return {"solution": "manual_review", "reason": "策略解析失败", "confidence": 0.0} return result def generate_response(state: TicketState) -> str: # 根据当前状态生成最终回复，prompt 略 return "已为您申请换货，请您将商品寄回，我们收到后会在 48 小时内发出新品。" def run_loop(user_msg: str, max_global_rounds: int = 8) -> str: state = TicketState() round_count = 0 while round_count < max_global_rounds: round_count += 1 if state.current_state == "TICKET_CLASSIFY": result = classify_ticket(user_msg) state.ticket_type = result["ticket_type"] if state.ticket_type == "unknown": # 分类失败，直接转人工，不消耗重试次数 state.current_state = "HUMAN_HANDOFF" elif not result["order_ref"]: # 缺订单号，生成反问 state.current_state = "RESPONSE_GENERATE" # 记录一个待补充信息标记 state.conversation_history.append("need_order_ref") else: state.current_state = "ORDER_CHECK" elif state.current_state == "ORDER_CHECK": order_info = check_order(state.order_ref) if order_info is None: # 查不到订单，转人工 state.current_state = "HUMAN_HANDOFF" else: state.order_info = order_info state.current_state = "POLICY_MATCH" elif state.current_state == "POLICY_MATCH": result = match_policy(state.ticket_type, state.order_info) state.solution = result["solution"] state.confidence = result["confidence"] if state.confidence < 0.7: # 置信度不足不硬决策，转人工 state.current_state = "HUMAN_HANDOFF" else: state.current_state = "RESPONSE_GENERATE" elif state.current_state == "RESPONSE_GENERATE": if "need_order_ref" in state.conversation_history: return "请问您的订单号是多少？提供后我可以帮您查询处理进度。" return generate_response(state) elif state.current_state == "HUMAN_HANDOFF": return "您的工单已转人工客服，预计 24 小时内联系您，请留意消息。" else: return "系统状态异常，工单已转人工处理。" # 全局轮数耗尽 return "处理超时，工单已转人工客服跟进。"

这段代码真正在干的事，是两件：第一，把一个多分支的流程拆成了状态之间的跳转，每个状态只做一件事，模型不需要一次性推理到底；第二，在跳转之间维护一个上下文对象 TicketState，让每一步都能访问到前面几步的结论，同时每一步的结论都固化下来，不会被后面的步骤覆盖改掉。

我在代码里特意留了retry_count和max_retries字段，虽然上面的简化代码没有完整使用，但在完整版本里，它们承担了“重试循环”的职责：当extract_json返回 None 时，我会把原始输出和报错信息一起拼进一条修正指令，让模型重新输出一次。这个逻辑不能省略，因为不同模型在输出格式上的稳定性差异非常大。有些模型你告诉它输出 JSON，它 10 次有 9 次老老实实；有些模型你还得写上“绝对不要输出 Markdown 代码块”才能保证干净。重试机制是最后的兜底。

3.5 退出条件设计：最大的坑是“不知道该停”

循环工程里最隐蔽的问题，不是跑错方向，而是跑对了方向却停不下来。我见过一个同事做的数据分析 Agent，模型在循环里反复调用同一个 API，因为它的终止条件是“找到所有异常”，但“所有”这个词在数据场景里根本没有明确的定义，模型永远觉得还有异常没找到，结果烧掉了上千次 API 调用。

退出条件设计要遵循一个原则：可验证性优先。你设计的退出条件必须能被程序在代码层面判断，而不是等模型来“感觉”。比如“用户消息包含感谢、再无新诉求”就不是一个好的退出条件，因为“再无新诉求”需要模型去做语义判断，容易误判。改成“模型输出 finish 标签，并且附带一段结构化原因，代码校验原因字段非空”就是可验证的。

另一个实用的做法是给每一个循环都设置“最大轮数上限”，这个上限要根据业务场景拍脑袋定，但在跑调优实验时，先设一个比较大的值，比如 10，然后在日志里观察正常任务通常在几轮内完成，再往下压，压到正常任务最坏情况的多一轮，留出余量。设太大，会在异常时烧大量 token；设太小，会打断正常的重试流程。

我还习惯在循环里加一个“连续相同动作检测”，如果模型连续两轮做了完全相同的工具调用且参数相同，说明它已经卡住了，此时直接终止循环走人工兜底，比让它无限重试聪明得多。这个逻辑不需要模型参与，纯代码就能判断，非常值得加进所有 Loop 工程里。

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

4.1 高频问题速查表

我把这个项目里踩过的坑和后来带团队时别人踩过的坑汇总成了一张表，你在做自己的 Loop 工程项目时可以直接对着排查。

4.2 三个最实用的排查技巧

排查 Loop 工程问题，第一件事不是看代码，是看日志。你的循环每一步都要埋日志，而且要结构化，记下当前状态、输入摘要、模型输出原文、解析结果、跳转去向、耗时。模型输出原文必须留完整版，不要只留解析后的 JSON，因为很多时候你看着解析后的结果没问题，但输出原文里其实有“警告”或者“备注”之类的内容，会干扰模型的后续判断。这种问题你不看原文永远发现不了。

第二个技巧是做一个微型 trace 可视化工具。不用很复杂，每轮循环用一条文本记录，类似[ROUND 3] STATE=ORDER_CHECK -> POLICY_MATCH | order_status=shipped | policy=replacement，一轮一行，按顺序打印出来。这个工具能在排障时帮你快速定位循环卡在哪一步、跳转是否符合预期。实际调试时，它的价值甚至超过调试器本身。

第三个技巧是关于 Prompt 迭代方式的。我会给每次修改建立一个数据对照：同一组测试用例，在修改前跑一遍记录通过率，修改后再跑一遍对比通过率。不要凭感觉说“这样改好像更稳了”，要用数据说话。Loop Engineering 里的回归问题是常态，你修好 A 问题常常引发 B 问题，没有数据对照的话，你可能根本发现不了 B 问题是什么时候被引入的。

4.3 关于测试数据集的建议

说一句很多教程不会说但极其重要的话：Loop Engineering 项目的质量，很大程度上由测试数据集的质量决定。 单轮问答还能靠人工看几个例子估摸一下质量，多轮循环工程完全不同——同一个问题在循环第 1 轮、第 3 轮、第 5 轮出现，表现可能天差地别。你必须准备一批“带流程标注”的测试用例，每个用例不仅标注输入和期望输出，还要标注中间每一步的期望状态跳转路径。

比如测试用例“用户说‘我要退货’但没给订单号”，期望路径是：TICKET_CLASSIFY → detect missing order_ref → RESPONSE_GENERATE → 输出反问订单号的问题，并且状态停留在等待用户补充信息的状态，而不是直接跳到 HUMAN_HANDOFF 或者擅自把工单关了。这类用例是循环工程测试数据的核心，它们测的不是结果对不对，而是路径对不对。

我还会给测试集分几个层级：第一层是单步正确性测试，只测每个状态单独调模型的输出是否合法；第二层是跳转正确性测试，测状态 A 到状态 B 的跳转是否符合预期；第三层是端到端测试，跑完整循环看最终效果。分层测试的最大好处是，出了问题你能快速定位到具体层，而不是对着整个链路的失败一头雾水。

5. 项目收尾中的另一些心得

5.1 从实战项目中提炼的几条原则框架

做完这个工单助手项目后，我把 Loop Engineering 的实践沉淀成了几条可供复用的原则框架。第一条是“状态外置优于状态内隐”，也就是说，循环走到哪一步了，必须由代码里的状态变量来记录，而不是让模型从对话历史里自己推断。哪怕模型推断能力再强，状态外置都会让系统更可靠、更可控。这一点是硬性的，没有商量余地。

第二条是“每次循环只做一件事”，这是从代码工程的单一职责原则迁移过来的。循环里的每一步如果承担了太多任务，比如既要判断工单类型又要提取信息还要决定回复话术，那模型大概率会在某一个子任务上掉链子，而且你很难定位到底是哪个子任务出了问题。拆得越细，单个步骤的准确率越高，整体链路的可维护性也越强。拆分的粒度大致可以按“一个步骤只产生一个关键输出”来把握，如果一个步骤需要产生两个互不相关的输出，就拆成两个步骤。

第三条是“宁可放弃也不硬撑”，置信度不足的时候，不要逼模型“猜一个最可能的”，而是让它输出 manual_review 之类的兜底标记。这个原则在电商客服这个场景特别重要，宁可把用户转给人工，也不能给一个错误方案让用户白折腾一圈。对用户的信任伤害是成本最高的，远高于人工介入的成本。这个原则放到其他领域也一样成立，无人值守的系统里，安全退出永远比错误执行重要。

5.2 后续可扩展的方向

项目上线稳定运行之后，我又思考过一些后续扩展方向，你可以根据自己的项目情况参考。

一个方向是给循环加“学习能力”，也就是把每一次跑完的路径和结果记录下来，定期做统计分析，看哪些跳转路径频繁出现、哪些状态经常导致终止，然后反过来优化 Prompt 和状态机设计。这本质上是一种基于真实运行数据的持续调优，比拍脑袋调 Prompt 靠谱得多。

另一个方向是引入多模型协作。比如用一个价格低、速度快的小模型做状态分类和简单跳转判断，用能力更强的大模型做策略匹配和回复生成。这样能在保持质量的同时大幅降低成本。但这种拆分对状态设计的要求更高，你需要精确计算出每个状态的处理量和延迟，才能确定分模型的收益是否大于增加通信开销的损失。我是建议先把单模型方案跑通、跑稳了再动这个方向，跳级会给自己挖坑。

还有一个方向是把这套循环做成可视化的流程编排，让非技术人员也能在界面上拖拽状态节点、配 Prompt、设定跳转规则。目前很多团队用代码硬编码状态机，理解门槛高，迭代效率低。如果能把状态设计做成一种可视化的配置工作，整个团队的迭代速度会快一个量级。

5.3 做了这个项目之后，我对“循环工程”这个能力定位的体会

就我个人实际操作下来的体会，Loop Engineering 与其说是一个具体技术，不如说是一种解决问题时的思维习惯。它强迫你在动手写代码之前，先把“模型在这个流程里每一步该干嘛、不该干嘛、怎么停下来、失败了怎么办”这些问题想清楚。很多人做 Agent 项目失败，不是模型能力不够，不是框架选得不好，而是根本没把流程本身当成一个需要认真设计的产品来做。

我在这个项目里踩过最大的坑，就是一开始太迷信“大模型很聪明，你只要给它一个目标它自己会想办法”。这个想法在做 demo 的时候没问题，但一上真实业务就露馅了。真实业务有各种边界、各种规则、各种不可控的用户输入，没有严格的循环工程约束，大模型会把你的业务规则当成参考意见而不是铁律来执行。

把状态机、退出条件、重试机制、兜底方案这四件事做扎实，把测试集分成单步、跳转、端到端三层来持续回归，再配合结构化日志去排查每一次异常，你就能把一个看起来不可控的多轮 Agent 流程做得像传统后端服务一样稳定。当然，稳定到这里还没有终点，每次性能调优之后，我都会拿着日志再从头到尾走一遍完整链路，确认没有引入新的回归。这一套习惯，比任何特定技术都值钱。