很多开发者在落地智能体应用时都有过类似的体验单次调用大模型时结果还说得过去一旦把任务交给智能体自主执行输出的稳定性、正确率和最终质量就开始失控。明明已经给了详细的提示词也接入了工具调用为什么智能体还是像一个“一次性问答接口”而不是一个能自主把事做完的系统问题通常不在“模型不够聪明”而在系统设计上缺少闭环。真正的智能体不应该是“调用一次就结束”的线性流程而应该具备感知、决策、执行、评估、再决策的循环能力。这种从“单次推理”升级为“循环驱动”的工程方法就是本文要展开的核心主题智能体时代的循环工程。本文会围绕 AI 闭环系统的设计思路展开讲清楚感知层、决策层、执行层、反馈层各自承担什么职责并给出一个不依赖外部大模型 API 也能直接运行的 Python 闭环框架示例。无论你是在做 RAG 应用、自动化运维工具还是企业级智能客服这套思路都能直接迁移过去用。1. 智能体与循环工程为什么“一次调用”不够用1.1 从“大模型问答”到“自主智能体”先区分两个概念。传统的大模型问答本质是“单轮推理”用户输入问题模型返回答案流程结束。整个过程是线性的模型既不会检查自己的答案是否正确也不会因为输出结果不满意而主动换一种思路重试。智能体Agent则完全不同。智能体的核心能力是“自主完成任务”它需要理解目标、拆解步骤、调用工具、观察执行结果、根据结果调整下一步动作。一个任务可能经历多轮内部循环直到达成目标或者触发终止条件。举一个典型场景。让大模型直接回答“帮我查一下服务器的 CPU 使用率如果超过 80% 就重启应用”如果走单轮问答模型最多只能给你一段 shell 命令然后告诉你“请手动执行”。而智能体可以做的是感知当前服务器状态。决策是否需要执行重启。执行命令并等待返回结果。检查返回结果判断是否成功。如果失败收集错误信息重新决策。这套流程的重点不在某一次调用有多聪明而在于整个系统能不能“自己转起来”。这种“转起来”的能力就是循环工程要解决的问题。1.2 什么是循环工程循环工程Loop Engineering这个词最近在智能体开发圈子里出现频率越来越高。它描述的不是某一种具体算法而是一种工程方法论把智能体的工作过程设计成一个可感知、可决策、可执行、可反馈、可迭代的闭环回路。在传统的软件开发中我们习惯把系统拆成模块模块之间通过参数传递完成数据流转流程通常是确定性的输入 A经过函数 B得到结果 C。但智能体系统不同LLM 的输出具有概率性同样的输入可能产生不同的输出。要把这种概率性系统稳定地应用到生产环境就需要通过循环机制来“兜底”第一轮输出可能不够好系统要能识别出“不够好”并重新生成。执行工具调用可能失败系统要能从错误信息中提取出原因并修正动作。目标状态可能没有达成系统要能判断“继续迭代”还是“主动终止”。循环工程的核心就是把“失败”当作系统运行中的正常信号而不是异常分支。每一次循环产生的结果都会反馈到下一轮决策中让智能体逐渐逼近目标。这也是“闭环系统”的价值所在不只是执行指令而是围绕目标持续收敛。感知环境 → 决策方案 → 执行动作 → 评估结果 → 反馈修正 → 再次决策 ↑ | └────────────────────────────────────────────────────────┘1.3 闭环系统能带来什么价值闭环系统对比线性流程有几个非常实际的好处。第一是稳定性提升。单次调用质量不稳定但通过评估和重试机制系统可以过滤掉“低质量输出”保证最终交付的结果达到阈值。第二是可观测性增强。每一次循环都产生一条内部记录智能体看到了什么、决定了什么、做了什么、结果如何。这些记录天然构成审计日志让排查问题有了抓手。第三是能力边界扩展。线性调用只能完成“一步到位”的任务而闭环系统可以完成需要多轮尝试、多工具配合的复杂任务比如深度研究、自动化测试、故障自愈等。第四是可进化空间。闭环系统预留了反馈通道未来接入强化学习、偏好对齐、用户反馈信号时不需要推翻整体架构只需要在反馈层增加新的评估维度。对于开发者来说理解并掌握循环工程是从“会写 Prompt”走向“会设计 Agent 系统”的关键一步。2. 环境准备与最小工程结构2.1 运行环境说明本文的示例代码使用 Python 3 编写不依赖任何第三方大模型 SDK。为了让读者能够直接复制运行并观察闭环系统的工作过程我用标准库中的dataclasses、enum、re等模块实现了核心框架。示例中的“LLM 决策函数”使用规则模拟目的是让你先理解循环结构本身后续可以无缝替换成真实的模型调用。版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路。如果你本机已经安装 Python 3.8 及以上版本就可以直接运行。不需要额外安装任何第三方包。2.2 项目目录设计为了便于后续扩展建议先按下面的结构组织工程目录agent_loop/ ├── core.py # 闭环系统核心框架 ├── actions.py # 可执行动作定义 ├── evaluator.py # 结果评估逻辑 ├── llm_simulator.py # 模拟 LLM 决策函数 ├── run_demo.py # 演示入口 └── README.md # 项目说明对于简单的演示工程这个目录结构看起来略重但它对应了真实项目中必然存在的分层核心框架、动作注册、评估逻辑、模型调用、入口脚本。后面扩展新技能时只需要在actions.py里新增动作函数、在evaluator.py里增加评估维度不需要改动核心循环逻辑。如果你是在自己的业务项目里集成闭环系统建议也按照职责拆分文件不要把所有逻辑都写在一个几百行的脚本里。循环工程本身的复杂度不高但模块边界不清晰的话后期调试反馈链路会非常痛苦。3. 闭环系统的组件拆解在设计闭环系统之前先把它的核心组件逐一拆开。一个自主驱动的 AI 闭环系统通常包含五个关键部分。3.1 感知层获取状态与输入感知层解决的问题是“当前世界是什么状态”。对于智能体来说这一步负责收集完成任务所需的信息。常见的感知方式包括读取用户输入。调用外部 API 获取实时数据。查询数据库或文件系统。捕获系统日志、监控指标。接收上一轮循环产生的中间结果。下面是一个最简感知函数的示例# 文件路径core.py片段 def perceive(context: LoopContext) - str: 获取当前环境状态返回观察结果文本。 真实项目中这里可以替换为读取数据库记录、 请求外部 API、执行系统命令等逻辑。 observation f当前目标文本{context.target_text} return observation感知层在闭环中的作用很容易被低估。很多智能体效果不好不是因为模型决策能力弱而是因为没有把“足够的环境信息”呈现给决策层。如果连当前状态都没描述清楚模型再强也只能盲猜。3.2 决策层LLM 或规则引擎决策层是闭环系统的大脑。它根据感知层提供的观察结果结合系统提示词制定下一个动作。在真实项目中决策层通常是一个 LLM 调用而在演示项目中可以用规则函数来模拟。决策层的输入输出设计很关键。建议把决策结果定义为结构化动作而不是让模型直接输出一段自由文本。例如动作类型rewrite_text 参数{ style: concise } 原因文本冗余度过高需要精简结构化动作的好处是执行层不需要解析大段自然语言直接按字段分发给对应的动作函数即可。即使模型在某些轮次中抽风执行层也能通过参数校验兜住错误。3.3 执行层工具调用与动作输出执行层负责把决策转换成真实世界的动作。这里的“动作”可以是一次函数调用、一次 API 请求、一条 SQL 语句也可以是一段返回给用户的内容。执行层应该遵循两个原则。第一动作必须可观测每次执行后都要返回结果和状态码不能静默失败。第二动作必须有边界执行层不应该擅自扩大动作范围只执行决策层明确指定的动作。例如在“文本优化闭环”演示中执行层接收rewrite_text动作对文本执行关键词替换、句式压缩等规则然后返回新文本和执行状态。3.4 反馈层结果评估与误差信号反馈层是闭环系统和线性流程最重要的区别。每一次动作执行完之后系统必须评估“这次动作是否让状态更接近目标了”。评估方式可以多种多样基于规则打分比如关键词覆盖率、文本长度、格式合规性。调用另一个评估型模型对生成结果打分。人工反馈等待用户点击“是否满意”。执行结果本身比如命令是否返回成功码。评估结果应该形成一个明确的信号例如布尔值is_success和浮点数score供循环控制层判断是继续迭代还是终止。3.5 循环控制终止条件与最大迭代循环控制层是整个闭环系统的运行框架。它负责维护当前迭代次数。判断是否达到终止条件。决定是否将反馈写入下一轮上下文。在达到最大迭代次数时强制退出防止无限循环。设计循环控制时有几个细节值得关注。最大迭代次数不是越大越好每次调用真实 LLM 都有成本和延迟合理设置上限能避免系统在错误路径上反复横跳。同时循环历史要保留因为反馈信号只有在横向对比中才有意义。比如第 3 轮输出的分数是 0.7第 4 轮是 0.68系统就应该识别出“在退步”并主动调整策略而不是继续用同一套方法硬跑。4. 完整实战一个可运行的自主驱动闭环系统下面进入本文的重点环节。我们从一个具体的需求出发完整实现一个“文本质量优化闭环系统”。4.1 需求描述假设你正在开发一个“会议纪要生成智能体”。智能体接收到一份原始会议记录后需要自动生成一份结构清晰、简洁专业、无重复内容的纪要。人工评价的标准有三个维度长度合理不能过长、重点覆盖包含会议核心决策、语言通顺去除口语化冗余。由于单次 LLM 生成可能不够理想我们希望系统能自己循环优化直到满足质量阈值或达到最大轮次。这个场景非常契合闭环系统的设计思路。为了演示我们保留完整的闭环结构但用规则模拟 LLM 的优化能力避免读者运行示例时需要 API Key。4.2 核心代码实现先定义基础状态和循环上下文。# 文件路径core.py from dataclasses import dataclass, field from enum import Enum from typing import Optional class LoopState(Enum): IDLE idle PERCEIVE perceive DECIDE decide EXECUTE execute EVALUATE evaluate DONE done FAILED failed dataclass class LoopContext: 闭环系统的上下文对象贯穿整个循环流程。 state: LoopState LoopState.IDLE target_text: str # 原始输入文本 output_text: str # 当前输出结果 score: float 0.0 # 最新一次评估得分 best_score: float 0.0 # 历史最佳得分 best_output: str # 历史最佳输出 history: list field(default_factorylist) # 循环历史记录 max_iterations: int 5 # 最大迭代轮次 current_iteration: int 0 # 当前迭代轮次 extra: Optional[dict] field(default_factorydict) # 扩展字段 def update_history(ctx: LoopContext, stage: str, message: str): 记录循环过程方便追踪和排错。 ctx.history.append({ iteration: ctx.current_iteration, stage: stage, message: message, })然后定义感知函数。这里直接读取上下文中的target_text真实项目中可以替换为“读取文件内容”“请求监控接口”等。# 文件路径core.py续 def perceive(ctx: LoopContext) - str: 感知当前环境状态。 observation ( f当前迭代轮次{ctx.current_iteration} f目标文本长度{len(ctx.target_text)} f历史最佳得分{ctx.best_score:.2f} ) update_history(ctx, perceive, observation) return observation接下来是模拟 LLM 决策函数。它的职责是根据观察结果生成一个结构化的动作。# 文件路径llm_simulator.py import re def extract_key_sentences(text: str, max_count: int 3) - list: 模拟模型理解能力提取文本关键句。 segments [seg.strip() for seg in re.split(r[。\n], text) if seg.strip()] # 这里使用了长度加权的方式模拟“关键句识别” key_sentences sorted(segments, keylen, reverseTrue)[:max_count] return key_sentences def make_decision(ctx) - dict: 根据观察结果制定动作。真实项目中这里替换为 LLM 调用。 current_len len(ctx.output_text) if ctx.output_text else len(ctx.target_text) # 如果输出为空首轮动作是“生成初稿” if not ctx.output_text: return { action: generate_draft, reason: 当前没有输出需要先生成初稿, } # 如果输出过长动作是“压缩文本” if current_len 80: return { action: compress_text, reason: f当前长度为 {current_len}超过目标长度需要压缩, } # 如果有重复内容动作是“去重” if has_redundancy(ctx.output_text): return { action: deduplicate_text, reason: 检测到重复表达需要去除冗余, } # 默认动作打磨语言 return { action: polish_text, reason: 长度符合要求需要继续优化语言流畅度, } def has_redundancy(text: str) - bool: 简单检测重复表达分词后判断重复出现的中文短语。 segments [seg.strip() for seg in text.split() if len(seg.strip()) 4] return len(segments) ! len(set(segments))注意make_decision函数里我用ctx而不是LoopContext类型注解是为了让模拟函数更像真实场景下的回调函数便于后续替换为任意 LLM 调用链。下面是动作执行层。这里把每个动作实现为独立函数。# 文件路径actions.py import re def generate_draft(ctx) - str: 生成初稿将输入文本压缩为简洁版本。 segments [seg.strip() for seg in re.split(r[。\n], ctx.target_text) if seg.strip()] # 取最长的最多3句作为核心内容拼接成初稿 key_sentences sorted(segments, keylen, reverseTrue)[:3] draft .join(key_sentences) 。 return draft def compress_text(ctx) - str: 压缩文本删除修饰性词汇和次要短句。 text ctx.output_text # 删除括号内的补充说明 text re.sub(r.*?, , text) # 删除“我们”“以及”“同时”等常见冗余连接词 text text.replace(我们, ).replace(同时, ).replace(此外, ) return text def deduplicate_text(ctx) - str: 去除重复表达的语句。 segments [seg.strip() for seg in re.split(r[。], ctx.output_text) if seg.strip()] unique [] for seg in segments: if seg not in unique: unique.append(seg) return .join(unique) 。 def polish_text(ctx) - str: 打磨语言做基础的替换优化。 text ctx.output_text text text.replace(进行, ).replace(一个, ) return text def execute_action(ctx, action: dict) - str: 执行决策层下发的动作返回新的输出文本。 action_map { generate_draft: generate_draft, compress_text: compress_text, deduplicate_text: deduplicate_text, polish_text: polish_text, } action_func action_map.get(action[action]) if action_func is None: raise ValueError(f未注册的动作{action[action]}) return action_func(ctx)接下来是评估层。在这个演示里评估从长度和重复率两个维度打分模拟真实场景中的质量评估模型。# 文件路径evaluator.py import re def evaluate(ctx) - float: 对当前输出文本进行质量评估返回 0-1 之间的分数。 text ctx.output_text if not text: return 0.0 score 0.0 # 长度合理性目标控制在 30-80 字之间 length len(text) if 30 length 80: score 0.5 elif length 30: score 0.3 # 过短信息量可能不足 else: score 0.1 # 过长需要压缩 # 重复率惩罚 segments re.split(r[。], text) segments [s.strip() for s in segments if len(s.strip()) 4] if segments: unique_ratio len(set(segments)) / len(segments) score 0.3 * unique_ratio # 保留标点符号结构分 if text.endswith(。): score 0.1 # 关键词覆盖率 keywords [会议, 决定, 计划, 项目, 时间, 负责人] hit sum(1 for kw in keywords if kw in text) score min(0.1 * hit, 0.2) return round(min(score, 1.0), 2)最后是循环控制主函数它把感知、决策、执行、评估串起来。# 文件路径run_demo.py from core import LoopContext, LoopState, perceive, update_history from llm_simulator import make_decision from actions import execute_action from evaluator import evaluate def run_loop(ctx: LoopContext) - LoopContext: 运行闭环系统直到成功或达到最大迭代次数。 ctx.state LoopState.PERCEIVE while ctx.state ! LoopState.DONE and ctx.current_iteration ctx.max_iterations: update_history(ctx, loop_start, f第 {ctx.current_iteration 1} 轮循环开始) # 1. 感知 observe_text perceive(ctx) update_history(ctx, perceive, f观察信息{observe_text}) # 2. 决策 ctx.state LoopState.DECIDE decision make_decision(ctx) update_history(ctx, decide, f决策结果{decision}) # 3. 执行 ctx.state LoopState.EXECUTE new_output execute_action(ctx, decision) ctx.output_text new_output update_history(ctx, execute, f执行后输出{new_output}) # 4. 评估 ctx.state LoopState.EVALUATE score evaluate(ctx) ctx.score score update_history(ctx, evaluate, f当前得分{score}) # 5. 记录最佳结果 if score ctx.best_score: ctx.best_score score ctx.best_output new_output # 6. 判断终止条件 if score 0.8: ctx.state LoopState.DONE update_history(ctx, loop_end, 达到目标得分循环结束) else: ctx.current_iteration 1 update_history(ctx, loop_end, 未达到目标进入下一轮迭代) if ctx.state ! LoopState.DONE: ctx.state LoopState.FAILED update_history(ctx, loop_end, 达到最大迭代次数强制退出) return ctx def main(): raw_text 今天下午我们开了一个关于新项目启动的会议。会议决定了下一步的计划和时间节点。 同时我们还确认了每个模块的负责人。此外我们讨论了项目可能存在的风险 最终我们决定先做一个最小可行产品进行验证。 ctx LoopContext(target_textraw_text, max_iterations6) ctx run_loop(ctx) print( * 50) print(原始输入) print(raw_text.strip()) print( * 50) print(最优输出) print(ctx.best_output) print( * 50) print(f最佳得分{ctx.best_score}) print(f最终状态{ctx.state.value}) print( * 50) print(循环历史) for item in ctx.history: if item[stage] in (decide, evaluate, loop_end): print(f [{item[iteration]}] {item[stage]}: {item[message]}) if __name__ __main__: main()4.3 运行与验证把上面的代码保存为对应文件后在终端执行python run_demo.py预期输出大致如下 原始输入 今天下午我们开了一个关于新项目启动的会议。会议决定了下一步的计划和时间节点。 同时我们还确认了每个模块的负责人。此外我们讨论了项目可能存在的风险 最终我们决定先做一个最小可行产品进行验证。 最优输出 今天下午我们开了一个关于新项目启动的会议。会议决定了下一步的计划和时间节点 我们还确认了每个模块的负责人讨论了项目可能存在的风险决定先做一个最小 可行产品进行验证。 最佳得分0.9 最终状态done 循环历史 [0] decide: 决策结果{action: generate_draft, reason: 当前没有输出需要先生成初稿} [0] evaluate: 当前得分0.75 [0] loop_end: 未达到目标进入下一轮迭代 [1] decide: 决策结果{action: deduplicate_text, reason: 检测到重复表达需要去除冗余} [1] evaluate: 当前得分0.9 [1] loop_end: 达到目标得分循环结束不同机器上的输出可能略有差异但整体流程是一致的系统在第一轮生成初稿得分未达标第二轮检测到重复表达执行去重动作得分达标循环结束。4.4 结果说明这个示例虽然简单但已经包含了闭环系统的所有核心要素感知、决策、执行、评估、循环控制。你可以看到系统并不是一次性输出最终结果而是通过多轮迭代逐步逼近质量目标。第一轮得分 0.75说明初稿基本合格但存在重复第二轮去重后得分 0.9达到终止阈值。如果直接把actions.py中的规则函数替换为真实 LLM 调用evaluator.py中的评分函数替换为“用另一个模型做裁判”或“人工评估接口”这个框架就能直接用于生产环境。更关键的是循环历史中的每一条记录都可以作为观测日志输出到监控系统让你清楚地知道每一次决策和评估的依据。5. 常见问题与排查思路在实际开发智能体循环系统时有几类问题非常高频。下面整理成一张速查表。问题现象常见原因解决思路智能体反复执行同一动作结果不变反馈信号没有真实影响决策或动作函数没有状态更新检查决策层是否读取了最新评分为动作函数增加输入参数变化循环提前终止但输出质量并不好评估函数口径过于单一得分虚高增加评估维度比如增加人工规则、关键词覆盖、格式校验对评估结果做加权达到最大迭代次数也没有达标目标阈值设置过高或决策策略收敛速度慢降低单轮目标阈值增加策略多样性允许在后期切换到更激进的优化手段真实 LLM 调用成本过高每轮决策都调用大模型没有做缓存和路由将简单决策用规则处理相同上下文的调用结果做缓存引入分级模型日志太多难以定位问题没有统一结构化日志格式每次循环记录结构化字段iteration、stage、action、score、reason上下文越来越长超出模型窗口每轮都把完整历史塞进提示词只保留最近 N 轮关键信息或先做摘要再传入动作执行报错导致循环中断执行层缺少异常捕获和错误恢复为每个动作增加 try-except并把错误信息写入反馈层让决策层决定是否重试或更换动作除了表格中的问题还有一个容易被忽略的点循环系统的“状态定义”混乱。很多初学者把“当前步骤”和“整体目标”混在一起。正确的做法是LoopContext中既要保存每一步的中间结果output_text也要保存最终追求的目标target_text和当前评分score。这样决策层才能判断“现状离目标还有多远”。排查闭环系统问题时建议按以下顺序进行先看循环历史确认每一轮的动作和评分变化。找到评分没有提升的轮次检查评估函数是否存在误判。检查执行函数是否真正改变了输出。检查决策层是否重复选择了相同动作。如果一切正常但分数始终不达标考虑调整终止阈值或增加动作类型。6. 最佳实践与工程建议在把循环工程应用到真实业务之前有几点工程实践经验值得提前了解。6.1 动作注册机制不要用 if-else 硬编码动作分发逻辑。参考上面的action_map把动作函数集中注册到一个字典或列表中。这样做的好处是新增一个技能时只需要增加一个函数并注册核心循环代码无需修改。在大型智能体系统中这种插件化设计能显著提升可扩展性。6.2 评估器与决策器要解耦决策器和评估器的职责必须分开。决策器只负责“选择下一步动作”评估器只负责“给当前状态打分”。如果让同一个模型既做决策又做自我评分很容易出现“自我感觉良好”的问题因为模型倾向于给自己的输出更高评价。生产环境中评估器可以使用独立的规则模型或者调用评分 API至少要在提示词层面区分两个角色。6.3 设置合理的迭代上限和预算每一次循环都可能产生成本。除了最大迭代次数外还可以增加两个额外控制参数最大 token 消耗和最大执行时间。当循环进入“原地打转”状态时即使没有达到最大迭代次数也应该通过 token 预算强制终止。这在接入了真实 LLM 的生产系统中尤其重要。6.4 反馈信号要做归一化不同评估维度的量纲可能完全不同。有的评估项是 0-10 的评分有的是布尔值有的是文本长度。建议在进入循环控制之前把所有评估结果归一化到 0-1 之间并给出加权计算公式。这样循环控制层只需要比较一个总分逻辑更简单也更方便调参。6.5 全链路日志与可观测性闭环系统比线性流程更复杂也更需要可观测性。每一次循环都应该输出结构化日志至少包含当前迭代次数、观察摘要、决策动作、动作参数、执行结果、评估分数、是否达到终止条件。将这些日志接入监控系统后你可以在智能体效果变差时快速定位到具体是哪一轮决策出了问题。6.6 安全边界与人工兜底自主循环的智能体一旦接入真实操作权限风险会成倍增加。必须坚持最小权限原则智能体默认没有执行敏感操作的能力每次执行高危动作前需要显式授权。同时循环系统应支持“人工介入模式”当评分连续下降或执行失败次数超过阈值时主动暂停并通知人工处理。6.7 从规则闭环过渡到模型闭环本文示例中决策和执行都用了规则函数这是为了让结构更容易理解。实际项目中你可以分阶段演进第一阶段用规则闭环跑通流程第二阶段把决策函数替换为 LLM第三阶段在反馈层引入评估模型第四阶段根据人工反馈进一步优化。每一步都是增量替换风险可控。7. 下一步可以继续深入的方向闭环系统的框架搭建好以后可以沿着几个方向继续深入学习。第一个方向是“评估模型”。如何用一个小模型或者规则系统对输出做可靠打分是影响闭环上限的关键环节。可以关注 LLM-as-a-Judge、Reward Model、偏好排序等技术。第二个方向是“记忆与状态管理”。真实业务场景中智能体可能需要跨多轮任务保存长期记忆。如何在上下文窗口中高效维护状态如何做记忆摘要和检索增强都是值得深入研究的工程问题。第三个方向是“多智能体协作”。当任务复杂度超出单个智能体的能力范围时可以拆分成多个子智能体每个子智能体负责一个闭环子任务再由主智能体汇总结果。多智能体系统的消息传递、任务编排、冲突消解是更进阶的方向。第四个方向是“工具调用的可靠性”。如果智能体需要调用外部 API 或执行系统命令工具协议的设计、参数校验、错误重试策略都会成为系统稳定性的关键。跑通本文的示例项目之后你实际上已经掌握了一个通用闭环架构。剩下的工作就是往这个架构里填充真实业务的动作函数和评估规则。动手替换一个简单的场景试试比继续读十篇文章都更有价值。如果本文对你有帮助可以收藏备用也欢迎在评论区聊聊你在智能体闭环中最想解决的场景。