> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 用知识图谱实现可移植的AI代理
- URL: https://www.hubwiz.com/blog/build-portable-ai-agents-with-knowledge-graph/
- Published: 2026-02-09T13:20:47.000Z
- Updated: 2026-02-09T13:20:47.000Z
- Description: 为什么学习图谱——而不是语言模型——才是真正的真相来源
- Author: admin
- Tags: AI, CONTEXT ENGINEERING, #Import 2026-10-14 14:41

随着生成式AI的成熟，我们正在看到围绕*代理*、*工具*和*技能*等概念的快速融合。**OpenAI**、**Anthropic**和**Hugging Face**现在都支持某种形式的可重用技能。同时，像**ByteDance**这样的组织已经在强调结构化工作流程和外部编排的代理框架上投入了大量资金。

乍一看，这些生态系统似乎是碎片化的。每个都有自己的API、工具约定和关于智能应该如何组合的哲学假设。这种碎片化给任何构建长期教育系统的人提出了一个明显的问题：

> 我们如何构建在所有这些框架中保持可移植、确定性和一致性的智能教科书——今天和未来？

我们的答案出人意料地简单：

> ***让知识图谱（学习图谱）成为真相来源，并将AI框架视为可互换的执行引擎。***

本文解释了该决策如何使我们在Anthropic、OpenAI、HuggingFace甚至ByteDance风格的代理系统中获得可移植性——无需重写核心逻辑或损害教学完整性。

## 1、核心设计原则：生成之前的结构

我们架构的核心是一个**概念知识图谱**——我们称之为学习图谱。

- 每个节点代表一个概念（例如，*欧姆定律*、*矩阵乘法*、*贝叶斯定理*）
- 每条边代表一个**依赖关系**（先决条件、细化或概念基础）
- 图谱从课程描述生成，并通过编辑概念列表和概念依赖关系迭代细化
- 图谱以**确定性JSON表示**存储，用于生成内容的所有实现中

学习图谱**不是元数据**。学习图谱**不是文档**。学习图谱**不是建议性的**。

学习图谱是教科书生成一切的**单一真相来源**：章节内容、术语表等。其他工件以精确和可重现的依赖链从这些工件生成。

所有内容——章节、术语、解释、示例、练习、模拟、评估、摘要——都从这个结构流出。

![学习图谱示例](https://www.hubwiz.com/blog/content/images/2026/02/1-H2N11GDTW6kRD5hVekDiAg.png)

数学学习图谱的简单示例。每个箭头都是"依赖于理解"另一个概念。

## 2、为什么我们不让模型决定"什么属于上下文"

许多现代代理框架隐式假设模型应该决定：

- 哪些先前信息重要
- 哪些概念相关
- 什么可以安全地总结掉
- 什么上下文可以丢弃以适应窗口

这种方法对于探索性任务（如编码辅助或开放式研究）效果 reasonably 好。但对于教育来说**是危险的**。

教育内容有严格的约束：

- 先决条件不能被跳过
- 概念必须按精确顺序引入
- 术语必须保持稳定
- 解释必须是可重现的
- 细微的遗漏可能导致重大的学习差距

由于这些原因，我们**不**允许模型确定上下文组成。

相反：

> ***上下文是通过遍历知识图谱计算的。***

模型从不猜测哪些先前概念是相关的。 它是被明确、确定性和可重复地告知的。

## 3、知识图谱在上下文构建中的作用

![学习图谱示例](https://www.hubwiz.com/blog/content/images/2026/02/1-h4Cd2Ie_LNZLt8S_OTfkeg.png)

使用mkdocs生成智能教科书的学习图谱示例。

对于每个生成任务，我们执行以下操作：

1. 识别目标概念节点
2. 遍历其依赖链
3. 只选择所需的先决条件概念
4. 应用明确的上下文预算规则
5. 将结构化概念摘要注入提示

这个过程是：

- 确定性的
- 可解释的
- 可审计的
- 独立于任何AI供应商

**JSON图谱表示**确保相同的遍历产生相同的上下文——无论下游使用哪个模型或框架。

## 4、技能作为执行后端，而非决策引擎

![工作流程示例](https://www.hubwiz.com/blog/content/images/2026/02/1-E74D6zZiFKY_XS8c5rDgkw.png)

生成智能教科书的高级工作流程示例，围绕学习图谱的生成展开。此工作流程被简化，以便更容易理解以学习图谱为中心的设计的高级概念。

这种架构选择使我们能够重新构建如何使用技能。

在**OpenAI**、**Anthropic**和**HuggingFace**中，技能通常被定位为*智能行为单元*。在我们的系统中，它们扮演不同的角色。

> ***技能是执行后端，不是规划者。***

技能：

- 接收定义明确的提示
- 在受约束的上下文中操作
- 产生一个工件（文本、JSON、代码、图表）
- 对课程结构没有权威

这种区别对于可移植性至关重要。

## 5、OpenAI的可移植性

使用OpenAI的技能和工具调用：

- 我们将技能绑定到特定工件类型（例如，解释、测验、摘要）
- 提示完全由图谱遍历构建
- 模型从不自行推断依赖关系

交换模型（GPT-4.x → 未来GPT变体）不会影响：

- 概念排序
- 覆盖保证
- 教学正确性

只有文体质量会改变。

## 6、Anthropic的可移植性

Anthropic的Claude Code技能擅长：

- 长形式推理
- 结构化解释
- 谨慎使用源材料

在我们的架构中，Claude的优势被放大，因为：

- 上下文窗口已经优化
- 只包括相关的先决条件概念
- 模型不需要"寻找"意义

关键的是，**Claude从不被要求决定包含什么**——只被要求如何很好地解释它。

这使Claude可以与其他模型互换，同时保持输出一致性。

## 7、HuggingFace的可移植性

HuggingFace的生态系统引入了额外的多样性：

- 开源模型
- 较小的上下文窗口
- 本地或隔离部署

我们的架构自然适应：

- 图谱遍历限制上下文大小
- 摘要是明确和受控的
- 较小的模型接收更简单、范围明确的提示

因为**图谱逻辑是外部的**，我们可以在不触及基础课程的情况下调整摘要和提示结构。

这使我们的系统在专有API不可用的教室、地区和国家中可行。

## 8、ByteDance风格代理框架的可移植性

ByteDance框架如Coze强调：

- 外部工作流程
- 确定性编排
- 工具驱动管道

虽然这些框架在ByteDance之外没有被广泛采用，但**架构哲学与我们的紧密对齐**：

> 系统决定；模型执行。

从这个意义上说，我们的知识图谱驱动的方法是该哲学的**通用、供应商中立版本**。

我们不依赖ByteDance工具——但我们可以干净地部署到它，因为决策逻辑已经存在于模型之外。

## 9、为什么这种架构随时间扩展

AI框架将会改变。

- 上下文窗口将增长
- 模型将变得更便宜
- 工具API将演进
- 一些供应商将消失

我们的架构是有弹性的，因为：

- 知识图谱是稳定的
- 学习图谱的JSON表示是可移植的
- 上下文选择是明确的
- 技能是可替换的
- 模型是可交换的

随着模型改进，我们总结得更少。 随着约束收紧，我们总结得更多。

**学习图谱保持不变**。

## 10、更深层的见解：智能属于结构

我们学到的最重要的教训是：

> ***教育系统中最有价值的智能不是生成式的——它是结构性的。***

大型语言模型在表达、解释和综合方面非常出色。 它们不是课程结构的可靠仲裁者。

通过使知识图谱成为真相来源，我们：

- 保留教学完整性
- 实现真正的可移植性
- 获得可重现性
- 降低供应商风险
- 使我们的内容经得起未来考验

AI框架来来去去。 设计良好的概念结构经久不衰。

## 11、关键要点

技能是强大的。 代理是有用的。 模型是令人印象深刻的。

但**结构才是使智能持久的因素**。

如果你想要在所有地方都能工作的智能教科书——跨越Anthropic、OpenAI、HuggingFace、ByteDance风格的系统以及接下来出现的任何东西——从详细的学习图谱开始，让其他一切都可替换。

这是真正可移植性的基础。

---

原文链接: [Keeping Intelligent Textbook Generation Agents Portable Across AI Frameworks](https://dmccreary.medium.com/keeping-intelligent-textbook-generation-agents-portable-across-ai-frameworks-64a8f5f475d1?ref=hubwiz.com)

汇智网翻译整理，转载请标明出处