当前位置：首页 > news >正文

Agents 2.0：基于符号学习框架实现LLM智能体的自我进化

news 2026/4/25 18:51:07

1. 项目概述：从静态工具到自我进化的智能体

如果你在过去一年里尝试过基于大语言模型（LLM）构建智能体（Agent），大概率经历过这样的场景：你精心设计了提示词（Prompt），配置了工具（Tools），构建了一个看似完美的任务执行流水线。它在几个测试案例上运行良好，但当你把它放到真实、多变的环境中，面对未曾预料到的用户输入或复杂情况时，它的表现就开始“掉链子”。这时，你不得不手动介入，分析日志，绞尽脑汁地修改提示词或调整流程，然后重新测试。整个过程耗时耗力，且效果难以保证。本质上，我们构建的还是一个“静态”的系统，它的“智能”在部署的那一刻就被冻结了，无法从经验中学习和进化。

这正是aiwaves-cn/agents项目，特别是其最新的 2.0 版本，试图从根本上解决的问题。它不再仅仅是一个构建智能体的工具库，而是引入了一套名为“符号学习”（Symbolic Learning）的系统性框架，旨在让语言智能体具备像神经网络一样的“学习”能力。简单来说，它让智能体能够通过执行任务、评估结果、反向分析错误并自动优化自身配置（如提示词、工具选择、流程结构）来完成自我进化。这个思路非常巧妙，它将我们熟悉的深度学习训练范式（前向传播、损失计算、反向传播、参数更新）映射到了由自然语言和符号逻辑构成的智能体世界。

对于开发者、研究者乃至任何希望构建更健壮、更自适应AI应用的人来说，这个框架打开了一扇新的大门。它意味着我们有可能构建出能够从少量示例或与环境的交互中持续改进的智能体，而无需开发者进行繁琐的手动调优。接下来，我将结合自己的实践，深入拆解这套框架的核心思想、实现细节，并分享在真实场景中应用它时可能遇到的“坑”以及应对技巧。

2. 核心理念拆解：当智能体遇见“反向传播”

要理解 Agents 2.0，必须吃透其核心类比：将智能体流水线视为一个可微分的计算图。这个类比是整套框架的理论基石，理解它，后面的所有设计就都顺理成章了。

2.1 核心映射关系：从神经网络到智能体

在传统深度学习中，我们训练一个模型，本质上是调整其“权重”（Weights），以最小化“损失”（Loss）。Agents 2.0 将这一套完整逻辑移植到了智能体领域，建立了一套精妙的映射关系：

计算图 (Computational Graph) -> 智能体流水线 (Agent Pipeline)：一个神经网络是由层层连接的计算节点（层）组成的图。同样，一个智能体的工作流程也可以被抽象为由多个“节点”按特定顺序连接而成的图。每个节点负责一项子任务，例如“理解用户意图”、“调用搜索工具”、“分析结果”、“生成最终回答”。
网络层 (Layer) -> 流水线节点 (Node)：神经网络中的全连接层、卷积层等，对应智能体流水线中的功能模块。每个节点接收上游的输入（可能是文本、数据结构），进行处理，并产生输出传递给下游。
层权重 (Weights) -> 节点的符号组件 (Symbolic Components)：这是最关键的映射。神经网络层的权重是待优化的连续参数。在智能体节点中，没有连续的数值参数，但其行为由“符号化”的组件决定，主要包括：
- 提示词 (Prompts)：指导LLM在该节点如何思考、行动的指令。
- 工具集 (Tools)：该节点可以调用哪些外部API或函数。
- 节点间的连接逻辑：决定数据流和控制流的规则。这些符号组件，就是智能体版本的“待优化权重”。

2.2 符号学习的工作流程：一次完整的“训练”迭代

基于上述映射，框架实现了一个完整的学习循环，下图清晰地展示了从“前向执行”到“损失计算”、“反向传播”再到“权重更新”的闭环过程：

flowchart TD A[“启动: 给定任务与初始智能体”] --> B[“前向传播<br>智能体执行任务”] B --> C[“轨迹记录<br>存储节点输入/输出/提示/工具使用”] C --> D[“损失计算<br>基于任务结果生成语言损失”] D --> E{“损失评估”} E -- 结果不理想 --> F[“反向传播<br>沿轨迹反向生成语言梯度”] E -- 结果满意 --> G[“完成: 获得优化后的智能体”] F --> H[“权重更新<br>根据语言梯度优化提示/工具/图结构”] H --> B

这个流程具体是如何运作的呢？我们结合一个“旅游规划助手”智能体的例子来一步步看。

步骤一：前向传播与轨迹记录假设我们的智能体流水线有三个节点：1. 需求澄清节点，2. 信息检索节点（调用天气、酒店、景点API），3. 行程整合节点。用户输入“我想下周末去杭州玩”。

前向执行：智能体按顺序执行这三个节点，最终生成一份旅游计划。
轨迹记录：框架会像记录日志一样，完整记录下每个节点的输入（如，节点2的输入是“杭州、下周末、用户偏好休闲”）、输出（如，节点2的输出是“西湖晴转多云，25-30°C；某酒店价格；灵隐寺介绍”）、当时使用的提示词、以及具体调用了哪个工具及其参数。这份完整的“病历本”就是后续分析的依据。

步骤二：语言损失计算训练需要一个“评判标准”。框架通过一个精心设计的“提示词型损失函数”来实现。例如，我们可以定义损失函数为：“评估生成的旅游计划是否涵盖了用户隐含需求（如美食、交通）、信息是否准确、行程是否合理”。这个评估任务本身也是由一个LLM（或一套规则）来执行的，它会输出一段文本化的“诊断报告”，例如：“计划缺少从机场到酒店的交通建议，且午餐推荐距离下午景点太远”。这段文本报告就是“语言损失”。它不是标量，而是富含语义信息的描述。

步骤三：语言梯度反向传播这是框架最精妙的部分。既然有了“损失”（诊断报告），就需要找出问题根源。框架会沿着执行轨迹从后往前进行反向分析。

它首先来到最后一个节点（行程整合），将“语言损失”和该节点的输入输出、提示词一起，交给一个“分析LLM”，询问：“根据最终计划的不足（缺少交通、午餐位置不合理），你认为我这个节点（负责整合信息）的提示词或处理逻辑有什么问题？应该如何改进？” LLM可能会反馈：“你的提示词中未强调‘地理邻近性’和‘交通衔接’的重要性，导致整合时忽略了这些因素。” 这个反馈就是该节点的“语言梯度”。
接着，框架带着这个分析，来到前一个节点（信息检索），问：“由于后续节点需要地理和交通信息，而你提供的信息中缺少这些，你认为你的工具调用策略或信息过滤提示词有什么问题？” 如此层层回溯，直到第一个节点。每个节点都会得到针对其自身“符号权重”（提示词、工具使用策略）的文本化改进建议。

步骤四：符号权重更新收集到所有节点的“语言梯度”（改进建议）后，框架会调用一个“优化器LLM”。这个优化器的提示词任务是：“根据以下对各节点的分析建议，请直接输出一份修改后的、完整的智能体配置（包括所有节点更新后的提示词，以及是否需要增删工具或调整节点连接）。” 于是，我们得到了一份进化后的智能体配置。原来的提示词被润色，可能增加了对“地理距离”的考量；信息检索节点可能被建议新增一个“地图路径规划”工具；甚至流程可能被修改，在整合前增加一个“地理位置校验”节点。

注意：这里的“梯度”和“更新”是符号化和离散的，不同于神经网络中连续的数学运算。它更像是一次基于反思的、有指导的“代码重构”或“文档修订”。其威力在于，这个过程可以自动化、迭代进行。

2.3 多智能体系统的自然支持

框架的设计天生适合多智能体系统（Multi-Agent Systems, MAS）。有两种视角：

节点即智能体：流水线中的每个节点都可以是一个独立的、拥有自己思维链和工具的智能体。那么学习过程就是在优化一个多智能体协作团队的内部工作手册和协作协议。
节点内多智能体协作：一个节点内部可以包含多个智能体进行辩论、投票等交互。学习过程则会优化这个内部协作机制。

这使得该框架不仅能优化单个智能体的能力，更能优化复杂群体智能的协作效率，应用在辩论系统、软件开发团队模拟等场景中潜力巨大。

3. 实战入门：安装、配置与第一个自进化智能体

理论说得再多，不如亲手跑通一个例子。我们以构建一个“文本摘要质量评估与优化器”智能体为例，让它学会通过自我批评来改进自己的摘要提示词。

3.1 环境搭建与核心概念初始化

首先，按照官方推荐的方式进行安装。为了便于后续开发和调试，我建议使用本地开发模式安装：

git clone -b master https://github.com/aiwaves-cn/agents cd agents pip install -e .

接下来，你需要准备一个LLM的API密钥。框架默认支持OpenAI格式的API，也易于扩展其他模型。假设我们使用OpenAI GPT-4，在代码中设置：

import os os.environ['OPENAI_API_KEY'] = 'your-api-key-here'

现在，理解框架中的几个核心对象：

Agent: 代表一个具有推理和执行能力的基本单元。它由role（角色描述）、prompt（核心提示词）和tools（工具列表）定义。
Pipeline: 由多个Agent（或更基础的Node）连接而成的有向无环图（DAG），定义了任务执行的流程。
AgentLearning: 学习的核心控制器，负责组织数据、执行学习循环。

3.2 构建一个可学习的摘要智能体流水线

我们的目标是：一个智能体接收长文本，生成摘要。另一个“评估节点”对摘要质量打分并给出批评。学习框架将利用这些批评来反向优化摘要智能体的提示词。

首先，定义两个节点：

from agents import Agent, Pipeline from agents.learn import AgentLearning # 1. 摘要生成节点 (SummAgent) summarizer = Agent( name="Summarizer", role="你是一个专业的文本摘要助手。", # 初始提示词，比较简陋 prompt="请为以下文本生成一个简洁的摘要：{input}", tools=[], # 本例暂不需要工具 ) # 2. 摘要评估节点 (EvalAgent) evaluator = Agent( name="Evaluator", role="你是一个严格的摘要质量评估员。", prompt="请评估以下摘要的质量。要求：1. 忠实于原文核心事实。2. 简洁无冗余。3. 连贯可读。\n原文：{original_text}\n摘要：{summary}\n请先给出1-5分的评分（5分最佳），然后详细指出摘要的不足之处。", tools=[], )

然后，将它们连接成一个简单的线性流水线。注意，我们需要让评估节点能同时拿到原文和摘要，这里通过配置Pipeline中节点的输入输出映射来实现：

# 构建流水线 pipeline = Pipeline() pipeline.add_node(summarizer, inputs=["global_input"]) # summarizer接收全局输入 pipeline.add_node(evaluator, inputs=["global_input", summarizer.name]) # evaluator接收原文和summarizer的输出 # 定义流水线的入口和出口 pipeline.set_entry_point(summarizer.name) pipeline.set_exit_point(evaluator.name)

这个流水线的工作流是：用户输入长文本 -> Summarizer生成摘要 -> 将原文和摘要一起交给Evaluator -> Evaluator输出评分和批评。

3.3 配置学习循环：定义损失与优化器

现在，我们需要告诉框架如何学习。关键是要定义“语言损失”和“优化策略”。

1. 定义损失函数：损失函数的目标是将评估节点的输出（评分和批评）转化为一个可供反向传播的“语言损失”。我们可以设计一个提示词来实现：

def custom_loss_function(evaluator_output, original_input, **kwargs): """ 将评估员的输出转化为损失描述。 evaluator_output: Evaluator节点的输出文本。 返回一个字典，必须包含 'loss_description' 键。 """ # 这里简化处理：直接从评估员的文本中提取关键批评作为损失。 # 更复杂的实现可以用LLM来提炼。 loss_text = f"摘要评估结果指出：{evaluator_output}" # 假设我们更关心批评部分，可以尝试提取评分低于4分时的内容 if "评分：3" in evaluator_output or "评分：2" in evaluator_output or "评分：1" in evaluator_output: loss_text += " 摘要质量不合格，需要重点改进。" return {"loss_description": loss_text}

2. 配置学习器：创建AgentLearning实例，并绑定我们的流水线、损失函数以及指定需要优化的节点（这里我们只优化Summarizer的提示词）。

learning_controller = AgentLearning( pipeline=pipeline, loss_function=custom_loss_function, # 指定要优化的节点和其可优化组件，'prompt'表示优化其提示词 learnable_components={summarizer.name: ['prompt']}, # 使用框架内置的基于LLM的优化器 optimizer="llm_based", # 配置优化器的提示词，指导它如何根据损失修改提示词 optimizer_config={ "instruction": "你是一个提示词优化专家。根据以下对任务执行结果的批评，请重新撰写'{agent_name}'节点的提示词，以解决指出的问题。直接输出新的提示词，不要包含解释。原提示词：{old_prompt}。批评意见：{loss_description}。新提示词：" } )

3.4 运行学习迭代与效果观察

准备一些训练数据（长文本和期望的摘要，或仅用长文本进行无监督学习）。这里我们用简单示例：

training_data = [ { "input": "人工智能是研究、开发用于模拟、延伸和扩展人的智能的理论、方法、技术及应用系统的一门新的技术科学。该领域的研究包括机器人、语言识别、图像识别、自然语言处理和专家系统等。人工智能从诞生以来，理论和技术日益成熟，应用领域也不断扩大，可以设想，未来人工智能带来的科技产品，将会是人类智慧的‘容器’。人工智能可以对人的意识、思维的信息过程的模拟。人工智能不是人的智能，但能像人那样思考、也可能超过人的智能。", "id": 1 }, # ... 可以添加更多样本 ] # 执行单次学习迭代 for data in training_data[:1]: # 先用一个样本试试 print(f"处理样本: {data['id']}") print("--- 学习前执行结果 ---") # 学习前的执行 original_output = pipeline.run(data["input"]) print(f"评估结果: {original_output}") print("\n--- 开始学习迭代 ---") # 关键步骤：运行学习循环 learning_report = learning_controller.learn_one(data["input"], data) print("\n--- 学习后提示词变化 ---") print(f"Summarizer旧提示词: {summarizer.prompt}") # 学习后，learning_controller内部的pipeline节点的prompt已被更新 # 我们需要重新获取更新后的agent（这里简化展示，实际应从controller中获取更新后的pipeline） updated_summarizer = learning_controller.pipeline.get_node(summarizer.name) print(f"Summarizer新提示词: {updated_summarizer.prompt}") print("\n--- 学习后再次执行 ---") new_output = learning_controller.pipeline.run(data["input"]) print(f"新评估结果: {new_output}")

运行这段代码，你会观察到一次完整的学习过程：

初始的简陋提示词生成一个摘要。
评估节点给出批评（例如：“摘要遗漏了‘人工智能不是人的智能’这一关键辩证观点”）。
损失函数将批评转化为损失描述。
优化器LLM根据损失描述，反思并重写了Summarizer的提示词。新的提示词可能会变成：“请为以下文本生成一个简洁的摘要，需全面涵盖原文核心观点，包括其定义、研究领域、发展前景以及重要的辩证关系（如人工智能与人类智能的区别）。文本：{input}”
用新提示词再次执行，生成的摘要质量应该有所提升。

实操心得：第一次运行时，重点不是看摘要质量提升多少，而是确认整个学习链路是否跑通。查看控制台日志，确认loss_description被正确生成，并且优化器确实输出了新的提示词。优化器的提示词（optimizer_config[‘instruction’]）需要精心设计，它直接决定了“如何优化”。可以命令它“在原有提示词基础上进行最小化修改”，或“专注于解决损失描述中提到的具体问题”。

4. 深入核心：框架源码关键模块解析

要真正掌握并灵活运用 Agents 2.0，甚至进行二次开发，有必要深入其核心模块看看。框架的代码结构比较清晰，主要模块如下：

agents/ ├── agents/ # 核心Agent、Node、Pipeline定义 │ ├── agent.py # Agent类，核心执行单元 │ ├── pipeline.py # Pipeline类，管理节点与流程 │ └── ... ├── learn/ # 学习框架核心 │ ├── learning.py # AgentLearning 主类 │ ├── loss.py # 损失函数基类与内置实现 │ ├── gradient.py # “语言梯度”计算与反向传播逻辑 │ ├── optimizer.py # 优化器基类与LLM优化器实现 │ └── trajectory.py # 轨迹记录与存储 └── ...

4.1 轨迹记录模块：学习的数据基础

trajectory.py定义了Trajectory类，它就像飞机的黑匣子，完整记录了单次任务执行中所有节点的“现场信息”。每个节点的记录包括：

node_id: 节点名称。
input: 该节点的输入数据。
output: 该节点的输出数据。
prompt_used: 执行时实际使用的提示词（可能已被部分优化）。
tool_calls: 调用的工具列表及参数、结果。
metadata: 其他元数据，如时间戳、token消耗。

AgentLearning.learn_one()方法内部会先调用pipeline.run()并自动收集完整的轨迹。这份轨迹是后续所有分析（损失计算、反向传播）的唯一数据源。因此，确保你的流水线中每个节点的输入输出是可序列化、可被清晰记录的，至关重要。

4.2 梯度计算与反向传播：框架的灵魂

gradient.py中的BackPropagator类实现了“语言梯度”的计算。其核心方法是compute_gradients(trajectory, loss_description)。

反向遍历：它从轨迹的最后一个节点开始，向前迭代。
梯度提示工程：对于每个节点，它会构造一个特定的提示词，将以下信息喂给LLM：
- 该节点的原始输入、输出。
- 该节点使用的提示词和工具调用记录。
- 下游梯度：对于非最终节点，这个“梯度”是后一个节点对其的批评分析。对于最终节点，下游梯度就是最终的loss_description。
- 指令：“基于下游的分析/损失，请反思你这个节点的处理过程。你的提示词或工具使用策略存在什么问题？应该如何改进？”
生成节点梯度：LLM返回的文本分析，即为该节点的“语言梯度”。这个梯度不仅包含对提示词的修改建议，也可能包含对工具选择的建议（例如，“你应该调用工具A而不是工具B”）。

这个过程是链式的，逐节点回溯，形成了一条从结果到原因的“反思链”。

4.3 优化器模块：执行更新的“操作手”

optimizer.py定义了Optimizer基类。目前最常用的是LLMOptimizer。它的工作是根据所有节点的“语言梯度”，执行实际的更新操作。

输入：一个字典，键为节点名，值为该节点的“语言梯度”文本。
处理：优化器LLM的提示词任务（即我们之前配置的optimizer_config[‘instruction’]）被触发。它需要综合所有节点的改进建议，输出一份具体的、可执行的更新指令集。框架内置的解析逻辑会将这些指令应用到对应的节点上，例如替换agent.prompt属性，或启用/禁用某些工具。
输出：更新后的智能体配置（在内存中修改了原Pipeline中各个Agent的属性）。

注意事项：优化器LLM的能力直接影响学习效果。如果梯度信息过于模糊或矛盾，优化器可能生成无效甚至破坏性的修改。因此，设计清晰、具体的优化器指令，并可能通过“验证阶段”（用一组验证集检查更新后的性能）来过滤不良更新，是保证学习稳定性的关键。

5. 高级应用与避坑指南

掌握了基础用法和原理后，我们可以探索更复杂的场景，并总结一些实践中必然遇到的“坑”。

5.1 设计有效的“语言损失函数”

损失函数是学习的指挥棒。一个糟糕的损失函数会导致智能体学到错误的东西。设计时需考虑：

对齐最终目标：损失必须精准对应你希望智能体优化的方向。如果你希望摘要“简洁”，损失函数就应惩罚冗长；如果希望“全面”，就应惩罚信息缺失。
可操作性：损失描述应尽可能具体、可指导改进。对比“摘要不好”（太模糊）和“摘要遗漏了第三段中关于安全风险的描述”（具体），后者能产生更有用的梯度。
多维度权衡：有时目标相互冲突（如简洁vs全面）。你可以设计多维度损失，让优化器LLM进行权衡。例如，损失描述可以是：“在保持简洁性（当前得分B+）的同时，需要大幅提升事实完整性（当前得分D）”。
利用外部评估器：损失函数不一定非要另一个LLM。可以集成传统指标（如ROUGE分数用于摘要）、规则系统（代码编译是否通过）、甚至人类反馈（通过简单打分接口）。框架的loss_function接口是开放的，只要返回包含loss_description的字典即可。

5.2 处理复杂流水线与多智能体学习

当你的流水线变得复杂（分支、循环、多智能体）时，学习会面临新挑战：

分支路径：轨迹只记录实际执行过的路径。如果学习样本只覆盖了部分分支，那么未执行分支上的节点将无法得到优化。解决方案：需要设计覆盖关键路径的多样化训练数据。
多智能体协作：当多个智能体在一个节点内交互（如辩论）时，轨迹记录会变得复杂。框架需要能记录内部的对话历史。这时，损失函数和梯度计算需要更高级的设计，例如，评估最终共识的质量，并让每个智能体反思自己在辩论中的贡献是否合理。
学习速率与稳定性：类似于神经网络训练中的学习率，一次更新就完全重写提示词可能“步子太大”。可以设计“保守型”优化器，例如：“请基于以下批评，对原提示词进行最小程度的、针对性的修改，只解决提到的问题。”

5.3 常见问题与排查技巧实录

以下是我在实验中遇到的一些典型问题及解决方法：

问题1：学习循环后，智能体性能没有提升，甚至下降。

排查思路：
1. 检查轨迹记录：首先打印出trajectory，确认每个节点的输入输出是否符合预期。可能某个节点输出格式错误，导致下游节点接收异常输入。
2. 检查损失描述：打印loss_description，看它是否准确捕捉到了失败点。如果损失描述本身模糊或错误，后续所有步骤都是徒劳。
3. 检查梯度质量：打印每个节点反向传播后得到的“语言梯度”。看LLM给出的改进建议是否合理、具体。如果梯度是“需要更好”这样的废话，问题可能出在梯度计算的提示词设计上。
4. 检查优化器输出：打印优化器生成的新提示词。对比旧提示词，看修改是否针对了梯度中提到的问题。有时优化器会“过度发挥”或误解指令。
解决策略：从后往前逐层调试。先确保损失函数正确，再确保梯度计算合理，最后调整优化器指令。可以先用一个非常简单的、目标明确的任务（如“总是输出数字1”）来测试整个学习链路是否基本通畅。

问题2：学习过程消耗大量Token，成本高昂。

排查思路：每次学习迭代，都会进行至少N次LLM调用（N=节点数），用于梯度计算，外加一次优化器调用。复杂流水线成本很高。
解决策略：
- 小样本启动：先用极少量（5-10个）高质量样本进行学习，观察趋势。
- 课程学习：先让智能体学习简单任务，稳定后再增加任务复杂度。
- 离线学习与批量更新：收集一批轨迹和损失后，批量生成梯度并执行一次优化更新，而不是每样本一更新。
- 使用低成本模型：对于梯度计算和优化器，可以尝试使用性能足够但更便宜的模型（如GPT-3.5-Turbo），而前向执行的关键节点用更强模型。

问题3：智能体学会了“作弊”或优化方向偏离。

现象：例如，摘要评估任务中，智能体可能学会在摘要开头加上“这是一份优秀的摘要，涵盖了所有要点...”，以此来“欺骗”评估节点打高分，而实际内容并未改进。
原因：损失函数和评估逻辑存在漏洞，被智能体通过“提示词注入”等方式找到了捷径。
解决策略：
- 设计更健壮的评估：评估节点不应只依赖智能体自己的输出，应结合原始输入进行交叉验证。
- 加入正则化：在优化器指令中强调“保持提示词的一般性和可迁移性，避免针对特定评估模式的过拟合”。
- 使用验证集：在每次更新后，用一个独立的验证集测试性能，只有性能提升才保留更新，否则回滚。

问题4：工具使用策略难以优化。

现象：智能体在需要调用工具时选择错误，或参数传递不对，但梯度计算和优化器似乎难以有效调整工具调用逻辑。
原因：工具调用涉及离散选择（调用哪个工具）和结构化参数，纯文本的“语言梯度”和优化指令对此类问题的表达能力有限。
解决策略：
- 细化工具描述：在工具的description中提供更详细、更场景化的使用说明，这些描述也会被作为“可优化权重”的一部分。
- 提供示例：在节点的提示词中，加入少量工具调用的示例（Few-shot Learning），优化过程可能会修改或增加这些示例。
- 分层学习：先固定工具，优化提示词和流程；待提示词稳定后，再开启对工具选择策略的优化。

Agents 2.0 框架为我们提供了一套强大的方法论和工具，将智能体从静态脚本推向动态自进化的新阶段。它的价值不仅在于自动化调优，更在于提供了一种系统化的“元认知”能力，让AI能够审视并改进自己的工作方式。虽然目前在实际应用中还会遇到稳定性、成本和“对齐”方面的挑战，但这无疑是通向更通用、更强大自主智能体的重要一步。我个人的体会是，开始使用它时，最好从一个定义清晰、范围狭窄的任务开始，耐心地设计和调试损失函数、梯度提示、优化指令这三个核心组件，就像训练神经网络时调整超参数一样。一旦跑通，你会发现，看着智能体自己“琢磨”出更好的工作方法，是一种非常奇妙的体验。

查看全文

http://www.jsqmd.com/news/699321/