docs: 在other.md文件中加入关于astrbot.core.star.Context上下文接口的介绍

[Li-shi-ling]

docs: 在other.md文件中加入关于astrbot.core.star.Context上下文接口的介绍,并添加插件的元数据获取,和插件的注册表获取,以及StarTools的部分介绍

Fixes #105
Fixes #90

由 Sourcery 生成的摘要

文档：

• 为 astrbot.core.star.Context 及其提供者、平台、会话、消息历史、人物设定、知识库和配置管理器补充完整的中文文档，包括使用模式和示例。

Original summary in English

Summary by Sourcery

Documentation:

• Add comprehensive Chinese documentation for astrbot.core.star.Context and its provider, platform, conversation, message history, persona, knowledge base, and configuration managers, including usage patterns and examples.

[sourcery-ai]

嗨，我发现了 4 个问题，并留下了一些总体反馈：

• 在“平台适配器管理器”一节中，描述为 astrbot.core.platform.manager 下的 KnowledgeBaseManager 类似乎是笔误，应该改成对应的平台管理器类名以避免误导读者。
• 删除知识库示例中使用了 loger 变量名，建议统一修改为更常见的 logger 或与项目内实际日志记录器一致的命名，以免用户直接复制示例时出错。
• 在“平台消息历史管理器”部分的示例中直接使用了 history_manager 变量，建议与其它章节保持一致，显式示范通过 self.context.message_history_manager 获取实例，避免让读者误解为需要手动构造该对象。

面向 AI 代理的提示

请根据本次代码评审中的评论进行修改：

## 总体评论
- 在“平台适配器管理器”一节中，描述为 `astrbot.core.platform.manager` 下的 `KnowledgeBaseManager` 类似乎是笔误，应该改成对应的平台管理器类名以避免误导读者。
- 删除知识库示例中使用了 `loger` 变量名，建议统一修改为更常见的 `logger` 或与项目内实际日志记录器一致的命名，以免用户直接复制示例时出错。
- 在“平台消息历史管理器”部分的示例中直接使用了 `history_manager` 变量，建议与其它章节保持一致，显式示范通过 `self.context.message_history_manager` 获取实例，避免让读者误解为需要手动构造该对象。

## 单条评论

### 评论 1
<location> `zh/dev/star/guides/other.md:92` </location>
<code_context>
+
+## 关于知识库管理器
+
+它为 `astrbot.core.knowledge_base.kb_mgr`下的`KnowledgeBaseManager`类别在插件中可以通过`self.context.kb_manager`对这个类别进行访问
+
+## 获取所有数据库名称和id以及其对应的编码器id
</code_context>

<issue_to_address>
**suggestion (typo):** 这句话缺少必要的标点，阅读起来不够顺畅。

建议在“类别”后或“在插件中”前加逗号，例如：
“它为 `astrbot.core.knowledge_base.kb_mgr` 下的 `KnowledgeBaseManager` 类别，在插件中可以通过 `self.context.kb_manager` 对这个类别进行访问。”

```suggestion
它为 `astrbot.core.knowledge_base.kb_mgr` 下的 `KnowledgeBaseManager` 类别，在插件中可以通过 `self.context.kb_manager` 对这个类别进行访问
```
</issue_to_address>

### 评论 2
<location> `zh/dev/star/guides/other.md:542` </location>
<code_context>
+       # 执行嵌入相关操作
+   ```
+
+## 可以通过以下方式查看所有可用供应商
+
+```python
</code_context>

<issue_to_address>
**suggestion (typo):** 前文中“供应商”和“提供商”的用词不完全统一，可能会造成轻微混淆。

本节与前文中“供应商”和“提供商”交替使用，建议在整篇文档内统一为一个术语（如固定为“提供商”或“供应商”），以减少理解成本。

建议实现方式：

```
5. **类型检查**：使用前可检查提供商类型：

```

```
## 可以通过以下方式查看所有可用提供商

```

为在整篇文档中彻底统一术语，建议：
1. 全文搜索“供应商”，并视上下文统一替换为“提供商”（或根据项目整体术语规范反向统一为“供应商”）。
2. 同步检查其他相关文档（如同目录下的指南或概览文档），在标题、段落描述、代码注释和字符串中使用同一术语，以保持用户在阅读多篇文档时的连贯性。
</issue_to_address>

### 评论 3
<location> `zh/dev/star/guides/other.md:557-559` </location>
<code_context>
+---
+---
+
+## 关于平台适配器管理器
+
+它为 `astrbot.core.platform.manager` 下的`KnowledgeBaseManager`类别在插件中可以通过`self.context.platform_manager`对这个类别进行访问
+
+- 注:目前没有提供直接在webui添加自定义平台适配器的代码,如果需要可以通过修改`astrbot.core.config.default` 下的 `CONFIG_METADATA_2`来修改webui(该方法并不正式,可能会在未来被修复),并且需要在代码注册对应的提供商
</code_context>

<issue_to_address>
**issue:** 平台适配器管理器的类名描述似乎有误，容易与知识库管理器混淆。

这里实际介绍的是“平台适配器管理器”，但文案中引用的是 `KnowledgeBaseManager`，容易让人误解为仍在介绍知识库管理器。建议将类名改为对应的平台管理类的实际名称，并在“类别”后加上逗号，例如：`它为 �astrbot.core.platform.manager� 下的 `<实际类名>` 类别，在插件中可以通过 �self.context.platform_manager� 对这个类别进行访问。`
</issue_to_address>

### 评论 4
<location> `zh/dev/star/guides/other.md:682` </location>
<code_context>
+}
+```
+
+## 注意项
+
+以上代码都是和前端代码高度绑定的,直接在代码进行操作是不明智的
</code_context>

<issue_to_address>
**suggestion (typo):** 小节标题“注意项”略显别扭，建议改为更常见的“注意事项”。

在中文技术文档中更常见的写法是“注意事项”，这样更符合读者的阅读习惯。

```suggestion
## 注意事项
```
</issue_to_address>

---

Sourcery 对开源项目免费——如果你觉得我们的评审有帮助，欢迎分享 ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{请帮助我变得更有用！欢迎在每条评论上点击 👍 或 👎，我会根据你的反馈改进之后的评审。}

Original comment in English

Hey - I've found 4 issues, and left some high level feedback:

• 在“平台适配器管理器”一节中，描述为 astrbot.core.platform.manager 下的 KnowledgeBaseManager 类似乎是笔误，应该改成对应的平台管理器类名以避免误导读者。
• 删除知识库示例中使用了 loger 变量名，建议统一修改为更常见的 logger 或与项目内实际日志记录器一致的命名，以免用户直接复制示例时出错。
• 在“平台消息历史管理器”部分的示例中直接使用了 history_manager 变量，建议与其它章节保持一致，显式示范通过 self.context.message_history_manager 获取实例，避免让读者误解为需要手动构造该对象。

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- 在“平台适配器管理器”一节中，描述为 `astrbot.core.platform.manager` 下的 `KnowledgeBaseManager` 类似乎是笔误，应该改成对应的平台管理器类名以避免误导读者。
- 删除知识库示例中使用了 `loger` 变量名，建议统一修改为更常见的 `logger` 或与项目内实际日志记录器一致的命名，以免用户直接复制示例时出错。
- 在“平台消息历史管理器”部分的示例中直接使用了 `history_manager` 变量，建议与其它章节保持一致，显式示范通过 `self.context.message_history_manager` 获取实例，避免让读者误解为需要手动构造该对象。

## Individual Comments

### Comment 1
<location> `zh/dev/star/guides/other.md:92` </location>
<code_context>
+
+## 关于知识库管理器
+
+它为 `astrbot.core.knowledge_base.kb_mgr`下的`KnowledgeBaseManager`类别在插件中可以通过`self.context.kb_manager`对这个类别进行访问
+
+## 获取所有数据库名称和id以及其对应的编码器id
</code_context>

<issue_to_address>
**suggestion (typo):** 这句话缺少必要的标点，阅读起来不够顺畅。

建议在“类别”后或“在插件中”前加逗号，例如：
“它为 `astrbot.core.knowledge_base.kb_mgr` 下的 `KnowledgeBaseManager` 类别，在插件中可以通过 `self.context.kb_manager` 对这个类别进行访问。”

```suggestion
它为 `astrbot.core.knowledge_base.kb_mgr` 下的 `KnowledgeBaseManager` 类别，在插件中可以通过 `self.context.kb_manager` 对这个类别进行访问
```
</issue_to_address>

### Comment 2
<location> `zh/dev/star/guides/other.md:542` </location>
<code_context>
+       # 执行嵌入相关操作
+   ```
+
+## 可以通过以下方式查看所有可用供应商
+
+```python
</code_context>

<issue_to_address>
**suggestion (typo):** 前文中“供应商”和“提供商”的用词不完全统一，可能会造成轻微混淆。

本节与前文中“供应商”和“提供商”交替使用，建议在整篇文档内统一为一个术语（如固定为“提供商”或“供应商”），以减少理解成本。

Suggested implementation:

```
5. **类型检查**：使用前可检查提供商类型：

```

```
## 可以通过以下方式查看所有可用提供商

```

为在整篇文档中彻底统一术语，建议：
1. 全文搜索“供应商”，并视上下文统一替换为“提供商”（或根据项目整体术语规范反向统一为“供应商”）。
2. 同步检查其他相关文档（如同目录下的指南或概览文档），在标题、段落描述、代码注释和字符串中使用同一术语，以保持用户在阅读多篇文档时的连贯性。
</issue_to_address>

### Comment 3
<location> `zh/dev/star/guides/other.md:557-559` </location>
<code_context>
+---
+---
+
+## 关于平台适配器管理器
+
+它为 `astrbot.core.platform.manager` 下的`KnowledgeBaseManager`类别在插件中可以通过`self.context.platform_manager`对这个类别进行访问
+
+- 注:目前没有提供直接在webui添加自定义平台适配器的代码,如果需要可以通过修改`astrbot.core.config.default` 下的 `CONFIG_METADATA_2`来修改webui(该方法并不正式,可能会在未来被修复),并且需要在代码注册对应的提供商
</code_context>

<issue_to_address>
**issue:** 平台适配器管理器的类名描述似乎有误，容易与知识库管理器混淆。

这里实际介绍的是“平台适配器管理器”，但文案中引用的是 `KnowledgeBaseManager`，容易让人误解为仍在介绍知识库管理器。建议将类名改为对应的平台管理类的实际名称，并在“类别”后加上逗号，例如：`它为 �astrbot.core.platform.manager� 下的 `<实际类名>` 类别，在插件中可以通过 �self.context.platform_manager� 对这个类别进行访问。`
</issue_to_address>

### Comment 4
<location> `zh/dev/star/guides/other.md:682` </location>
<code_context>
+}
+```
+
+## 注意项
+
+以上代码都是和前端代码高度绑定的,直接在代码进行操作是不明智的
</code_context>

<issue_to_address>
**suggestion (typo):** 小节标题“注意项”略显别扭，建议改为更常见的“注意事项”。

在中文技术文档中更常见的写法是“注意事项”，这样更符合读者的阅读习惯。

```suggestion
## 注意事项
```
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[Li-shi-ling]

上传附带的介绍怎么不见了.我添加一点关于插件的注册表,元数据的获取方法

[Li-shi-ling]

上传附带的介绍没有是因为我填错位置了,emmm,我变基修改了一下重新上传了

[Li-shi-ling]

反正都写了,要不帮忙解决一下iss #90