可观测性AI 评测LLMOpsAI 应用人工智能【免费下载链接】phoenixAI Observability Evaluation项目地址https://gitcode.com/gh_mirrors/phoenix13/phoenix点击查看免费下载导读本篇文章围绕 Phoenix 仓库中 examples/rag_agent 目录下的 Agentic RAG 示例展开完整讲解如何用 LangChain LangGraph 构建一个具备「向量库检索 → 网络搜索兜底 → 响应质量分析」三重能力的 RAG Agent并通过 OpenInference 自动插桩与 Phoenix 实现端到端追踪。阅读本文后你将掌握该示例的完整目录结构、三个核心工具的实现原理、LangGraph 状态机的路由机制以及如何一键在 Gradio 界面上完成密钥配置、数据源初始化和 Agent 会话追踪。示例概览一个可运行的 Agentic RAG 最小闭环examples/rag_agent是一个开箱即用的 Agentic RAG 示例它解决的核心问题是如何让 LLM 不再是「无脑生成」而是先主动检索知识库、必要时再上网查证、最后还能自我评估回答质量。示例用五个文件组成了完整闭环文件职责app.pyGradio 主入口负责启动 Web 服务默认端口 10000提供密钥配置面板与聊天界面agent.py用 LangGraph 构建 Agent 工作流定义 agent / tools / user_input 三个节点与条件路由tools.py定义三个 LangChain 工具create_rag_response、analyze_rag_response、web_searchrag.py网页内容加载、文本切分、Embedding 与内存向量库初始化requirements.txt声明全部依赖Phoenix 系列包、LangChain/LangGraph、OpenInference 插桩器等从原文档的 Features 清单看该示例刻意覆盖了四条主线能力用 LangChain 构建 RAG Agent 工作流接入 OpenAI 模型完成语言生成与检索工具化使用web search、response analysis、create rag responseOpenInference 装饰器自动插桩Phoenix 端到端追踪跟踪 Agent 性能。环境准备与安装原文档列出的 Requirements 如下LangChain 库、OpenAI API Key、LangGraph、Python 3.x、Gradio用于 UI。对照 requirements.txt 可得到精确的依赖版本要求arize-phoenix arize-phoenix-evals arize-phoenix-otel beautifulsoup44.12.3 duckduckgo_search7.2.1 langchain1.0.0 langchain-community0.4.0 langchain-core1.0.0 langchain-openai1.0.0 langchain-text-splitters1.0.0 langgraph1.0.0 loguru0.7.2 pandas2.2.3 python-dotenv1.2.2 tqdm4.66.6 gradio openinference-instrumentation-openai openinference-instrumentation-langchain安装与启动只需两步与 README 的 Installation 一致pip install -r requirements.txt python app.py几点值得注意的依赖设计arize-phoenix-otel提供phoenix.otel.register入口是追踪初始化的核心openinference-instrumentation-openai与openinference-instrumentation-langchain则让所有 OpenAI / LangChain 调用被自动插桩duckduckgo_search驱动web_search工具无需额外申请搜索 API 密钥python-dotenv支持通过.env文件预置环境变量load_dotenv()在 app.py 与 agent.py 开头均有调用。三层数据管线网页 → 向量库 → 检索rag.py 负责把「任意 HTML 数据源」变成「可检索的向量库」是整个 RAG 的数据地基。其流程可以拆解为三步1. 网页加载与解析load_web_content_to_vector_store使用WebBaseLoader抓取网页并通过bs4.SoupStrainer只保留正文相关的三个 classpost-title、post-header、post-content过滤导航、页脚等噪声bs4_strainer bs4.SoupStrainer(class_(post-title, post-header, post-content)) loader WebBaseLoader( web_paths(web_post_url,), bs_kwargs{parse_only: bs4_strainer}, ) docs loader.load()2. 递归文本切分用RecursiveCharacterTextSplitter将长文切成可检索的 chunk参数为chunk_size1000、chunk_overlap200、add_start_indexTrue——重叠窗口可以降低跨 chunk 语义断裂的概率同时保留起始位置便于溯源。3. 向量化与入库initialize_vector_store使用 OpenAItext-embedding-3-large模型做 Embedding并写入InMemoryVectorStoreembeddings OpenAIEmbeddings(modeltext-embedding-3-large) vector_store InMemoryVectorStore(embeddings) load_web_content_to_vector_store(web_post_url)默认数据源是 Lilian Weng 的经典博客《LLM Powered Autonomous Agents》https://lilianweng.github.io/posts/2023-06-23-agent/UI 中可随时替换为任意 HTML 网页实现「用你自己的数据源初始化项目」。检索时get_vector_store()返回全局单例由工具层调用similarity_search完成相似度召回。三个核心工具检索、分析与联网兜底tools.py 用tool装饰器定义了三个 Agent 可调用的工具它们分别对应原文档所说的 web search、response analysis、create rag responsecreate_rag_response第一顺位的检索工具工具的 docstring 明确要求 Agent「任何用户查询都必须先用本工具」。实现中先取全局向量库再开启一个openinference_span_kindretriever的检索 spanwith tracer.start_as_current_span(rag_retrieval, openinference_span_kindretriever) as span: span.set_attribute(input.value, user_query) retrieved_docs vector_store.similarity_search(user_query) ... for i, doc in enumerate(retrieved_docs): span.set_attribute(fretrieval.documents.{i}.document.id, str(i)) span.set_attribute(fretrieval.documents.{i}.document.content, doc.content)每个检索文档的 ID 与内容截断至 1200 字符都会以retrieval.documents.N.document.*语义属性写入 span这正是 OpenInference 检索语义规范在源码中的直接体现Phoenix 借此在 UI 中渲染出「查询 → 召回文档」的完整检索视图。检索结果用空行拼接返回供 LLM 直接作为上下文作答无结果时则返回提示信息交由 Agent 决定是否走联网兜底。analyze_rag_response对检索回答做质量审计该工具接收query与rag_response两个参数构造一段提示词让工具模型tool_model对回答做 JSON 结构化评估输出字段包括original_response原始回答全文key_points要点提炼列表clarity清晰度评分1–10及理由relevance相关性评分1–10suggestions改进建议。它把「回答得好不好」这件事从主观感受变成可量化的 JSON 输出方便后续接入评估管线。工具模型通过initialize_tool_llm(gpt-4o-mini)单独初始化与主 Agent 模型同为 gpt-4o-mini解耦便于单独调参。web_searchDuckDuckGo 联网兜底当向量库中检索不到足够信息时Agent 调用web_search工具。它基于DuckDuckGoSearchResults(max_results5, output_formatlist)拉取前 5 条结果格式化为「序号 标题 摘要 URL」的文本返回给 LLM 二次加工异常时记录loguru日志并返回错误信息保证 Agent 流程不中断。LangGraph 工作流状态机如何把工具串起来agent.py 的核心是construct_agent()它把上面的工具与 LLM 组织成一个三节点状态机tool_node ToolNode([create_rag_response, analyze_rag_response, web_search]) workflow StateGraph(MessagesState) workflow.add_node(agent, call_llm) workflow.add_node(tools, tool_node) workflow.add_node(user_input, user_input) workflow.add_edge(START, agent) workflow.add_conditional_edges(agent, router) workflow.add_edge(tools, agent) workflow.add_conditional_edges(user_input, router) checkpointer MemorySaver() return workflow.compile(checkpointercheckpointer)节点职责agent 节点call_llm将当前MessagesState中的全部消息交给绑定了工具的ChatOpenAItemperature0.7tool_choiceauto让模型自行决定是直接回答还是发起工具调用tools 节点ToolNodeLangGraph 预置的工具执行节点按模型返回的tool_calls依次执行三个工具user_input 节点命令行交互模式下打印 Agent 上一条回答并等待用户输入仅用于 agent.py 的main()控制台模式。条件路由Agent 的决策中枢router函数决定每次执行后下一步去向逻辑非常简洁if hasattr(last_message, tool_calls) and last_message.tool_calls: return tools # 模型想调工具 → 进入工具节点 if type(last_message) is HumanMessage: return agent # 用户输入 → 回 Agent 节点 return END # 否则 → 结束会话由此形成「Agent 决定调工具 → 执行工具 → 结果回传 Agent → 再决策」的循环直到模型给出最终回答。MemorySaver作为 checkpointer 保存每个线程thread_id的对话状态为多轮对话提供记忆。控制台模式除了 Gradio UIagent.py 还内置了main()控制台入口设置USER_AGENT环境变量、初始化两个 LLM 与向量库后即可在终端直接问答适合快速验证或脚本化集成。一键配置面板与 Phoenix 端到端追踪Gradio 配置面板app.py 用gr.Blocks构建了「左配置、右聊天」的双栏界面Phoenix API Key仅 Phoenix Cloud 需要本地部署可留空Project Name默认Agentic Rag Demo决定追踪数据在 Phoenix 中的归属项目OpenAI API Key必填Phoenix Endpoint默认http://localhost:6006initialize_agent会自动补全为http://localhost:6006/v1/tracesVector Source Web URL默认指向 Lilian Weng 博客可替换为自己的 HTML 数据源。所有密钥都在 UI 中输入README Notes 强调initialize_agent回调会将其写入进程环境变量PHOENIX_API_KEY、OPENAI_API_KEY、USER_AGENT再依次完成插桩、LLM 初始化与向量库加载最后输出「Configuration Set: Project xxx is Ready!」状态。Phoenix 自动插桩的底层实现插桩由initialize_instrumentor完成核心是phoenix.otel.registertracer_provider register( project_nameproject_name, endpointendpoint, batchTrue, auto_instrumentTrue, )对照 phoenix-otel 源码register会依次完成创建带project_name资源的TracerProvider→ 选择BatchSpanProcessor生产环境推荐批量导出→ 推断 HTTP/gRPC 导出协议 → 设置为全局 TracerProvider →auto_instrumentTrue时遍历所有已安装的openinference_instrumentorentry points 并自动调用instrumentor.instrument(...)。这正是「安装 openai / langchain 两个 instrumentor 依赖即获得全链路自动追踪」的原理所在。batchTrue在源码中的语义是使用BatchSpanProcessor见 otel.py即 span 先入队批量导出比逐条导出的SimpleSpanProcessor更高效适合 Agent 多轮调用场景。会话级追踪与 Agent span聊天入口chat_with_agent展示了 Phoenix 追踪的两层设计会话绑定用using_session(session_iduser_session_id)上下文管理器把整轮对话的所有 span 关联到同一个 session对应 OpenInference 的session_id语义见 phoenix/otel/init.py 的导出Agent 级 span手动开启openinference_span_kindagent的 span设置输入输出并标记成功状态with using_session(session_iduser_session_id): with agent_tracer.start_as_current_span(fagent-{user_session_id}, openinference_span_kindagent) as span: span.set_input(user_input_message) conversation_history copilot_agent.invoke(...) span.set_output(conversation_history[messages][-1].content) span.set_status(Status(StatusCode.OK))由此一次用户提问在 Phoenix 中呈现为agentspan整体会话→ LLM 调用 span自动插桩→retrieverspan检索含文档语义属性→ 工具执行 span 的完整调用树实现 README 所述「End-to-end tracing with Phoenix to track agent performance」。服务启动细节app.py末尾通过os.environ.get(PORT, 10000)读取端口默认 10000README 中描述为「web server with default port」并以shareTrue、server_name0.0.0.0启动 Gradio既支持本地访问也支持生成公网分享链接。实用注意事项与扩展建议原文档 Notes 给出的三条使用约束结合源码可以进一步明确所有密钥必须从 UI 输入README 强调 All the Keys must be inputted from the UI application源码中initialize_agent回调正是从gr.Textbox读取密钥后写入环境变量因此不要在代码里硬编码密钥默认数据源可替换RAG 默认加载 Lilian Weng 博客在 UI 的 Vector Source Web URL 输入框中替换 URL 后重新点击初始化即可换用你自己的数据源仅支持 HTML 数据源WebBaseLoaderSoupStrainer的解析链路面向 HTML 设计非 HTML 内容PDF、纯文本等需要自行扩展加载器。在此基础上结合仓库其他示例可以进一步演进把InMemoryVectorStore换成持久化向量库以支持服务重启后复用索引为analyze_rag_response的 JSON 输出接上arize-phoenix-evals的评估管线或在 Phoenix UI 中基于自动插桩的 trace 数据定位检索质量与工具调用失败点。总结examples/rag_agent是理解「Agentic RAG 可观测性」的最佳入门样例rag.py解决数据进得来tools.py解决检索/分析/联网的能力边界agent.py用 LangGraph 状态机把能力编排成自主决策流程而app.py与phoenix.otel.register让这一切从第一行代码起就处于 Phoenix 的端到端追踪之下。对照 agent.py 与 tools.py 的 span 语义属性与 phoenix-otel 实现你可以轻松把这个模式迁移到自己的 RAG 应用中实现「可检索、可分析、可兜底、可观测」的完整 Agent 闭环。赞分享可观测性AI 评测LLMOpsAI 应用人工智能【免费下载链接】phoenixAI Observability Evaluation项目地址https://gitcode.com/gh_mirrors/phoenix13/phoenix点击查看免费下载相关推荐All-in-RAG 实战基于 LangGraph 的 Agentic RAG 端到端实现All in RAG 实战基于 LangGraph 的 Agentic RAG 端到端实现 导读 本篇文章聚焦 Datawhale All in RAG 项目教程人工智能大模型RAGAutoAgent Agentic RAG 实战从智能检索决策到 MultiHopRAG 端到端评测AutoAgent Agentic RAG 实战从智能检索决策到 MultiHopRAG 端到端评测 Agentic RAG检索增强生成是 AutoAge人工智能大模型AI AgentAgent 框架工具调用自主智能体RAG用 RAG 对比评测 OpenAI o3 与 Claude 3.7 Sonnet基于 GitHub 代码检索的端到端评测与可观测性实战用 RAG 对比评测 OpenAI o3 与 Claude 3.7 Sonnet基于 GitHub 代码检索的端到端评测与可观测性实战 导读 本项目以对 G示例工程上一篇React-Bits推送通知用户 Engagement下一篇最完整的GoDS教程30种数据结构实现与实战案例解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 基于 LangGraph + Phoenix 的 Agentic RAG 示例：从向量检索、工具调用到端到端可观测性
可观测性AI 评测LLMOpsAI 应用人工智能【免费下载链接】phoenixAI Observability Evaluation项目地址https://gitcode.com/gh_mirrors/phoenix13/phoenix点击查看免费下载导读本篇文章围绕 Phoenix 仓库中 examples/rag_agent 目录下的 Agentic RAG 示例展开完整讲解如何用 LangChain LangGraph 构建一个具备「向量库检索 → 网络搜索兜底 → 响应质量分析」三重能力的 RAG Agent并通过 OpenInference 自动插桩与 Phoenix 实现端到端追踪。阅读本文后你将掌握该示例的完整目录结构、三个核心工具的实现原理、LangGraph 状态机的路由机制以及如何一键在 Gradio 界面上完成密钥配置、数据源初始化和 Agent 会话追踪。示例概览一个可运行的 Agentic RAG 最小闭环examples/rag_agent是一个开箱即用的 Agentic RAG 示例它解决的核心问题是如何让 LLM 不再是「无脑生成」而是先主动检索知识库、必要时再上网查证、最后还能自我评估回答质量。示例用五个文件组成了完整闭环文件职责app.pyGradio 主入口负责启动 Web 服务默认端口 10000提供密钥配置面板与聊天界面agent.py用 LangGraph 构建 Agent 工作流定义 agent / tools / user_input 三个节点与条件路由tools.py定义三个 LangChain 工具create_rag_response、analyze_rag_response、web_searchrag.py网页内容加载、文本切分、Embedding 与内存向量库初始化requirements.txt声明全部依赖Phoenix 系列包、LangChain/LangGraph、OpenInference 插桩器等从原文档的 Features 清单看该示例刻意覆盖了四条主线能力用 LangChain 构建 RAG Agent 工作流接入 OpenAI 模型完成语言生成与检索工具化使用web search、response analysis、create rag responseOpenInference 装饰器自动插桩Phoenix 端到端追踪跟踪 Agent 性能。环境准备与安装原文档列出的 Requirements 如下LangChain 库、OpenAI API Key、LangGraph、Python 3.x、Gradio用于 UI。对照 requirements.txt 可得到精确的依赖版本要求arize-phoenix arize-phoenix-evals arize-phoenix-otel beautifulsoup44.12.3 duckduckgo_search7.2.1 langchain1.0.0 langchain-community0.4.0 langchain-core1.0.0 langchain-openai1.0.0 langchain-text-splitters1.0.0 langgraph1.0.0 loguru0.7.2 pandas2.2.3 python-dotenv1.2.2 tqdm4.66.6 gradio openinference-instrumentation-openai openinference-instrumentation-langchain安装与启动只需两步与 README 的 Installation 一致pip install -r requirements.txt python app.py几点值得注意的依赖设计arize-phoenix-otel提供phoenix.otel.register入口是追踪初始化的核心openinference-instrumentation-openai与openinference-instrumentation-langchain则让所有 OpenAI / LangChain 调用被自动插桩duckduckgo_search驱动web_search工具无需额外申请搜索 API 密钥python-dotenv支持通过.env文件预置环境变量load_dotenv()在 app.py 与 agent.py 开头均有调用。三层数据管线网页 → 向量库 → 检索rag.py 负责把「任意 HTML 数据源」变成「可检索的向量库」是整个 RAG 的数据地基。其流程可以拆解为三步1. 网页加载与解析load_web_content_to_vector_store使用WebBaseLoader抓取网页并通过bs4.SoupStrainer只保留正文相关的三个 classpost-title、post-header、post-content过滤导航、页脚等噪声bs4_strainer bs4.SoupStrainer(class_(post-title, post-header, post-content)) loader WebBaseLoader( web_paths(web_post_url,), bs_kwargs{parse_only: bs4_strainer}, ) docs loader.load()2. 递归文本切分用RecursiveCharacterTextSplitter将长文切成可检索的 chunk参数为chunk_size1000、chunk_overlap200、add_start_indexTrue——重叠窗口可以降低跨 chunk 语义断裂的概率同时保留起始位置便于溯源。3. 向量化与入库initialize_vector_store使用 OpenAItext-embedding-3-large模型做 Embedding并写入InMemoryVectorStoreembeddings OpenAIEmbeddings(modeltext-embedding-3-large) vector_store InMemoryVectorStore(embeddings) load_web_content_to_vector_store(web_post_url)默认数据源是 Lilian Weng 的经典博客《LLM Powered Autonomous Agents》https://lilianweng.github.io/posts/2023-06-23-agent/UI 中可随时替换为任意 HTML 网页实现「用你自己的数据源初始化项目」。检索时get_vector_store()返回全局单例由工具层调用similarity_search完成相似度召回。三个核心工具检索、分析与联网兜底tools.py 用tool装饰器定义了三个 Agent 可调用的工具它们分别对应原文档所说的 web search、response analysis、create rag responsecreate_rag_response第一顺位的检索工具工具的 docstring 明确要求 Agent「任何用户查询都必须先用本工具」。实现中先取全局向量库再开启一个openinference_span_kindretriever的检索 spanwith tracer.start_as_current_span(rag_retrieval, openinference_span_kindretriever) as span: span.set_attribute(input.value, user_query) retrieved_docs vector_store.similarity_search(user_query) ... for i, doc in enumerate(retrieved_docs): span.set_attribute(fretrieval.documents.{i}.document.id, str(i)) span.set_attribute(fretrieval.documents.{i}.document.content, doc.content)每个检索文档的 ID 与内容截断至 1200 字符都会以retrieval.documents.N.document.*语义属性写入 span这正是 OpenInference 检索语义规范在源码中的直接体现Phoenix 借此在 UI 中渲染出「查询 → 召回文档」的完整检索视图。检索结果用空行拼接返回供 LLM 直接作为上下文作答无结果时则返回提示信息交由 Agent 决定是否走联网兜底。analyze_rag_response对检索回答做质量审计该工具接收query与rag_response两个参数构造一段提示词让工具模型tool_model对回答做 JSON 结构化评估输出字段包括original_response原始回答全文key_points要点提炼列表clarity清晰度评分1–10及理由relevance相关性评分1–10suggestions改进建议。它把「回答得好不好」这件事从主观感受变成可量化的 JSON 输出方便后续接入评估管线。工具模型通过initialize_tool_llm(gpt-4o-mini)单独初始化与主 Agent 模型同为 gpt-4o-mini解耦便于单独调参。web_searchDuckDuckGo 联网兜底当向量库中检索不到足够信息时Agent 调用web_search工具。它基于DuckDuckGoSearchResults(max_results5, output_formatlist)拉取前 5 条结果格式化为「序号 标题 摘要 URL」的文本返回给 LLM 二次加工异常时记录loguru日志并返回错误信息保证 Agent 流程不中断。LangGraph 工作流状态机如何把工具串起来agent.py 的核心是construct_agent()它把上面的工具与 LLM 组织成一个三节点状态机tool_node ToolNode([create_rag_response, analyze_rag_response, web_search]) workflow StateGraph(MessagesState) workflow.add_node(agent, call_llm) workflow.add_node(tools, tool_node) workflow.add_node(user_input, user_input) workflow.add_edge(START, agent) workflow.add_conditional_edges(agent, router) workflow.add_edge(tools, agent) workflow.add_conditional_edges(user_input, router) checkpointer MemorySaver() return workflow.compile(checkpointercheckpointer)节点职责agent 节点call_llm将当前MessagesState中的全部消息交给绑定了工具的ChatOpenAItemperature0.7tool_choiceauto让模型自行决定是直接回答还是发起工具调用tools 节点ToolNodeLangGraph 预置的工具执行节点按模型返回的tool_calls依次执行三个工具user_input 节点命令行交互模式下打印 Agent 上一条回答并等待用户输入仅用于 agent.py 的main()控制台模式。条件路由Agent 的决策中枢router函数决定每次执行后下一步去向逻辑非常简洁if hasattr(last_message, tool_calls) and last_message.tool_calls: return tools # 模型想调工具 → 进入工具节点 if type(last_message) is HumanMessage: return agent # 用户输入 → 回 Agent 节点 return END # 否则 → 结束会话由此形成「Agent 决定调工具 → 执行工具 → 结果回传 Agent → 再决策」的循环直到模型给出最终回答。MemorySaver作为 checkpointer 保存每个线程thread_id的对话状态为多轮对话提供记忆。控制台模式除了 Gradio UIagent.py 还内置了main()控制台入口设置USER_AGENT环境变量、初始化两个 LLM 与向量库后即可在终端直接问答适合快速验证或脚本化集成。一键配置面板与 Phoenix 端到端追踪Gradio 配置面板app.py 用gr.Blocks构建了「左配置、右聊天」的双栏界面Phoenix API Key仅 Phoenix Cloud 需要本地部署可留空Project Name默认Agentic Rag Demo决定追踪数据在 Phoenix 中的归属项目OpenAI API Key必填Phoenix Endpoint默认http://localhost:6006initialize_agent会自动补全为http://localhost:6006/v1/tracesVector Source Web URL默认指向 Lilian Weng 博客可替换为自己的 HTML 数据源。所有密钥都在 UI 中输入README Notes 强调initialize_agent回调会将其写入进程环境变量PHOENIX_API_KEY、OPENAI_API_KEY、USER_AGENT再依次完成插桩、LLM 初始化与向量库加载最后输出「Configuration Set: Project xxx is Ready!」状态。Phoenix 自动插桩的底层实现插桩由initialize_instrumentor完成核心是phoenix.otel.registertracer_provider register( project_nameproject_name, endpointendpoint, batchTrue, auto_instrumentTrue, )对照 phoenix-otel 源码register会依次完成创建带project_name资源的TracerProvider→ 选择BatchSpanProcessor生产环境推荐批量导出→ 推断 HTTP/gRPC 导出协议 → 设置为全局 TracerProvider →auto_instrumentTrue时遍历所有已安装的openinference_instrumentorentry points 并自动调用instrumentor.instrument(...)。这正是「安装 openai / langchain 两个 instrumentor 依赖即获得全链路自动追踪」的原理所在。batchTrue在源码中的语义是使用BatchSpanProcessor见 otel.py即 span 先入队批量导出比逐条导出的SimpleSpanProcessor更高效适合 Agent 多轮调用场景。会话级追踪与 Agent span聊天入口chat_with_agent展示了 Phoenix 追踪的两层设计会话绑定用using_session(session_iduser_session_id)上下文管理器把整轮对话的所有 span 关联到同一个 session对应 OpenInference 的session_id语义见 phoenix/otel/init.py 的导出Agent 级 span手动开启openinference_span_kindagent的 span设置输入输出并标记成功状态with using_session(session_iduser_session_id): with agent_tracer.start_as_current_span(fagent-{user_session_id}, openinference_span_kindagent) as span: span.set_input(user_input_message) conversation_history copilot_agent.invoke(...) span.set_output(conversation_history[messages][-1].content) span.set_status(Status(StatusCode.OK))由此一次用户提问在 Phoenix 中呈现为agentspan整体会话→ LLM 调用 span自动插桩→retrieverspan检索含文档语义属性→ 工具执行 span 的完整调用树实现 README 所述「End-to-end tracing with Phoenix to track agent performance」。服务启动细节app.py末尾通过os.environ.get(PORT, 10000)读取端口默认 10000README 中描述为「web server with default port」并以shareTrue、server_name0.0.0.0启动 Gradio既支持本地访问也支持生成公网分享链接。实用注意事项与扩展建议原文档 Notes 给出的三条使用约束结合源码可以进一步明确所有密钥必须从 UI 输入README 强调 All the Keys must be inputted from the UI application源码中initialize_agent回调正是从gr.Textbox读取密钥后写入环境变量因此不要在代码里硬编码密钥默认数据源可替换RAG 默认加载 Lilian Weng 博客在 UI 的 Vector Source Web URL 输入框中替换 URL 后重新点击初始化即可换用你自己的数据源仅支持 HTML 数据源WebBaseLoaderSoupStrainer的解析链路面向 HTML 设计非 HTML 内容PDF、纯文本等需要自行扩展加载器。在此基础上结合仓库其他示例可以进一步演进把InMemoryVectorStore换成持久化向量库以支持服务重启后复用索引为analyze_rag_response的 JSON 输出接上arize-phoenix-evals的评估管线或在 Phoenix UI 中基于自动插桩的 trace 数据定位检索质量与工具调用失败点。总结examples/rag_agent是理解「Agentic RAG 可观测性」的最佳入门样例rag.py解决数据进得来tools.py解决检索/分析/联网的能力边界agent.py用 LangGraph 状态机把能力编排成自主决策流程而app.py与phoenix.otel.register让这一切从第一行代码起就处于 Phoenix 的端到端追踪之下。对照 agent.py 与 tools.py 的 span 语义属性与 phoenix-otel 实现你可以轻松把这个模式迁移到自己的 RAG 应用中实现「可检索、可分析、可兜底、可观测」的完整 Agent 闭环。赞分享可观测性AI 评测LLMOpsAI 应用人工智能【免费下载链接】phoenixAI Observability Evaluation项目地址https://gitcode.com/gh_mirrors/phoenix13/phoenix点击查看免费下载相关推荐All-in-RAG 实战基于 LangGraph 的 Agentic RAG 端到端实现All in RAG 实战基于 LangGraph 的 Agentic RAG 端到端实现 导读 本篇文章聚焦 Datawhale All in RAG 项目教程人工智能大模型RAGAutoAgent Agentic RAG 实战从智能检索决策到 MultiHopRAG 端到端评测AutoAgent Agentic RAG 实战从智能检索决策到 MultiHopRAG 端到端评测 Agentic RAG检索增强生成是 AutoAge人工智能大模型AI AgentAgent 框架工具调用自主智能体RAG用 RAG 对比评测 OpenAI o3 与 Claude 3.7 Sonnet基于 GitHub 代码检索的端到端评测与可观测性实战用 RAG 对比评测 OpenAI o3 与 Claude 3.7 Sonnet基于 GitHub 代码检索的端到端评测与可观测性实战 导读 本项目以对 G示例工程上一篇React-Bits推送通知用户 Engagement下一篇最完整的GoDS教程30种数据结构实现与实战案例解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考