1. 项目概述：当AI智能体开始玩“猜词游戏”

最近，我花了些时间捣鼓了一个挺有意思的项目，我把它叫做“AI智能体的Wordle”。如果你玩过Wordle，肯定知道那种每天猜一个五个字母单词的乐趣——有限次数的尝试、基于颜色反馈的逻辑推理。但这次，我想把这个经典的文字游戏，从一个人类玩家的智力挑战，变成一个AI智能体之间相互博弈、学习和推理的竞技场。简单来说，我构建了一个平台，让AI智能体（比如基于GPT、Claude等大语言模型构建的自动化程序）来扮演“玩家”，它们需要根据游戏规则，自主地生成猜测、解析反馈、调整策略，最终猜出目标单词。

这听起来可能像是一个简单的API调用，但实际做起来，你会发现其中充满了关于智能体架构、推理链设计、成本控制和性能评估的深度思考。它不再是一个简单的“调用模型API猜单词”的脚本，而是一个观察和测试AI智能体在结构化、有约束环境中如何“思考”和“行动”的绝佳沙盒。对于从事AI应用开发、智能体研究，或者单纯对“让AI玩游戏”感兴趣的朋友来说，这个项目能帮你理清很多实操中的关键问题。

2. 核心设计思路：从人类游戏到智能体竞技场的转变

2.1 Wordle游戏规则的机器可理解化

Wordle的人类规则很简单：六次机会猜一个五个字母的单词。每次猜测后，每个字母会得到三种颜色反馈之一：绿色（字母正确且位置正确）、黄色（字母正确但位置错误）、灰色（字母不在单词中）。

要让AI智能体玩这个游戏，第一步是将这套规则转化为机器可精确理解和执行的逻辑。这不仅仅是提供一个API接口那么简单。我们需要定义一个清晰的“游戏状态”对象，它至少包含：

• 目标单词 ：当然是保密的，由游戏服务器持有。
• 历史猜测记录 ：一个数组，记录每次猜测的单词和对应的反馈结果。
• 剩余尝试次数 ：从6开始递减。
• 字母状态表 ：一个动态更新的数据结构，记录每个字母（A-Z）当前已知的“可能状态”。例如，字母‘E’可能被标记为“已确认存在于单词中，但位置未知（黄色）”或“已确认不存在于单词中（灰色）”，甚至“已确认在特定位置（绿色）”。智能体需要基于这个状态表进行推理。

注意：这里的一个关键设计决策是，我们提供给智能体的“反馈”，是经过解析的结构化数据，而不是简单的“绿黄灰”颜色字符串。例如，反馈可能是一个数组： [ {letter: ‘C’, status: ‘absent’}, {letter: ‘R’, status: ‘present’}, {letter: ‘A’, status: ‘correct’}, … ] 。这降低了智能体解析自然语言描述的负担，让它更专注于策略推理。

2.2 智能体的核心能力定义

一个能玩Wordle的AI智能体，需要具备以下几种核心能力，这直接决定了我们如何设计它的架构：

1. 单词生成与验证能力 ：给定当前的游戏状态（历史反馈、字母约束），智能体必须能生成一个符合所有已知约束的、有效的五个字母英文单词作为猜测。这需要它拥有或能访问一个单词词典，并具备基础的逻辑过滤能力。
2. 反馈解析与状态更新能力 ：收到服务器返回的结构化反馈后，智能体能据此更新其内部的“字母状态表”和“单词可能性空间”。
3. 策略决策能力 ：这是智能体的“大脑”。它决定在每次猜测时采用什么策略。是优先使用高频字母进行试探（信息最大化策略）？还是根据当前可能性空间，随机选择一个符合条件的单词？或者是更复杂的、基于概率模型的决策？
4. 记忆与学习能力（可选但重要） ：智能体能否从多次游戏（无论是同一局还是多局）中学习？例如，它能否记住某些字母组合的常见性，从而优化其初始猜测？这涉及到智能体是否具有“长期记忆”或“经验库”。

在我的实现中，我将这些能力模块化，构建了一个典型的“规划-执行-观察”循环的智能体架构。智能体内部有一个“推理引擎”（通常由大语言模型驱动）和一个“工具集”（包含单词查询、规则检查等函数）。

3. 智能体架构的深度拆解与实现

3.1 基础架构：基于LLM的规划器与工具调用

我选择了当前最主流也最灵活的架构：以大语言模型作为智能体的“中央处理器”或“规划器”。这个规划器不直接生成单词，而是生成“下一步该做什么”的规划，并调用相应的工具来完成任务。

一个典型的交互循环如下：

1. 状态感知 ：智能体接收到当前的游戏状态（JSON格式）。
2. 规划生成 ：LLM规划器分析状态，决定行动。例如，它可能输出：“当前是第一次猜测，没有任何信息。我应该选择一个包含常见元音和辅音的单词来最大化信息获取。我将调用 generate_candidate_words 工具，传入约束条件‘无’，并请求返回前5个高频单词供我选择。”
3. 工具执行 ：智能体框架解析规划，调用 generate_candidate_words 工具。这个工具可能访问一个本地词频列表，返回 [‘AROSE’, ‘IRATE’, ‘SOARE’, ‘ALERT’, ‘SAINT’]。
4. 决策与行动 ：LLM规划器收到工具返回的结果，做出最终决策：“我将选择‘AROSE’作为第一次猜测，因为它包含了A, E, O, S, R这些极高频的字母。” 然后，它调用 submit_guess 工具，提交单词“AROSE”。
5. 观察与更新 ：收到游戏反馈后， update_knowledge_base 工具被调用来更新字母状态表。然后循环回到第1步。

这种架构的优势在于非常灵活，LLM的强大推理能力可以用来处理复杂的、非预设的策略。但缺点也很明显：延迟高、成本高（每次循环都需要调用LLM API），且稳定性受LLM输出格式的影响。

3.2 优化架构：规则引擎与LLM协同的混合模式

为了克服纯LLM架构的缺点，我引入了“规则引擎”作为协同处理器。核心思想是：将可以确定化的逻辑交给规则引擎，LLM只处理需要模糊推理和策略选择的部分。

具体分工如下：

• 规则引擎负责：

  • 约束过滤 ：根据最新的字母状态表（绿色确定位置、黄色存在但排除位置、灰色排除），从一个预加载的5字母单词列表中，实时过滤出所有符合条件的“候选单词集”。这是一个纯逻辑计算，速度快、零成本。
  • 反馈解析与状态更新 ：这是一个确定性算法，直接根据目标单词和猜测单词计算出每个字母的反馈状态，并更新状态表。同样由规则引擎高效完成。
  • 基础策略执行 ：例如，当候选单词集缩小到10个以内时，一个简单的策略是“随机选择其中一个”。这个策略可以直接由规则引擎执行，无需惊动LLM。

• LLM规划器负责：

  • 高层策略制定 ：在游戏的关键决策点介入。例如，在第一次猜测时，LLM决定采用“信息熵最大化”策略还是“常见单词优先”策略。
  • 处理模糊场景 ：当规则引擎过滤出的候选词集仍然很大（比如超过50个），且约束条件复杂时，LLM可以分析这些候选词的字母分布，选择一个能最好地区分剩余可能性的单词。
  • 从失败中学习（如果实现） ：分析游戏历史，总结哪类单词或字母组合容易导致失败，并调整未来的策略倾向。

这种混合架构大幅降低了LLM的调用频率。在一局游戏中，LLM可能只在第一、二次猜测，以及最后几次猜测的关键节点被调用，中间大量的机械性过滤和试探可以由规则引擎快速处理。实测下来，这种架构在成本和速度上取得了很好的平衡，同时保留了智能体应对复杂情况的“灵性”。

3.3 工具集的设计细节

一个健壮的工具集是智能体高效运行的基础。以下是我实现的一些核心工具：

1. get_possible_words(constraints) ：

   • 输入 ：约束条件对象，包含 must_include （黄色字母集）、 must_not_include （灰色字母集）、 correct_positions （绿色字母位置映射，如 {0: ‘S’, 2: ‘A’} ）、 wrong_positions （黄色字母的禁止位置映射，如 {‘E’: [1, 4]} ）。
   • 处理 ：对预加载的约10000个常用5字母单词列表进行遍历和匹配。这里用了位运算和集合操作来加速。
   • 输出 ：符合条件的单词列表。
   • 心得 ：单词列表的质量至关重要。我最初用了包含所有生僻词的完整列表，结果智能体经常猜出像“XYLYL”这样的词，虽然符合规则，但毫无意义。后来换成了经过词频过滤的常用词列表，游戏体验和智能体表现都正常多了。

2. analyze_word_entropy(word_list) ：

   • 输入 ：一个候选单词列表。
   • 处理 ：计算列表中每个单词的“信息熵”。简单来说，就是猜测这个词后，平均能将剩余可能性缩小多少。算法会模拟用该词去匹配列表中的其他词，统计反馈模式的分布。分布越均匀（即反馈结果越分散），熵值越高，该词的信息价值越大。
   • 输出 ：按熵值排序的单词列表。
   • 注意 ：计算熵是计算密集型操作，当单词列表很大时（如>1000）会非常慢。因此，这个工具通常只在候选词集已经较小（如<200）时，由LLM决定调用，用于精选最优猜测。

3. suggest_opening_guess() ：

   • 这是一个预计算工具 。我离线分析了大量Wordle游戏数据，计算了像“AROSE”、“SLATE”、“CRANE”等常见开局词的信息熵和胜率，将其硬编码。当LLM决定采用“最优开局”策略时，直接从此工具获取推荐，避免了实时计算的开销。

4. 智能体策略的实战分析与调优

4.1 不同策略的竞技场表现

我设计了几个具有不同策略的智能体，让它们在同一个游戏服务器上进行了数百局对抗，观察它们的胜率和平均尝试次数：

智能体类型	核心策略描述	平均尝试次数 (胜局)	胜率 (6次内)	特点分析
“信息熵最大化” Agent	每次猜测都选择能最大程度缩小候选词集的单词。使用 analyze_word_entropy 工具。	3.8	98%	表现最稳定、最优。但计算开销大，后期候选词少时优势明显。
“高频词优先” Agent	始终从符合约束的单词中，选择词频最高的那个。依赖一个静态词频表。	4.2	95%	速度快，成本低。在简单词上表现好，遇到生僻词容易“卡住”，因为它的词频表里可能没有。
“混合模式” Agent	我的主力架构。开局用预计算最优词，中期用规则引擎过滤+随机选择，当候选词<20时切回信息熵策略。	4.0	97%	在速度、成本和胜率间取得了最佳平衡。是实用化的选择。
“纯LLM直觉” Agent	没有规则引擎，每次都将全部状态和约束用自然语言描述给LLM，让它直接“想”出一个单词。	4.5	92%	最具“创意”，有时会走出令人惊叹的妙手。但更常犯低级错误（如拼写错误、重复已排除的字母），不稳定且成本极高。

从结果看，“信息熵最大化”在理论上是最优策略，但它的计算成本限制了其实用性。“混合模式”智能体通过分工协作，用20%的LLM调用解决了80%的问题，是工程上更优的解。

4.2 关键调优点：状态提示工程

智能体的表现极大程度上取决于我们如何将“游戏状态”描述给LLM规划器。经过多次试验，我总结出了最有效的提示词结构：

你是一个专业的Wordle玩家。当前游戏状态如下：
- 已进行回合：[当前回合数/6]
- 历史猜测及反馈：
  1. ARISE -> 反馈：A(黄色), R(灰色), I(灰色), S(黄色), E(绿色)
  2. ... 
- 当前已知字母约束：
  * 确定存在的字母（黄色或绿色）：A, S, E
  * 确定不存在的字母（灰色）：R, I, T, O
  * 确定位置的字母（绿色）：第4位是E
  * 禁止位置的字母（黄色）：A不能在第0位，S不能在第1位。
- 根据以上约束，系统工具已筛选出[XX]个可能的候选单词。

你的目标是：在剩余回合内猜出目标单词。
请规划你的下一步行动。你可以使用的工具有：[工具列表]。

请按以下格式输出你的规划：
思考：[你的推理过程，分析当前局面，选择策略的原因]
行动：[调用哪个工具，以及具体的输入参数]

这个提示词结构清晰地将“客观事实”（历史、约束）和“推理任务”分开，并强制LLM进行“思考-行动”的链式输出，大大提高了其决策的合理性和可解析性。

实操心得：在提示词中明确给出“输出格式”是至关重要的。这能极大减少LLM输出格式错误导致的解析失败。同时，将“候选单词数量”告知LLM，能帮助它决定策略——数量多时倾向于信息收集，数量少时倾向于直接猜测。

5. 多智能体竞技与系统架构

单个智能体自己玩固然有趣，但让多个智能体同台竞技，观察它们在不同单词下的表现，才是这个项目的精髓。我设计了一个简单的“竞技场”模式。

5.1 竞技场服务器设计

竞技场服务器核心功能包括：

1. 单词管理 ：每日或每轮从一个词库中随机选取一个目标单词。确保对所有智能体公平。
2. 游戏会话管理 ：为每个智能体创建独立的游戏会话，维护其游戏状态。
3. 动作队列与轮询 ：智能体通过API提交猜测。服务器验证猜测有效性（是否为5字母单词），计算反馈，更新该智能体的游戏状态，并返回结果。
4. 排行榜与数据收集 ：记录每个智能体猜中单词所用的尝试次数、是否成功、每一步的猜测历史。最终生成排行榜和详细的对局分析报告。

服务器用轻量级的框架实现，关键是要保证计算反馈的逻辑高效且一致，并且能处理一定程度的并发请求。

5.2 智能体客户端实现模式

智能体作为独立客户端，有两种主要模式与服务器交互：

1. 同步轮询模式 ：智能体在一个循环中，依次执行“获取状态 -> 本地推理 -> 提交猜测 -> 等待结果”的步骤。实现简单，但效率较低，且需要处理网络延迟。
2. 异步事件驱动模式 ：更先进的模式。智能体客户端在提交猜测后便不再阻塞，可以去处理其他任务或进行并行推理。当服务器返回结果时，通过Webhook回调或消息队列通知智能体。这种模式更适合需要长时间推理或同时参与多场游戏的智能体。

在我的项目中，为了简化，初期采用了同步轮询模式。但在设计上预留了回调接口，为后续升级异步模式做准备。

5.3 竞技数据分析的价值

让多个智能体竞技，产生的数据非常有价值：

• 策略评估 ：可以客观地比较不同策略（如信息熵 vs 词频优先）在不同类型单词（元音多、辅音多、有重复字母等）下的表现。
• 发现LLM的系统性弱点 ：例如，我发现“纯LLM直觉”智能体在面对含有“Y”字母的单词时，表现明显下滑，可能是因为训练数据中“Y”作为元音的情况不够典型。
• 优化启发式规则 ：通过分析大量对局，可以发现哪些启发式规则（如“优先尝试包含未出现元音的单词”）在大多数情况下是有效的，从而将其固化到规则引擎中，减少对LLM的依赖。

6. 成本控制、性能优化与扩展思考

6.1 控制LLM API调用成本

这是AI智能体项目无法回避的现实问题。我的优化措施包括：

• 缓存 ：对相同的游戏状态和约束条件，智能体的“思考”结果很可能是相同的。因此，我建立了一个简单的缓存层，键是游戏状态的哈希值，值是规划结果。这能避免大量重复计算，尤其是在智能体进行自我对弈训练时。
• 降级策略 ：为LLM规划器设置一个“置信度阈值”。当规则引擎过滤出的候选词数量极少（比如<3个）时，直接让规则引擎随机选择一个，不再调用昂贵的LLM。因为在这种情况下，LLM带来的收益微乎其微。
• 使用小型/廉价模型 ：对于“更新知识库”这类相对简单的解析任务，可以尝试使用更小、更快的模型（如较小的开源模型），而不是每次都使用GPT-4级别的模型。

6.2 性能瓶颈与优化

• 单词列表过滤 ：这是最频繁的操作。将单词列表从数组转换为前缀树（Trie）或使用位图进行表示，可以极大提升过滤速度。我最终采用了位图表示法，将每个单词表示为一个26位的字母存在位图，配合位置信息进行快速集合运算。
• 熵计算优化 ：完全实时计算熵是不现实的。我的做法是预计算一个“单词-反馈模式”的稀疏矩阵，或者只在候选词集已经很小（<100）时才启用熵计算。另一种思路是使用近似算法，如只考虑高频字母的分布来估算熵值。
• 并发处理 ：当竞技场中有数十个智能体同时游戏时，服务器的反馈计算和状态更新会成为瓶颈。采用异步IO和连接池，并将核心的反馈计算逻辑用更高效的语言（如Rust、Go）编写为微服务，可以显著提升吞吐量。

6.3 项目扩展方向

这个基础框架可以朝多个有趣的方向扩展：

1. 更复杂的游戏规则 ：不止于5字母单词。可以扩展为“四字成语Wordle”、“化学分子式Wordle”等，这需要更换词库和规则，但智能体的架构可以复用。
2. 多智能体协作与对抗 ：设计一种模式，让两个智能体协作猜一个单词，它们可以有限地交换信息。或者设计对抗模式，一个智能体出题，另一个猜题，出题者的目标是让猜题者用尽次数。
3. 强化学习训练 ：将智能体与环境（游戏）的交互视为一个马尔可夫决策过程，使用强化学习来训练策略网络。智能体的“工具调用”可以视为动作，游戏反馈是状态转移和奖励（猜中得正分，用尽次数得负分）。这能让智能体自我进化出超越人类预设的策略。
4. 可视化与解释性 ：为智能体的每一步决策提供可视化解释。例如，展示它内部的“字母状态表”如何变化，展示候选词列表如何缩小，甚至让LLM生成它选择某个单词的“内心独白”。这极大地增强了项目的可理解性和演示效果。

构建“AI智能体的Wordle”远不止是一个有趣的编程练习。它像一个显微镜，让你清晰地看到构建一个实用AI智能体所需的全套技术栈：从架构设计、工具编排、提示工程，到成本控制、性能优化。每一个环节的决策，都直接影响了智能体的“智商”和“体能”。通过这个具体的沙盒项目，你可以积累的经验，能无缝迁移到客服机器人、自动化数据分析助手、游戏NPC等更复杂的智能体应用中去。最让我有成就感的一点是，看着自己设计的几个智能体在竞技场中“斗智斗勇”，看着它们的策略从笨拙到娴熟，那种感觉就像在培养一群数字生命，观察它们如何在一个微小的规则宇宙中学习和适应。