AI Agent 如何决策：从 0.1% 胜率翻盘的搜索与评估逻辑

这是一场让我反复回看了很多遍的对局复盘。故障机器人在 A20 进阶难度下面对心魔，血量见底，牌组强度落后，胜率评估已经跌到 0.1% 以下。但 AI Agent 没有投降，它通过一轮又一轮的状态评估、目标拆解和行动搜索，在看似必败的局面上硬生生找到了一条获胜路径。

这个案例里最吸引我的不是“翻盘”，而是 AI Agent 的决策过程：它在极端劣势下如何定义问题、如何分配有限的资源、如何在大量无效行动中筛选出那一步关键操作。这篇文章我会把这次对局背后的 AI Agent 运行逻辑拆开来讲，包括状态建模、评估函数设计、搜索策略、风险决策，以及在实际工程中容易踩的坑。

如果你正在学习 AI Agent 开发，或者想理解 Agent 在复杂局面下是怎么做决策的，这篇文章会比较适合你。我会用完整的 Python 示例演示一个简化版的 Agent 决策核心，并给出可复用的排查思路和工程建议。

1. 从一个“不可能”的对局说起

1.1 A20 碎心对局里发生了什么

先解释几个关键词。故障机器人是游戏中的一名角色，A20 代表最高进阶难度，碎心则表示挑战最终 Boss 心脏。在 A20 难度下，敌人的伤害、行动模式、精英怪分布都会变得非常苛刻，原本在低难度下可以轻松取胜的思路，到这里往往会直接失效。

这次对局的特殊之处在于 AI Agent 接管角色时，局面已经处于极度劣势。血量接近斩杀线，核心输出牌没有抽到，防御资源严重不足，Boss 的血量还有大半。按照常规胜率模型估算，这个局面大概只有 0.1% 的概率能赢。大多数人看到这样的局面会直接选择重开，但 AI Agent 没有放弃，而是开始了一场“艰难蠕动”。

所谓“蠕动”，指的是当前条件下已经没有一步到位的翻盘操作，Agent 只能通过一系列看似微小、短期的生存动作，逐步换取时间和资源，再等待关键牌的到来。这个过程非常考验 Agent 对局面价值的判断能力：哪些资源值得牺牲，哪些行动会带来更大的生存概率。

1.2 为什么用 AI Agent 视角复盘对局

很多人会把这类对局当游戏攻略看，但我的关注点不在“这局怎么赢”，而在“Agent 是怎么想出来能赢的”。

传统的规则脚本在面对固定流程时表现稳定，可一旦局面偏离预设路径，脚本就会出现大量无效分支。AI Agent 不同，它不会死板地执行固定套路，而是会在每个决策点重新评估当前状态，动态选择下一步行动。这正是真实业务中非常需要的能力：在不确定性极高的环境里，依然能做出合理决策。

所以这篇复盘文章，我会把对局当成一个典型的 Agent 决策案例来分析。游戏里的血量、能量、手牌，对应到真实业务中就是系统资源、预算、可选动作。理解 Agent 怎么在这种极端局面上做决策，对你设计自己的智能体系统会有直接帮助。

2. AI Agent 的核心运行逻辑

2.1 感知层：把复杂局面变成结构化数据

AI Agent 的第一步是感知环境。在游戏对局中，Agent 需要读取的信息包括角色当前血量、能量点数、手牌列表、抽牌堆剩余数量、敌人意图、异常状态等。这些信息如果直接作为原始文本输入，模型很难处理，所以要先转换成结构化的状态对象。

感知层的关键不是“拿到所有信息”，而是“拿到决策需要的信息”。在 A20 碎心对局里，Agent 最关心的是几个核心指标：能否在下回合存活、当前能否造成足够伤害、手牌中是否有关键防御牌、行动是否会影响后续抽牌节奏。如果感知层把这些数据全部平等看待，状态空间会变得非常大，决策效率反而下降。

在工程实现中，感知层通常包含数据采集、清洗、特征提取三个步骤。数据采集负责对接环境接口，清洗负责去掉噪声数据，特征提取则把原始数据压缩成决策模型可以使用的向量或对象。这个环节做得越扎实，后续的评估和搜索就越准确。

2.2 决策层：策略、规划与搜索

决策层是 AI Agent 的核心。它接收感知层输出的状态数据，通过策略网络、规则库或搜索算法，计算当前应该执行哪个动作。

在复杂博弈环境中，决策层通常不只是做一个简单的映射，而是会进行一定深度的规划。例如在当前行动之前，先模拟执行某张牌后面的几个回合，评估这条行动路径的长期收益。这种“向前看几步”的能力，是 AI Agent 区别于普通条件判断脚本的重要特征。

规划过程中，Agent 会维护一个搜索树，树的根节点是当前状态，每一层代表一步行动后的可能状态。搜索算法会评估各个节点的价值，逐步扩展有希望的路径。这种方式的代价是计算量很大，所以需要配合剪枝策略和评估函数来控制搜索规模。

2.3 执行层：把决策变成动作并回收反馈

决策完成后，Agent 进入执行层。执行层需要把决策结果翻译成环境可以理解的动作指令，比如“使用某张牌”“结束回合”“跳过某个操作”。

执行之后，环境会返回新的状态和奖励信号。这个反馈非常重要，Agent 会根据反馈更新自己对局面的评估，从而影响下一步决策。在真实业务场景中，执行层还承担着动作验证、异常处理、超时控制等职责，避免 Agent 因为一次错误动作导致整个系统不可用。

感知、决策、执行、反馈，这四步组成了 Agent 的基本闭环。对局复盘的核心，就是观察这个闭环在极端劣势下如何运转：感知没有遗漏关键信息，决策没有陷入局部陷阱，执行没有出现偏差，最后通过多轮反馈逐步修正路径。

3. 极端劣势局面的决策复杂度分析

3.1 状态空间爆炸：为什么不能穷举

在 A20 碎心对局里，单纯枚举所有可能的操作序列是不可行的。故障机器人的牌组通常有二十到三十张牌，手牌有五到十张，每张牌可能有多个目标选择，再加上敌人的行动随机性，状态树会以指数级速度增长。

这就是状态空间爆炸问题。哪怕只看接下来三步，可能的行动组合就已经达到百万量级。如果 Agent 试图遍历所有路径，计算时间会超出对局允许的范围。真实业务系统同样面临这个问题，比如一个推荐 Agent 需要考虑用户行为序列、商品库存、活动规则等多重因素，穷举所有推荐组合在工程上完全不现实。

解决思路是放弃“找到绝对最优解”，转而寻找“在有限预算内足够好的解”。搜索算法通过评估函数筛选出有希望的节点，把计算资源集中在价值更高的路径上，而不是均匀分散到所有可能行动上。

3.2 0.1% 胜率背后代表什么

胜率不是凭空给出的数字，它来自评估函数对当前状态的打分。当 Agent 说“当前胜率只有 0.1%”时，意味着在这个状态下，绝大部分可行路径最终都会导向失败，只有极少数路径可能翻盘。

0.1% 的胜率听起来很低，但它传递了一个重要信息：当前局面并非绝对必败，仍然存在勝利路径。这对 Agent 的决策策略影响很大。如果胜率评估为 0，Agent 的最佳策略可能是尽早结束以减少损失；但只要胜率不是零，Agent 就应该选择能最大化长期胜率的行动，即使短期看起来是在“苟活”。

这也是为什么 Agent 会做出一些看起来很保守的操作。比如在血量很低的时候，它不会急着输出伤害，而是优先使用防御牌、回复牌，尽量拖到关键牌上手。每一步单独看都只是在延续生存，但放在整个路径中，这些“蠕动”是在为未来的翻盘创造窗口。

3.3 “蠕动”策略的本质：局部最优下的生存

蠕动的本质，是在无法直接获胜的条件下，选择一系列局部最优的生存动作，通过这些动作不断改变局面状态，从而降低未来决策的难度。

以对局为例，Agent 发现当前手牌无法造成足够伤害，但有一张能力牌可以在后续回合显著提升输出。此时 Agent 会优先使用防御手段撑过几个回合，直到那张能力牌被抽到并发挥作用。这个过程里，Agent 的每个动作都不是为了立即赢，而是为了“别死”。

理解这一点对设计真实系统很有价值。很多业务场景中，Agent 面临的外部环境不会给你一个完美的解决方案，你只能在约束条件下不断优化。此时，好的 Agent 不应该因为当前方案不完美就放弃，而是应该通过一系列短期策略调整，为更优方案的到来争取时间。

4. 构建一个简化版 AI Agent 决策核心

4.1 项目结构与环境说明

为了把上面的理论落实到代码层面，我们来构建一个简化版的 Agent 决策核心。这个示例不会复刻完整的游戏逻辑，而是聚焦在 AI Agent 最核心的决策机制上：状态建模、行动生成、评估函数、搜索策略。

示例环境使用 Python 3.9+，不需要引入第三方依赖，核心逻辑都用标准库实现。项目结构如下：

agent_core/ ├── state.py # 状态定义与评估 ├── actions.py # 行动生成与模拟 ├── search.py # 搜索策略（简化版 MCTS） ├── agent.py # Agent 主循环 └── main.py # 示例运行入口

这个结构适合刚开始接触 AI Agent 的开发者学习和改造。每份代码文件职责清晰，你可以把游戏相关的内容替换成自己的业务逻辑，搜索策略和评估框架可以复用。

4.2 状态与评估函数设计

先看状态定义。在游戏对局中，Agent 需要关注的字段包括角色剩余生命、护甲值、能量、手牌列表、Boss 剩余血量，以及一个用来记录异常状态或关键 Buff 的字典。

状态类会提供两个核心方法：一个是把对象转换为便于分析的结构化表示，另一个是判断当前是否已经进入终局状态。终局状态包括胜利、失败，以及 Agent 需要强制等待的情况。

# 文件路径：agent_core/state.py from dataclasses import dataclass, field from typing import List, Dict, Optional @dataclass class GameState: """简化版对局状态。""" hp: int block: int energy: int hand_cards: List[str] boss_hp: int buffs: Dict[str, int] = field(default_factory=dict) turn: int = 1 def is_terminal(self) -> bool: """是否已经到达终局状态。""" if self.hp <= 0: return True if self.boss_hp <= 0: return True return False def is_win(self) -> bool: return self.boss_hp <= 0 and self.hp > 0 def is_lose(self) -> bool: return self.hp <= 0 def to_feature(self) -> Dict[str, int]: """把状态转换成结构化特征，便于评估。""" return { "hp": self.hp, "block": self.block, "energy": self.energy, "hand_size": len(self.hand_cards), "boss_hp": self.boss_hp, "turn": self.turn, }

评估函数的作用是给当前状态一个 0 到 1 之间的分数，表示胜率估计。这个函数不需要做到绝对准确，但必须能分辨出不同状态的优劣，否则搜索算法会失去方向。

在极端劣势局面中，评估函数需要重点考虑几个因素：角色能否继续承受下一轮伤害、当前输出是否能在有限回合内击杀 Boss、是否还有可用的回复或防御手段。下面的示例采用加权打分方式，实际项目中你可以换成更复杂的模型。

# 文件路径：agent_core/state.py（继续追加) def estimate_win_rate(state: GameState) -> float: """ 基于规则给出简化的胜率估计。 这里故意保持逻辑透明，方便读者理解评估函数的作用。 实际项目中可以用模型输出替代，但思路相同。 """ if state.is_win(): return 1.0 if state.is_lose(): return 0.0 score = 0.0 # 角色血量越低，分数越低 hp_score = max(0.0, min(1.0, state.hp / 30.0)) score += hp_score * 0.4 # 护甲可以缓冲伤害，有一定加成 block_score = max(0.0, min(1.0, state.block / 20.0)) score += block_score * 0.2 # Boss 血量越低，说明越接近胜利 boss_score = max(0.0, min(1.0, (100.0 - state.boss_hp) / 100.0)) score += boss_score * 0.3 # 手牌数量代表可选项多少 hand_score = max(0.0, min(1.0, len(state.hand_cards) / 8.0)) score += hand_score * 0.1 return max(0.0, min(1.0, score))

这里的权重是人为设定的，你可以根据实际场景调整。重要的是理解设计思路：评估函数必须能够区分“有希望”和“没希望”的状态，这样搜索算法才能把资源投入到正确方向。

4.3 行动生成器

行动生成器负责从当前状态生成所有合法行动。在游戏中，行动包括使用手牌、使用药水、结束回合等。我们把它简化成三类动作：攻击、防御、等待。

每类动作都会改变状态。攻击减少 Boss 血量，防御增加角色护甲，等待则可以让某些 buff 生效。为了演示，这里把动作定义为返回新状态的函数，避免修改原始状态对象。

# 文件路径：agent_core/actions.py from typing import List, Callable, Tuple from state import GameState def attack_action(state: GameState, damage: int = 6) -> GameState: """攻击行动：减少 Boss 血量。""" new_state = GameState( hp=state.hp, block=state.block, energy=state.energy - 1, hand_cards=state.hand_cards[:], boss_hp=state.boss_hp - damage, buffs=state.buffs.copy(), turn=state.turn, ) return new_state def defend_action(state: GameState, armor: int = 5) -> GameState: """防御行动：增加护甲。""" new_state = GameState( hp=state.hp, block=state.block + armor, energy=state.energy - 1, hand_cards=state.hand_cards[:], boss_hp=state.boss_hp, buffs=state.buffs.copy(), turn=state.turn, ) return new_state def wait_action(state: GameState) -> GameState: """等待行动：通常用于让 buff 生效。""" new_state = GameState( hp=state.hp, block=state.block, energy=state.energy, hand_cards=state.hand_cards[:], boss_hp=state.boss_hp, buffs=state.buffs.copy(), turn=state.turn + 1, ) return new_state def generate_actions(state: GameState) -> List[Tuple[str, Callable[[], GameState]]]: """根据当前状态生成可执行动作列表。""" actions = [] if state.energy >= 1: actions.append(("attack", lambda: attack_action(state))) actions.append(("defend", lambda: defend_action(state))) actions.append(("wait", lambda: wait_action(state))) return actions

注意，这里为了简洁，每个动作的执行条件没有完全模拟原版游戏。你在改造时，需要根据自己的业务规则补充动作的合法性判断，比如“没有能量时不能攻击”“手牌中没有攻击牌时不能攻击”等。

4.4 简化版蒙特卡洛树搜索

搜索策略是 Agent 的核心。这里实现一个简化版的蒙特卡洛树搜索（MCTS），它通过多次模拟对局来评估不同动作的价值。

完整版 MCTS 包含选择、扩展、模拟、回溯四个阶段。为了便于阅读，下面给出一个偏模拟型的版本：在有限预算内，从当前状态出发随机执行若干步，直到到达终局或达到模拟深度，然后根据胜负结果更新动作评分。

# 文件路径：agent_core/search.py import random from typing import Dict, List from state import GameState, estimate_win_rate from actions import generate_actions def simulate(state: GameState, max_depth: int = 10) -> bool: """从当前状态随机模拟，返回是否胜利。""" current = state for _ in range(max_depth): if current.is_terminal(): return current.is_win() actions = generate_actions(current) # 优先选择能量足够时评估较高的动作，采用 epsilon 贪心 if random.random() < 0.2: _, action = random.choice(actions) else: best_action = None best_score = -1 for _, action in actions: next_state = action() score = estimate_win_rate(next_state) if score > best_score: best_score = score best_action = action if best_action is None: return False action = best_action current = action() return current.is_win() def mcts_search(state: GameState, iterations: int = 200) -> str: """简化版搜索：多次模拟，统计每个动作的胜率。""" action_scores: Dict[str, List[bool]] = {} for _ in range(iterations): actions = generate_actions(state) action_name, action = random.choice(actions) next_state = action() win = simulate(next_state, max_depth=8) action_scores.setdefault(action_name, []).append(win) # 按平均胜率排序，返回最优动作名 best_action = None best_avg = -1 for action_name, results in action_scores.items(): avg = sum(results) / len(results) if avg > best_avg: best_avg = avg best_action = action_name return best_action or "wait"

这个实现非常精简，实际项目中你会加入 UCB 公式来平衡探索和利用，还会引入动作剪枝、时间预算控制等。但核心思路已经体现出来了：Agent 不是凭感觉做决策，而是通过反复模拟来评估不同动作的长期价值。

4.5 Agent 主循环与决策流程

Agent 主循环负责把感知、决策、执行串起来。每个回合先获取当前状态，然后调用搜索策略选出动作，再执行动作并更新状态。

# 文件路径：agent_core/agent.py from state import GameState, estimate_win_rate from search import mcts_search from actions import generate_actions class Agent: def __init__(self, iterations: int = 200): self.iterations = iterations def decide(self, state: GameState) -> str: """根据当前状态选择动作。""" if state.is_terminal(): return "game_over" action_name = mcts_search(state, iterations=self.iterations) return action_name def run_episode(self, initial_state: GameState): state = initial_state step = 0 while not state.is_terminal() and step < 20: action_name = self.decide(state) actions = dict(generate_actions(state)) if action_name not in actions: action_name = "wait" state = actions[action_name]() print(f"step={step}, action={action_name}, hp={state.hp}, boss_hp={state.boss_hp}") step += 1 return state.is_win()

运行入口可以随机生成一个初始状态，让 Agent 跑完整局：

# 文件路径：agent_core/main.py from state import GameState from agent import Agent def main(): init_state = GameState( hp=18, block=0, energy=3, hand_cards=["攻击", "防御", "防御"], boss_hp=60, buffs={"力量": 2}, turn=1, ) agent = Agent(iterations=300) win = agent.run_episode(init_state) print("win:", win) if __name__ == "__main__": main()

上面的示例体现了一个完整的 Agent 闭环：状态对象承载感知数据，评估函数判断局面好坏，搜索策略选择动作，主循环模拟执行。你可以直接用 Python 运行这段代码，观察 Agent 在不同初始状态下的表现差异。

5. 从“蠕动”到“获胜路径”

5.1 识别真正的获胜条件

在极端劣势下，Agent 第一件要做的事不是盲目反击，而是重新定义“获胜”的条件。表面的获胜条件是 Boss 血量归零，但如果当前角色的输出能力不足，这个条件在短时间内无法满足，Agent 就必须寻找间接路径。

对局中，Agent 识别出两条可能的获胜路径：一条是短时间内凑齐高爆发手牌，另一条是通过特定能力牌叠加 buff，在中后期形成可持续输出。前者需要运气，后者需要时间。Agent 在评估后认为第二条路径更符合当前牌组的构成，于是开始围绕这张能力牌规划后续回合。

这个步骤在真实系统中非常重要。一个业务 Agent 的最终目标可能是“提升转化率”，但在某些状态下，直接提升转化率不现实。此时 Agent 需要识别出中间目标，比如先降低用户流失风险，再寻找转化机会。

5.2 分解子目标并验证可行性

确定获胜条件后，Agent 会把长期目标拆解成一系列短期子目标。拿对局来说，子目标可以拆解为：

• 存活到下回合
• 在 Boss 释放高伤害技能前建立足够护甲
• 抽到关键能力牌
• 能力牌生效后开始叠加输出
• 在角色血量耗尽前击杀 Boss

每个子目标之间有时间依赖关系。Agent 会在搜索中验证这些子目标是否可连续实现。如果某个子目标在当前状态下无论如何都无法达成，Agent 就会回到上层重新选择路径。

这种目标拆解能力是 AI Agent 区别于简单规则系统的重要特征。规则脚本只回答“当前该做什么”，而 Agent 会回答“为了最终目标，现在应该把资源花在哪个中间步骤上”。

5.3 搜索到路径后的执行与验证

当搜索算法返回一条可行路径后，Agent 并不会盲目执行到底。它会在每一步执行后重新评估当前状态，确认实际发展是否与预期一致。

例如 Agent 计划两个回合后抽到关键牌，但实际抽牌结果不理想，此时它会立即调整策略，优先使用防御牌争取更多回合，而不是继续按原计划等待。这个“执行-验证-修正”的循环，保证了 Agent 在随机性较高的环境中也能保持稳定。

在执行阶段，日志记录非常关键。Agent 需要记录每个时间点的状态评估值、动作选择、预期收益和实际结果。这些日志是对局复盘的基础，也是后续优化评估函数和搜索策略的重要依据。

5.4 为什么 AI Agent 能找到人类容易忽略的路线

人类玩家在劣势局容易产生两种情绪：一种是急于翻盘而盲目冒进，另一种是认为必败而提前放弃。AI Agent 没有这两种情绪，它只根据评估函数和搜索结果的数值做决策。

0.1% 胜率的局面，从数值上看赢的概率极低，但搜索算法会告诉 Agent：当前所有可用动作中，哪些动作能让胜率从 0.1% 提升到 0.3%，哪些动作会让胜率归零。Agent 会坚持选择前者，即使提升幅度很小。

这种“不放弃任何微小的概率提升”的决策方式，让 Agent 在不依赖直觉的情况下，逐步把胜率从 0.1% 拉高到 1%、5%、30%，最终找到那条具体的获胜路径。这也是 AI Agent 在复杂决策场景中最有价值的地方。

6. 常见问题与排查思路

AI Agent 在极端劣势局面里工作时，会遇到不少实际问题。这里整理几个常见问题，供你在开发时参考：

排查这类问题的一个通用方法是：先固定随机种子，复现同一局对局，然后逐层打印感知数据、评估分数、动作选择结果。通过对比不同时刻的决策依据，通常能快速定位是状态建模、评估函数还是搜索策略出了问题。

另外，如果 Agent 在调试环境中表现正常，但线上表现变差，要优先检查输入数据的分布是否发生了变化。游戏环境的 Boss 行为、真实业务中的用户行为，都可能导致评估函数失效。

7. 最佳实践与工程建议

7.1 评估函数是决策质量的天花板

搜索算法再强，如果评估函数给出的分数是错乱的，最终决策一定不会好。评估函数代表了 Agent 对“什么局面更好”的理解，因此它的设计质量直接决定了决策质量的上限。

建议从简单规则开始迭代，先用少量特征建立基线版本，再用对局日志分析哪些特征与胜负结果相关性更强，逐步加入新特征。尽量避免一开始就引入大量参数，否则很难定位问题。

7.2 给搜索预算设置边界

搜索算法虽然能提升决策质量，但也有计算成本。实际项目中，Agent 往往需要在几十毫秒内做出响应，不可能做几万次模拟。因此必须设置明确的搜索预算，比如最大模拟次数、最大搜索深度、最大耗时。

当预算不足时，Agent 应该能退回到一个快速策略，保证系统基本可用。这个兜底策略可以是一个简单的规则函数，也可以是一个训练好的轻量模型。

7.3 日志与复盘：打造 Agent 的“黑匣子”

AI Agent 的决策过程如果不记录，出问题时很难定位。建议在每个决策点输出结构化日志，包括当前状态的简化特征、动作候选列表、每个动作的评价值、最终选择的动作，以及执行后的实际结果。

这样做可以在对局结束后完整复盘 Agent 的整个决策过程，找到是哪个环节出现了评估偏差。这套日志体系放在真实业务中，也是审计和合规的基础，能让系统的决策行为可解释、可追溯。

7.4 保持系统的随机性与稳定性平衡

Agent 需要一定的随机性来探索新策略，但随机性过强会导致行为不可控。建议在探索阶段引入随机动作选择，在后续阶段逐步降低探索概率，让 Agent 趋于稳定。

对局中，Agent 在前期会尝试多种防御组合，以寻找更优的 buff 叠加顺序；到了后期，当胜率明显提升后，它会更倾向于按照已验证有效的路径执行。这种“前期探索、后期利用”的策略，在真实推荐系统、自动化运维、交易决策中同样适用。

7.5 从游戏 Agent 到业务 Agent 的迁移思路

游戏对局中的状态建模、评估函数、搜索策略，本质上和业务 Agent 是相通的。你可以把“血量”理解为系统剩余资源，把“手牌”理解为当前可选工具，把“Boss 血量”理解为业务目标的完成进度，把“Buff”理解为临时权限或加速条件。

迁移时最关键的是重新设计状态特征和评估函数，而不是直接复用游戏代码。先把业务目标量化，再确定影响目标的关键变量，最后建立状态到分数的映射关系。这个思路适用于从电商导购到运维诊断的各类 AI Agent 场景。

8. 总结与下一步学习路线

这场 A20 碎心对局，真正打动我的不是最终翻盘的结果，而是 Agent 在 0.1% 胜率下依然没有停止评估和搜索。它通过不断的“蠕动”积累优势，用一次次局部最优选择拼接出一条完整的获胜路径。这种决策方式放在工程实践中，对应的正是目标拆解、状态评估、预算控制和执行验证这几个核心模块。

如果你希望继续深入，可以从以下几个方向展开：

• 学习完整的蒙特卡洛树搜索实现，理解 UCB 公式和反向传播的作用。
• 尝试把评估函数替换成简单的神经网络模型，观察模型对搜索质量的影响。
• 在示例代码中接入更真实的业务场景，比如库存优化、客服对话策略选择。
• 研究 AlphaGo 和 AlphaZero 这类系统，看它们如何把搜索和深度模型结合。

代码仓库可以在你自己的本地环境中直接运行和修改。改一改评估函数的权重，或者调整搜索迭代次数，你会直观地感受到 Agent 的决策风格发生变化。这种动手验证的习惯，比只读概念收获大得多。