金泉网做网站多少钱专业做域名的网站

金泉网做网站多少钱,专业做域名的网站,做视频网站资源采集,网站建设一般分为几个步骤本系列文章基于在多个项目中积累的Agent应用构建经验#xff0c;分享Agentic AI基础设施实践经验内容#xff0c;帮助您全面深入地掌握Agent构建的基本环节。上篇文章系统介绍了Agent质量评估相关内容。本篇文章将探讨Agent可观测性的核心要素、实现方式和最佳实践#xff0…本系列文章基于在多个项目中积累的Agent应用构建经验分享Agentic AI基础设施实践经验内容帮助您全面深入地掌握Agent构建的基本环节。上篇文章系统介绍了Agent质量评估相关内容。本篇文章将探讨Agent可观测性的核心要素、实现方式和最佳实践为您提供实用参考框架。引言当前正处在一个由AI Agent驱动的范式转换前夜。它们不再只是简单的文本生成器而是能够理解复杂指令、自主规划多步任务并调用各类API与数字世界交互的“数字工作者”在为大语言模型LLM增加“执行臂膀”后Agent正在成为企业应用中的“能力放大器”。过去监控传统微服务或Web应用时“Metrics→Logs→Traces”的可观测模型已足够应对。但在Agent场景它只能告诉用户“发生了什么”却无法解释“为什么会这样”——也无法指明“下一步该怎么办”。一旦将关键业务流程托付给Agent黑盒效应便迅速显现决策的“原因”为何Agent选择在此时发起特定调用它基于怎样的上下文与推理行为的“链条”在这次调用之前Agent是否已经与用户或其他工具反复交互这一步是解决方案的关键还是误入歧途的昂贵尝试结果的“质量”返回的内容是否真正提升了任务完成度还是引入了新的偏差或错误下文将结合Amazon Bedrock、Amazon Bedrock AgentCore、Amazon CloudWatch等原生能力构建一套从行为洞察到质量评估、从成本监控到闭环优化的多维度可观测框架。Agent可观测性详解Agentic AI可观测性是一个多维度的概念它不仅包括传统应用监控中的指标还需要特别关注AI特有的行为特征。在Agent系统中需要监控从用户输入到最终输出的整个处理流程包括模型调用、推理过程、工具使用等各个环节。这种全方位的监控能力使用户能够及时发现问题、优化性能、提升体验。对于Agent系统这里主要需要关注指标、追踪两方面。重要指标响应时间指标时间相关的指标是评估Agent性能的重要维度其中最关键的是以下几个指标总体请求处理时间TotalTime这个指标衡量了从接收用户请求到生成最终响应的完整时间。例如当用户询问“巴黎的天气如何”时系统可能需要500ms来理解问题300ms调用天气API再用200ms生成回答总计1000ms。监控这个指标可以帮助发现性能瓶颈优化响应速度。首个token生成时间TTFT这是衡量系统响应速度的关键指标它记录从请求开始到生成第一个响应token的时间。比如如果系统在接收到问题后能在200ms内开始生成回答这表明系统的初始响应速度较快。这个指标对于提供流式响应的系统特别重要。模型延迟ModelLatency专门衡量模型推理所需的时间。通过监控这个指标可以评估不同模型的性能表现为特定场景选择最适合的模型。Token使用指标Token使用情况直接关系到系统的运营成本和效率。输入Token数量InputTokenCount记录发送给模型的token数量。例如一个包含系统提示词、上下文历史和用户问题的请求可能使用了1000个token。这个指标帮助优化提示词设计和上下文管理策略。输出Token数量OutputTokenCount统计模型生成的token数量。比如一个详细的天气报告响应可能产生200个token。监控这个指标有助于控制响应的简洁度和成本。工具使用指标Agent系统中的工具调用情况也需要密切监控调用频率InvocationCount记录每个工具被调用的次数。例如在一个客服Agent中可能发现知识库查询工具的使用频率是订单查询工具的三倍这样的信息可以指导优化工具的设计和缓存策略。工具执行时间监控每个工具的执行耗时。比如如果发现天气API的平均响应时间超过800ms可能需要考虑更换更合适的模型或实施缓存机制。Agent追踪完整的执行链路视图在传统的可观测性三支柱中追踪Tracing对于Agent系统具有独特且至关重要的价值。与指标和日志相比追踪能够提供Agent决策过程的完整上下文链路这对于理解和优化AI系统的行为模式至关重要。传统指标虽然能够反映系统的健康状况和性能特征但无法解释Agent在特定情境下做出某个决策的原因。日志虽然提供了详细的事件记录但往往缺乏跨服务的关联性难以构建完整的执行图谱。而追踪数据通过span的层次化结构能够精确记录Agent从接收用户输入、理解意图、规划执行路径、调用工具、生成响应的完整决策链条。这种端到端的可见性使开发者能够快速定位性能瓶颈、识别错误根因并深入理解Agent的推理逻辑。根据Amazon X-Ray和OpenTelemetry的最佳实践Agent场景下的追踪数据不仅记录了“发生了什么”更重要的是揭示了“为什么这样发生”以及“各个组件之间如何相互作用”。具体而言Agent追踪系统需要关注以下几个核心维度Agent执行追踪提供完整的执行链路视图包括系统级追踪和推理周期追踪。系统级追踪记录每个请求的完整生命周期从用户输入、系统提示词到最终响应的全过程形成完整的执行图谱帮助理解Agent的决策过程。推理周期追踪则深入到每个推理步骤的细节详细记录当前思考步骤的内容、工具调用的决策过程以及中间结果的处理方式这些信息对于调试复杂的推理链特别有价值。错误和异常追踪系统中的错误和异常需要特别关注主要包括客户端错误和服务器错误两类。客户端错误记录由客户端引起的问题如参数错误、认证失败等这些信息帮助改进API设计和文档。服务器错误则追踪服务器端的异常情况如模型调用失败、资源不足等这类信息对于提升系统可靠性至关重要。而这些内容均可通过Opentelemerty协议记录并传输到后端以供分析。在OpenTelemetry的追踪体系中每个操作都有对应的span ID和trace ID这两个标识符构成了分布式追踪的核心骨架。Trace ID代表Agent执行循环中的一次完整会话从用户发起请求到Agent返回最终结果的整个生命周期都会共享同一个trace ID。而span ID则代表这个执行循环中的每个具体操作如模型调用、工具执行、上下文检索等每个span ID都是唯一的并通过父子关系构建起完整的执行树状结构。在Agent场景中一个trace包含了从用户输入到最终响应生成的所有中间步骤每个步骤都通过span来表示。Agent traces通常包含模型调用span和工具调用span这些span会根据其追踪的步骤类型被丰富的上下文信息所充实。图1Agent完整执行链路除了标准属性外OpenTelemetry还提供了baggage机制来传递自定义的跨服务元数据。Baggage是一种分布式上下文传播机制允许开发者在整个请求链路中传递业务相关的键值对信息。例如可以通过baggage传递用户类型、实验标识、会话主题等业务属性这些信息会自动附加到所有相关的span中为后续的离线评估、性能分析和A/B测试提供宝贵的上下文。通过合理使用baggage机制开发者可以实现更精细化的Agent行为分析和优化。图2OpenTelemetry span机制许多Agent框架已自带Opentelemetry支持但仍需要将Opentelemetry SDK嵌入应用中。对于采用Python开发的Agent可使用自动注入方式利用opentelemetry-instrument命令将SDK自动嵌入到应用中。这一命令会自动化配置流程从参数或环境变量中生成Opentelemetry配置并自动将SDK附加至Agent的内部、亚马逊云科技调用或其他的外部调用中。这样Agent的所有操作都会被Opentelemetry记录并传输到后端。下面是一段跟踪数据的样本{ name: chat, context: { trace_id: 0x68888fcdba6326c1fc004fe9396ad6a8, span_id: 0x4f4c5c4caf92a36d, trace_state: [] }, kind: SpanKind.CLIENT, parent_id: 0xbc776902450f8294, start_time: 2025-07-29T09:09:33.427326Z, end_time: 2025-07-29T09:09:34.932205Z, status: { status_code: OK }, attributes: { session.id: session-1234, gen_ai.event.start_time: 2025-07-29T09:09:33.42734200:00, gen_ai.system: strands-agents, gen_ai.operation.name: chat, gen_ai.request.model: us.anthropic.claude-3-5-haiku-20241022-v1:0, gen_ai.event.end_time: 2025-07-29T09:09:34.93217300:00, gen_ai.usage.prompt_tokens: 443, gen_ai.usage.input_tokens: 443, gen_ai.usage.completion_tokens: 76, gen_ai.usage.output_tokens: 76, gen_ai.usage.total_tokens: 519 }, events: [ { name: gen_ai.user.message, timestamp: 2025-07-29T09:09:33.427368Z, attributes: { content: [{\text\: \Research and recommend suitable travel destinations for someone looking for China traditional culture experience in Beijing city. \\nUse web search to find current information about venues, \\nevents, and attractions.\}] } }, { name: gen_ai.choice, timestamp: 2025-07-29T09:09:34.932167Z, attributes: { finish_reason: tool_use, message: [{\text\: \Ill search for the best traditional cultural experiences in Beijing.\}, {\toolUse\: {\toolUseId\: \tooluse_JSt-cJ9fRU28RmhdJ1XENA\, \name\: \web_search\, \input\: {\query\: \Top traditional cultural attractions and experiences in Beijing 2024\}}}] } } ], links: [], resource: { attributes: { telemetry.sdk.language: python, telemetry.sdk.name: opentelemetry, telemetry.sdk.version: 1.33.1, service.name: agentic-travel-strands, telemetry.auto.version: 0.10.0-aws, aws.local.service: agentic-travel-strands, aws.service.type: gen_ai_agent }, schema_url: }}左右滑动查看完整示意从这个示例中可以看到Strands Agents框架已经内置了对OpenTelemetry的深度集成支持。根据Strands官方文档该框架遵循OpenTelemetry生成式AI语义约定会自动将Agent的内部决策过程以标准化的事件event形式发送至追踪后端。这种自动化的遥测数据收集机制大大简化了Agent应用的可观测性实现开发者无需手动编写复杂的追踪代码即可获得生产级别的监控能力。Strands Agents的OpenTelemetry集成特别针对生成式AI工作负载进行了优化能够自动捕获Agent执行过程中的关键信息包括用户消息、系统提示词、模型推理结果、工具调用参数和返回值等。每个操作都会被封装为符合OpenTelemetry语义约定的span并通过Baggage机制自动添加相应的属性标签。从上面的示例中可以看到常用的元数据包括session.id会话标识符、gen_ai.systemAI系统标识如strands-agents、gen_ai.operation.name操作名称如chat、gen_ai.request.model请求的模型名称以及各种token使用统计信息这些元数据对于后续的数据分析和问题诊断至关重要。这些标准化的属性遵循OpenTelemetry生成式AI语义约定确保了不同Agent框架和监控系统之间的互操作性。默认情况下Agent应用产生的遥测数据会通过OTLPOpenTelemetry Protocol协议直接发送到Amazon CloudWatch的OTLP端点这种直连方式简化了部署架构减少了额外的基础设施维护成本。然而在生产环境中为了实现更灵活的数据处理和路由策略通常会在数据源和目标系统之间部署OpenTelemetry Collector作为中间处理层。OpenTelemetry Collector是一个功能强大的独立服务组件专门用于接收、处理和导出遥测数据到多个目标系统。其架构采用了管道化设计包含三个核心组件Receivers接收器负责从各种数据源收集遥测数据Processors处理器对数据执行转换、过滤、采样、属性增删等操作Exporters导出器将处理后的数据发送到指定的后端系统在Agent可观测性场景中Collector的处理器组件尤其有价值。例如可以使用attributes处理器为特定的Agent span添加环境标签或业务标识使用sampling处理器对高频操作进行智能采样以控制数据量使用filter处理器过滤掉敏感信息或无关数据使用batch处理器优化网络传输效率。这种流水线式的数据处理能力使企业能够根据具体需求定制化Agent遥测数据的收集和分发策略实现成本效益的最优平衡。实践方式开源生态以及亚马逊云科技托管方案理解了Agent可观测性的核心概念和关键指标后现在需要将这些理论转化为实际的技术实现。亚马逊云科技为Agent可观测性提供了完整的托管解决方案同时开源社区也贡献了丰富的第三方工具。下文将详细探讨如何在不同的技术栈和部署环境中实现Agent的全方位监控。Amazon Cloudwatch生成式AI ObservabilityAmazon Cloudwatch生成式AI Observability专门用于监控生成式AI工作负载包括Amazon Bedrock AgentCore Runtime。它提供1.端到端提示词跟踪End-to-end prompt tracing跟踪AI Agent的所有行为包含大模型推理和工具调用2.预配置仪表盘提供两个内置仪表盘Model Invocations详细的模型使用、token消耗和成本指标Amazon Bedrock AgentCore agentsAgent的性能和决策指标3.关键指标监控总调用次数和平均调用次数Token使用情况总数、每查询平均数、输入、输出延迟平均值、P90、P99错误率和限流事件按应用程序、用户角色或特定用户的成本归因生成式AI Observability的核心是Amazon Cloudwatch Transation Search生成式AI Observability利用Cloudwatch Transation Search收集并转换的结构化日志进行AI工作负载的深度分析。亚马逊云科技在现有X-ray跟踪服务的基础上推出了Amazon CloudWatch Transaction Search。Transaction Search最核心的创新在于其双重存储策略这一设计巧妙地平衡了成本效益与数据完整性。当用户启用Transaction Search时所有发送到X-Ray的spans都会被自动转换为语义约定格式semantic convention format并以结构化日志的形式存储在Amazon CloudWatch Logs的专用日志组aws/spans中。这个转换过程完全透明spans会自动采用W3C trace ID标准确保与OpenTelemetry系统的完整兼容性。每个span都包含完整的追踪信息开始时间、结束时间、持续时间以及丰富的元数据包括业务属性如客户ID、订单ID等。这些数据全部可以进行搜索和分析完全消除了传统采样带来的“盲区”问题。Transaction Search提供的搜索能力远超传统X-Ray的范畴。通过可视化编辑器用户可以基于任意span属性进行搜索包括服务名称、span持续时间、状态码以及自定义的业务属性。系统支持多种查询格式List格式专注于单个span的详细分析特别适合故障排查。当出现问题时工程师可以直接使用对应的业务ID快速定位相关的trace然后深入分析具体的执行路径。Group analysis格式提供聚合分析能力可以按照可用区、状态码或客户ID等维度进行分组统计快速识别影响面最大的问题。对于熟悉SQL的用户Transaction Search还支持Amazon CloudWatch Logs Insights查询语言提供更灵活的数据分析能力。在Amazon Bedrock AgentCore Runtime上集成Cloudwatch生成式AI ObservabilityAmazon Bedrock AgentCore Observability在Amazon Cloudwatch生成式AI Observability的基础上为Amazon Bedrock AgentCore Runtime上运行的Agent提供更便捷的可观测性体验。在基础设施层面AgentCore Runtime会自动创建和配置所需的Amazon CloudWatch日志组如/aws/bedrock-AgentCore/runtimes/agent_id-endpoint_name/runtime-logs自动处理IAM权限并预配置好OTEL环境变量应用只需添加Opentemeletry SDK即可使用无需配置任何参数或环境变量。AgentCore为不同资源类型提供差异化的默认观测能力Agent资源的指标可以在生成式AI Observability页面直接查看AgentCore自动提供针对Agent运行时的丰富指标如InvocationsAPI请求总数、Session CountAgent会话总数、细分的错误类型统计InvocationError.Validation、InvocationError.Internal等以及跨所有资源的聚合指标。而Memory、Gateway、Tools资源的指标、spans和logs会自动路由到相应的Amazon CloudWatch组件中。特别是Memory资源AgentCore提供了独特的深度可观测性包括Creation Count内存事件创建数量、Memory特定的延迟指标以及专门的工作流日志提取日志和整合日志。本文提供基于Jupyter Notebook的快速使用指导帮助您快速在Amazon Bedrock AgentCore Runtime上部署一个AI Agent并从Amazon Bedrock AgentCore Observability上观测Agent的运行状况您可以参阅下方链接获取此快速使用指导。快速使用指导https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/01-tutorials/06-AgentCore-observability/01-Agentcore-runtime-hosted在其他计算服务上集成Amazon Cloudwatch生成式AI Observability对于选择在自建运行环境如Amazon EC2、Amazon EKS、Amazon Lambda等部署Agent但仍希望使用Amazon CloudWatch生成式AI Observability能力的组织可以通过标准的OpenTelemetry集成来实现。您可以在软件包管理器中安装ADOT SDK依赖将SDK注入到Agent代码中配置详细的OTEL环境变量后即可将可观测性数据上送至Amazon Cloudwatch。Amazon CloudWatch生成式AI Observability的体验与AgentCore一致您同样可以基于Trace和Span进行查询但无法使用Amazon Bedrock AgentCore Observability的指标面板需要您自行创建。本文提供基于Jupyter Notebook的快速使用指导帮助您在本地运行基于Strands框架的AI Agent并从Amazon Cloudwatch生成式AI Observability上观测Agent的运行状况您可以参阅下方链接获取此快速使用指导。快速使用指导https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/01-tutorials/06-AgentCore-observability/02-Agent-not-hosted-on-runtimeMLFlow、Langfuse等第三方组件除了Amazon Cloudwatch生成式AI Observability许多开源第三方工具例如Langfuse、MLFlow也作为观测数据的分析系统。可以提供包括数据可视化和分析界面执行边缘案例分析评估准确性和成本的权衡分析用户交互模式提供性能优化建议。以Amazon SageMaker托管的MLFlow 3.0进行Agent开发中的Tracing为例通过全托管MLflow 3.0的追踪能力开发者可以记录请求每个中间步骤关联的输入、输出和元数据从而准确定位错误根源和意外行为的来源。以下示例代码展示了使用Strands Agents来构建一个基本的Agent工作流及使用MLFlow来对其中间环节进行追踪。mlflow.trace(name strands-bedrock, attributes{k: v}, span_typeSpanType.LLM)def get_model():... mlflow.trace(name strands-agent, attributes{k: v}, span_typeSpanType.AGENT)def create_agent(model):... mlflow.trace(name strands-chain, attributes{k: v}, span_typeSpanType.CHAIN)def run_agent(): model get_model() agent create_agent(model) return agent(Hi, where can I eat in San Francisco?) with mlflow.start_run(run_nameStrandsAgentRun): results run_agent()左右滑动查看完整示意这些能力通过捕获工作负载服务、节点和工具执行的详细信息为您的AI工作负载提供可观测性。可以在MLFlow Tracking Server前端的Trace选项卡中查看这些完整记录的执行信息。见如下示例图3MLFlow trace页面同时对于使用Amazon Bedrock AgentCore执行环境的Agent工作流来说可以直接利用其集成至Amazon CloudWatch中的生成式AI Observability能力直接获取整个Agent调用链的轨迹信息见以下基于AgentCore进行Strands Agents搭建的调试示例。图4Amazon CloudWatch生成式AI Observability页面除了MLFlow之外也可使用其他可观测性系统例如Langfuse是一个专为LLM应用设计的开源可观测性系统提供了完整的追踪、评估和分析能力。它支持多种LLM框架的集成能够自动捕获Agent的执行轨迹、token使用情况和成本信息并通过直观的Web界面展示这些数据帮助开发者快速识别性能瓶颈和优化机会。利用可观测性组件运维Agent此部分将以基于Strands Agents构建的电商售后智能客服为例展示如何在应用开发和生产迭代的过程中遇到的多个场景使用可观测性组件进行运维。示例环境可根据workshop进行创建创建资源包括一个含有订单数据表格并通过api gateway对外暴露的电商系统和一个通过网页交互的电商售后智能客服应用智能客服Agent应用通过添加多个MCP servers其中包括调用电商系统的API Gateway接口的工具来实现对电商系统中的订单进行查询并按照售后流程定义规则进行处理的功能。以下为智能客服的页面截图支持添加丰富的MCP servers选择不同的LLM模型。图5Agent应用客户端界面以上应用在开发阶段会在前端页面显示所有的模型和工具调用信息在实际生产环境中基于数据安全应该在前端隐去。此时则可以将Agent的追踪数据打入到Langfuse进行监控来保证重要指标的收集和功能异常的分析。模拟新模型发布针对不同的LLM进行效果和成本对比测试使用两个不同的user对相同的问题进行测试在Langfuse中观察到不同的Latency、Token和Cost可以观察到Claude 3.7和Amazon Nova Lite分析过程和对工具的调用次数上一致Claude 3.7在成本上更有优势而Amazon Nova Lite则在成本上更有优势。图6使用Langfuse对模型分析对比模拟模型混用、网关智能路由的场景假设基于测试结果团队希望使用Amazon Nova Lite为主要模型Claude 3.7为备用模型对话过程中交替切换LLM来进行充分测试发现出现错误。图7Agent客户端错误示例从Langfuse页面可以快速定位到历史对话采用Claude 3.7模型和当前切换的Amazon Nova Lite模型的信息格式不一致导致调用出错。基于此类的追踪分析可以针对性地快速解决开发迭代和生产中遇到的问题。图8使用Langfuse分析错误日志模拟新功能上线分析功能调用全流程售后客服扩展功能为不同卖家提供数据查询功能应用后端通过Mysql MCP server接入电商系统数据库。以数据查询“查询今年销售额最高的3个客户”为例虽然两种模型都可以完成查询通过调用流程可以看到Claude 3.7对数据查询语句的生成思考更严谨更适合用在数据分析的场景。图9使用Langfuse分析调用全流程总结随着AI Agent在企业应用中扮演越来越重要的角色建立完善的可观测性体系已成为确保其可靠运行的关键基础设施。本文探讨了Agent可观测性的核心要素、实现方式和最佳实践为开发团队提供了一个实用的参考框架详细介绍了亚马逊云科技为Agent可观测性提供的完整解决方案。通过Amazon CloudWatch生成式AI Observability和Amazon Bedrock AgentCore Observability团队可以快速获得对Agent系统的全面洞察无需搭建复杂的基础设施。这些服务与OpenTelemetry的深度集成不仅确保了与开源生态的互操作性更为后续的分析和优化提供了坚实基础。建议您从访问Amazon Bedrock控制台开始体验Amazon CloudWatch生成式AI Observability的监控能力并参考本文提供Agent Observability示例代码将Agent应用接入这些服务。在Amazon Web Services Sample仓库中还有更多资源供您参考。Amazon Bedrock控制台https://console.aws.amazon.com/bedrockAgent Observability示例代码https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/01-tutorials/06-AgentCore-observabilityAmazon Web Services Sample仓库https://github.com/aws-samples/sample-agentic-platform随着AI Agent在企业应用中的广泛部署可观测性已经从“锦上添花”的辅助工具转变为“不可或缺”的核心能力。传统的监控方式虽然能够告诉用户系统的运行状态但面对Agent的复杂决策链条和多步推理过程用户需要更深层次的洞察能力。通过本文介绍的多维度可观测性框架用户不仅能够监控Agent的性能指标和资源消耗更重要的是能够理解Agent的“思考过程”——从意图理解到工具调用从推理链条到最终输出的完整决策轨迹。亚马逊云科技提供的Amazon CloudWatch生成式AI Observability和Amazon Bedrock AgentCore等托管服务结合开源生态中的MLFlow、Langfuse等工具为企业构建Agent可观测性提供了完整的技术栈支持。无论是选择全托管的便捷方案还是基于开源工具的灵活定制企业都能找到适合自身需求的实施路径。在AI Agent成为企业数字化转型重要推动力的今天建立完善的可观测性体系不仅是技术需要更是业务成功的关键保障。只有真正“看见”和“理解”Agent的行为才能充分释放其潜力让AI真正成为企业的智能助手和效率倍增器。本篇作者于昺蛟亚马逊云科技现代化应用解决方案架构师负责亚马逊云科技容器和无服务器产品的架构咨询和设计。在容器服务的建设和运维、应用现代化、DevOps等领域有多年经验致力于容器技术和现代化应用的推广。杜晨曦亚马逊云科技解决方案架构师负责基于亚马逊云科技云计算方案架构的咨询和设计在国内推广亚马逊云科技云服务技术和各种解决方案。郑昊亚马逊云科技人工智能与机器学习解决方案架构师。主要专注于基础模型的训练、推理及性能优化广告、排序算法等及其基于亚马逊云科技人工智能与机器学习技术栈的相关优化及方案构建。穆迪亚马逊云科技产品分析师负责深入研究和评估亚马逊云科技的云与AI产品。密切关注主流产品的产品策略、技术创新以及市场动向,以确保亚马逊云科技能够保持竞争优势。富宸亚马逊云科技生成式AI解决方案技术专家负责生成式AI各个方向解决方案的设计和推广。曾进行AI应用技术研究工作在计算机视觉以及多模态领域有丰富的应用落地经验。往期精彩内容re:Invent 2025中国行火热进行中即刻点击小程序卡片抢占席位↓↓↓新用户注册海外区域账户可获得最高200美元服务抵扣金覆盖Amazon Bedrock生成式AI相关服务。“免费计划”账户类型确保零花费安心试用。星标不迷路开发更极速关注后记得星标「亚马逊云开发者」听说点完下面4个按钮就不会碰到bug了点击阅读原文查看博客获得更详细内容