基于现代霍普菲尔德网络的AI智能体记忆方案：高速、免费、确定性的联想记忆系统

1. 项目概述：为什么我们需要一种全新的AI智能体记忆方案？

如果你正在构建一个AI智能体，无论是用于自动化客服、个人助手还是复杂的任务编排，记忆系统都是其核心组件。传统的做法是什么？无非是两种：要么把对话历史一股脑塞进上下文窗口，要么用向量数据库存储文本，每次查询时再调用大语言模型进行语义检索和推理。这两种方法我都深度使用过，也踩过不少坑。

上下文窗口方案简单粗暴，但随着对话轮次增加，成本飙升、速度变慢，而且模型可能会“忘记”早期的重要信息。向量数据库+LLM的方案听起来更优雅，但每次检索都是一次API调用，意味着你要为每一次记忆查询付费，等待几百毫秒甚至几秒的响应，并且结果是非确定性的——同样的查询，两次可能给出略有不同的答案，这对于需要稳定行为的自动化流程来说是个噩梦。

这就是我接触到MHN AI Agent Memory这个库时的感受：它提供了一种截然不同的思路。它不依赖LLM在查询时进行推理，而是将现代霍普菲尔德网络的更新规则直接作为记忆机制。简单说，它把记忆存储为一个“能量景观”中的模式，查询时通过一次矩阵乘法，让网络“放松”到最接近的存储模式。整个过程是确定性的，发生在微秒级，而且查询本身零成本。

注意：这里的“确定性”指的是，给定相同的存储内容和查询输入，输出结果总是完全一致的。这与LLM基于概率采样生成答案有本质区别，对于需要可重复、可审计的自动化任务至关重要。

这个库的核心价值，在于它为AI智能体提供了一种高速、免费、可靠的“工作记忆”。想象一下，你的智能体需要频繁访问一组固定的规则、用户偏好或产品信息。每次访问都调用GPT-4，不仅慢、贵，还可能因为模型的随机性而出错。而用这个库，你可以将这些信息一次性编码存储，后续的每次关联查询都像从内存中读取一个变量一样快速、准确。

2. 核心原理拆解：从注意力机制到联想记忆

要理解这个库为什么快，为什么免费，以及它能力的边界，我们必须深入其数学基础。这听起来可能有点硬核，但我会用最直白的方式讲清楚，因为这决定了你该如何用好它。

2.1 现代霍普菲尔德网络：一个优雅的数学框架

传统的霍普菲尔德网络是神经网络的早期模型，用于存储和检索二进制模式。现代霍普菲尔德网络（Modern Hopfield Network, MHN）是其升级版，关键突破在于它使用了连续值向量和基于内积的相似性度量，其能量函数和更新规则与Transformer中的注意力机制有着深刻的数学联系。

这个库的核心，就是这个更新规则：xi_new = X @ softmax(beta * X^T @ xi)

我们来拆解这个公式：

• X： 这是一个矩阵，它的每一行都是一个你存储的“记忆模式”（即文本经过编码器转换成的向量）。
• xi： 这是你的查询向量（即你的问题或提示词经过同一个编码器转换成的向量）。
• X^T @ xi： 计算查询向量xi与记忆矩阵X中每一个存储向量的内积（点积）。内积越高，表示两者越相似。
• softmax(beta * ...)： 对内积结果进行softmax操作。beta是一个逆温度参数，可以控制注意力分布的尖锐程度。beta值越大，网络越倾向于将全部“注意力”集中在与查询最相似的那个记忆上。
• X @ ...： 最后，用softmax得到的注意力权重对记忆矩阵X进行加权求和，得到一个新的向量xi_new。这个xi_new就是网络“联想”到的结果，它会是所有存储模式中，与查询最相似的那个模式的近似。

这个过程在干什么？你可以把它想象成一个“模式完善”的过程。你输入一个模糊或不完整的线索（xi），网络通过计算它与所有记忆的相似度，然后“放大”最相关的记忆，最终输出一个清晰的、完整的记忆模式（xi_new）。在库的API中，我们通常不直接使用xi_new，而是看哪个存储模式获得了最高的注意力权重，那个模式对应的原始文本就是检索结果。

2.2 与Transformer注意力机制的亲缘关系

如果你熟悉Transformer，会发现一个惊人的事实：上述更新规则，本质上就是单头、键值绑定的自注意力机制的一次前向传播。

• 记忆矩阵X同时扮演了键（Key）和值（Value）的角色。
• 查询向量xi是查询（Query）。
• softmax(beta * X^T @ xi)计算的是注意力权重。
• X @ (注意力权重)是注意力输出。

这个库的巧妙之处在于，它剥离了Transformer中复杂的多层结构和前馈网络，只保留了最核心的注意力计算，并将其重新定位为一个专用的、可解释的联想记忆系统。这意味着：

1. 速度极快： 它就是一次矩阵乘法，在CPU上都能在微秒内完成。
2. 零推理成本： 没有LLM参与，自然没有API调用费用。
3. 完全透明： 你可以精确查看每个记忆的注意力权重，知道为什么是A而不是B被检索出来。

2.3 能力边界：它不是什么？

理解了原理，就能看清它的边界。这不是一个“小模型”，不能做复杂的逻辑推理或文本生成。

• 它是检索器，不是生成器： 它只能返回你预先存储好的文本片段。它不会像LLM那样，综合多条记忆后生成一段新的总结或答案。
• 它是基于相似度的联想，不是逻辑推理： 它的“推理”仅限于模式匹配。如果你存储了“A是B的朋友”和“B在巴黎”，查询“A的朋友在哪？”它无法直接推导出“巴黎”。你需要通过“多跳检索”功能，先检索出“A是B的朋友”，再用“B”作为新查询去检索“B在巴黎”。
• 它的“智能”取决于编码器： 网络本身只处理向量。文本之间的语义相似度完全由你选择的编码器（如sentence-transformers）决定。如果编码器认为“狗”和“犬科动物”的向量不相似，那么网络就无法在这两者间建立联想。

3. 从安装到实战：构建你的第一个智能体记忆系统

理论说得再多，不如上手一试。我们从一个最简单的例子开始，逐步深入到生产级别的配置。

3.1 基础安装与快速验证

安装非常简单，基础库只依赖NumPy。

pip install mhn-ai-agent-memory

接下来，用不到10行代码感受一下它的工作方式：

from hopfield_memory import HopfieldMemory # 1. 初始化记忆库 mem = HopfieldMemory() # 2. 存储一些事实（知识） mem.store("OpenAI发布了GPT-4o模型，支持多模态输入。") mem.store("Python 3.12版本在性能上有显著提升，特别是子解释器特性。") mem.store("量子计算目前处于NISQ（含噪声中等规模量子）时代。") # 3. 进行查询 result, confidence = mem.query_with_confidence("GPT-4 多模态") print(f"检索结果: {result}") print(f"置信度: {confidence:.4f}") # 输出可能为: # 检索结果: OpenAI发布了GPT-4o模型，支持多模态输入。 # 置信度: 0.9987

发生了什么？我们存储了三条文本。当用“GPT-4 多模态”查询时，网络计算了这个查询与三条记忆的相似度。由于“GPT-4o”和“多模态”这两个关键词与第一条记忆高度重叠，网络将几乎全部的注意力权重（0.9987）都分配给了它，因此将其作为结果返回。

实操心得：默认情况下，HopfieldMemory使用RandomIndexEncoder，这是一种基于随机映射的词袋模型编码器。它只进行精确的词匹配，所以“GPT-4”无法匹配到“GPT-4o”。为了获得语义理解能力，我们需要更强大的编码器。

3.2 选择你的编码器：平衡质量与依赖

编码器是将文本转换为向量的组件，直接决定记忆系统的“理解能力”。库提供了四种选择：

from hopfield_memory import HopfieldMemory, RandomIndexEncoder, TFIDFEncoder, SentenceTransformerEncoder, OpenAIEncoder # 方案1：随机索引（默认，轻量，仅精确匹配） mem1 = HopfieldMemory(encoder=RandomIndexEncoder()) # 适合：关键词严格匹配的场景，如代码片段检索、命令别名。 # 方案2：TF-IDF编码（需要scikit-learn） # pip install mhn-ai-agent-memory[tfidf] 或 pip install scikit-learn mem2 = HopfieldMemory(encoder=TFIDFEncoder()) # 适合：中等规模文档，需要考虑词频和逆文档频率的检索。 # 方案3：句子Transformer编码（高质，推荐） # pip install mhn-ai-agent-memory[semantic] mem3 = HopfieldMemory(encoder=SentenceTransformerEncoder()) # 适合：需要语义理解的绝大多数场景。它能理解“狗”和“犬科动物”的相似性。 # 方案4：OpenAI Embeddings API（质量最高，但有成本和外网依赖） # pip install mhn-ai-agent-memory[openai] # 需要设置环境变量 OPENAI_API_KEY mem4 = HopfieldMemory(encoder=OpenAIEncoder(model="text-embedding-3-small")) # 适合：对语义质量要求极高，且能接受API调用延迟和成本的场景。

我个人的选择与建议：对于大多数AI智能体项目，SentenceTransformerEncoder是甜点。它在质量、速度和离线能力之间取得了最佳平衡。安装sentence-transformers时会自动下载一个约80MB的预训练模型（如all-MiniLM-L6-v2），之后就可以完全离线运行。

让我们用语义编码器重写上面的例子：

from hopfield_memory import HopfieldMemory, SentenceTransformerEncoder mem = HopfieldMemory(encoder=SentenceTransformerEncoder()) mem.store("OpenAI发布了GPT-4o模型，支持多模态输入。") mem.store("Python 3.12版本在性能上有显著提升，特别是子解释器特性。") # 现在，即使查询词不完全匹配，也能正确检索 result, _ = mem.query_with_confidence("OpenAI的新模型，能看能听") print(result) # 成功检索到第一条关于GPT-4o的记忆

3.3 处理“无匹配”场景：避免强行回答

一个健壮的记忆系统必须能说“我不知道”。传统的向量检索+LLM方案中，即使最相关的文档只有一点点相似，LLM也可能基于此编造一个答案（幻觉）。这个库通过内置的“哨兵模式”机制，优雅地解决了这个问题。

from hopfield_memory import HopfieldMemory, SentenceTransformerEncoder mem = HopfieldMemory(encoder=SentenceTransformerEncoder()) mem.store("火星是太阳系的第四颗行星，表面呈红色。") mem.store("比特币是一种基于区块链的加密货币。") # 方法1：query_or_none —— 最简洁的API result = mem.query_or_none("今天天气怎么样？") if result is None: print("记忆库中没有相关信息。") # 输出: 记忆库中没有相关信息。 # 方法2：match_quality —— 获取详细诊断信息 diagnosis = mem.match_quality("苹果公司市值") print(f"最大相似度: {diagnosis['max_similarity']:.3f}") # 可能很低，如0.15 print(f"是否匹配: {diagnosis['is_match']}") # False print(f"注意力间隙: {diagnosis['gap']:.3f}") # 第一名和第二名注意力权重的差 print(f"哨兵权重: {diagnosis['sentinel_weight']:.3f}") # 多少注意力流向了“无结果”

背后的原理：网络内部存储了一个全零向量作为“哨兵”模式。当查询与所有存储的记忆都不够相似时，这个哨兵模式会获得显著的注意力权重。query_or_none和is_match等方法就是通过分析注意力权重在真实记忆和哨兵之间的分布，来判断是否存在有效匹配的。

避坑指南：query_with_confidence返回的置信度永远是softmax后的最高权重，其值总是接近1（只要有一个记忆比其他的稍好一点）。因此，不要用这个置信度来判断匹配是否可靠。判断“有无匹配”请务必使用query_or_none或has_match()。

4. 高级功能与应用模式

掌握了基础，我们就可以探索这个库更强大的功能，来解决实际项目中更复杂的问题。

4.1 矛盾检测：维护知识库的一致性

当智能体从不同来源学习知识时，很容易存入矛盾的信息。例如，先存了“地球是圆的”，后又存了“地球是平的”。这个库提供了启发式的矛盾检测工具。

from hopfield_memory import HopfieldMemory, ContradictionDetector mem = HopfieldMemory() detector = ContradictionDetector() # 存储第一条事实 mem.store("地球是球体。") # 尝试存储可能矛盾的事实 new_fact = "地球是一个平面。" conflict_report = detector.check(mem, new_fact) if conflict_report.has_conflict: print(f"警告：检测到潜在矛盾！") print(f" 新事实: {new_fact}") print(f" 冲突事实: {conflict_report.conflicting_fact}") print(f" 解释: {conflict_report.explanation}") # 此时你可以选择：1. 拒绝存储 2. 要求用户确认 3. 记录冲突日志 else: mem.store(new_fact)

矛盾检测器的工作原理是计算新事实与已有记忆的相似度，并结合注意力权重进行分析。如果新事实与某个旧事实高度相似但语义可能相反（这需要编码器能捕捉语义对立），它就会触发警告。需要注意的是，这只是启发式的，对于复杂的、隐含的矛盾可能失效。在关键系统中，它应作为一道辅助防线，而非唯一依据。

4.2 多跳检索：实现简单的关联查询

这是实现“推理”链条的关键。虽然网络本身不做逻辑推导，但我们可以通过连续检索来串联相关事实。

from hopfield_memory import HopfieldMemory, chain_query mem = HopfieldMemory() mem.store("阿尔伯特·爱因斯坦提出了相对论。") mem.store("相对论包括广义相对论和狭义相对论。") mem.store("广义相对论描述了引力是时空弯曲的效应。") # 我们想知道“爱因斯坦提出的理论如何描述引力？” # 单次查询可能无法直接得到答案。 result = mem.query_or_none("爱因斯坦 引力 理论") print(result) # 可能返回None或第一条不完全相关的记忆 # 使用多跳检索，设置最大跳数 chain = chain_query(mem, "爱因斯坦 引力", max_hops=3) print("检索链条:") for i, fact in enumerate(chain): print(f" 跳{i+1}: {fact}") # 可能的输出: # 跳1: 阿尔伯特·爱因斯坦提出了相对论。 # 跳2: 相对论包括广义相对论和狭义相对论。 # 跳3: 广义相对论描述了引力是时空弯曲的效应。

chain_query的内部逻辑是：用初始查询进行检索，将检索到的结果文本中的关键实体或概念提取出来（一个简单的实现是取名词短语），合并到新的查询中，进行下一轮检索，如此循环直到达到最大跳数或没有新的相关记忆。这模拟了人类通过联想一步步追溯信息的过程。

4.3 排斥性注意力：提升记忆分离度

这是库里的一个实验性但强大的功能。标准的霍普菲尔德网络只有“吸引子”（存储的记忆点）。排斥性注意力在此基础上增加了“排斥子”，在能量景观中创造“小山丘”，主动将网络状态推离某些模式。

这有什么用？假设你的智能体需要区分两个非常相似的概念，比如“Java（编程语言）”和“Java（印度尼西亚岛屿）”。单纯存储它们，当查询“咖啡 岛屿”时，网络可能会被“Java（编程语言）”吸引（因为“Java”一词的强匹配）。如果你将“编程”、“代码”作为“Java（岛屿）”的排斥模式存储，就可以降低这种误匹配。

from hopfield_memory import HopfieldMemory mem = HopfieldMemory(repulsive=True) # 启用排斥模式 mem.store("Java是一种广泛使用的面向对象编程语言。") # 为“Java（岛屿）”存储一个排斥模式，避免被编程相关的查询吸引 # 注意：库的API可能以不同方式暴露此功能，此处为概念演示 # mem.store_negative("编程 代码 开发") # 在启用排斥后，对于模糊查询，网络会更谨慎 result = mem.query_or_none("咖啡 产地") # 由于排斥力的存在，即使“Java”一词匹配，也可能因为“编程”排斥子的作用而降低权重，甚至返回None。

根据项目文档中的基准测试，排斥性注意力可以将多步检索的收敛速度提升高达17倍。这对于需要精确区分相似条目的知识库非常有用。

5. 规模化部署：从原型到生产

当你的记忆从几十条增长到数万甚至数百万条时，简单的内存矩阵乘法会遇到瓶颈。这个库提供了分层存储的策略。

5.1 使用预设的内存规模

库提供了几个工厂函数，帮助你快速配置适合不同数据量的记忆系统。

from hopfield_memory import small_memory, large_memory, massive_memory # 场景1：小型工具或插件，记忆少于100条 mem_small = small_memory() # 特点：全内存，使用SentenceTransformer编码器，响应极快。 # 场景2：中型知识库，记忆在10万条左右 mem_large = large_memory() # 特点：分层存储。高频（“热”）记忆保留在精确的Hopfield网络中；低频（“冷”）记忆可能使用更节省内存的近似表示或移至磁盘索引。 # 场景3：超大规模记忆，百万级以上 mem_massive = massive_memory() # 特点：集成FAISS等近似最近邻搜索库。热记忆仍在Hopfield网络，冷记忆完全由FAISS管理，通过磁盘索引进行查询，牺牲少量精度换取巨大容量。

5.2 与向量数据库的集成策略

你可能会问，既然用了FAISS，那和直接用向量数据库（如Chroma, Weaviate）有什么区别？关键在于架构定位。

• MHN AI Agent Memory + FAISS： FAISS在这里仅作为冷存储的检索后端。热数据仍然在Hopfield网络中享受微秒级、确定性的检索。查询时，系统可能先查热内存，未命中再查FAISS。它的核心优势仍然是对热数据的极致快速、确定性访问，FAISS只是扩展了容量。
• 纯向量数据库 + LLM： 所有数据都在向量索引中，每次查询都是向量相似度搜索，然后必须将搜索结果交给LLM去理解和生成答案。这必然带来LLM的延迟、成本和不确定性。

如何选择？

• 如果你的智能体需要反复、高速访问一个核心规则集或状态信息（如用户当前会话的上下文、正在执行的任务步骤），那么MHN的热内存特性无可替代。
• 如果你主要是对海量文档进行一次性或低频的语义搜索，那么传统的向量数据库方案可能更合适。

一个混合架构的示例：

# 伪代码，展示思路 hot_memory = small_memory() # 存储会话状态、临时变量 vector_db_client = ChromaClient() # 连接外部向量数据库，存储产品手册、历史日志 def agent_think(question, session_id): # 1. 先查热内存（用户本次会话的历史） session_history = load_session_from_hot_memory(session_id) immediate_answer = hot_memory.query_or_none(question) if immediate_answer: return immediate_answer # 2. 热内存未命中，查向量数据库（背景知识） docs_from_vector_db = vector_db_client.similarity_search(question, k=3) # 3. 将热内存上下文和向量数据库结果一起交给LLM做最终推理 final_prompt = f"基于以下信息：{session_history} {docs_from_vector_db}， 回答问题：{question}" return call_llm(final_prompt)

6. 实战：构建一个多智能体协作的项目记忆中枢

这个库一个杀手级特性是提供了MCP服务器。MCP（Model Context Protocol）是Anthropic推出的一种协议，允许像Cursor、Claude Code这样的AI编码助手安全地访问外部工具和数据。这意味着你可以让多个AI助手共享同一个持久化的、基于磁盘的Hopfield记忆库，作为项目的“集体工作记忆”。

6.1 设置MCP服务器

假设我们有一个Python项目，希望AI助手能记住我们定义的项目规范、API密钥命名规则、常用的代码片段等。

1. 安装与配置：

   # 在项目根目录 pip install mhn-ai-agent-memory[semantic]

2. 创建MCP服务器配置文件： 复制项目自带的示例配置。

   cp .cursor/mcp.json.example .cursor/mcp.json

   编辑.cursor/mcp.json，确保路径正确。关键配置项：

   { "mcpServers": { "hopfield-memory": { "command": "python", "args": [ "/绝对路径/到/你的/项目/mcp-server/server.py" ], "env": { "HOPFIELD_STATE_PATH": "/绝对路径/到/你的/项目/.hopfield_memory.pkl", "HOPFIELD_AUTO_SAVE": "true", "HOPFIELD_ENCODER": "sentence_transformer" } } } }

3. 启动支持MCP的编辑器： 在Cursor或Claude Code中打开该项目。编辑器会自动加载MCP配置，并与你的Hopfield记忆服务器建立连接。

6.2 使用共享记忆进行协作

现在，你可以在不同的聊天会话中，或者同一个会话的不同阶段，使用MCP工具与共享记忆交互。

场景模拟：

• 会话1（你与AI助手A）：

  你：“记住，我们这个项目的API密钥都统一放在config/api_keys.yaml文件里，变量名格式是{SERVICE_NAME}_API_KEY。” AI助手A（通过MCP工具调用store_fact）: 已存储事实：“项目API密钥统一存储在config/api_keys.yaml中，变量命名格式为{SERVICE_NAME}_API_KEY。”

• 会话2（你的同事与AI助手B，或在另一天的你）：

  同事：“我们项目的API密钥放哪来着？怎么命名？” AI助手B（通过MCP工具调用query_or_none）: 检索到：“项目API密钥统一存储在config/api_keys.yaml中，变量命名格式为{SERVICE_NAME}_API_KEY。”

通过这种方式，项目的重要决策、规范、踩坑记录都可以被持久化记忆，并被团队内的任何AI助手随时检索，极大地提升了协作效率和知识传承。

7. 性能调优与问题排查

在实际使用中，你可能会遇到检索不准、速度变慢或内存占用过高的问题。以下是一些排查思路和调优技巧。

7.1 常见问题速查表

7.2 关键参数beta的理解与调整

beta（逆温度参数）控制着注意力分布的“尖锐”程度。

• beta值小： softmax输出更平缓，注意力会分散给多个相似记忆。结果可能更“平均”，但确定性降低。
• beta值大： softmax输出更尖锐，注意力几乎全部集中在最相似的一个记忆上。结果确定性高，但如果最相似的记忆其实也不够相关，可能会强行匹配。

from hopfield_memory import HopfieldMemory import numpy as np mem = HopfieldMemory(beta=10.0) # 高beta，非常“武断” mem.store("苹果是一种水果。") mem.store("苹果公司生产iPhone。") # 查询“水果” result1, conf1 = mem.query_with_confidence("水果") print(f"beta=10.0: {result1} (置信度: {conf1:.4f})") mem2 = HopfieldMemory(beta=1.0) # 低beta，更“犹豫” mem2.store("苹果是一种水果。") mem2.store("苹果公司生产iPhone。") result2, conf2 = mem2.query_with_confidence("水果") print(f"beta=1.0: {result2} (置信度: {conf2:.4f})")

高beta下，对于“水果”的查询，第一条记忆会以接近1的置信度胜出。低beta下，虽然第一条记忆仍然权重最高，但置信度可能只有0.6，第二条记忆也有0.4的权重。在需要衡量“匹配质量”的场景，适度调低beta有助于观察注意力分布。

7.3 编码器维度的选择

不同的编码器产出不同维度的向量。维度d直接影响记忆容量和计算速度。

• 高维度（如OpenAI text-embedding-3-large: 3072）： 表征能力极强，能捕捉细微语义差别，理论记忆容量（指数于d）巨大。但计算和存储开销也大。
• 低维度（如RandomIndexEncoder: 可配置，通常1024）： 速度快，内存省，但只有词袋模型的能力。

经验法则： 从sentence-transformers的all-MiniLM-L6-v2（384维）开始。它在质量、速度和资源消耗上取得了很好的平衡。只有在明确遇到语义区分度不够的问题时，才考虑升级到更高维的编码器。

8. 总结与最佳实践建议

经过一系列的原理剖析和实战演练，我们可以清晰地看到MHN AI Agent Memory的定位：它不是一个通用的“AI大脑”，而是一个专精于高速、确定性联想检索的“海马体”。

它的最佳应用场景包括：

1. AI智能体的工作记忆： 存储当前任务的状态、步骤、临时结果。
2. 高频规则/配置检索： 例如，客服机器人对标准问答库的匹配。
3. 多智能体/多会话的共享上下文： 通过MCP服务器，实现知识的持久化与共享。
4. 作为RAG管道中的快速缓存层： 将最热门的文档片段放在Hopfield内存中，避免频繁查询向量数据库和LLM。

在项目中的集成建议：

• 启动阶段： 使用SentenceTransformerEncoder和small_memory()快速原型验证。
• 数据增长后： 切换到large_memory()，利用其分层存储自动管理热/冷数据。
• 生产环境： 对于核心的、要求极致速度的检索路径，使用MHN。对于背景知识、文档搜索，结合传统的向量数据库。用chain_query或自定义逻辑将两者串联。
• 持续维护： 像维护任何知识库一样，定期审查存储的记忆，去重、修正矛盾、归档过期信息。可以利用ContradictionDetector进行初步的冲突扫描。

最后，记住它的核心优势：确定性与速度。当你需要智能体对相同的输入永远给出相同的记忆反馈，并且需要在微秒内完成时，这个库是目前你能找到的最优雅的解决方案之一。它不是要取代LLM或向量数据库，而是为AI智能体的架构拼图补上了一块长期缺失的关键部件。