当AI说"我需要算一下"时，它到底在想什么？——揭秘ReAct框架中LLM的"计算决策"黑箱，让你彻底搞懂Agent的第二轮思考逻辑

---

目录

1. 决策触发机制——AI什么时候才会"动计算器"
2. 计算类型识别——算术题和逻辑题，AI分得清吗
3. 工具选择逻辑——计算器、Python、还是硬算
4. 参数构造策略——怎么把"人话"翻译成"机器话"
5. 结果预期校准——算完怎么知道对不对
6. 错误回退机制——算错了怎么办

---

嗨，大家好呀，我是你的老朋友精通代码大仙。接下来我们一起学习 《大模型应用开发_动手做AI_Agent》，震撼你的学习轨迹！

---

“脑子是个好东西，但有时候你得知道什么时候该用它，什么时候该用计算器。”

这句糙话，放在咱们程序员身上再贴切不过了。你有没有过这种经历？写代码时遇到一个复杂计算，心里嘀咕"这数我能口算"，结果调试半小时发现是小学数学算错了。或者反过来，明明一个简单的加法，非要写个函数调用，代码臃肿得像裹了三层棉袄。

现在轮到AI Agent了。当我们用ReAct框架做自动定价系统时，大模型面临同样的灵魂拷问：“这个问题，我需要算一下吗？”

这就是第二轮思考的核心——决策逻辑。不是计算本身，而是决定要不要计算、怎么计算、用什么工具计算的那一瞬间。

很多新手学Agent开发，盯着工具调用和结果解析猛啃，却忽略了最关键的决策层。结果呢？Agent要么像个书呆子，遇到啥都"让我算算"，效率低得感人；要么像个莽夫，该算的时候硬推理，输出一堆离谱价格。今天咱们就把这层窗户纸捅破，看看模型到底是怎么"拍脑袋"做决定的。

---

一、决策触发机制——AI什么时候才会"动计算器"

点题

第二轮思考的第一步，是判断当前状态是否需要引入外部计算。这不是简单的"有数字就算"，而是一套复杂的触发条件评估系统。

痛点分析

新手最容易犯的错，是以为只要有数字就要算。看这段典型的错误Prompt设计：

# 错误的触发逻辑
if "价格" in query or "成本" in query or "折扣" in query:
    use_calculator = True

这会导致什么灾难？用户问"你们的价格策略是什么"，Agent哐哐打开计算器，发现没数字可算，当场尬住。或者用户说"这个成本大概三千左右吧"，明明是个模糊估计，Agent非要算个精确值出来。

更隐蔽的坑是心算边界误判。LLM对自信心算的范围没有清晰认知，经常自信满满地算错：

用户：原价199，打8.5折后再减20，最终多少钱？

错误Agent（心算）：199×0.85=169.15，再减20是149.15... 等等，199×0.85真的是169.15吗？
（实际：199×0.85=169.15没错，但LLM经常算成168.15或169.05，小数点漂移是常态）

解决方案/正确做法

正确的触发机制需要三层过滤：

第一层：语义意图识别

不是看有没有数字，而是看数字是否需要被操作：

# 正确的意图分类
def need_calculation(query, context):
    # 模式1：明确要求计算（关键词+疑问词）
    explicit_patterns = ["多少", "等于", "计算", "总价", "合计"]
    
    # 模式2：隐含计算需求（比较、优化、验证）
    implicit_patterns = ["哪个更划算", "最多能省", "最少需要"]
    
    # 模式3：上下文累积（多轮对话后的汇总）
    if context.turns > 2 and has_accumulated_numbers(context):
        return "contextual"
    
    return analyze_intent(query, explicit_patterns, implicit_patterns)

第二层：复杂度评估

给问题打个"难度分"：

def estimate_complexity(numbers, operations):
    score = 0
    # 数字位数
    score += sum(len(str(n).replace('.', '')) for n in numbers) * 0.5
    # 操作复杂度
    op_weights = {'+': 1, '-': 1, '*': 2, '/': 3, '^': 4, 'log': 5}
    score += sum(op_weights.get(op, 2) for op in operations) * 2
    # 步骤数
    score += len(operations) * 3
    
    # 阈值：10以下心算，10-30可选，30以上必须工具
    return "mental" if score < 10 else "optional" if score < 30 else "required"

第三层：置信度自检

让模型自己说"我不太确定"：

系统提示词片段：
"如果你能在3秒内确定计算结果，直接回答；如果有任何犹豫，请使用计算工具。
心算时请默念步骤，检查奇偶性、数量级、末位数字等快速验证方法。"

小结

决策触发的本质是成本权衡——心算的错误成本 vs 工具调用的延迟成本。好的Agent像经验丰富的收银员，扫一眼就知道该口算还是按计算器。

---

二、计算类型识别——算术题和逻辑题，AI分得清吗

点题

触发计算后，模型需要判断算什么。是纯粹的数值运算，还是需要结合业务规则的条件计算？是确定性计算，还是涉及概率的估计？

痛点分析

新手常把所有计算都塞进一个计算器工具，结果惨不忍睹：

# 用户的复杂需求
"我们满300减50，会员额外9折，这个订单怎么算最划算？凑单的话买什么？"

# 错误做法：直接丢给计算器
calculator("300 * 0.9 - 50")  # 完全没理解"凑单优化"的意图

# 结果：算了个寂寞，用户要的是策略，不是数字

另一个经典误区是混淆精确计算和估算。定价系统里，成本核算需要精确到分，但市场预估可能只需要数量级正确。用同一套精度要求处理，要么浪费算力，要么误导决策。

错误案例：
Agent计算竞品价格趋势，调用高精度计算器：
calculate("基于过去30天数据，线性回归预测下月价格 = 123.4567890123元")

实际上：市场波动±20%，小数点后三位毫无意义，反而显得不专业

解决方案/正确做法

建立计算类型标签体系，让模型先做分类：

CALCULATION_TYPES = {
    "ARITHMETIC": {
        "description": "确定性数值运算，有唯一正确答案",
        "examples": ["199 * 0.85", "(成本 + 运费) * 税率"],
        "tool": "calculator",
        "precision": "exact",
        "validation": "reverse_calculation"  # 反向验算
    },
    
    "CONDITIONAL": {
        "description": "基于业务规则的分支计算",
        "examples": ["满减规则叠加", "会员等级折扣"],
        "tool": "rule_engine",
        "precision": "exact",
        "validation": "rule_coverage_check"  # 检查是否遗漏规则
    },
    
    "OPTIMIZATION": {
        "description": "在约束条件下求最优解",
        "examples": ["凑单满减最优组合", "定价利润最大化"],
        "tool": "solver",
        "precision": "optimal",
        "validation": "constraint_satisfaction"  # 验证约束满足
    },
    
    "ESTIMATION": {
        "description": "基于不确定信息的近似推断",
        "examples": ["市场接受价格区间", "销量预测"],
        "tool": "estimator",
        "precision": "interval",
        "validation": "confidence_interval"  # 置信区间评估
    }
}

具体实现时，用Few-shot引导模型分类：

用户：这批货进价5000，想保证30%毛利，定什么价？还要考虑平台抽成5%

思考过程：
1. 识别计算类型：这是CONDITIONAL + ARITHMETIC混合
   - 基础定价：ARITHMETIC (5000 / 0.7)
   - 平台抽成调整：CONDITIONAL (if platform_fee then adjust)
   
2. 选择工具链：
   - 先算基础价：calculator(5000 / (1-0.3))
   - 再算平台调整：rule_engine(apply_platform_fee, base_price, 0.05)
   
3. 预期结果：不是单一数字，而是带条件的定价方案

小结

计算类型识别是问题重构的关键步骤。把用户的"大白话"翻译成机器能处理的计算范式，决定了后续工具选择和结果质量。

---

三、工具选择逻辑——计算器、Python、还是硬算

点题

确定要算、知道算什么之后，轮到选什么工具。ReAct框架里，工具就是Agent的"手"，但手有巧拙，用手术刀切菜和用菜刀做手术都是灾难。

痛点分析

工具选择是新手翻车重灾区。常见症状：

症状一：工具崇拜症

看到Python执行器强大，啥都用它：
"1+1" 也要生成完整Python代码，延迟500ms，杀鸡用牛刀

症状二：工具恐惧症

明明需要复杂计算，硬用基础计算器：
calculator("((199.99 * 1.08 + 15) * 0.95 - 20) / 1.06")

结果：括号嵌套三层，Agent自己写错了都不知道，返回None

症状三：工具错乱症

需要查询历史价格做趋势分析，却用计算器：
calculator("根据去年数据，今年Q2价格趋势")

计算器：??? 这不是数字啊兄弟

解决方案/正确做法

建立工具选择决策树，让模型有据可依：

def select_tool(calculation_type, data_context, constraints):
    # 决策维度1：计算复杂度
    complexity_score = assess_complexity(calculation_type)
    
    # 决策维度2：数据依赖
    data_source = data_context.get("source", "inline")
    data_volume = data_context.get("volume", 0)
    
    # 决策维度3：时效要求
    time_budget = constraints.get("max_latency_ms", 1000)
    
    # 决策矩阵
    if complexity_score <= 2 and data_source == "inline":
        # 简单内联计算：直接用LLM内置能力或轻量eval
        return ToolChoice("inline_calculator", priority="speed")
    
    elif complexity_score <= 5 and data_volume < 1000:
        # 中等复杂度，小数据：Python解释器
        return ToolChoice("python_executor", 
                         sandbox="restricted",
                         timeout=min(time_budget * 0.8, 5000))
    
    elif data_source in ["database", "api"]:
        # 需要外部数据：SQL或专用查询工具
        return ToolChoice("sql_engine" if is_structured_query(data_context) 
                         else "api_client")
    
    elif "optimization" in calculation_type:
        # 优化问题：调用求解器
        return ToolChoice("solver", 
                         algorithm=select_algorithm(constraints))
    
    else:
        # 兜底：人工确认
        return ToolChoice("human_in_the_loop", 
                         reason="uncertain_tool_match")

实际案例对比：

场景：计算"满200减30，满500减100"的最优凑单方案

错误选择：
Tool: calculator
Input: "optimize_purchase(467, [(200,30), (500,100)])"
Result: 计算器不认识"optimize"，报错

正确选择：
Tool: python_executor
Input: 
"""
def optimize_threshold(current, thresholds):
    # 动态规划求解最小支付金额
    ...
print(optimize_threshold(467, [(200,30), (500,100)]))
"""
Result: 建议凑单至500，实付400，比当前方案省67元

小结

工具选择的核心是匹配原则——不是最强的最好，是最合适的最好。就像你不会因为要拧个螺丝就开机加工中心。

---

四、参数构造策略——怎么把"人话"翻译成"机器话"

点题

选对工具后，关键是构造正确的输入参数。这是第二轮思考中最考验"翻译能力"的环节——把自然语言的模糊描述，转化为工具能精确执行的指令。

痛点分析

参数构造的坑，坑坑致命：

坑1：单位混乱

用户："这批货5吨，每吨3000，运费按每公斤0.5算"

错误构造：
weight = 5  # 忘了单位是吨
freight_rate = 0.5  # 直接用了
result = 5 * 3000 + 5 * 0.5  # 运费差了1000倍！

正确构造：
weight_kg = 5 * 1000  # 统一转换为公斤
freight = weight_kg * 0.5
result = 5 * 3000 + freight

坑2：精度丢失

用户："利率3.5%，存10000，一年后本息和"

错误构造：
interest = 10000 * 0.035  # 直接用浮点
result = 10000 + interest  # 可能是10349.9999999

正确构造：
from decimal import Decimal
principal = Decimal('10000')
rate = Decimal('0.035')
result = principal * (1 + rate)  # 精确10350.00

坑3：语义歧义

用户："第二件半价，买三件多少钱"

错误理解A：第二件半价，第三件原价
(100 + 50 + 100) = 250

错误理解B：只有第二件享受优惠
(100 + 50 + 100) = 250  # 巧合相同

正确理解：通常"第二件半价"指每两件中的第二件
即：买三件 = 两件套装(100+50) + 一件原价(100) = 250
或：三件都参与，(100 + 50 + 50) = 200  # 不同商家规则不同！

关键：必须明确规则，不能假设

解决方案/正确做法

建立参数构造的标准流程：

步骤1：信息抽取与标准化

def extract_parameters(query, context):
    # 使用NER识别数值和实体
    entities = ner_extract(query, ["NUMBER", "CURRENCY", "UNIT", "TIME"])
    
    # 单位标准化映射
    unit_map = {
        "吨": ("kg", 1000), "斤": ("kg", 0.5),
        "万": ("", 10000), "k": ("", 1000),
        "个点": ("%", 1), "成": ("%", 10)
    }
    
    # 时间标准化
    time_normalizer = RelativeTimeParser(base_time=context.current_time)
    
    return {
        "raw_values": entities.numbers,
        "normalized": [normalize(e, unit_map) for e in entities],
        "confidence": entities.confidence_scores,
        "ambiguities": flag_ambiguous(entities)  # 标记需要澄清的
    }

步骤2：运算结构构建

def build_expression(values, operations, constraints):
    # 使用AST（抽象语法树）确保结构正确
    ast = {
        "type": "binary_op",
        "op": operations[0],
        "left": values[0],
        "right": {
            "type": "binary_op",
            "op": operations[1],
            "left": values[1],
            "right": values[2]
        } if len(values) > 2 else values[1]
    }
    
    # 添加类型约束
    if constraints.get("currency"):
        ast["precision"] = 2
        ast["rounding"] = "HALF_UP"
    
    # 生成目标代码
    return ast_to_target(ast, target=constraints.tool_type)

步骤3：验证与回显

构造完成后，不直接执行，先给用户确认：

"我理解您的计算需求是：
- 原价：199.00元
- 第一步：打8.5折 → 169.15元
- 第二步：会员减免 → -20.00元
- 最终结果：149.15元

确认无误后执行计算？[Y/n]"

小结

参数构造是精确翻译的艺术。自然语言的模糊性必须通过显式确认和结构化转换来消除，否则"差不多"就会变成"差很多"。

---

五、结果预期校准——算完怎么知道对不对

点题

工具返回结果后，模型不能无脑接受，需要进入结果验证环节。这是第二轮思考的"质检关卡"，防止"Garbage In, Garbage Out"的灾难。

痛点分析

结果验证的缺失，会让错误沉默地传播：

用户：成本80，定价要50%毛利，卖多少？

Agent计算：80 * 1.5 = 120 ✓

但用户实际意思：毛利=利润/售价=50%，即 80 / (1-0.5) = 160

Agent没有验证"50%毛利"的语义，直接按成本加成算，
结果少卖了40块，用户血亏

另一个常见问题是精度幻觉：

计算器返回：149.9999999997

Agent直接展示："价格是149.9999999997元"

用户：？？？你们系统有bug吧

正确做法：识别浮点误差，四舍五入到分位，展示150.00元

解决方案/正确做法

建立多层验证体系：

层1：数学合理性检查

def mathematical_sanity_check(result, inputs, operation):
    checks = []
    
    # 数量级检查
    expected_magnitude = estimate_magnitude(inputs, operation)
    actual_magnitude = math.floor(math.log10(abs(result) + 1e-10))
    if abs(expected_magnitude - actual_magnitude) > 2:
        checks.append(SanityAlert(
            level="ERROR",
            message=f"数量级异常：预期10^{expected_magnitude}，实际10^{actual_magnitude}"
        ))
    
    # 符号检查
    if operation in ["add", "multiply"] and all(i > 0 for i in inputs):
        if result < 0:
            checks.append(SanityAlert("ERROR", "正数运算得负结果"))
    
    # 特殊值检查
    if result in [float('inf'), float('nan'), None]:
        checks.append(SanityAlert("ERROR", "非法数值"))
    
    # 末位验证（乘法）
    if operation == "multiply":
        expected_last_digit = (inputs[0] % 10) * (inputs[1] % 10) % 10
        if int(result) % 10 != expected_last_digit:
            checks.append(SanityAlert("WARN", "末位数字不匹配，可能计算错误"))
    
    return checks

层2：反向验算

def reverse_verification(result, original_inputs, operation):
    """用逆运算验证结果"""
    if operation == "add":
        # a + b = c → c - b = a
        check = result - original_inputs[1]
        expected = original_inputs[0]
    elif operation == "multiply":
        # a * b = c → c / b = a
        check = result / original_inputs[1]
        expected = original_inputs[0]
    # ... 其他运算
    
    # 考虑浮点误差
    if abs(check - expected) < 1e-6 * max(abs(check), abs(expected), 1):
        return VerificationResult(passed=True)
    else:
        return VerificationResult(
            passed=False,
            discrepancy=check - expected,
            suggestion="重新计算或检查输入"
        )

层3：业务规则验证

def business_rule_validation(price, context):
    violations = []
    
    # 价格区间检查
    if price < context.min_allowed_price:
        violations.append(f"低于最低限价{context.min_allowed_price}")
    if price > context.max_allowed_price * 1.5:  # 允许一定上浮
        violations.append(f"显著高于市场均价，建议复核")
    
    # 利润率检查
    margin = (price - context.cost) / price
    if margin < 0:
        violations.append("亏损定价，需特批")
    elif margin > 0.8:
        violations.append("利润率超80%，确认无垄断风险")
    
    # 竞品对比
    if context.competitor_prices:
        percentile = stats.percentileofscore(context.competitor_prices, price)
        if percentile > 95:
            violations.append(f"价格高于{percentile:.0f}%竞品，竞争力存疑")
    
    return violations

层4：置信度评分

def calculate_confidence(result, verification_results):
    base_score = 1.0
    
    # 数学检查扣分
    for alert in verification_results["math"]:
        if alert.level == "ERROR":
            base_score -= 0.4
        elif alert.level == "WARN":
            base_score -= 0.2
    
    # 反向验算扣分
    if not verification_results["reverse"].passed:
        base_score -= 0.3
    
    # 业务规则扣分
    base_score -= len(verification_results["business"]) * 0.1
    
    # 工具可靠性
    base_score *= verification_results["tool_reliability"]
    
    return max(0, min(1, base_score))  # 归一化到[0,1]

小结

结果验证是防御性编程在Agent中的体现。没有验证的计算结果，就像没有测试的代码——能跑，但不敢用。

---

六、错误回退机制——算错了怎么办

点题

即使层层验证，错误仍可能发生。第二轮思考的最后一步，是设计优雅降级策略——当计算失败时，Agent如何保持有用性。

痛点分析

错误处理是最容易被忽略，又最能体现专业度的环节。常见业余表现：

业余Agent：
"计算出错，请稍后再试"  # 用户：？？？我的订单呢？

或者更糟：
"结果是None"  # 直接暴露内部状态

错误场景1：工具超时

定价系统高峰期，Python执行器队列满了，调用超时。
Agent没有备选方案，用户干等30秒后报错。

错误场景2：精度溢出

计算阶乘定价方案，20! 超出计算器范围，返回inf。
Agent直接展示"Infinity元"，成为内部笑话。

错误场景3：规则冲突

同时满足"满200减30"和"会员8折"，但规则写明"优惠不叠加"。
Agent按顺序应用两个优惠，给出不可能的价格。

解决方案/正确做法

设计分级回退策略：

级别1：瞬时错误重试

@retry(
    stop=stop_after_attempt(3),
    wait=wait_exponential(multiplier=1, min=1, max=10),
    retry=retry_if_exception_type((TimeoutError, ConnectionError))
)
def execute_with_retry(tool, params):
    return tool.execute(params)

级别2：工具切换

TOOL_FALLBACK_CHAIN = {
    "python_executor": ["calculator", "formula_lookup", "human_assist"],
    "sql_engine": ["in_memory_cache", "simplified_query", "batch_process"],
    "solver": ["heuristic_estimate", "monte_carlo_sim", "manual_calc_guide"]
}

def fallback_execute(primary_tool, params, error):
    for fallback in TOOL_FALLBACK_CHAIN.get(primary_tool, []):
        try:
            adapted_params = adapt_params(params, fallback)
            result = execute_tool(fallback, adapted_params)
            logger.info(f"Fallback to {fallback} succeeded")
            return result, f"via_{fallback}"  # 标记回退路径
        except Exception as e:
            continue
    
    raise NoFallbackAvailable("所有回退方案失败")

级别3：计算降级

def degrade_gracefully(original_request, failure_reason):
    """当精确计算不可行时，提供有价值的替代输出"""
    
    if "too_complex" in failure_reason:
        # 复杂计算 → 范围估计
        return {
            "type": "estimate",
            "value": {
                "min": heuristic_lower_bound(original_request),
                "max": heuristic_upper_bound(original_request),
                "confidence": "low"
            },
            "note": "精确计算暂时不可用，此为估算范围",
            "action_required": "如需精确值，请提供更多信息或稍后重试"
        }
    
    elif "insufficient_data" in failure_reason:
        # 数据缺失 → 敏感性分析
        return {
            "type": "sensitivity",
            "scenarios": generate_scenarios(original_request),
            "note": "基于假设情景的分析，实际结果可能不同",
            "action_required": "请补充[具体数据项]以获得精确结果"
        }
    
    elif "rule_conflict" in failure_reason:
        # 规则冲突 → 方案对比
        return {
            "type": "alternatives",
            "options": apply_rules_individually(original_request),
            "note": "检测到优惠规则冲突，以下是各方案对比",
            "recommendation": "建议选择方案X（最优惠）或方案Y（最合规）"
        }

级别4：人工接管

def escalate_to_human(context, error_history):
    """准备完整的交接信息"""
    
    handoff_package = {
        "original_query": context.user_query,
        "agent_thinking_trace": context.reasoning_log,
        "attempted_calculations": error_history,
        "current_partial_result": context.best_effort_result,
        "specific_question": generate_clarifying_question(context),
        "suggested_resolution": propose_resolution_paths(context)
    }
    
    return {
        "response": "这个问题需要您的确认...",
        "handoff": handoff_package,
        "estimated_resolution_time": "2分钟内"
    }

实际案例：完整的错误处理流程

场景：用户询问"定制1000件，阶梯报价怎么算"

Round 1: 调用solver求解最优阶梯
→ 超时（高峰期）

Round 2: 回退到heuristic_estimate
→ 基于历史数据给出粗略范围 [8.5-12.3元/件]

Round 3: 主动提供价值
"根据您的数量级，建议分三档：
- 1000件：约10元/件（参考近期类似订单）
- 3000件：约8.5元/件（预估，需确认产能）
- 5000件：需单独询价（超出标准阶梯）

精确报价需要2分钟计算，或您可以直接联系专员..."

结果：用户获得有用信息，系统保持专业形象

小结

错误回退的本质是韧性设计——承认系统不完美，但确保在任何状态下都能提供价值。好的Agent像经验丰富的销售，算不出精确数字时，至少能给个靠谱的范围和下一步建议。

---

写在最后

咱们今天把ReAct框架的第二轮思考扒了个底朝天。从"要不要算"的决策触发，到"算什么"的类型识别，再到"用什么算"的工具选择、"怎么传参"的构造策略，然后是"算得对不对"的结果验证，最后是"算错了怎么办"的错误回退——这六个环节环环相扣，构成了Agent计算决策的完整闭环。

说实话，我刚学Agent开发的时候，也觉得这些"决策逻辑"是虚头巴脑的东西，不如直接上代码实在。但踩过足够多的坑之后才明白：Agent的智能不在工具多强，而在决策多准。一个能正确判断"这个问题不需要算"的Agent，比一个拥有超级计算器但乱算一气的Agent有用得多。

定价系统只是Agent应用的一个缩影。无论是客服机器人、代码助手还是数据分析Agent，这种"元认知"能力——对自己思考过程的监控和调节——都是区分玩具和产品的关键。

编程之路不易，但每一步成长都算数。你今天搞懂的这些决策逻辑，未来会体现在每一个流畅的Agent交互里。保持好奇，持续迭代，你也能做出让人眼前一亮的AI应用。

咱们下回见！

---

关注私信备注：“资料代找获取”，全网计算机学习资料代找：例如:
《课程：2026 年多模态大模型实战训练营》
《课程：AI 大模型工程师系统课程 (22 章完整版 持续更新)》
《课程：AI 大模型系统实战课第四期 (2026 年开课 持续更新)》
《课程：2026 年 AGI 大模型系统课 23 期》
《课程：2026 年 AGI 大模型系统课 21 期》
《课程：AI 大模型实战课 8 期 (2026 年 2 月最新完结版)》
《课程：AI 大模型系统实战课三期》
《课程：AI 大模型系统课程 (2026 年 2 月开课 持续更新)》
《课程：AI 大模型全阶课程 (2025 年 12 月开课 2026 年 6 月结课)》
《课程：AI 大模型工程师全阶课程 (2025 年 10 月开课 2026 年 4 月结课)》
《课程：2026 年最新大模型 Agent 开发系统课 (持续更新)》
《课程：LLM 多模态视觉大模型系统课》
《课程：大模型 AI 应用开发企业级项目实战课 (2026 年 1 月开课)》
《课程：大模型智能体线上速成班 V2.0》
《课程：Java+AI 大模型智能应用开发全阶课》
《课程：Python+AI 大模型实战视频教程》
《书籍：软件工程 3.0: 大模型驱动的研发新范式.pdf》
《课程：人工智能大模型系统课 (2026 年 1 月底完结版)》
《课程：AI 大模型零基础到商业实战全栈课第五期》
《课程：Vue3.5+Electron + 大模型跨平台 AI 桌面聊天应用实战 (2025)》
《课程：AI 大模型实战训练营 从入门到实战轻松上手》
《课程：2026 年 AI 大模型 RAG 与 Agent 智能体项目实战开发课》
《课程：大模型训练营配套补充资料》