从OpenMythos项目拆解大语言模型思维链生成原理与工程实践

简介大语言模型LLM的推理能力源于其基于Transformer架构的注意力机制和海量参数所实现的模式涌现。这种涌现并非真正的意识思考而是模型通过前向传播在预测下一个token时对训练数据中逻辑推理文本模式的统计模仿。其技术价值在于通过显式生成和管理“推理文本轨迹”即思维链可以将模型内部的推理计算过程外化为可观察、可干预的文本流从而提升复杂问题求解的可解释性和可控性。在应用场景上这种机制被广泛应用于数学推理、代码生成、科学问答等需要多步逻辑推演的任务中。本文以OpenMythos开源项目为例深入剖析了实现思维链生成所需的PyTorch动态计算图调试与两阶段生成控制等关键技术展示了如何从第一性原理出发用代码构建和驾驭模型的“思考”过程。1. 从“思考”的幻觉到“涌现”的机制我们到底在谈论什么最近Claude Mythos 的预览版在社区里掀起了一阵不小的波澜。很多人都在讨论它那令人印象深刻的“思考”能力——那种在复杂推理任务中仿佛能像人类一样进行内部推演、权衡利弊、甚至自我修正的表现。作为一个长期和代码、模型打交道的开发者我本能地对“思考”这个词保持警惕。在AI领域我们常常陷入一种“拟人化”的陷阱用我们理解自身心智的词汇去描述一个完全不同的、基于统计和计算的系统。这就像用“马跑得快”去描述一辆汽车的速度虽然直观但完全掩盖了内燃机、变速箱和轮胎摩擦力的本质。所以当看到 OpenMythos 这个项目时我立刻来了兴趣。它的目标不是简单地复现一个 Claude 的接口或外壳而是宣称要从“第一性原理”出发去还原 Mythos 背后所谓的“思考”本质。这听起来像是一个极客的浪漫宣言抛开所有华丽的营销话术和模糊的比喻直接深入到数学、算法和代码的层面看看这个“魔法”究竟是如何被制造出来的。那么这个“本质”到底是什么在深入代码之前我们必须先达成一个共识当前大语言模型LLM所展现出的“思考”并非我们人类意识层面的、带有主观体验的思考。它是一种基于注意力机制、海量参数和复杂架构的“模式涌现”。模型通过前向传播在每一个时间步token上根据上文context计算出下一个 token 的概率分布。所谓的“推理链”Chain-of-Thought, CoT或“思考过程”本质上是一段被模型“写出来”的、对人类推理过程进行模仿的中间文本。模型“写”下“让我们一步步思考”这句话然后接着“写”下推理步骤这个过程本身仍然是下一个 token 的预测只不过这种预测因为训练数据中大量存在的逻辑推理文本模式而显得具有连贯性和逻辑性。OpenMythos 的价值就在于它试图用 Python 代码将这个过程透明化、可操作化。它不是去模拟一个黑箱的“思考者”而是去构建一个能够显式地生成和管理这种“推理文本轨迹”的系统。这让我们有机会亲手“拧动螺丝”观察“思考”这个幻觉是如何一砖一瓦搭建起来的。接下来我将带你一起从环境搭建开始逐步拆解 OpenMythos 的核心架构看看我们能否用代码触及那个迷人的“本质”。2. 环境奠基超越pip install的依赖哲学拿到 OpenMythos 的源码第一件事永远是搭建环境。但这次我们不能满足于一个简单的requirements.txt。要理解一个从第一性原理出发的项目我们必须理解它的每一个依赖项为何存在以及它们共同构成了一个怎样的计算基础。2.1 核心依赖的三重境界OpenMythos 的依赖大致可以分为三个层次计算引擎、神经网络骨架和工具链。第一层计算引擎PyTorch这是整个项目的基石。选择 PyTorch 而非 TensorFlow 或 JAX对于研究导向的项目来说几乎是必然的。PyTorch 的动态计算图eager execution模式使得调试和实验变得异常直观。你可以在任意位置插入print语句或者使用 Python 调试器pdb实时查看张量的形状和数值这对于理解模型内部的数据流动至关重要。在 OpenMythos 中当我们试图追踪一个“思考”token 是如何被生成并影响后续上下文时这种可调试性是无价的。安装时务必去 PyTorch 官网 根据你的 CUDA 版本和系统环境生成安装命令。一个常见的坑是版本不匹配。例如你的显卡驱动可能支持 CUDA 11.8但你却安装了 CUDA 12.1 编译的 PyTorch这会导致无法调用 GPU。我的经验是先通过nvidia-smi查看驱动支持的最高 CUDA 版本然后在官网选择比这个版本低一级的稳定版进行安装兼容性最好。第二层神经网络骨架Transformers, xFormerstransformers库来自 Hugging Face它提供了各种预训练模型和标准化的模型组件。OpenMythos 很可能不是从零开始编写每一个 Transformer 层而是基于transformers库中的LlamaModel或MistralModel等类进行构建和修改。这节省了大量底层编码工作让我们能聚焦于“思考”机制的实现。xFormers是一个优化库它提供了内存效率更高、速度更快的注意力机制实现。对于需要长上下文long context的“思考”过程来说注意力是内存消耗的大户。标准的注意力计算复杂度是序列长度的平方O(n²)当“思考”轨迹很长时这会是瓶颈。xFormers提供了诸如memory_efficient_attention等算子可以显著降低内存占用。安装xFormers通常需要从源码编译对新手不太友好。一个取巧的办法是使用预编译的 wheel 文件或者如果只是实验前期可以暂时注释掉相关代码用标准的注意力机制代替先保证跑通。第三层工具链Tokenizer Datasets, AccelerateTokenizer: 分词器。Claude 系列通常使用 SentencePiece 或 Tiktoken类似 GPT。OpenMythos 需要加载与预训练模型完全一致的分词器否则 token ID 对不上一切都会乱套。你需要确认项目使用的是LlamaTokenizer还是ClaudeTokenizer如果有的话。Datasets: 用于加载和管理训练或演示数据。如果你想用自己的数据微调“思考”能力这个库必不可少。Accelerate: Hugging Face 出品的分布式训练库。它能让你几乎不用修改代码就能让同一份代码在单 GPU、多 GPU 甚至 CPU 上运行。对于资源有限的个人开发者学会用Accelerate是最大化利用硬件的关键。一个完整的、带有版本锁定的环境配置示例environment.yaml适用于 Conda可能如下所示name: openmythos channels: - pytorch - nvidia - conda-forge - defaults dependencies: - python3.10 - pytorch2.1.0 - torchvision - torchaudio - pytorch-cuda11.8 - pip - pip: - transformers4.35.0 - datasets2.14.0 - accelerate0.24.0 - sentencepiece0.1.99 - tiktoken - einops - wandb - scipy - numpy注意xFormers通常建议用pip从源码安装 (pip install -U xformers --index-url https://download.pytorch.org/whl/cu118)因为它和 PyTorch 版本的绑定非常紧密。直接写在yaml里可能失败。2.2 版本地狱与依赖冲突的实战解法“我明明按照 README 装了为什么还是报错”——这是每个开源项目新手都会经历的痛。对于 OpenMythos 这类前沿项目其依赖可能指向某个库的特定 commit而非稳定版。策略一隔离环境是底线无论使用 Conda 还是 Python 的venv都必须为这个项目创建独立的环境。这能避免和你系统里其他项目的依赖比如一个老旧的 TensorFlow打架。策略二逆向安装法如果项目提供的requirements.txt安装失败不要死磕。尝试以下步骤先安装最核心、版本要求最明确的包通常是torch和transformers。然后尝试直接运行项目的主脚本比如train.py或demo.py。运行后看第一个ModuleNotFoundError报错缺少哪个包再手动pip install那个包。重复步骤2和3直到脚本能正常启动即使可能因为功能缺失而运行失败。这时你就得到了一个“最小可运行环境”。最后根据脚本运行时的错误或警告逐步补充安装其他功能性的包如wandb用于可视化scipy用于某些计算。这种方法虽然笨但能让你清晰地知道每一个包到底是干什么用的而不是面对一长串列表感到茫然。3. 架构透视拆解“思考”的流水线环境就绪后我们终于可以打开 OpenMythos 的源码了。一个从第一性原理还原“思考”本质的项目其代码结构本身就是最好的说明书。它通常会摒弃那些为了生产环境部署而设计的复杂抽象直指核心流程。3.1 核心模块的职责划分一个典型的 OpenMythos 项目可能包含以下模块modeling_mythos.py: 这是心脏。它定义了模型的核心架构。关键不在于它复现了一个多大的 Transformer而在于它如何修改或包装这个 Transformer 来实现“思考”。你可能会发现一个名为MythosThinkingWrapper或ChainOfThoughtModel的类。这个类可能做了以下几件事输入预处理在用户问题prompt前自动添加一个“思考触发器”比如\n\nLets think step by step: 。这不是简单的字符串拼接而是需要在分词tokenization层面处理好。生成过程干预重写或继承transformers的generate方法。在生成每一个 token 时模型不仅看之前的对话历史还可能维护一个内部的“思考缓冲区”。这个缓冲区里的 tokens即模型的“内心独白”会作为上下文的一部分参与后续生成但最终输出给用户时会被过滤掉。思考轨迹管理提供方法来提取、清理和解析模型生成的完整文本中的“思考部分”和“最终答案部分”。tokenization_mythos.py: 定义了如何将文本转化为模型能理解的 token ID以及如何反向解码。这里需要特别注意“思考”部分可能使用的特殊 token。例如模型是否用think和/think这样的特殊标记来包裹思考过程OpenMythos 需要确保分词器能正确识别和处理这些标记。configuration_mythos.py: 模型的配置文件。这里可能定义了一些控制“思考”行为的超参数例如thinking_max_length: 思考部分的最大 token 长度。thinking_token: 用于触发或标识思考的特殊 token ID。thinking_strategy: “贪心搜索”greedy还是“集束搜索”beam search通常对于思考过程为了保持连贯性可能会使用贪心搜索而对于最终答案可能会采用采样sampling来增加多样性。train_mythos.py和data_utils.py: 如果项目包含训练代码这部分展示了如何构建训练数据来“教会”模型思考。数据格式可能是(prompt, chain_of_thought, answer)的三元组。训练的目标是让模型学会在遇到复杂问题时首先生成chain_of_thought然后基于此生成answer。损失函数可能会对思考部分和答案部分赋予不同的权重。3.2 数据流动一次“思考”生成的完整旅程让我们跟踪一个用户查询“鸡兔同笼共有头10个脚28只问鸡兔各几何”在 OpenMythos 系统中的旅程。输入与触发prompt “鸡兔同笼共有头10个脚28只问鸡兔各几何” # 在 modeling_mythos.py 的预处理中可能会被转化为 formatted_prompt “请解决以下问题” prompt “\n\n让我们一步步推理” input_ids tokenizer.encode(formatted_prompt, return_tensors“pt”).to(device)注意“让我们一步步推理”这个触发器被无缝地拼接进去它作为一个强烈的信号引导模型进入“思考模式”。生成与缓冲 模型开始生成 tokens。在自定义的generate函数中代码会区分两种状态“思考中”和“输出答案”。一个简单的判断逻辑可能是在遇到特定的“思考结束符”如换行符\n或特殊 token之前所有的生成内容都被存入thinking_buffer。这个缓冲区的 tokens 会持续被添加回input_ids作为生成下一个 token 的上下文。这就模拟了“一边想一边写”的过程。切换与输出 当模型生成了一个预定义的“思考结束标记”比如“因此答案是”或者思考长度达到thinking_max_length状态切换到“输出答案”。此后生成的 tokens 不再存入思考缓冲区而是直接作为最终答案的一部分。最终函数返回两个字符串清理后的thinking_text(让我们一步步推理假设全是鸡则有20只脚...) 和answer_text(鸡有6只兔有4只)。后处理与呈现 呈现给用户的可以是只有answer_text也可以是thinking_text answer_text的组合这取决于应用场景。OpenMythos 的价值在于它让这个“思考”缓冲区从黑箱里的隐状态变成了我们可以观察、记录甚至干预的显式文本流。这个架构的核心思想是“显式化”和“可干预”。它不假设模型天生就会思考而是通过工程架构为模型搭建一个“思考的脚手架”引导它按照我们设计的方式将内部的推理计算过程“外化”为文本。4. 训练与调优赋予模型“思考”的习惯如果 OpenMythos 只提供了推理代码那它只是一个精巧的“播放器”。要真正理解“思考”如何从数据中学习我们必须看它的训练部分如果有的话。训练一个具有显式思考能力的模型其数据构造和损失函数设计是关键中的关键。4.1 训练数据构造思维链的“教材”模型不是天生就知道“一步步推理”这个格式的。它需要从大量的例子中学习。这些例子通常来自人工标注或大模型如 GPT-4的合成。一个典型的数据样本格式如下JSONL格式{ “instruction”: “解鸡兔同笼问题头10个脚28只。”, “input”: “”, “chain_of_thought”: “假设全是鸡那么10个头对应20只脚。现在有28只脚多出了8只脚。每只兔子比鸡多2只脚所以多出的8只脚对应4只兔子。因此兔子有4只鸡有10-46只。”, “output”: “鸡有6只兔子有4只。” }在训练时我们不会简单地把instruction output扔给模型。而是采用一种“多段式”的输入构造输入序列构造[BOS] Instruction: [instruction] Question: [input] Let‘s think step by step: [chain_of_thought] Therefore, the answer is: [output] [EOS]训练目标损失计算这里有一个精妙的细节。我们通常会对[chain_of_thought]和[output]部分的 tokens 计算损失而对Instruction:、Question:以及触发器文本Let‘s think...等部分的 tokens 进行掩码不计算损失。这样做的目的是强制模型学习生成思考链因为思考链部分的损失是有效的模型必须学会生成合理的推理步骤才能降低这部分损失。建立从思考到答案的因果关联模型在生成Therefore, the answer is:之后的答案时其上下文包含了完整的思考链。它必须学会基于前面的推理得出正确的结论。在 OpenMythos 的train_mythos.py中你可能会看到一个自定义的data_collator函数它负责在 batch 中构建这种格式的输入并生成相应的attention_mask和labels用于损失计算。4.2 损失函数与课程学习简单的“思考链-答案”联合训练可能还不够。为了让“思考”更有效训练策略上可能会有一些进阶技巧加权损失对[output]答案部分赋予比[chain_of_thought]部分更高的损失权重。这传达了一个信息“最终答案的正确性比中间过程的详细程度更重要”。但权重需要小心调整否则模型可能会为了降低答案损失而“抄近路”生成无意义的思考链。渐进式训练课程学习阶段一使用高质量的、人工标注的思维链数据数量少但精度高进行微调让模型初步建立“思考-回答”的范式。阶段二使用模型自己生成的思维链数据进行扩充。例如用阶段一的模型在大量问题上生成思考链和答案然后通过一些规则如答案是否正确或一个“验证器”模型进行过滤将高质量的数据加入训练集。这能低成本地扩大数据规模。阶段三引入“无思考链”的数据。在训练中混入一部分(instruction, output)的普通样本但不要求模型生成思考链。这可以防止模型对“思考触发器”产生过强的依赖使其在不需要复杂推理的简单问题上能够直接给出答案提高效率。强化学习微调RLHF for Reasoning这是更前沿的方向。我们可以定义“好的思考”的奖励信号例如答案正确性是终极奖励但也可以加入思考链的连贯性、步骤的合理性、是否包含无关信息等中间奖励。通过强化学习如 PPO引导模型生成更高奖励的思考过程。OpenMythos 如果涉及这部分代码会复杂很多通常会集成trlTransformer Reinforcement Learning库。在翻阅训练代码时重点关注loss function的计算部分和data collator。这两个地方是“思考”能力如何被灌输进模型的“魔法发生地”。5. 推理策略与可控生成驾驭“思考”的野马有了一个训练好的模型如何在推理时让它稳定、可靠地输出我们想要的“思考”和“答案”这涉及到生成策略的精细调控。OpenMythos 的推理代码里很可能隐藏着不少让“思考”变得更像“思考”的秘诀。5.1 解码策略贪心、采样与束搜索的抉择在生成“思考链”和“最终答案”时采用不同的解码策略会带来截然不同的效果。思考链生成Thinking Phase贪心搜索Greedy Search每一步都选择概率最高的 token。这能保证生成的思考链是局部最合理的连贯性最好不容易跑偏或陷入循环。对于逻辑推理连贯性至关重要因此贪心搜索通常是思考链生成的首选。OpenMythos 可能会在思考阶段设置do_sampleFalse, num_beams1。弊端缺乏多样性。对于同一个问题每次生成的思考链几乎一模一样。这有时不一定是坏事因为它保证了输出的确定性。最终答案生成Answer Phase采样Sampling从概率分布中随机选取下一个 token可以通过temperature参数控制随机性。temperature0等价于贪心搜索temperature较高时创造性更强但可能胡言乱语。对于答案我们可能希望有一点多样性或者当答案是一个短语时采样能产生更自然的语言。可以设置do_sampleTrue, temperature0.7。集束搜索Beam Search保留多个可能序列beam width最终选择整体概率最高的序列。它在机器翻译等任务中常用但在开放生成长文本时容易导致重复和乏味。对于思考后的答案生成束搜索可能过于死板。OpenMythos 中的实现技巧它很可能实现了一个两阶段生成函数。第一阶段用一套参数贪心生成思考链在检测到“思考结束标记”后用另一套参数采样继续生成答案。这需要精细地控制generation_config在生成过程中的动态切换。5.2 约束生成与引导让思考走在正确的路上完全放任模型“自由思考”它可能会天马行空离题万里。因此需要施加一些约束和引导。逻辑格式约束我们可以强制思考链遵循某种格式比如“步骤1... 步骤2...”。这可以通过“前缀允许词Prefix Allowed Tokens”来实现。在生成思考链时我们可以设定一个有限状态机当生成到“步骤”这个词时下一个 token 只允许是数字“1”、“2”等或特定的几个字。这能极大地提高思考链的结构化程度。Hugging Face 的generate函数支持prefix_allowed_tokens_fn参数OpenMythos 可能会利用这一点。关键词引导对于数学问题我们希望思考中出现“设”、“方程”、“解得”等词对于物理问题希望出现“力”、“速度”、“能量守恒”等。这可以通过“偏置Bias”或“提示Prompting”来实现。一种简单的方法是在输入提示中显式加入“请使用数学方程进行推理”。更高级的方法是在生成时动态地增加特定 token 的 logits模型输出的原始分数使其更可能被选中。长度惩罚与重复惩罚length_penalty: 用于束搜索对长序列进行惩罚防止答案过于啰嗦。在思考阶段可以设置较小的长度惩罚甚至为负鼓励长思考在答案阶段设置较大的惩罚让答案简洁。repetition_penalty: 防止模型陷入重复循环比如不断重复“然后...然后...”。这个参数在生成思考链时尤其重要可以设置为1.2左右。思考中断与答案强制模型有时会没完没了地“思考”下去或者在应该给出答案时又开始新一轮思考。我们需要一个明确的停止信号。除了依赖模型自己生成“答案是”这类标记还可以通过max_new_tokens分别限制思考阶段和答案阶段的最大生成长度。一旦思考阶段达到thinking_max_tokens无论生成了什么都强制结束思考转入答案阶段。这些控制逻辑使得“思考”从一个不可控的随机过程变成一个半引导的、目标明确的文本生成任务。OpenMythos 的代码里这些策略可能被封装在ThinkingGenerationConfig这样一个配置类中与标准的GenerationConfig协同工作。6. 评估与调试量化“思考”的质量我们如何知道 OpenMythos 还原的“思考”是有效的它生成的思考链是真正的逻辑推演还是看似合理的“鹦鹉学舌”这就需要一套评估和调试的方法。6.1 构建评估基准不能只看最终答案的对错还要评估思考过程本身。一个完整的评估基准可能包含最终答案准确率这是最直接的指标。在数学问题GSM8K、科学问答ARC、常识推理CommonsenseQA等标准数据集上测试。思考链忠实度思考链是否真正支持了最终答案我们可以训练一个小的“验证器”模型输入“问题思考链答案”判断答案是否可以从该思考链中合理推导出来。或者使用规则匹配检查思考链中是否出现了答案计算的关键数字和步骤。思考链可读性与合理性这是一个更主观的指标但可以通过人工评估或强大的大模型如 GPT-4进行打分。让 GPT-4 对思考链的“逻辑连贯性”、“步骤清晰度”、“无关信息多少”进行评分。效率指标思考长度平均生成一个思考链需要多少 tokens过短可能推理不充分过长可能包含冗余。思考时间引入思考步骤后整体生成耗时增加了多少这关系到实用性。在 OpenMythos 项目中你可能会找到一个evaluation.py脚本它使用datasets库加载基准数据集然后批量运行模型并计算上述指标。6.2 实战调试当“思考”出错时模型生成了一段荒谬的思考链我们该如何入手调试案例问题“一个篮子里有5个苹果我拿走了2个还剩几个” 模型思考链“假设篮子里原来有x个苹果。我拿走了y个。剩余z个。根据能量守恒定律x - y z。已知x5, y2所以z3。因此答案是3。” 答案对了但思考过程引入了莫名其妙的“能量守恒定律”。调试步骤检查输入首先打印出tokenizer.decode(input_ids)确认输入给模型的 prompt 格式完全正确触发器Let‘s think step by step:是否在正确的位置。检查训练数据回顾训练数据中是否有类似的不相关文本被错误地包含在“思考链”字段中模型可能只是在模仿数据中的噪声。干预生成过程在推理代码中在思考链生成结束后立即将其打印出来。然后手动修改这段思考链比如删掉“能量守恒定律”替换成一句正确的话再将这个修改后的思考链作为上下文让模型继续生成答案。如果答案依然正确说明模型对思考链的具体内容并不敏感它可能只是依赖了思考链的“存在”而非“内容”。这提示我们模型没有学会严格依赖思考链进行推理。可视化注意力这是一个高级调试手段。使用transformers库的钩子hooks或captum等库可以可视化模型在生成“能量守恒定律”这个词时它最“关注”输入提示的哪些部分。也许它过度关注了提示中不相关的词或者它在训练数据中看到了“物理问题”和“数学计算”的虚假关联。简化问题用一个更简单的模型比如 7B 参数而不是 70B来跑同样的代码。小模型能力弱其错误模式往往更明显、更根源有助于定位架构或训练逻辑上的根本问题。调试 AI 模型的“思考”就像调试一个思维混乱的人。你需要通过设计精妙的“测试问题”、观察其“中间输出”、并对比“预期行为”来逐步缩小问题范围。OpenMythos 这样的开源项目给了我们设置断点、插入打印语句、修改中间变量的终极自由这是研究“思考”本质不可或缺的利器。7. 从复现到创新扩展 OpenMythos 的可能性当我们理解了 OpenMythos 的基本原理并成功运行后就可以以此为起点进行一些有趣的实验和扩展。这才是从“使用者”变为“创造者”的关键一步。7.1 实验一不同的“思考”触发器原项目可能使用“Let‘s think step by step: ”作为触发器。我们可以实验不同的触发器对思考质量和风格的影响中文触发器“请逐步推理”、“我们不妨这样思考”、“解这道题关键在于”结构化触发器“首先我们需要理解问题...其次我们分析已知条件...接着我们建立关系...最后我们得出结论...”领域特定触发器对于代码生成可以用“我们先分析需求...然后设计数据结构...接着编写函数框架...最后实现并测试...”实验方法在同一个评估数据集上仅改变触发器保持其他所有超参数一致比较最终答案的准确率和思考链的质量。你可能会发现某些触发器能更好地“激活”模型底层训练出的推理能力。7.2 实验二迭代式思考与自我修正Claude Mythos 的一个宣传点是能进行多轮、迭代式的深度思考。我们可以在 OpenMythos 的基础上模拟这一点。实现思路第一轮生成初始思考链和答案。第二轮将[第一轮思考链 第一轮答案]作为新的输入前面加上新的触发器“请检查上述推理和答案是否存在错误或可以改进的地方。让我们重新思考”模型生成第二轮的“批判性思考”和“修正后的答案”。可以重复多轮直到模型自己表示“无需再修正”或达到轮次上限。这需要设计更复杂的生成状态机并可能引入一个“批判者”模块来评估每一轮输出的质量决定是否继续。这个实验能让我们探索模型“元认知”对自身思考的认知能力的边界。7.3 集成外部工具让思考“落地”纯粹的文本思考有其局限尤其是在涉及精确计算、信息检索或代码执行时。我们可以扩展 OpenMythos使其在思考过程中调用外部工具。架构设计在思考链生成中定义一个特殊语法例如“calc3.14 * 10/calc”或“search爱因斯坦的生日/search”。模型生成到这些标记时生成流程暂停。一个工具调用解析器拦截输出识别出工具调用指令和参数。调用相应的计算器、搜索引擎 API 或 Python 解释器得到结果。将结果以特定格式如“result31.4/result”插回模型的输入上下文。模型基于这个结果继续它的思考链。这样模型的“思考”就不再是空对空的臆想而是可以结合真实世界数据和计算的能力。这更接近我们理想中 AI 助手的形态。实现这个功能需要对生成循环进行更底层的控制是挑战也是乐趣所在。通过这些扩展实验我们不再仅仅是 Claude Mythos 行为的模仿者而是成为了“思考”机制本身的探索者和改造者。OpenMythos 提供的不是一个终点而是一个强大且透明的起点。它用代码告诉我们那些令人惊叹的“智能”表现背后是一系列可理解、可修改、可优化的工程决策和算法组合。本文还有配套的精品资源点击获取