北京
框架碎片化带来的评测困境
构建生产级智能体的AI团队正面临一种令人沮丧的不对称：智能体框架的多样性持续增长，但评测工具却没有跟上。大多数评测系统都假设你是以特定方式构建智能体的——特定的SDK、特定的大语言模型客户端、特定的追踪模式。一旦你跨出这个狭窄的兼容区域，评测流水线就会断裂。
团队在LangGraph上构建是为了其工作流编排模型，在LlamaIndex上构建是为了其与检索流水线的紧密集成，在OpenAI Agents SDK上构建则是因为组织在GPT模型上做了标准化。他们使用Google ADK进行多智能体协调，或使用Claude Agent SDK来获得Anthropic的原生能力。他们选择Strands Agents，是因为其模型驱动的循环能在几分钟内、而不是几天内，在Amazon Bedrock AgentCore上跑起一个可用的智能体。
越来越多团队将所有这些框架部署在Amazon Bedrock AgentCore运行时上，这是Amazon Bedrock AgentCore的一项能力。它处理了托管、扩展、内存和可观测性基础设施，否则这些工作每个项目都要重新搭建一遍。
评测与框架选择解耦
Amazon Bedrock AgentCore评测服务通过将评测与框架选择解耦，解决了这种碎片化问题。每个主流框架都支持OpenTelemetry，无论是原生支持还是通过社区插桩库实现。只要智能体的遥测数据流经OpenTelemetry，评测服务就能为其打分，无论底层是什么SDK。
这篇文章解释了其工作原理：服务读取哪些遥测数据、它如何决定读取你的span、哪些属性携带评测数据，以及覆盖范围如何扩展到已命名列表之外的框架。
OpenTelemetry作为通用语言
OpenTelemetry是一个厂商中立的插桩框架，标准化了分布式系统如何发出trace、指标和日志。一个trace是一棵span树，每个span代表请求中的一个步骤：一个带有名称、时间戳、一组类型化属性和可选span事件的工作单元。Span通过OpenTelemetry协议导出，并由遥测后端收集。
在AgentCore运行时上，这个后端是AWS Distro for OpenTelemetry，它将span和事件记录路由到Amazon CloudWatch。一个智能体的执行会产生多种span，因为智能体会做多种工作。单个用户回合可以生成用于模型调用、工具调用、从向量存储或数据库检索文档、对检索结果重排、嵌入生成、护栏检查、提示模板渲染、内存读写以及将它们连接起来的编排步骤的span。
两个约定明确命名了这些操作：OpenTelemetry GenAI约定定义了诸如chat、embeddings、retrieval、execute_tool、invoke_agent、create_agent、plan以及一系列内存操作。OpenInference定义了诸如LLM、TOOL、RETRIEVER、RERANKER、EMBEDDING、AGENT、CHAIN等span类型。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
