1. 项目概述当Agent学会“自我进化”最近在折腾OpenClaw这个开源AI智能体框架时我一直在琢磨一件事我们给Agent喂数据、写技能、调参数本质上还是在“教”它做事。有没有可能让Agent自己学会“学习”甚至能主动发现自己的不足然后像打游戏升级技能一样给自己“加点”呢这个想法听起来有点科幻但结合“自我改进”和“自动技能生成”这两个概念还真能搞出点名堂。我花了些时间给我的OpenClaw装上了一套“学习系统”核心就是让Agent具备Self-Improving自我改进和AutoSkill自动技能生成的能力。简单说就是让Agent从一个需要手把手教的“实习生”变成一个能自己看文档、学新招、总结经验、越用越强的“老司机”。这套系统的价值在于它试图解决AI Agent开发中的一个核心痛点技能固化与场景泛化能力不足。传统的Agent其能力边界在部署时就被预设的技能列表锁死了。遇到稍微超出预设范围的任务它要么直接摆烂说“我不会”要么给出一个漏洞百出的答案。而一个具备自我进化能力的Agent则能通过与环境用户、工具、网络的持续交互主动识别知识盲区生成新的解决方案即技能并验证、优化、固化这些方案形成一个“观察-学习-实践-优化”的正向循环。这对于需要处理开放域、长尾问题的应用场景如智能客服、自动化办公、个性化助手来说意义重大。接下来我就把这套“学习系统”的设计思路、核心模块拆解、具体的实现步骤以及过程中踩过的坑和收获的经验毫无保留地分享出来。无论你是刚接触OpenClaw的新手还是已经在探索Agent高级玩法的开发者相信都能从中获得一些启发。2. 系统核心架构与设计思路给OpenClaw添加自我进化能力不是一个简单的插件而是一套需要深度集成到其运行循环中的子系统。我的设计目标是非侵入、模块化、可观测。即尽量不改动OpenClaw的核心调度逻辑以插件或中间件的形式接入各个功能模块清晰独立便于调试和扩展整个学习过程的关键决策和数据流都有日志记录方便我们人类“导师”进行监督和干预。2.1 整体架构设计整个“学习系统”围绕Agent的一次任务执行周期来构建核心是一个增强版的“感知-思考-行动-学习”循环。传统Agent循环: [感知输入] - [思考/规划] - [执行动作] - [输出结果] 增强版循环: [感知输入] - [思考/规划] - [执行动作] - [评估结果] - [学习与进化] ^ | |_____________________________|这个“评估结果”和“学习与进化”模块就是新加入的系统。具体来说它包含以下几个核心组件技能效果评估器在Agent每次使用技能无论是内置技能还是已学习的技能后自动对执行结果进行多维度评估。评估维度包括任务完成度、输出质量、执行效率、资源消耗等。知识缺口探测器持续分析用户对话历史、任务执行日志和评估结果。当发现Agent反复无法解决某一类问题或用户对某个回答明确表示不满时将其标记为潜在的知识/技能缺口。自动技能生成器这是系统的“魔法核心”。当探测到明确的技能缺口后此模块被激活。它利用大语言模型的代码生成和逻辑推理能力结合问题上下文、可用工具API文档、最佳实践示例等尝试自动编写一个新的Python函数即一个Skill来解决该类问题。技能沙盒验证器新生成的技能代码不能直接投入使用。必须在一个安全的沙盒环境如Docker容器或严格限制的Python子进程中用一组测试用例进行功能和安全性验证。只有通过验证的技能才会被提交给“技能管理器”。技能管理器与版本库负责新技能的注册、元数据管理描述、参数、适用场景、版本控制以及旧技能的迭代更新。它维护着一个动态增长的技能库。反思与优化引擎定期例如每处理100个任务后对技能库进行“复盘”。分析各技能的使用频率、成功率和用户反馈对低效或过时的技能提出优化建议甚至触发技能重构。2.2 关键技术选型与考量要实现上述架构有几个关键的技术选择点评估模型的选择技能效果评估需要模型具备较强的推理和评判能力。我放弃了让Agent“自己评价自己”的做法因为这容易陷入循环论证。我采用的是“轻量级评估模型规则引擎”的组合。对于简单的是非、匹配度判断用规则如关键词匹配、JSON结构校验对于需要理解语义的复杂评估调用一个比Agent本体稍小、但专精于评判的模型例如Qwen2.5-Coder-7B-Instruct。这样在成本和效果间取得了平衡。代码生成模型的选择AutoSkill的核心是代码生成。这部分必须使用顶尖的代码模型。我测试了DeepSeek-Coder-V2、Codestral和Qwen2.5-Coder。最终选择了Qwen2.5-Coder-32B-Instruct如果本地资源充足或Codestral-22B-v0.1追求速度和效率。它们的代码生成质量、对工具调用逻辑的理解能力直接决定了生成技能的可运行率和有效性。沙盒环境安全是第一要务。我选择了Docker容器作为沙盒。每个新技能都在一个全新的、网络受限、文件系统只读除了特定临时目录的容器中运行测试。容器镜像基于最精简的Python环境只包含必要的依赖。这确保了即使生成的代码有恶意行为也不会影响到宿主机和OpenClaw主进程。与OpenClaw的集成方式OpenClaw本身提供了良好的插件机制。我选择以自定义Skill Provider和中间件的形式进行集成。Self-Improving模块主要作为中间件挂在Agent的post_process阶段负责触发评估、探测缺口和启动学习流程。AutoSkill模块则作为一个特殊的、元级别的Skill存在。当系统决定要学习新技能时会创建一个内部任务由这个“元技能”来协调代码生成、沙盒测试和技能注册的全过程。注意这套系统会显著增加单次任务的处理耗时和计算资源消耗。因此我为其设计了异步触发和批处理学习机制。非关键路径的评估和学习任务会被放入队列由后台工作线程处理不影响主对话的响应速度。同时技能缺口会积累到一定数量或达到特定时间窗口才触发一次批量学习以提高资源利用率。3. 核心模块实现细节拆解下面我深入拆解两个最核心的模块技能效果评估器和自动技能生成器分享具体的实现逻辑和代码片段。3.1 技能效果评估器的实现评估器不能只是一个简单的“好/坏”二分类。我设计了一个多级、可配置的评估管道。评估维度设计功能性正确技能的输出是否直接解决了问题例如一个“查询天气”的技能返回的是否是结构化的天气信息。格式合规性输出是否符合预期的格式如JSON、Markdown、纯文本段落。这对于后续技能链式调用至关重要。信息完整性是否包含了所有必要的信息没有关键字段缺失。效率与耗时技能执行时间是否在可接受范围内。用户反馈如有如果对话中能捕获到用户的明确反馈如“不对”、“这不是我想要的”这是一个极强的负向信号。实现代码核心逻辑我创建了一个SkillEvaluator类它结合了规则检查和LLM调用。class SkillEvaluator: def __init__(self, llm_client_for_eval): self.llm_client llm_client_for_eval # 用于复杂评估的轻量级LLM客户端 self.rule_checkers self._load_rule_checkers() # 加载预定义的规则检查器 def evaluate(self, skill_name: str, user_input: str, skill_output: dict, execution_time: float) - EvaluationReport: 评估技能单次执行效果 report EvaluationReport(skill_nameskill_name) # 1. 规则检查 for checker in self.rule_checkers.get(skill_name, []): rule_result checker(skill_output) report.add_rule_result(rule_result) # 2. LLM语义评估异步进行避免阻塞 llm_eval_prompt self._build_eval_prompt(user_input, skill_output) # 这里使用异步调用评估结果会稍后填充到报告中 asyncio.create_task(self._async_llm_evaluation(llm_eval_prompt, report)) # 3. 记录元数据 report.execution_time execution_time report.timestamp datetime.now() return report # 注意此时LLM评估结果可能还未就绪 async def _async_llm_evaluation(self, prompt: str, report: EvaluationReport): 异步调用LLM进行复杂评估 try: response await self.llm_client.chat_completion( messages[{role: system, content: 你是一个严格的任务输出评估助手。}, {role: user, content: prompt}], temperature0.1 # 低温度保证评估稳定性 ) # 解析LLM返回的评估JSON填入report llm_verdict self._parse_llm_response(response) report.llm_verdict llm_verdict # 根据LLM评估结果计算一个综合置信度分数 report.calculate_confidence_score() except Exception as e: logging.warning(fLLM评估失败: {e}) report.llm_eval_failed True def _build_eval_prompt(self, user_input, output) - str: 构建给评估LLM的提示词 prompt_template 请评估以下AI技能的执行结果。 用户原始请求: {user_input} 技能输出: {skill_output} 请从以下维度评估并给出1-5分的评分5为最佳 1. 相关性输出是否直接回应了用户请求 2. 准确性输出中的信息是否准确无误 3. 完整性与有用性输出是否提供了足够有用且完整的信息 4. 清晰度输出是否易于理解 请以JSON格式回复包含维度评分和一段简要的总体评价。 return prompt_template.format(user_inputuser_input, skill_outputjson.dumps(output, ensure_asciiFalse))评估报告的数据结构EvaluationReport对象会汇总所有评估信息并最终产生一个“是否需要学习”的建议信号。这个信号会传递给知识缺口探测器。3.2 自动技能生成器的工作流这是整个系统最有趣也最复杂的部分。当知识缺口探测器确认需要学习新技能时会生成一个“学习任务”描述触发自动技能生成器。工作流步骤任务分析与上下文收集生成器首先会分析“学习任务”收集所有相关上下文包括导致技能缺口的原始用户对话。之前尝试解决但失败的技能执行记录和评估报告。系统中已有的、功能相近的技能代码作为参考。可用的工具和API的文档例如如果涉及网络请求会提供requests库的用法示例如果涉及文件操作会提供os、pathlib的示例。提示词工程这是成败的关键。我设计的提示词不仅要求生成代码还要求生成技能的元数据和测试用例。def build_skill_generation_prompt(learning_task: LearningTask, context: Dict) - str: prompt f 你是一个资深的Python程序员和AI技能设计师。现在需要你为我的AI助手创建一个新的技能。 **学习需求分析** 用户反复遇到这类问题{learning_task.problem_description} 之前的解决尝试失败了原因是{learning_task.failure_analysis} **技能创建要求** 1. 技能功能{learning_task.desired_functionality} 2. 输入参数{learning_task.expected_input} 3. 输出格式{learning_task.expected_output_format} 4. 可用的工具/库{context[available_tools]} 5. 参考的类似技能代码python {context[similar_skill_code]}请严格按照以下结构生成内容第一部分技能实现代码写一个完整的Python函数。函数名应清晰反映其功能如fetch_weather_forecast。必须包含详细的文档字符串docstring说明功能、参数、返回值。代码必须健壮包含必要的错误处理try-excatch。如果涉及外部API调用请使用requests库并处理网络超时和状态码。输出必须与“输出格式”要求严格匹配。第二部分技能元数据以YAML格式提供该技能的注册信息包括name: 技能唯一标识名英文蛇形命名description: 对技能功能的自然语言描述parameters: 参数列表及类型说明output_schema: 输出数据的JSON Schema第三部分单元测试用例提供2-3个针对该技能的Python pytest测试用例覆盖正常情况和边界情况。请开始你的生成将以上三部分用明确的标记分隔开例如[CODE]、[METADATA]、[TESTS]。 return prompt3. **调用代码生成LLM**使用准备好的提示词调用强大的代码生成模型如Qwen2.5-Coder-32B。 4. **解析与结构化输出**解析模型的返回内容按照标记分离出代码、元数据和测试用例。这一步需要较强的文本解析和容错能力因为模型输出可能不严格遵循格式。 5. **代码初步净化**对生成的代码进行简单的安全扫描如检查是否有os.system、eval、__import__等危险函数调用并进行基本的代码风格格式化。 **实操心得**提示词中要求模型同时生成**测试用例**是极其重要的一步。这不仅仅是用于后续验证更重要的是“引导模型的思考过程”。当模型被要求编写测试时它不得不更仔细地考虑函数的边界条件、异常处理和输入输出规范从而显著提高了生成代码的鲁棒性和可用性。这比单纯说“请写出健壮的代码”要有效得多。 ## 4. 沙盒验证与技能集成流程 生成的代码不能直接信任。必须经过严格的“入职培训”——沙盒验证。 ### 4.1 Docker沙盒验证环境搭建 我使用一个轻量级的Python Docker镜像作为基础并在宿主机上通过Docker SDK for Python来动态创建和管理容器。 python import docker import asyncio import tempfile import os class SandboxValidator: def __init__(self): self.client docker.from_env() self.base_image python:3.11-slim # 使用slim镜像减少体积 self.timeout 30 # 技能运行超时时间秒 async def validate_skill(self, skill_code: str, test_code: str, skill_name: str) - ValidationResult: 在Docker容器中验证技能 result ValidationResult(skill_nameskill_name) container None try: # 1. 创建临时目录存放技能代码和测试代码 with tempfile.TemporaryDirectory() as tmpdir: skill_file os.path.join(tmpdir, f{skill_name}.py) test_file os.path.join(tmpdir, ftest_{skill_name}.py) with open(skill_file, w, encodingutf-8) as f: f.write(skill_code) with open(test_file, w, encodingutf-8) as f: # 写入测试代码并确保它会导入我们生成的技能模块 test_wrapper f import sys sys.path.insert(0, /tmp/validation) from {skill_name} import * {test_code} f.write(test_wrapper) # 2. 创建并启动Docker容器 container self.client.containers.run( imageself.base_image, commandfsh -c pip install pytest requests -q /dev/null 21 cd /tmp/validation python -m pytest {test_file} -v, volumes{tmpdir: {bind: /tmp/validation, mode: ro}}, # 只读挂载 network_disabledTrue, # 禁用网络除非技能明确需要需额外白名单 mem_limit100m, # 内存限制 cpu_period100000, cpu_quota50000, # CPU限制 detachTrue, stdoutTrue, stderrTrue ) # 3. 等待执行完成或超时 try: exit_code container.wait(timeoutself.timeout) logs container.logs().decode(utf-8) except Exception as e: container.kill() # 超时则终止容器 result.passed False result.error fValidation timeout: {e} return result # 4. 分析结果 if exit_code[StatusCode] 0: result.passed True result.details logs # 可以从日志中解析出测试覆盖率等信息如果安装了pytest-cov else: result.passed False result.error fTests failed. Exit code: {exit_code}. Logs:\n{logs} except docker.errors.ImageNotFound: # 如果镜像不存在先拉取 print(fImage {self.base_image} not found locally, pulling...) self.client.images.pull(self.base_image) # 重试验证逻辑这里简化实际需更严谨的重试机制 except Exception as e: result.passed False result.error fSandbox validation error: {e} finally: # 5. 清理容器 if container: try: container.remove(forceTrue) except: pass return result4.2 技能注册与动态加载验证通过的技能需要被集成到OpenClaw的Skill系统中。OpenClaw的技能通常是预先加载的我们需要实现动态注册。实现思路技能存储将生成的技能代码、元数据和验证报告存储在一个特定的目录下例如./learned_skills/。每个技能一个子文件夹包含skill.py、metadata.yaml和validation_report.json。技能发现与加载修改或扩展OpenClaw的Skill加载器。我创建了一个DynamicSkillProvider类它继承自OpenClaw的基础Skill Provider。这个类会监听./learned_skills/目录的变化使用watchdog库。热加载当发现有新的技能文件夹或现有技能文件被更新时DynamicSkillProvider会读取metadata.yaml获取技能信息。使用Python的importlib模块动态地将skill.py作为模块加载。将加载的技能函数和元数据注册到OpenClaw的技能注册表中。技能调用此后Agent在规划任务时就能从注册表中看到这个新技能并在合适的场景下调用它。import importlib.util import sys from pathlib import Path from watchdog.observers import Observer from watchdog.events import FileSystemEventHandler class DynamicSkillProvider(BaseSkillProvider, FileSystemEventHandler): def __init__(self, skill_dir: Path): self.skill_dir skill_dir self.skill_dir.mkdir(parentsTrue, exist_okTrue) self.loaded_skills {} # name - (function, metadata) self._load_existing_skills() # 启动文件系统监听 self.observer Observer() self.observer.schedule(self, pathstr(self.skill_dir), recursiveTrue) self.observer.start() def _load_skill_from_path(self, skill_path: Path): 从指定路径动态加载一个技能 skill_name skill_path.stem metadata_path skill_path / metadata.yaml py_path skill_path / skill.py if not py_path.exists(): return # 加载元数据 with open(metadata_path, r) as f: metadata yaml.safe_load(f) # 动态导入Python模块 module_name flearned_skill_{skill_name} spec importlib.util.spec_from_file_location(module_name, py_path) module importlib.util.module_from_spec(spec) sys.modules[module_name] module spec.loader.exec_module(module) # 假设技能函数名与文件名相同或在元数据中指定 function_name metadata.get(function_name, skill_name) skill_function getattr(module, function_name, None) if skill_function and callable(skill_function): self.loaded_skills[skill_name] (skill_function, metadata) # 注册到OpenClaw的核心技能管理器这里需要根据OpenClaw具体API调整 self._register_to_openclaw(skill_name, skill_function, metadata) print(f✅ Dynamically loaded skill: {skill_name}) def on_created(self, event): 监听新技能文件夹创建 if event.is_directory: self._load_skill_from_path(Path(event.src_path)) def get_skill(self, name: str): return self.loaded_skills.get(name) def list_skills(self): return list(self.loaded_skills.keys())注意事项动态加载代码存在安全风险。尽管经过了沙盒验证但在生产环境中仍需考虑额外的安全措施例如对加载的代码进行二次静态分析限制其可访问的系统资源或者在独立的子进程中运行学到的技能。5. 系统部署、调优与实战效果将这套系统与OpenClaw整合并运行起来还需要一些工程上的打磨。5.1 部署架构与资源配置我建议采用以下部署架构以平衡性能、安全性和可维护性主服务运行标准的OpenClaw并加载SelfImprovingMiddleware中间件和DynamicSkillProvider。评估与学习工作队列使用Redis或RabbitMQ作为任务队列。耗时的评估和技能生成任务被封装成消息发送到队列。工作节点一个或多个独立的Worker进程可以使用Celery负责消费队列中的任务。这些Worker需要访问用于评估的轻量级LLM如Qwen2.5-7B。用于技能生成的重量级代码LLM如Qwen2.5-Coder-32B。Docker守护进程用于沙盒验证。共享存储一个网络存储卷如NFS目录或云存储用于存放./learned_skills/目录确保主服务和工作节点都能访问到最新的技能文件。资源配置建议代码生成LLM这是资源消耗大户。如果使用32B模型至少需要60GB以上的GPU内存或使用量化版。可以考虑使用推理API服务如Together AI, Replicate来避免维护大模型的麻烦但需考虑网络延迟和成本。Docker资源需要为每个并发的技能验证任务准备独立的容器资源。要合理配置容器的CPU、内存限制并设置全局的并发数上限防止资源耗尽。5.2 关键参数调优系统的行为由一系列参数控制调优它们对效果影响巨大参数描述建议初始值调优方向EVALUATION_CONFIDENCE_THRESHOLD评估置信度阈值低于此值认为技能执行不佳0.7调高可减少误报但可能错过学习机会调低则更敏感。KNOWLEDGE_GAP_MIN_OCCURRENCES同一类问题出现多少次才触发学习3避免为一次性问题生成技能。可根据问题复杂度调整。SKILL_GENERATION_TIMEOUT生成技能LLM调用的超时时间60秒根据模型速度和复杂度调整。SANDBOX_TEST_TIMEOUT沙盒验证超时时间30秒防止恶意或死循环代码占用资源。MAX_CONCURRENT_LEARNING_TASKS最大并发学习任务数2防止资源争抢尤其是GPU内存。SKILL_USAGE_WEIGHT技能使用频率在技能优化决策中的权重0.4与SUCCESS_RATE_WEIGHT共同决定优化优先级。SUCCESS_RATE_WEIGHT技能成功率在优化决策中的权重0.6成功率低的技能应优先被优化或淘汰。5.3 实战效果与观察我将这套系统接入了一个用于处理内部IT支持问答的OpenClaw Agent。运行一周后观察到了一些有趣的现象技能库的有机增长最初Agent只有十几个基础技能查文档、创建工单等。一周后技能库增加了8个新技能例如parse_error_log从用户粘贴的杂乱错误日志中提取关键错误信息、时间戳和可能的原因。suggest_meeting_time根据参会人的日历忙闲状态模拟智能推荐会议时间。generate_simple_chart根据提供的结构化数据生成描述性文字并建议合适的图表类型。 这些技能都不是我预先编写的而是Agent在交互中“领悟”到需求后自己创建的。技能迭代优化系统自动对两个使用频繁但偶尔出错的技能search_internal_kb和format_json_response提出了优化建议。我审核后同意了优化请求系统生成了改进版的代码经测试后替换了旧版本。“学歪了”的情况出现过一次“假阳性”学习。用户开玩笑地问“怎么让服务器跳舞”Agent在几次尝试失败后竟然生成了一个make_server_dance的技能代码里试图调用一个不存在的“硬件控制API”。这暴露了知识缺口探测器的误判问题。解决方法是在探测器中加入了更严格的意图过滤和常识判断对于明显荒谬或超出系统边界的问题不予触发学习。性能开销在对话量大的时段后台学习任务队列会出现堆积。通过将部分评估任务从LLM改为更精细化的规则引擎并优化Docker容器的启动速度使用预热的容器池有效降低了平均处理延迟。6. 常见问题、排查与未来展望在开发和运行这套系统时我遇到了不少问题这里把典型的几个和解决方法列出来。6.1 常见问题与解决方案问题现象可能原因排查步骤与解决方案新技能生成后Agent从不调用。1. 技能元数据中的description或parameters描述不准确导致规划器无法匹配。2. 技能优先级设置过低。1. 检查生成的metadata.yaml确保描述清晰包含关键动词和名词。用示例查询测试规划器的意图识别。2. 在技能注册时为学到的技能设置一个基础优先级。沙盒验证总是超时失败。1. 生成的代码有死循环。2. Docker容器资源CPU/内存不足。3. 网络依赖的技能在禁用网络的沙盒中运行。1. 在生成提示词中强调“避免无限循环”。2. 增加沙盒容器的资源限制或减少并发数。3. 对于确实需要网络的技能在元数据中标记并使用特殊的、有受限网络访问的沙盒环境进行验证。生成的技能代码语法正确但逻辑错误。代码生成LLM对复杂业务逻辑理解有偏差。1. 在提示词中提供更详细的“上下文”和“失败案例”。2. 引入分步生成先让LLM生成解决思路或伪代码确认后再生成具体代码。3. 增加人工审核环节对于高置信度但高风险的技能暂停自动注册等待人工批准。系统频繁为同一问题生成不同技能导致技能冗余。知识缺口探测器对问题的“聚类”不准确。1. 改进探测器的聚类算法使用更强大的文本嵌入模型如bge-m3来计算问题语义相似度。2. 在新技能生成前先在现有技能库中进行语义搜索确认是否已有类似技能。评估LLM的反馈不稳定同一结果评分波动大。评估提示词不够具体或LLM温度参数过高。1. 细化评估维度提供更明确的评分标准例如什么是“5分”的清晰度。2. 将评估LLM的温度temperature设置为0或接近0的值以提高一致性。3. 考虑使用多个评估LLM进行投票Ensemble。6.2 系统的局限性与未来优化方向目前的系统只是一个强有力的起点还有很长的路要走技能的可解释性与可控性系统生成的技能目前还是一个“黑盒”。未来需要为每个技能附加“生成理由”和“决策逻辑”的可视化让人类管理员能快速理解这个技能为什么被创建、它做了什么。同时需要更精细的权限控制例如禁止学习涉及敏感操作删除、修改核心数据的技能。跨技能组合与规划学习目前的学习是原子化的一次只学一个技能。更高级的进化是让Agent学会技能链或工作流即如何将多个已有技能按顺序组合来解决复杂问题。这需要引入更高级的规划学习和序列建模。从“模仿学习”到“创造学习”当前系统本质上是“模仿学习”基于已有的失败案例和成功模式来生成代码。未来的方向是“创造学习”让Agent能通过阅读文档、探索API主动学习完全陌生的工具和领域甚至能提出全新的问题解决方法。多模态技能学习当前的技能局限于文本和代码处理。随着多模态大模型的发展让Agent学会处理图像生成、语音分析、视频理解等多模态技能将是下一个前沿。给OpenClaw装上“学习系统”的过程让我深刻体会到AI Agent的“自动化”终点并非是预设所有规则而是赋予其“自我进化”的种子。这套Self-Improving AutoSkill的机制就像给Agent装上了发动机和导航仪让它不仅能沿着既定道路行驶还能在遇到断头路时自己摸索着造一座桥过去。虽然这座桥一开始可能不太稳固但通过持续的验证和优化它会越来越可靠。这个过程本身就是智能体迈向真正“自主”的关键一步。如果你也在探索Agent的更多可能性不妨从搭建一个简单的评估循环开始亲眼看看你的Agent是如何一步步“成长”起来的那感觉非常奇妙。