快速摘要
Feeling AI 团队自研的 CodeBrain-1 智能体框架，在斯坦福大学与 Laude Institute 联合打造的权威评测基准 Terminal-Bench 2.0 上拿下全球第二名（70.3%），仅次于 OpenAI 官方的 Simple Codex（74.9%）。这意味着一个中国初创团队在「AI 智能体自主完成真实命令行任务」这一前沿赛道上，已经具备了与硅谷顶尖机构正面较量的实力。 本文将从底层原理出发，详细拆解 Terminal-Bench 2.0 到底在测什么、CodeBrain-1 的核心技术架构是如何设计的、以及 Agentic Memory 和 Agentic Coding 这两个热门方向为何值得所有开发者关注。如果你对 AI Agent 的工程落地感兴趣，往下看有更详细的拆解。
—— 莫潇羽@无忆研习社（www.wuyi.wiki）
一、从「跑分竞赛」到「实战进化」：大模型竞争格局正在被改写
2025 年下半年到 2026 年初，全球大模型领域迎来了一轮密集的产品更新。Anthropic 推出了 Claude Opus 4.6，OpenAI 则以 GPT-5.3-Codex 作为回应，Google 的 Gemini 3 系列也在快速迭代。但如果你仔细观察这一轮竞争，会发现一个关键变化：各家巨头的关注点已经不再是「模型参数谁更大」或「通用跑分谁更高」，而是集中到了一个更务实的问题上——你的 AI 能不能在真实的工作环境中，自主地把一件复杂的事情做完？
这个问题的术语表达就是 Agentic AI（智能体 AI）。所谓 Agent（智能体），简单来说就是一个能够自主规划、执行、反馈和纠错的 AI 系统。它不像传统的对话式 AI 那样「你问一句我答一句」，而是能够接过一个复杂任务，自己拆解步骤、调用工具、处理中间错误，最终交付一个完整的结果。
举一个直观的例子来帮助理解：假设你需要在一台 Linux 服务器上部署一个机器学习模型的推理服务，传统的做法是你一步步输入命令——安装依赖、配置环境、编写服务脚本、测试端口……每一步都需要人来判断和操作。而一个理想的 AI Agent 可以接收到「请在这台服务器上部署模型推理服务」的指令后，自主完成上述所有步骤，遇到报错还能自行排查和修复。
这正是 Terminal-Bench 2.0 要测试的核心能力，也是 CodeBrain-1 所展现出的强悍实力所在。
莫潇羽在这里想多说一句（www.wuyi.wiki）：理解这个背景很重要。因为如果你还在用「模型能力 = MMLU 跑分」的思维来衡量当前的 AI 技术水平，可能会错过真正重要的技术变革。2026 年的 AI 竞争，核心战场已经转移到了 Agent 层面。
二、Terminal-Bench 2.0 到底是什么？为什么巨头都在上面较量？
2.1 一句话定义
Terminal-Bench 是由斯坦福大学（Stanford University）与 Laude Institute 联合打造的开源评测基准，官方网站是 https://www.tbench.ai，GitHub 仓库在 https://github.com/laude-institute/terminal-bench。它被业界公认为 AI 智能体在真实命令行（CLI）环境下端到端执行能力的「金标准」。
2.2 它与普通代码评测有什么本质区别？
很多朋友可能听说过 HumanEval、MBPP 甚至 SWE-bench 这些代码评测基准。Terminal-Bench 与这些测试的根本区别在于：它不是让 AI 在一个虚拟的、纯文本的环境里「生成一段代码片段然后检查输出」，而是把 AI 扔进一个真实的、隔离的 Docker 容器中，要求它像一个资深工程师那样，在完整的 Linux 生态中自主完成从编译、调试、训练到部署的全流程任务。
下面莫潇羽用一个对照表帮你理解它们的区别（无忆研习社原创整理）：
|
维度 |
传统代码生成评测（如 HumanEval） |
Terminal-Bench 2.0 |
|
任务形式 |
给一个函数签名，生成函数体 |
给一段自然语言任务描述，在真实终端中自主完成 |
|
执行环境 |
代码沙箱，通常只有单一语言运行时 |
完整 Linux Docker 容器，含文件系统、网络、多种工具链 |
|
评判标准 |
输出是否匹配预期结果 |
0/1 严格判定，必须通过所有 pytest 测试用例，产出符合预期的交付物 |
|
任务复杂度 |
通常可在几行到几十行代码内完成 |
需要多步骤长链操作，涉及编译、配置、调试等系统级操作 |
|
是否允许交互 |
一次性生成，无法交互 |
Agent 与终端持续交互，可以观察输出、调整策略 |
|
是否有「模糊分」 |
部分评测有部分得分 |
完全没有，要么通过要么失败 |
2.3 Terminal-Bench 2.0 的核心设计特点
为了让不熟悉这个评测的朋友有更清晰的理解，莫潇羽@无忆研习社在这里梳理一下 Terminal-Bench 2.0 的几个关键设计特点：
闭环实战环境。 每一个任务都运行在一个独立的 Docker 容器中。AI 智能体拿到的不是一道「编程题」，而是一个真实的操作系统环境——里面有文件系统、有预装的软件包、有需要处理的数据文件，有时候甚至有需要调试的错误代码。AI 必须像一个人类工程师坐在终入命令来完成任务。这种设置确保了评测结果反映的是真实世界中的工程能力，而不是「在考试中猜对答案」的技巧。
高压长程任务。 Terminal-Bench 2.0 包含 89 个精心设计的深度场景，横跨软件工程、科学计算、系统管理等多个领域。这些任务的关键特点是不能通过简单的模式匹配来解决。比如，有一个经典任务是「从源码编译 Linux 内核 6.9」——这个任务涉及到理解内核配置、处理依赖关系、应对编译错误等多个环节，每一步都需要 AI 具备真实的系统理解能力。
零容忍验证。 Terminal-Bench 2.0 采用 0/1 二元判定准则。每个任务完成后，系统会运行预先编写好的 pytest 测试脚本来验证结果——只有所有测试全部通过，才算成功。不存在「做对了一半给一半分」的情况。这种严苛的评判方式意味着，Agent 不仅要能「做」，还必须做得「对」且「完整」。
2.0 版本的难度升级。 相比 1.0 版本，Terminal-Bench 2.0 在任务质量和验证严谨性方面做了大幅提升。1.0 版本中存在一些因外部依赖变化（比如 YouTube 的反爬机制更新）而导致不稳定的任务，这些在 2.0 中都被修正或替换了。同时，每个任务都经过了数小时的人工和 LLM 辅助验证，确保任务的可解性和评测的可复现性。即便如此，当前全球顶尖模型和 Agent 的解决率仍然普遍难以突破 65%，这说明 Terminal-Bench 2.0 确实是大模型处理系统级复杂任务的「深水区」。
2.4 Terminal-Bench 的运行方式
从技术实现角度来看，Terminal-Bench 2.0 是通过一个叫做 Harbor 的配套框架来运行的。Harbor 是 Terminal-Bench 团队同步发布的开源评测执行框架，支持在云端大规模并行运行容器化的 Agent 评测任务。
一个典型的评测流程是这样的：
# 安装 Harbor 并运行 Terminal-Bench 2.0 评测
harbor run -d terminal-bench@2.0 -a "你的Agent" -m "你的模型" -k 5这条命令的含义是：使用 Harbor 框架，运行 Terminal-Bench 2.0 数据集，-k 5` 表示每个任务重复 5 次取成功率。评测时，Harbor 会为每个任务启动一个独立的 Docker 容器，Agent 通过标准输入输出与容器中的终端进行交互，最终由 pytest 脚本来判定任务是否完成。
2.5 任务示例：让你感受真实的评测难度
为了帮助大家建立更直观的认知，这里引用 Terminal-Bench 官方公开的两个任务描述作为示例：
任务一：训练 FastText 模型
请在data/文件夹中的 Yelp 数据上训练一个 FastText 模型。最终模型大小需小于 150MB，但需要在一个来自同分布的私有测试集上达到至少 0.62 的准确率。模型应保存为/app/model.bin。
这个任务看似简单，但 Agent 需要自己搞清楚数据格式、选择合适的 FastText 参数、在模型大小约束下优化准确率——这一系列决策都需要真实的工程判断力。
任务二：搭建安全的 Jupyter Notebook 服务器
安装 Jupyter Notebook 及必要依赖，配置服务器在 8888 端口运行、接受任意 IP 连接、使用密码认证（密码为 "benchmarkpass"）、生成自签名 SSL 证书，创建包含特定内容的示例 Notebook，最后在后台启动 Jupyter 服务器。
这个任务涉及到系统管理、安全配置、SSL 证书生成等多个知识领域的综合运用，对 Agent 的「全栈能力」提出了很高的要求。
三、CodeBrain-1 技术架构深度解析
3.1 CodeBrain-1 是什么？
CodeBrain-1 是由中国的 AI 初创团队 Feeling AI 自主研发的一款 Agent 框架（也可以理解为 Agent 的「大脑」）。请注意这个定义中的关键词——它不是一个大语言模型（LLM），而是一个运行在大模型之上的智能调度和执行框架。
打个比方来帮助理解：如果把大语言模型比作一个极其聪明但「没有手脚」的大脑，那么 Agent 框架就相当于给这个大脑装上了四肢、感官和条件反射系统。大脑（LLM）提供的是理解和推理能力，而框架（CodeBrain-1）提供的是如何把这些能力组织起来、高效地应用到真实任务中的方法论。
在 Terminal-Bench 2.0 的评测中，CodeBrain-1 搭配 GPT-5.3-Codex 作为底座模型，以 70.3% 的综合通过率位居全球第二。下面莫潇羽带你逐层拆解它的核心技术实现。
3.2 核心技术一：Useful Context Searching——只用「真正有用」的上下文
问题背景：为什么不能把所有信息都塞给模型？
在实际的编码任务中，一个项目的代码库可能有成千上万个文件、数十万行代码。当 AI 需要编写或修改某段代码时，理论上它需要了解相关的 API 签名、函数用法、已有的代码模式等上下文信息。但大语言模型的上下文窗口是有限的（即便是当前最先进的模型，有效注意力窗口也有上限），而且研究已经反复证明：塞入过多不相关的信息不仅不会帮助模型，反而会导致注意力分散，增加「幻觉」（hallucination）的概率。
所谓「幻觉」，就是模型「一本正经地胡说八道」——它会生成看起来合理但实际上不存在的 API 调用，或者编写出语法正确但逻辑完全错误的代码。在传统的对话场景中，幻觉可能只是一个「有趣的错误」；但在 Terminal-Bench 2.0 的闭环环境中，一个幻觉调用会直接导致运行报错，进而引发一连串的级联失败。
CodeBrain-1 的解决方案：基于 LSP 的精准上下文检索
CodeBrain-1 引入了 LSP（Language Server Protocol，语言服务器协议） 作为核心的上下文检索机制。LSP 是由微软最初设计的一套开放标准协议，它定义了代码编辑器与语言分析服务器之间的通信方式。简单来说，LSP 能够像一个「代码百科全书」一样，为你提供任何符号的定义、引用、类型信息和文档注释。
在日常开发中，当你在 VS Code 里把鼠标悬停在一个函数名上时弹出的文档提示、按下 Ctrl+Click 跳转到定义、输入几个字母后弹出的自动补全建议——这些功能的底层都是由 LSP 驱动的。
CodeBrain-1 的创新之处在于：它把 LSP 这套原本服务于人类开发者的代码智能工具，改造为了服务于 AI Agent 的上下文检索引擎。 具体的工作流程是这样的：
任务输入
↓
CodeBrain-1 分析当前任务需求
↓
根据需求关键词，对已有 Code Base 建立索引
↓
通过 LSP 查询获取精准的上下文信息：
- 相关 API 的方法签名（参数类型、返回值）
- 方法的文档注释
- 代码库中该方法的已有使用示例
↓
将筛选后的「精准上下文」注入模型的 Prompt
↓
模型基于高质量上下文生成代码实际案例：游戏 Bot 的任务规划
文档中提到了一个具体的案例来说明这一机制的效果。假设 CodeBrain-1 需要为一个游戏 Bot 编写任务规划代码，它首先需要了解该 Bot 的 API 有哪些可用的方法。
在传统的做法中，Agent 可能会尝试把整个 Bot SDK 的文档都塞进上下文——这不仅浪费 Token，还会引入大量无关信息。而 CodeBrain-1 会通过 LSP Search，精确地获取到与当前任务直接相关的方法信息：
# LSP 检索返回的精准上下文示例
# 方法签名
def move_to(target: Position) -> bool:
"""
将 Bot 移动到指定位置。
Args:
target: 目标位置坐标
Returns:
是否成功到达目标位置
"""
...
def do(action: ActionType) -> ActionResult:
"""
执行指定动作。
Args:
action: 要执行的动作类型
Returns:
动作执行结果
"""
...CodeBrain-1 只获取了 move_to(target) 和 do(action) 这两个与当前任务直接相关的方法签名、文档和使用示例，而不是把整个 SDK 的数百个方法都丢给模型。这种精准的上下文供给极大地降低了噪声干扰，使得模型能够更准确地生成代码。
对小白的解释
如果你完全不了解编程也没关系。你可以这样理解：想象你要写一篇关于某个历史事件的论文。传统做法是把图书馆里所有相关的书都搬到你桌上——信息是够了，但你被淹没了，很可能写着写着就把不同书里的内容搞混了。CodeBrain-1 的做法相当于有一个极其靠谱的图书管理员，他能根据你当前正在写的段落，精确地只把最相关的那几页资料递到你面前。你需要的信息一个不少，干扰你的噪音也一个没有。
3.3 核心技术二：Validation Feedback——让失败真正变成信息
问题背景：AI 写代码出错了怎么办？
在真实的软件开发中，代码写出来一次就完全正确的情况是极少的。即使是经验丰富的人类程序员，也需要经历「编写 → 运行 → 报错 → 修改」的迭代循环。对于 AI Agent 来说同样如此——关键不在于它是否会犯错，而在于它能否从错误中高效地提取有用信息，然后快速修正。
传统的 Agent 框架在处理代码错误时，通常的做法比较粗暴：把报错信息原封不动地丢回给模型，让模型「看着办」。这种方式的问题在于，编译器或解释器的报错信息通常很简略（比如一个 TypeError: argument type mismatch 就完事了），模型拿到这个信息后，往往需要花大量的 Token 去「猜」到底哪里出了问题，这不仅效率低下，还容猜错」方向导致越改越远。
CodeBrain-1 的解决方案：LSP Diagnostics 驱动的富错误反馈
CodeBrain-1 利用 LSP Diagnostics 能力，在代码出错时不仅捕获错误信息本身，还会自动补充一系列与错误直接相关的上下文，构建出一个「富错误反馈包」。
举一个文档中提到的实际例子：当 CodeBrain-1 编写的代码中调用 on(observation, exec) 方法（这是一个用来定义 Bot 反应行为的方法）时，出现了参数 exec 的类型错误。在这个场景下，CodeBrain-1 的处理流程如下：
代码执行/检查
↓
LSP Diagnostics 捕获错误：argument type mismatch
↓
CodeBrain-1 自动补充以下上下文信息：
├── 该方法 on() 的完整签名和参数说明
├── 代码库中其他地方调用 on() 方法的正确示例（caller 示例）
├── exec 参数的类型定义和文档说明
└── exec 参数在实际实现中是如何被使用的
↓
将「错误信息 + 富上下文」一起传递给模型
↓
模型基于充分信息进行精准修复这种做法的效果可以用一组对比来说明（无忆研习社 莫潇羽整理）：
|
维度 |
传统 Agent 的错误处理 |
CodeBrain-1 的错误处理 |
|
错误信息 |
|
同上 + 方法签名 + 正确调用示例 + 参数文档 |
|
模型需要做的事 |
猜测哪个参数类型错了，猜测正确类型是什么 |
直接看到正确的类型定义和使用方式 |
|
修复轮次 |
可能需要 3-5 轮尝试 |
通常 1 轮即可修复 |
|
Token 消耗 |
大量 Token 用于「试错」 |
Token 集中用于「修正」 |
Generate → Validate 循环的优化
这个设计的本质是大幅缩减了 Agent 的「Generate → Validate」循环次数。在软件工程中，这个循环可以类比为「编码 → 测试 → 修复」的迭代过程。每多循环一次，就意味着更多的时间消耗和 Token 开销。CodeBrain-1 通过在错误发生的瞬间就提供全面的诊断信息，让模型能够「一次修对」，而不是「反复试错」。
根据 Feeling AI 披露的对比数据，当底座模型都使用 Claude Opus 4.6 时，CodeBrain-1 相比 Claude Code（Anthropic 的官方编码 Agent）在两者均成功完成的 Python 子任务上，总 Token 消耗大幅缩减了超 15%。这个数字在实际的工程应用中意义重大——Token 消耗的降低不仅意味着更快的执行速度，也意味着更低的 API 调用费用。
3.4 核心设计哲学：不让 AI 「随意发挥」，而是重新定义分工
如果说上面两个技术点是 CodeBrain-1 的「硬件能力」，那么它背后的设计哲学则更值得关注。
传统的编码 Agent 设计思路通常是：把任务描述和相关信息一股脑丢给模型，然后让模型「自由发挥」——从理解任务、制定计划、写代码到调试修复，全部由模型的「思维链」（Chain of Thought）来完成。这种方式的问题在于，当任务复杂度增加时，模型很容易在长链推理中「走偏」，出现所谓的「过度思考」现象——花了大量 Token 在推理链上兜圈子，但实际的行动效率却很低。
CodeBrain-1 的设计思路是完全不同的：它并非让 AI 直接「随意发挥」，而是反过来调整人（框架）和 AI（模型）的分工方式。
具体来说，CodeBrain-1 扮演的是一个「调度中枢」和「效率校准器」的角色：
- 在常规操作中，CodeBrain-1 引导模型保持极速响应——快速执行标准化的步骤，不做多余的「思考」
- 在遭遇关键报错或需要决策的节点时，才激活模型的深层推理能力
- 框架负责「在什么时候做什么事」的决策逻辑，模型负责「这件事具体怎么做」的执行能力
这种设计巧妙地避免了大模型在长链任务中容易出现的两个极端：要么因为「想太多」而效率低下，要么因为「想太少」而遗漏关键细节。CodeBrain-1 通过动态调节推理深度，在速度和准确性之间找到了一个精妙的平衡点。
四、Terminal-Bench 2.0 榜单详细解读
4.1 全球前十排名
根据 Terminal-Bench 2.0 官方排行榜（数据来源：https://www.tbench.ai/leaderboard/terminal-bench/2.0）的最新数据，莫潇羽@无忆研习社为你整理了前十名的具体成绩：
排名 Agent 框架 底座模型 Python子集 编码任务 总体成绩
─────────────────────────────────────────────────────────────────────────────
1 Simple Codex GPT-5.3-Codex 73.9% 72.7% 74.9%
2 CodeBrain-1 GPT-5.3-Codex 72.3% 70.2% 70.3%
3 Droid Claude Opus 4.6 70.2% 66.8% 69.9%
4 Mux GPT-5.3-Codex 71.9% 69.2% 68.5%
5 Droid GPT-5.2 66.0% 61.6% 65.1%
6 Ante Gemini 3 Pro 66.8% 62.7% 64.9%
7 Terminus 2 GPT-5.3-Codex 64.7% 61.4% 64.7%
8 Junie CLI Gemini 3 Flash 68.9% 62.7% 64.3%
9 Droid Claude Opus 4.5 62.1% 58.3% 63.1%
10 Terminus 2 Claude Opus 4.6 67.2% 63.1% 62.9%4.2 几个值得关注的数据看点
看点一：CodeBrain-1 是前十中唯一的中国团队作品。 其他选手要么是硅谷巨头的官方产品（如 OpenAI 的 Simple Codex），要么是来自知名海外 AI 工程公司的产品（如 Factory 的 Droid、Warp 的 Mux）。一个中国初创团队能在这样的阵容中占据第二的位置，其工程能力可见一斑。
看点二：同一底座模型下，Agent 框架的差异巨大。 仔细看榜单你会发现，使用同一个底座模型 GPT-5.3-Codex 的 Agent 有好几个（Simple Codex、CodeBrain-1、Mux、Terminus 2），但它们的成绩差异从 74.9% 到 64.7%，跨度超过 10 个百分点。这清楚地说明了：在当前的 AI 技术生态中，底座模型的能力固然重要，但 Agent 框架如何调度和使用模型的能力，同样是决定最终效果的关键变量。
看点三：Python 子集上 CodeBrain-1 与榜首差距极小。 在 Python 子任务上，CodeBrain-1 的 72.3% 与 Simple Codex 的 73.9% 仅有 1.6 个百分点的差距，几乎处于同一水平线。这表明 CodeBrain-1 在单一语言的深度编码任务上已经非常接近当前的最优水平。
看点四：Feeling AI 团队还专门筛选了一个 47 任务的 Python 聚焦子集进行了额外测试。 在这个更聚焦的子集中，CodeBrain-1 展现出了稳定而一致的完成能力——在关联代码和文档检索方面更高效，在代码检查和验证失败时能更快定位问题。这种针对性的评测进一步验证了其核心技术机制的有效性。
4.3 理解「模型 + Agent 框架」的组合逻辑
这个榜单揭示了一个非常重要的行业趋势：模型与 Agent 框架的良好组合，正在成为大模型实际应用的标准形态。
莫潇羽在这里（www.wuyi.wiki）画一个简单的示意来帮助理解：
┌─────────────────────────────────────────────┐
│ 用户的任务需求 │
└──────────────────┬──────────────────────────┘
↓
┌─────────────────────────────────────────────┐
│ Agent 框架（如 CodeBrain-1） │
│ │
│ ┌─────────────┐ ┌──────────────────────┐ │
│ │ 任务分解 │ │ 上下文检索（LSP） │ │
│ └─────────────┘ └──────────────────────┘ │
│ ┌─────────────┐ ┌──────────────────────┐ │
│ │ 执行调度 │ │ 错误反馈与修复 │ │
│ └─────────────┘ └──────────────────────┘ │
│ ┌─────────────┐ ┌──────────────────────┐ │
│ │ 策略调整 │ │ Token 效率优化 │ │
│ └─────────────┘ └──────────────────────┘ │
└──────────────────┬──────────────────────────┘
↓
┌─────────────────────────────────────────────┐
│ 底座模型（如 GPT-5.3-Codex） │
│ 提供：语言理解、代码生成、逻辑推理能力 │
└─────────────────────────────────────────────┘这个架构意味着，未来的 AI 工程应用不会是一个单一模型包打天下，而是「模型负责能力，框架负责智慧」的协同模式。OpenAI 自己也在其官方博客中明确将 Simple Codex 定义为「针对长程软件工程任务的最优解」，进一步印证了这一趋势。
五、从 MemBrain 到 CodeBrain：Feeling AI 的技术布局全景
5.1 MemBrain 1.0——Agentic Memory 方向的第一张牌
在 CodeBrain-1 发布之前不久，Feeling AI 就已经在另一个热门技术方向上打出了第一张牌。他们发布的 MemBrain 1.0 是一个面向 Agent 的层级化记忆系统，在 LoCoMo、LongMemEval、PersonaMem-v2 等多项主流记忆基准评测中拿下了全新的最优水平（SOTA），超越了 MemOS、Zep 和 EverMemOS 等知名记忆系统。
更令人印象深刻的是，在 KnowMeBench Level III（这是当前最高难度的记忆评测之一）的两个最高难度等级中，MemBrain 1.0 的成绩比此前的最优结果提升了超过 300%。
Agentic Memory 是什么？为什么重要？
这里莫潇羽要为不太熟悉这个概念的朋友做一些科普（无忆研习社原创讲解）。
所谓 Agentic Memory（智能体记忆），指的是让 AI Agent 拥有跨会话、持久化的记忆能力。当前主流的大语言模型有一个根本性的局限：它们是「无状态」的——每次对话都是从零开始，前一次对话中的所有信息在新的会话中完全消失。
这就好比你每天去同一家咖啡店，但店员每次都不认识你，你每次都要重新说一遍「我要中杯美式不加糖」。而 Agentic Memory 要解决的就是让 AI 拥有「记住你」的能力——不仅记住你的偏好，还能记住过去交互中积累的经验教训，并在未来的任务中加以应用。
在 Agent 的工程实践中，记忆能力的缺失会带来几个严重问题：
- Agent 无法从过去的成功经验中学习，每次遇到类似问题都从零开始解决
- Agent 无法记住用户的个性化偏好和上下文，体验缺乏连贯性
- 在长程任务中，Agent 无法有效地维护任务状态和中间结果
- 在多 Agent 协作场景中，Agent 之间无法共享知识和经验
MemBrain 1.0 的设计理念是建立一套适配模型原生的层级化记忆系统。所谓「层级化」，是模指它拟了人类记忆的层次结构——短期记忆（工作记忆）、情景记忆（特定事语件的记忆）和义记忆（通用知识的记忆）。不同层级的记忆有不同的存储策略和检索机制，确保 Agent 在需要特定信息时能够高效地找到它。
5.2 InteractBrain 架构：技术全局视角
MemBrain 和 CodeBrain 并非两个孤立的产品，它们都属于 Feeling AI 提出的一套更大的技术架构—— 跨模态分层架构。这套架构包含三层核心能力：
┌─────────────────────────────────────────────────────┐
│ InteractBrain（大脑层） │
│ 负责：理解、记忆与规划 │
│ 已发布产品：MemBrain 1.0, CodeBrain-1 │
├─────────────────────────────────────────────────────┤
│ InteractSkill（技能层） │
│ 负责：具体能力的执行 │
│ （尚未公开详细产品） │
├─────────────────────────────────────────────────────┤
│ InteractRender（渲染层） │
│ 负责：结果的渲染与呈现 
