自动化与运维 context-graphsknowledge-graphsgraph-ragontology-managementworkflow-orchestrationmulti-tenant-deploymentsemantic-webmodel-inference

TrustGraph

用可追溯的上下文图谱构建确定性开源智能体。

FollowAgents 评估 · FARS-2.1
谨慎使用
62/ 100 五分制 3.1 / 5
1 2 3 4 5 6
1信任安全14 / 29 · 2.4/5

安装指南明确披露硬件检测、密钥收集、依赖安装、模型下载、容器启动、IAM 初始化和浏览器打开等外部影响,并提供交互确认、dry-run、fresh 与 remove-all;因此用户确认、数据流说明、外部影响和回滚得到中等支持。扣分在于保存的答案包含 API 密钥,但材料没有说明文件权限、加密、日志脱敏或密钥轮换;依赖和 GitHub Actions 多数未固定版本,CLA 工作流还使用 action@main 并申请多项写权限。Apache-2.0、项目名称和安全联系邮箱提供了基本归属,但发布者身份未经验证,且许可证附录仍是占位模板。

2可靠稳定8 / 14 · 2.9/5

安装流程、CI 测试分层和代理 DAG 分析器形成基本一致的操作与检查叙述;分析器会报告缺失 message_id、无三元组、多根、多终点、悬空来源和类型错误,安装文档也列出日志及常见故障。扣分在于庞大且未固定版本的 Python、容器、Node、模型和云服务依赖会降低可用性可预测性;材料没有展示依赖锁定、镜像摘要、重试策略或离线保障。静态评审未执行这些测试。

3适用触发12 / 18 · 3.3/5

材料覆盖本地或远程 LLM、Ollama、OpenAI 兼容端点、无 LLM、Docker、Podman、交互式和 CI 场景,并明确 macOS 安装器限制及无 LLM 时 Agent/RAG 不工作。服务、flow、user、collection 和 URL 可配置,使触发与环境适配达到普通使用水平。扣分在于 Linux/Windows 的具体标准安装说明未提供,示例大量依赖默认用户、集合和 flow,也未展示更细粒度的代理能力策略或触发冲突处理。

4规范维护13 / 18 · 3.6/5

开发安装文档结构清晰,包含先决条件、完整步骤、选项、环境变量、模式选择、重运行、卸载和故障排除,安装说明足以获得满分。命名在脚本间总体一致,示例和已知边界也较具体;完整 Apache-2.0 文本支持许可证满分。扣分在于没有提供仓库总览、正式 FAQ、变更日志或发布迁移记录;只看到安全支持线与版本阈值。安全邮箱和响应流程说明了维护入口,但未知发布者身份和缺少明确维护者名单限制了责任归属分数。

5有效结果9 / 13 · 3.5/5

Workbench、API、流式代理响应、可保存的 JSON trace、PROV/RDF 来源图及 DAG 完整性诊断均是可直接使用的输出;图谱化解释链相较于单纯聊天接口具有明确增量价值。安装器还能按硬件推荐本地或远程模式并提供跳过测试选项。扣分在于平台需要容器、多个语言运行时、模型或外部 API 以及大量数据和云依赖,材料未提供延迟、资源、质量、成本或规模基准,因而不能证明超出普通使用水平的成本收益。

6证据核验6 / 8 · 3.8/5

代理 trace 使用 explain_id、RDF 类型和 prov:wasDerivedFrom 建立实体级来源关系,分析脚本还检查根、终点、父节点存在性和子 trace 关系,因此声明可追踪性证据充分。README、CI、安全政策和开发工具在安装、测试与接口形态上相互支持。扣分在于没有提供捕获样例、测试结果、发布产物或独立来源来交叉验证平台级的可靠和确定性宣传;描述性产品主张与代码事实虽可区分,但材料没有系统标注哪些是已验证事实、设计意图或推断。

证据充分度: 评估于 2026年8月14日 审查版本 0bcfe9377c3d
上游仓库在本次评估后已有新提交;当前评分仍对应所示审查版本,可能尚未覆盖最新改动。
使用前请注意
  • requirements.txt 未固定版本,GitHub Actions 也使用浮动引用,包括高权限 CLA 工作流中的 action@main;采用前应锁定并审计依赖与工作流来源。
  • 安装器会保存 API 密钥、安装软件、下载模型、启动容器并初始化 IAM;应先使用 --dry-run,并核查保存文件权限、日志脱敏和卸载范围。
  • --remove-all 会删除 compose volumes、venv、部署输出、日志和保存的答案;执行前应备份任何需要保留的数据。
  • 开发安装器仅声明在 macOS 上测试过,Linux 和 Windows 需要另行验证标准 compose 路径。
  • 本评审仅依据所给静态文件,未运行安装器、测试、代理查询或 DAG 分析器。
查看完整评分方法 →

这个 Agent 能做什么,适合哪些场景?

TrustGraph 是面向生产级智能体系统的自托管上下文工程平台,将本体、实体、关系、证据、嵌入、溯源信息和检索策略封装为可部署、可版本化的 Context Core。它提供知识摄取、图谱构建、DocumentRAG、GraphRAG、OntologyRAG、图谱检索、智能体编排以及完整的 LLM 推理栈。系统以 Workspace、Collection 和 Flow 组织租户边界、领域知识及数据处理流水线,并在消息队列、存储和 API 网关层实施隔离。用户可以通过 Agent Console、GraphRAG View、Context Explorer、Document Ingestion、Ontology Workbench、Schema Workbench 和 Prompt Editor 操作系统,也可使用 TypeScript 客户端库接入自建界面。平台以容器集合运行,可部署到 Docker、Podman 或 Kubernetes,并支持云端模型 API以及 vLLM、Ollama、TGI、LM Studio 和 Llamafiles 等本地推理后端。

原始文档首先进入 Flow,由可配置流水线执行摄取、抽取、结构化和存储;自动实体与关系抽取及本体驱动的图谱构建会把结果写入包含图结构、嵌入、文档和证据的 Collection。查询可通过 DocumentRAG、GraphRAG 或 OntologyRAG 进入系统,利用向量嵌入定位语义入口,再沿显式图关系检索相关实体、边和子图,并将这些材料送入所选 LLM。生成结果可附带推理路径与事实级溯源,以便追查源文档、摄取时间及抽取方法。Agent Console 提供流式回答和实时可解释性事件;GraphRAG View 展示可解释性 DAG及内联溯源;Context Explorer 提供三维图谱、BFS 邻域提取和边脉冲动画。编排层支持单智能体、多智能体、ReAct、Plan-then-Execute、Supervisor 和 MCP 集成;存储与传输层使用 Cassandra、Qdrant、S3 兼容的 Garage,以及 Pulsar 或 RabbitMQ。

  1. 需要在生产环境审计回答来源的智能体团队,可用 GraphRAG、显式关系路径和事实级溯源记录每项结论所依据的图谱证据。
  2. 管理多个客户或业务部门的平台团队,可用 Workspace 隔离租户,再用 Collection 按领域划分知识,并通过独立 Flow 处理各自的数据。
  3. 拥有 RDF、OWL、SKOS 或 SHACL 资产的知识工程团队,可围绕既有语义模型构建本体驱动的上下文图谱和 OntologyRAG 流程。
  4. 希望减少外部托管依赖的组织,可在本地部署存储、消息系统和开源模型推理栈,仅在选择云端 LLM 或第三方 OCR 时使用外部 API。
  5. 需要在多个智能体或环境中复用领域知识的团队,可构建、固定版本、回滚并跨环境推广 Context Core。
  6. 需要探索复杂实体网络的分析人员,可通过三维 Context Explorer、BFS 邻域提取及 GraphRAG View 检查相关实体、关系和溯源信息。

这个 Agent 有哪些优点和局限?

优点
  • Context Core 同时封装本体、知识图谱、嵌入、溯源和检索策略,使领域上下文能够版本化、回滚并跨团队或环境复用。
  • 解释能力落实到显式图关系路径和节点、边的事实级溯源,UI 还提供可解释性 DAG、内联来源与实时事件跟踪。
  • 同时提供 DocumentRAG、GraphRAG、OntologyRAG,以及 ReAct、Plan-then-Execute、Supervisor、单智能体和多智能体编排。
  • 支持多家云端模型 API与 vLLM、Ollama、TGI、LM Studio、Llamafiles 等本地推理方式,模型和部署环境选择较宽。
  • Workspace、Collection、Flow 将租户隔离、领域知识组织和处理流水线明确分层,并在消息队列、存储及 API 网关层实施结构性隔离。
局限
  • 完整部署涉及容器编排、Cassandra、Qdrant、Garage,以及 Pulsar 或 RabbitMQ,运维面明显大于简单的单进程 RAG 应用。
  • 快速入门只说明配置器会生成 deploy.zip 和 INSTALLATION.md,没有给出统一启动命令、最低硬件配置或可复制的首个查询请求。
  • 使用云端 LLM 或第三方 OCR 时仍需相应服务的 API 密钥、网络连接并承担其外部依赖。
  • 本体驱动图谱、检索策略和 Context Core 引入额外的知识建模与治理工作;从扁平文本 RAG 迁移时需要重新组织实体、关系和证据。
  • 材料宣称支持多种云和推理后端,但未提供各组合的性能、扩展上限或功能一致性数据,选型前仍需自行验证。

如何安装或部署这个 Agent?

无需克隆仓库即可按文档提供的快速入门配置。准备可运行 npx 的命令行环境,以及 Docker、Podman 或 Minikube 之一,然后执行:

npx @trustgraph/config

配置器会生成 deploy.zip;Docker 或 Podman 目标包含 docker-compose.yaml,Kubernetes 目标包含 resources.yaml,同时生成 INSTALLATION.md。后续部署命令应以该文件为准,因为给定材料没有列出统一的启动命令。系统自身的大部分组件不需要第三方 API 密钥;仅当使用 Anthropic、OpenAI 等云端 LLM、Mistral OCR 等第三方 OCR 时需要对应密钥,TrustGraph API 网关还使用由部署者自行设置的密钥。

如何使用这个 Agent?

先运行 npx @trustgraph/config,选择 Docker、Podman 或 Minikube 配置,并按照生成的 INSTALLATION.md 启动容器。部署后,默认可在 8888 端口使用 TrustGraph UI:通过 Document Ingestion 上传并检查文档,通过 Ontology Workbench 导入或编辑 OWL/XML、Turtle 本体,通过 Schema Workbench 管理模式,再在 Agent Console 发起带流式输出的查询,或在 GraphRAG View 中检查检索图和溯源。需要自建界面时,可采用 @trustgraph/client、@trustgraph/react-state 和 @trustgraph/react-provider。材料还提供 Developer APIs and CLI 文档入口,但没有给出可直接复制的查询 API、CLI 调用示例或端到端示例请求,因此首次业务查询的准确参数需参考生成的安装说明和开发者参考文档。

这个 Agent 与同类方案有什么区别?

相较于只从向量库取回扁平文本片段的传统 RAG,TrustGraph 同时使用向量嵌入和显式关系图:嵌入用于寻找语义入口,图遍历用于组合实体、关系及证据,并保留事实级溯源。代价是需要维护本体、图谱、检索策略和一套由多个基础设施组件构成的部署环境,而不是仅维护分块与向量索引。

常见问题

必须购买云端模型 API 才能运行吗?
不必须。TrustGraph 支持 vLLM、Ollama、TGI、LM Studio 和 Llamafiles 等本地推理后端;只有选择 Anthropic、OpenAI 等云端 LLM 或第三方 OCR 时才需要相应 API 密钥。
它如何隔离不同客户的数据?
Workspace 是最外层租户边界,隔离覆盖数据、用户、配置和流水线,并在发布订阅队列、存储和 API 网关层执行。Workspace 内再用 Collection 划分领域知识。
回答能追溯到什么程度?
图中的节点和边保存溯源信息;材料称可追查到源文档、摄取时间和抽取方法,并可检查查询时使用的实体、关系及子图。
部署时需要哪些凭据?
TrustGraph API 网关需要部署者自行设置的密钥。云端 LLM 和第三方 OCR 集成需要各自的 API 密钥;其余列出的托管存储、向量库、对象存储和消息系统包含在部署栈中。
出现错误答案时能否保证完全没有幻觉?
平台通过结构化图谱、显式关系和溯源来约束并解释生成过程,但材料没有提供绝对正确性保证或失败率数据。采用前应使用自己的本体、文档和查询验证抽取、检索及模型输出。

相关 Agents