Gitee 2026 年度最有价值开源项目（GVP）名单近日公布，江苏千桐科技自主研发的 qKnow 智能体构建平台入选。GVP 评选从技术先进性、社区活跃度、行业应用潜力三个维度综合评估，qKnow 的入选意味着国内开源社区对智能体构建工具链的认可正在从"概念验证"走向"工程可用"。
智能体构建平台要解决什么问题
企业落地大模型，最常见的卡点不是模型本身，而是如何把模型能力封装成可复用的业务单元。一个客服智能体需要检索知识库、调用工单系统、遵守话术规范——这些逻辑散落在脚本和提示词里，很难维护和扩展。
智能体构建平台的核心价值在于：把"提示词 + 工具调用 + 记忆管理 + 流程编排"打包成一个可定义、可部署、可监控的标准化单元。qKnow 在这个方向上选择了开源路线，让企业可以在自己的基础设施上运行，而不是把知识数据交给第三方 SaaS。
GVP 评选背后的三个硬指标
GVP 不是流量投票，它要求项目在三个维度同时达标：
- 技术先进性：架构设计是否有前瞻性，是否解决了同类项目的真实痛点。qKnow 在知识检索与智能体编排的融合上做了针对性设计，而不是简单套用通用 Agent 框架。
- 社区活跃度：Issue 响应速度、PR 合入频率、贡献者数量。开源项目的生命力取决于社区，不是看 star 数。
- 行业应用潜力：项目是否能在真实业务场景中落地，而不是停留在 demo 阶段。qKnow 聚焦企业级知识智能化，场景明确。
这三个指标对选型者也有参考意义——评估任何开源智能体框架时，都可以用同样的维度打分。
用 qKnow 构建一个知识问答智能体：实践示例
以下示例展示如何用 qKnow 的项目结构定义一个企业知识问答智能体。qKnow 采用 YAML 声明式配置 + Python 插件扩展的架构，可以先在本地跑起来再迁移到生产环境。
注：具体 API 和配置字段以 qKnow 官方仓库最新文档为准，以下基于其公开架构设计给出可改造的模板。
1. 定义智能体配置文件 agent.yaml
# qKnow 智能体声明式配置示例
agent:
name: "knowledge-assistant"
description: "企业内部知识库问答智能体"
version: "1.0.0"
# 模型配置 — 替换为你自己的 API 地址和密钥
model:
provider: "openai-compatible"
base_url: "http://localhost:11434/v1" # 可用本地 Ollama 或远程服务
model_name: "qwen2.5:7b"
api_key: "${MODEL_API_KEY}" # 从环境变量读取
# 知识源配置
knowledge:
type: "vector-store"
collection: "internal-docs"
embedding_model: "bge-m3"
# 支持多种文档格式自动入库
source_paths:
- "./data/markdown/"
- "./data/pdf/"
# 工具注册 — 智能体可调用的外部能力
tools:
- name: "search_docs"
type: "builtin"
description: "从知识库中检索相关文档片段"
- name: "create_ticket"
type: "plugin"
module: "plugins.ticket" # 自定义 Python 插件
description: "无法回答时创建工单转人工"
# 行为策略
policy:
max_retrieval_results: 5
fallback_to_human: true # 检索无结果时转人工
response_template: |
根据知识库信息：
{{retrieved_content}}
如需进一步帮助，已为您创建工单 #{{ticket_id}}。
2. 编写自定义工具插件 plugins/ticket.py
"""qKnow 自定义工具插件示例 — 创建工单"""
from qknow.plugin import ToolBase
class CreateTicket(ToolBase):
name = "create_ticket"
description = "当智能体无法回答用户问题时，创建人工工单"
# 初始化时注入外部服务配置
def __init__(self, config: dict):
self.ticket_api = config.get("ticket_api_url", "http://localhost:8080/api/tickets")
self.api_token = config.get("ticket_api_token", "")
async def run(self, query: str, context: dict) -> dict:
"""
调用工单系统创建一条新工单。
实际部署时替换为你们内部的工单 API。
"""
import httpx
payload = {
"title": f"知识库未覆盖的问题：{query[:50]}",
"description": query,
"source": "qKnow-agent",
"priority": "normal",
}
headers = {"Authorization": f"Bearer {self.api_token}"}
resp = await httpx.AsyncClient().post(
self.ticket_api, json=payload, headers=headers, timeout=10
)
resp.raise_for_status()
data = resp.json()
return {
"ticket_id": data.get("id", "unknown"),
"status": data.get("status", "created"),
}
3. 本地启动智能体
# 克隆仓库并安装依赖
git clone https://gitee.com/qingtong-tech/qknow.git
cd qknow
pip install -e ".[all]"
# 准备知识库文档
mkdir -p data/markdown data/pdf
# 把你的企业文档放入对应目录，qKnow 会自动向量化入库
# 设置模型密钥（如果用远程 API）
export MODEL_API_KEY="sk-your-key-here"
# 启动智能体服务
qknow serve --config agent.yaml --port 8000
# 测试问答
curl -X POST http://localhost:8000/api/chat \
-H "Content-Type: application/json" \
-d '{"query": "公司差旅报销标准是什么？"}'
这个示例覆盖了智能体构建的三个核心环节：模型对接、知识检索、工具扩展。实际部署时，把 model.base_url 指向你的模型服务，knowledge.source_paths 指向真实文档目录，tools 里的插件对接内部系统，就能从 demo 跳到可用状态。
选型时的几条务实建议
如果你正在评估开源智能体构建平台（不限于 qKnow），可以关注以下几点：
| 评估维度 | 具体检查项 |
|---|---|
| 知识管理 | 是否支持多格式文档自动入库？向量库是否可替换？增量更新是否方便？ |
| 工具扩展 | 插件机制是否足够开放？能否用几行代码接入内部 API？ |
| 部署模式 | 能否纯本地/私有云运行？数据是否完全不外泄？ |
| 社区健康 | 最近 3 个月的 commit 频率、Issue 平均响应时间、是否有企业用户反馈？ |
| 可观测性 | 智能体运行日志、检索命中率、工具调用成功率是否可监控？ |
qKnow 入选 GVP 是一个信号：国内开源社区正在认真审视智能体构建工具的工程质量，而不只是看谁包装的概念更炫。对企业来说，这意味着可以放心地把这类项目纳入选型短名单——但最终能不能用，还是要跑一遍上面的检查项。