在 AgentScope 框架中通过自定义中间件把阿里云百炼 Knowledge Studio 作为智能体的知识记忆体,实现 static 静态注入与 agentic 自主检索两种模式
本实践面向使用 AgentScope 作为 runtime 托管智能体的开发者,展示如何通过自定义中间件把阿里云百炼 Knowledge Studio 接入 AgentScope Agent,作为智能体的知识记忆体。全流程高代码实现,不依赖控制台手动操作。文中示例代码实现基于 AgentScope 2.0.4 版本。
原理:知识库作为智能体的记忆体
大模型本身无状态,每次推理独立。AgentScope 通过中间件机制为智能体注入外部能力,RAG 检索、长期记忆、链路追踪等均以中间件形式挂载,无需修改智能体核心逻辑。
AgentScope 内置了 RAGMiddleware,它接收一组 KnowledgeBase 对象(封装了本地嵌入模型和向量库),在推理前注入检索结果。但阿里云百炼 Knowledge Studio 是托管服务,嵌入、向量存储、检索全部在服务端完成,不需要本地向量库。
本实践的做法是:编写一个自定义中间件 KnowledgeStudioRAGMiddleware,直接调用 Knowledge Studio 的知识检索 API,通过两种模式把检索结果接入 AgentScope Agent:
| 模式 | 触发时机 | 实现方式 | 对应 AgentScope 中间件 hook |
|---|---|---|---|
| static | 每次 reply 的首次推理前 | 把用户消息作为检索 query,结果注入 system prompt | on_system_prompt |
| agentic | 模型自主判断 | 暴露 search_knowledge 工具,Agent 自主调用 | list_tools |
AgentScope 中间件有 6 个 hook 位置。本实践用到两个:
on_system_prompt(Transformer 型,串行接力修改系统提示)和 list_tools(Tool source 型,声明中间件提供的工具)。详见 AgentScope 中间件文档。环境准备
安装依赖
准备参数
| 参数 | 获取方式 | 示例 |
|---|---|---|
| DashScope API Key | 设置 → API Key 页创建 | sk-xxxxxxxx |
| Workspace ID | 控制台 URL 中的业务空间 ID | llm-xxxxxxxx |
| 知识检索服务 ID | 在知识服务 → 知识检索创建并发布后获取 | aid-xxxxxxxx |
第一步:通过 API 搭建知识库
知识库的搭建(文件上传 → 创建索引 → 导入)全部通过 API 完成。以下封装为可复用函数,完整 API 细节见 创建知识库并导入 和 文件注册。
第二步:封装检索客户端
把 Knowledge Studio 的知识检索 API 封装成轻量类,供中间件调用。知识检索 API 基于已发布的检索服务(agent),检索策略(rerank、top_k 等)在控制台配置,调用时只需传入 agent_id 和查询意图。
第三步:实现 KnowledgeStudioRAGMiddleware
这是本实践的核心,一个自定义 MiddlewareBase 子类,同时实现 static 和 agentic 两种模式。参考 AgentScope 内置 RAGMiddleware 的设计,但检索后端改为 Knowledge Studio API。
AgentScope 的
ToolBase 是抽象基类,自定义工具需要实现:- 类属性
name、description、input_schema(JSON Schema 格式) - 类属性
is_concurrency_safe、is_read_only(权限与并发控制) check_permissions方法(返回PermissionDecision,搜索工具直接 ALLOW)call方法(async generator,yield ToolChunk返回结果)
第四步:组装并运行 Agent
用 DashScopeChatModel + KnowledgeStudioRAGMiddleware 组装 AgentScope Agent,展示两种模式的端到端运行。
创建模型和 Agent
模式一:static 静态注入
on_system_prompt,中间件自动执行检索并把结果拼进 system prompt,模型无需感知检索过程。
模式二:agentic 自主检索
search_knowledge 工具。
两种模式叠加
AgentScope 允许同时挂两个不同 mode 的实例,既自动注入,又提供按需工具:
模式对比与选型
| 维度 | static 静态注入 | agentic 自主检索 | 叠加模式 |
|---|---|---|---|
| 检索决策 | 固定(每次推理前都检索) | 模型自主(按需) | 两者兼有 |
| AgentScope hook | on_system_prompt | list_tools | 两个都用 |
| 上下文长度 | 每次注入 top_k 条切片 | 工具结果按需进入 | 两者叠加 |
| 多轮检索 | 不支持(一次检索定结果) | 支持(模型可多轮调用工具) | 支持 |
| 适用场景 | FAQ 问答、意图明确 | 复杂问答、需要判断是否查 | 高可靠性场景 |
| 与内置 RAGMiddleware | 设计一致(static 模式) | 设计一致(agentic 模式) | 设计一致 |
本实践的自定义中间件在设计上与 AgentScope 内置的
RAGMiddleware 保持一致,两种模式、相同的参数命名(mode、top_k)。区别在于检索后端:内置 RAGMiddleware 依赖本地 KnowledgeBase(嵌入模型和向量库),本实践的中间件直接调用 Knowledge Studio 知识检索 API。扩展:与 AgentScope 持久化状态结合
AgentScope 的 AgentState 可序列化为 JSON 并存储在 Redis 中,实现跨会话的状态恢复。知识库 ID 作为中间件配置项随 Agent 一起持久化:
Knowledge Studio 的检索是无状态的,每次检索调用独立,服务端不保存对话上下文。对话历史由 AgentScope 的
AgentState 管理,与知识库检索解耦。多轮对话传递工具历史的实践见多轮对话 cookbook。update_session_state 仅能更新已有会话的状态,首次调用需先通过 upsert_session 创建会话记录,否则会抛出 KeyError。常见问题
为什么不用 AgentScope 内置的 RAGMiddleware?
内置 RAGMiddleware 依赖本地 KnowledgeBase 对象,需要本地嵌入模型和向量库。Knowledge Studio 是托管服务,嵌入、向量存储、检索全部在服务端。本实践的中间件直接调知识检索 API,省去本地向量库的部署和维护。
static 模式每次推理都检索,会不会太慢?
Knowledge Studio 知识检索 API 的典型延迟在 200-500ms。如果对延迟敏感,可切换到 agentic 模式让模型按需检索,或调小 top_k。实测用 top_k=3 时,static 模式的 Agent 回答延迟在 3-5 秒(含模型生成时间)。
agentic 模式下模型不调工具怎么办?
确保 system prompt 中明确提示"可以调用 search_knowledge 工具检索知识库"。实测 qwen-plus 模型在问题涉及知识库内容时会自主调用工具。如果模型仍不调用,可换用更强的模型(如 qwen-max)。