OpenInference
用 OpenTelemetry 规范和插件追踪大模型、智能体、检索与工具调用。
证据表明该项目是向 OpenTelemetry 后端发送 AI 应用追踪数据的插桩层；测试具体展示了输入、输出、消息、工具调用、推理内容、文档和元数据可能被写入 span，并验证了 hideInputs 脱敏。发布工作流仅声明 contents 和 pull-requests 写权限、禁用 checkout 凭据持久化，并将变更提交为 PR。扣分原因是 README 未集中说明完整数据流、默认采集范围、后端传输或保留策略，也未展示输出脱敏、字段级敏感数据策略、运行时最小权限或发送前确认机制；回滚仅能从 PR 流程间接推断。仓库与 Arize 资源的归属线索清楚，但给定的发布者身份未经企业注册表验证，因此不视为已验证身份。
README 中的语义约定、插桩类别和 OpenTelemetry 定位与单元测试中的属性生成、span 类型、同步及异步调用、上下文嵌套和异常记录相互一致，足以给予自洽性满分。失败路径会保留原异常、设置 ERROR 状态、记录异常事件，发布自动化也对错误标签给出 notice，因此失败消息处理证据充分。依赖可用性方面，包列表和 PyPI 版本入口明确，发布流程还会等待目标版本实际可用；但材料未覆盖全部第三方 SDK 的兼容矩阵、离线方案或依赖不可用时的降级路径，因此扣分。
项目覆盖 Python、JavaScript、多种模型与 Agent 框架以及任意 OpenTelemetry 兼容后端，并按初级和中级场景组织示例。代码提供通用包装器、专用 span 类型、自定义输入输出处理器和显式 tracer，体现良好适配能力。扣分在于材料没有完整的支持版本矩阵、部署环境要求或不支持场景；它是可观测性插桩而非执行 Agent，能力边界主要靠描述和 API 名称表达。触发控制在包装函数和 release 标签的严格 semver 校验中得到支持，但未展示所有自动插桩的启停与过滤规则。
README 以规范、语言、库、span processor 和示例分层，包名与语义约定名称稳定且清晰；大量按框架分类并标注复杂度的示例，以及固定提交哈希的发布动作和明确的 semver 标签流程，支持信息架构、命名、示例和版本管理的高分。完整 Apache-2.0 文本与元数据一致，许可证可判满分。扣分在于所给 README 没有实际安装命令、配置步骤或 FAQ，已知限制仅由被跳过的 generator 测试和 TODO 间接体现。仓库、社区和自动维护路径可见，但没有明确列出负责维护者或支持承诺，且发布者身份仍未知。
结构化属性、统一语义约定、明确的 AGENT、TOOL、LLM、RETRIEVER 等 span 类型，以及同步、异步、异常和上下文传播行为，使输出可直接供 OpenTelemetry 后端使用；跨大量框架规范化 AI 追踪数据提供了明显增量价值，因此这两项证据充分。扣分集中在成本收益：材料没有说明延迟、存储量、网络流量、采样、属性基数或敏感数据治理成本，无法证明生产部署的开销与收益平衡。
核心陈述可追溯到 README 的包和能力目录、发布工作流以及针对属性序列化、脱敏、异常、嵌套和 span 类型的具体测试；多个来源对项目定位与实现行为形成较强交叉印证，因此可追溯性和交叉佐证可判满分。扣分在于 README 对广泛框架兼容性和“任意 OpenTelemetry 兼容后端”的表述，在所给材料中没有逐项实现或测试佐证，也没有显式区分已验证兼容性与设计意图。
- 默认追踪属性可能包含提示词、模型输出、工具参数、检索文档、元数据、会话标识以及推理或加密内容；部署前应验证所有 hide/redaction 配置、导出端点、访问控制和保留策略。
- 所给材料未证明输出及各类嵌套字段都可脱敏，也未提供默认采样、数据最小化或高基数控制；不要仅凭 hideInputs 测试推断完整隐私保护。
- 大量第三方 SDK 与框架会扩大兼容性和供应链表面；应在采用前核对具体 instrumentor 的版本约束、发布包和依赖审计状态。
- 这是静态、低置信度评估；未执行测试，也未验证 PyPI 包、后端互操作性、运行开销或生产环境行为。
这个 Agent 能做什么，适合哪些场景？
OpenInference 是一套补充 OpenTelemetry 的语义约定、插桩库和跨度处理器，用于观测 AI 应用，而不是一个负责推理或自主执行任务的智能体。它为 LLM 调用、向量存储检索、外部工具和 API 使用等上下文定义可传输、与文件格式无关的追踪规范。仓库提供 Python、JavaScript、Java 和 Go 组件，并覆盖 OpenAI、Anthropic、LangChain、LlamaIndex、MCP、Bedrock、Vertex AI 等多种 SDK 与框架。应用运行时产生的跨度可发送到 Arize Phoenix、Arize AX 或任意兼容 OpenTelemetry 的收集器。它适合需要统一 AI 遥测数据的工程与运维团队，但采用时需要为所用语言、框架和观测后端选择并配置对应包。
应用引入对应的 OpenInference 插桩包后，插桩会围绕受支持的 SDK 或框架调用创建追踪数据，并按照 openinference-semantic-conventions 描述 LLM、Agent、Chain、Tool、检索和相关应用上下文。Python 的 openinference-instrumentation 提供可复用的工具、装饰器、配置和辅助函数；JavaScript 的 @arizeai/openinference-core 提供相应的基础能力；Java 和 Go 也包含语义约定与基础插桩库。针对 OpenAI SDK、OpenAI Agents SDK、Anthropic、Claude Agent SDK、LangChain、MCP、Bedrock、VertexAI、PydanticAI 等组件，仓库提供独立适配包。openinference-instrumentation-openlit 和 openinference-instrumentation-openllmetry 可通过跨度处理器规范化其他插桩库产生的数据。最终跨度由 OpenTelemetry 管道发送至 Phoenix、Arize AX 或其他兼容收集器。
- 运行多框架 LLM 服务的平台团队，希望用统一语义约定比较 OpenAI、Anthropic、Bedrock 和 Vertex AI 调用链。
- 构建 RAG 应用的工程师，需要把模型调用、向量检索及外部搜索或 API 工具放进同一条分布式追踪。
- 采用 LangChain、LlamaIndex、Haystack、PydanticAI 或 OpenAI Agents SDK 的开发团队，希望利用现成插桩包减少手工埋点。
- 已经使用 OpenLIT 或 OpenLLMetry 的可观测性团队，需要借助跨度处理器规范化现有追踪数据。
- 同时维护 Python、JavaScript、Java 或 Go 服务的组织，希望将 AI 遥测发送到同一个 OpenTelemetry 兼容后端。
- 开发 MCP 客户端或服务端集成的团队，需要对 MCP 活动进行 OpenInference 插桩。
这个 Agent 有哪些优点和局限？
- 规范与传输格式、文件格式解耦，并可配合任意 OpenTelemetry 兼容收集器，不局限于 Arize 后端。
- 同时覆盖 Python、JavaScript、Java 和 Go，并为大量模型提供商、智能体 SDK、RAG 框架和 MCP 提供专用插桩。
- 不仅追踪模型请求，还明确覆盖向量存储检索以及搜索引擎、API 等外部工具上下文。
- 提供 OpenLIT 与 OpenLLMetry 跨度处理器，可规范化其他插桩体系已经生成的追踪数据。
- 包含从初级到中级的多种框架示例，涉及流式响应、工具调用、交接、群聊与 RAG。
- 它是遥测规范和库集合，不提供模型推理、智能体编排或独立可运行的观测后端。
- 不同语言和框架需要选择独立包并完成 OpenTelemetry 导出配置，多技术栈环境会增加依赖与版本管理成本。
- 材料未提供 Python、JavaScript 或 Java 的统一可复制安装流程、最低运行时版本或端到端首次调用。
- Go 库明确要求 Go 1.25+，可能迫使使用旧版 Go 的项目升级工具链。
- 若迁移自其他追踪语义体系，可能需要跨度处理器或字段映射；材料没有量化转换的完整性及兼容边界。
如何安装或部署这个 Agent？
仓库没有给出覆盖所有语言和插桩包的统一安装命令。Python 包发布到 PyPI，JavaScript 包发布到 npm，Java 包发布到 Maven Central，但所给材料未列出可复制的 pip、npm 或 Maven 安装命令，也未说明这些语言的最低运行时版本。Go 组件要求 Go 1.25+，可按目标组件执行：go get github.com/Arize-ai/openinference/go/openinference-semantic-conventions；go get github.com/Arize-ai/openinference/go/openinference-instrumentation；go get github.com/Arize-ai/openinference/go/openinference-instrumentation-anthropic-sdk-go；或 go get github.com/Arize-ai/openinference/go/openinference-instrumentation-openai-go。还需要选择并配置 OpenTelemetry 导出器或兼容后端；材料没有列出 API 密钥名称或统一凭据配置。
如何使用这个 Agent？
先根据语言和实际 SDK 选择语义约定、基础库及专用插桩包，例如 Python 的 openinference-instrumentation-openai、JavaScript 的 @arizeai/openinference-instrumentation-anthropic、Java 的 openinference-instrumentation-langchain4j，或 Go 的 openinference-instrumentation-openai-go。然后把该插桩接入应用的 OpenTelemetry 跟踪管道，并配置跨度导出目标。支持的目的地包括 Arize Phoenix、Arize AX 和任意兼容 OpenTelemetry 的收集器；Go 示例说明可将 Phoenix 的 OTLP/HTTP 端点设为 http://localhost:6006/v1/traces。运行被插桩的模型、智能体、检索或工具调用后，后端接收符合 OpenInference 语义约定的跨度。除 Go 的获取命令与 Phoenix 端点示例外，材料没有提供一段适用于所有包的完整首次调用代码，也没有说明各托管服务所需凭据。
这个 Agent 与同类方案有什么区别？
与只接受特定厂商遥测格式的方案相比，OpenInference 的规范可连接任意 OpenTelemetry 兼容收集器。Arize Phoenix 和 Arize AX 是原生支持的目的地，但不是强制依赖。对于已经使用 OpenLIT 或 OpenLLMetry（Traceloop）的团队，OpenInference 提供跨度处理器来统一这些系统生成的数据，而不要求立即替换原有插桩。